Subject: [tsvwg] RFC 4594 update: Audio class - consensus check

From: "Black, David" <[email-masked]>
Date: Fri, 15 Mar 2013 08:35:40 -0400

The discussion of the Audio service class in the RFC 4594 update
draft in the tsvwg meeting yesterday reached a couple of initial
conclusions that need to be checked on the list:

(1) The class is being renamed from "Telephony" to "Audio", in part
because "Telephony" is interpreted to include video in some contexts
and that's not intended here.  There have also been some slight
changes/generalizations to the description.

(2) The newly-standardized Voice-Admit PHB is being added to the
Audio class.

In the absence of objection on the list, these directions will be
confirmed as the rough consensus of the tsvwg WG - please comment.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 15 Mar 2013 14:16:20 +0000

> (2) The newly-standardized Voice-Admit PHB is being added to the

I support that.

Francois

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 15 Mar 2013 10:26:10 -0400

I support it. (and I was in the room)

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   "Black, David" <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Date:   03/15/2013 08:36 AM
Subject:        [tsvwg] RFC 4594 update: Audio class - consensus check
Sent by:        [email-masked]

Thanks,
--David

---

From: <[email-masked]>
Date: Mon, 18 Mar 2013 16:45:22 +0100

I don't object to broadening the name of a service class. As mentioned earlier,
I don't like transport QoS classes being named close to applications. So
weak objections against (1).

Brian Carpenter didn't seem to favor (2) prior to the meeting. I personally think,
classes Priority (here: audio) and Bulk Inelastic require admission control
in access networks or some kind of TE in backbone sections. So to me EF
already requires admission control and I don't think another PHB with
otherwise identical properties adds a lot of value. But well, that's my view.
Could an argument be given why Voice-Admit is required? I hope that has been
discussed during the meeting.

Regards,

Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Friday, March 15, 2013 1:36 PM
To: [email-masked]
Subject: [tsvwg] RFC 4594 update: Audio class - consensus check

Thanks,
--David

---

From: "Black, David" <[email-masked]>
Date: Mon, 18 Mar 2013 12:56:20 -0400

> discussed during the meeting.

See RFC 5865, starting with its Section 1.2 .

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 18, 2013 11:45 AM
> To: Black, David
> Cc: [email-masked]
> Subject: RE: RFC 4594 update: Audio class - consensus check
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Mar 2013 16:55:32 -0700

Audio is a horrible name; the requirements for Pandora are completely 
different from Skype.

Maybe "audio interactive" (vs. audio streaming)?

Joe

---

From: <[email-masked]>
Date: Tue, 19 Mar 2013 08:50:11 +0100

There's still a possibility of decoupling class names from applications.

pro: we don't run into problems like the one described by Joe.
con: nobody can imagine what that class would be good for by just
     reading the name. Readers must be educated.

The application decoupled class name I've suggested is "Priority".

Regards,

Rüdiger

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 12:56 AM
To: Geib, Rüdiger
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] RFC 4594 update: Audio class - consensus check

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 07:06:25 -0700

IMO, QOS classes ought to describe differential service _to_ the user, 
whereas PHB ought to describe differential capabilities available _from_ 
the network.

Yes, a (slowly evolving and updated) mapping between typical 
applications and QOS classes is useful, as advice to users as to what to 
"ask" for from the network.

As is a much more static mapping that explains how PHBs can be utilized 
to provide the various QOS classes.

It seems odd to explain this, however - I thought this was 
well-understood in the QOS community.

Joe

---

From: James Polk <[email-masked]>
Date: Tue, 19 Mar 2013 15:16:11 -0500

At 10:45 AM 3/18/2013, [email-masked] wrote:
>otherwise identical properties adds a lot of value.

Having EF marked traffic requiring admission 
controls in the core is very different than 
having EF marked traffic require admission 
controls everywhere. In fact, this is exactly the 
opposite view in all (if not 100%, only 1 or 2% 
off 100%) enterprise, Small/Medium Businesses 
(SMB) and residential environments.

The expedited forwarding codepoint that has 
admission control as part of its specification is 
"Voice-Admit" (101100), per RFC 5865 - thus, as 
someone stated before, having two codepoints with 
identical PHBs is redundant and should be avoided.

>But well, that's my view.

It has. It is an RFC from this WG. Please review 
RFC 5865. It's the singular purpose topic of that 
RFC. Given that DSCP and PHB already exist, where 
do they go in the service classes, in a new 
service class, or the one shared with Audio?

James

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Black, David

---

From: James Polk <[email-masked]>
Date: Tue, 19 Mar 2013 15:30:45 -0500

At 06:55 PM 3/18/2013, Joe Touch wrote:
>Audio is a horrible name; the requirements for 
>Pandora are completely different from Skype.

Pandora... as in the music service?

If so, then I agree with you - the requirements 
of a (bufferable) music service are clearly 
different than a two way realtime interactive service.

>Maybe "audio interactive" (vs. audio streaming)?

Audio is already in an interactive group. The 
draft calls the group "conversational", and includes the

         Realtime-Interactive service class,
         Video service class
         Hi-Res (I've admitted this is a bad name) service class

Audio streaming is covered within

         Broadcast service class, for non-buffered streams, and
         Multimedia-Streaming, for buffered streams

The "streaming" service classes are in RFC 4594.

James

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 19 Mar 2013 20:35:57 +0000

works for me

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 19 Mar 2013 20:37:01 +0000

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Tuesday, March 19, 2013 4:36 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [tsvwg] RFC 4594 update: Audio class - consensus check

works for me

---

From: James Polk <[email-masked]>
Date: Tue, 19 Mar 2013 15:38:34 -0500

>The application decoupled class name I've suggested is "Priority".

Nitpicking - that sends the wrong message, as 
DiffServ is *not* a priority service, it is a 
differentiated service. Brian C. is quick to point this out...

James

> > Brian Carpenter didn't seem to favor (2) 
> prior to the meeting. I personally think,

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 13:41:46 -0700

> Pandora... as in the music service?

Yeah - I was picking an example out of a hat...

> If so, then I agree with you - the requirements of a (bufferable) music
> service are clearly different than a two way realtime interactive service.
>
> Audio is already in an interactive group. The draft calls the group
> "conversational", and includes the
>

In that case a new class for audio isn't needed.

Though "realtime interactive" sounds like it could include voice, voice 
& video, and gaming - which aren't quite the same service class, IMO.

Joe

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 19 Mar 2013 20:53:22 +0000

I was unable to attend twvwg at IETF 86 as it competed with a meeting I presented in. I am told that there was a presentation in which folks argued against having a class of traffic for routing traffic. I'd like to comment on that.

The origin of a class of traffic for routing traffic was a bug. The Cisco 7000 had an issue with its offloaded forwarding cards, of which it had two. When there was a route flap, it blew away the route cache and then rebuilt it in response to traffic it needed to forward. In that implementation, that meant that the Route Processor (the CPU) suddenly had all traffic from all sources flooded into it. The impact of that was to make it very difficult for the RP to actually re-populate the Route Cache. Doubleplus ungood. The work-around was to rate-limit traffic from the line cards to the RP. However, rate limiting the routing traffic worked against getting routing to stabilize, so we marked routing traffic, and did not rate limit *it* from going to the RP.

Fast forward nearly 20 years. We don't have that bug anymore, if anything because nobody equipped with a right mind uses the Cisco 7000 any more.

However...

If we're going to discuss quality of service for any application, we are making some fundamental assumptions. These include the concept of having enough bandwidth and so on; we're managing traffic at points in time when peak traffic loads on a millisecond scale create issues. One of those fundamental issues is that routing must be current; if we're sending traffic on a route that loops because the other guy updated his route table but we didn't, or vice versa, or for which interface or next hop router is no longer there, we can discuss jitter, rate, and loss to our heart's content - the application's traffic isn't going to get there. At. All. And won't until routing stabilizes.

The fundamental argument for a class of traffic for routing in 2013 is not that routing requires certain jitter, rate, or etc characteristics; it is that routing traffic (apart from AQM issues, see separate discussion on [email-masked]) should simply *not*be*dropped* in the normal course of business. Routing is fundamental to all other services the network delivers, including QoS, and including every networks's SLAs. 

Now, one can say that routing is between neighboring nodes, and a router is able to do special things with traffic it itself originates. It is true that a router can do special things with its own traffic, and they do. But BGP Routing frequently goes from Route Arbiter to Route Arbiter instead of Router to Router, which is to say through other routers between routing engines. Traffic through other routers is traffic through other routers, not a router's own traffic. It requires some form of end to end marking to protect it. Something like a DSCP.

---

From: James Polk <[email-masked]>
Date: Tue, 19 Mar 2013 16:21:25 -0500

Joe

Audio is *not* a new service class, we're just 
proposing a name change of the existing Telephony 
service class, and removing the recommendation 
that video traffic be marked the same as audio 
traffic - which few networks currently do, even 
in the core/interconnect (unless of course both are marked as best effort).

>Though "realtime interactive" sounds like it 
>could include voice, voice & video, and gaming - 
>which aren't quite the same service class, IMO.

It's not, as gaming (still recommended in 
"realtime interactive" service class) is mostly 
TCP based, and we don't want to place TCP based 
anything in the same service class or queue with realtime UDP traffic.

James

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 14:27:31 -0700

> At 03:41 PM 3/19/2013, Joe Touch wrote:
...
>> Though "realtime interactive" sounds like it could include voice,
>> voice & video, and gaming - which aren't quite the same service class,
>> IMO.
>
> It's not, as gaming (still recommended in "realtime interactive" service
> class) is mostly TCP based, and we don't want to place TCP based

Gaming widely uses UDP. See a good example here:

https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711

http://www.practicallynetworked.com/sharing/app_port_list.htm

Note how many games use *only* UDP.

Joe

---

From: James Polk <[email-masked]>
Date: Tue, 19 Mar 2013 16:42:29 -0500

>Note how many games use *only* UDP.

Fair point. I wasn't claiming gaming only uses TCP, but that there 
were a fair amount of gaming apps that use TCP, and I was making the 
comment from the perspective of "let's not stuff audio and video into 
that service class as well if we don't have to, and we don't have to".

James

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 19 Mar 2013 23:01:16 +0000

On Mar 19, 2013, at 1:38 PM, James Polk <[email-masked]> wrote:

> Nitpicking - that sends the wrong message, as DiffServ is *not* a priority service, it is a differentiated service. Brian C. is quick to point this out...

More than a nitpick. This is actually important.

Priority is the name of a scheduler, not a service. I'm will enough to have the service decoupled from audio, but if we do, it would be better to identify the characteristics of the service in the name, not one of them in the absence of the others. The characteristics are that it limits jitter (the effect of a priority scheduler) for a limited amount of data (if you exceed the amount of data, it discards the excess).

I suspect that calling it "priority" will have every idiot on the planet trying to use it for his or her pet application without regard to the service it offers or what their application's specific needs are.

---

From: "Black, David" <[email-masked]>
Date: Tue, 19 Mar 2013 22:40:03 -0400

Hi Fred,

> I was unable to attend tsvwg at IETF 86 as it competed with a meeting I
> presented in. I am told that there was a presentation in which folks argued
> against having a class of traffic for routing traffic. I'd like to comment on
> that.

The argument in particular is about whether a class of traffic is needed for
Routing traffic across an interconnection of two carrier networks.

The argument was teed up for discussion in this slide presented in connection
with draft-geib-tsvwg-diffserv-intercon-02:

http://www.ietf.org/proceedings/86/slides/slides-86-tsvwg-5.pptx

Thank you for the comments,
--David

> Sent: Tuesday, March 19, 2013 4:53 PM
> To: [email-masked]
> Subject: [tsvwg] RFC 4594 update: Routing class
> 
> I was unable to attend twvwg at IETF 86 as it competed with a meeting I
> presented in. I am told that there was a presentation in which folks argued
> against having a class of traffic for routing traffic. I'd like to comment on
> that.
> 
> The origin of a class of traffic for routing traffic was a bug. The Cisco 7000
> had an issue with its offloaded forwarding cards, of which it had two. When
> there was a route flap, it blew away the route cache and then rebuilt it in
> response to traffic it needed to forward. In that implementation, that meant
> that the Route Processor (the CPU) suddenly had all traffic from all sources
> flooded into it. The impact of that was to make it very difficult for the RP
> to actually re-populate the Route Cache. Doubleplus ungood. The work-around
> was to rate-limit traffic from the line cards to the RP. However, rate
> limiting the routing traffic worked against getting routing to stabilize, so
> we marked routing traffic, and did not rate limit *it* from going to the RP.
> 
> Fast forward nearly 20 years. We don't have that bug anymore, if anything
> because nobody equipped with a right mind uses the Cisco 7000 any more.
> 
> However...
> 
> If we're going to discuss quality of service for any application, we are
> making some fundamental assumptions. These include the concept of having
> enough bandwidth and so on; we're managing traffic at points in time when peak
> traffic loads on a millisecond scale create issues. One of those fundamental
> issues is that routing must be current; if we're sending traffic on a route
> that loops because the other guy updated his route table but we didn't, or
> vice versa, or for which interface or next hop router is no longer there, we
> can discuss jitter, rate, and loss to our heart's content - the application's
> traffic isn't going to get there. At. All. And won't until routing stabilizes.
> 
> The fundamental argument for a class of traffic for routing in 2013 is not
> that routing requires certain jitter, rate, or etc characteristics; it is that
> routing traffic (apart from AQM issues, see separate discussion on
> [email-masked]) should simply *not*be*dropped* in the normal course of business.
> Routing is fundamental to all other services the network delivers, including
> QoS, and including every networks's SLAs.
> 
> Now, one can say that routing is between neighboring nodes, and a router is
> able to do special things with traffic it itself originates. It is true that a
> router can do special things with its own traffic, and they do. But BGP
> Routing frequently goes from Route Arbiter to Route Arbiter instead of Router
> to Router, which is to say through other routers between routing engines.
> Traffic through other routers is traffic through other routers, not a router's
> own traffic. It requires some form of end to end marking to protect it.
> Something like a DSCP.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2013 08:10:52 +0000

On 19/03/2013 20:38, James Polk wrote:
> Nitpicking - that sends the wrong message, as DiffServ is *not* a
> priority service, it is a differentiated service. Brian C. is quick to
> point this out...

Now I don't need to ;-)

   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2013 08:17:47 +0000

> Routing traffic across an interconnection of two carrier networks.

What am I missing? It seems blindingly obvious that the answer is yes
and that this is what CS6 and CS7 were intended for. Quoting RFC2474,
"  In addition, PHBs selected
   by codepoints '11x000' MUST give packets a preferential forwarding
   treatment by comparison to the PHB selected by codepoint '000000' to
   preserve the common usage of IP Precedence values '110' and '111' for
   routing traffic."

      Brian

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 20 Mar 2013 11:34:31 +0100

James, Joe,

My two cents about online games traffic.

We have two things here:

- Game genres: First Person Shooters, MMORPGs, Real-time Strategy, Racing
- TCP or UDP usage

A short summary:

- First Person Shooters always use UDP (as far as I know). You have to shoot
and move really fast, so TCP is not an option. They implement loss
concealment algorithms. For example, Quake III can work with 35% packet
loss. FPS players will be angry with delays over 50ms.

- MMORPG almost always use TCP: For example, World of Warcraft uses TCP, and
it had 12 million players. However, some of them use UDP. MMORPG players can
tolerate 150 or 200 ms.

- Real-time strategy (RTS) can use either TCP or UDP. Since they don't have
really tight interactivity requirements, TCP could be suitable, but some of
them use UDP (e.g. 0 Anno Domini). RTS can tolerate up to 1 second.

- Racing games: The only one I have studied uses UDP (Auto Club Revolution)

My conclusions:
- The game genre determines the delay requirements. 
- Perhaps we cannot put together all the game genres
- The genre and the protocol (TCP/UDP) should be considered "orthogonal".
Otherwise things will get very complicated

Best regards,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de
> James Polk
> Enviado el: martes, 19 de marzo de 2013 22:42
> Para: Joe Touch
> CC: [email-masked]
> Asunto: Re: [tsvwg] RFC 4594 update: Audio class - consensus check
> 
> >>>voice & video, and gaming - which aren't quite the same service
> >>>class, IMO.
> >>
> Fair point. I wasn't claiming gaming only uses TCP, but that there were a
fair
> amount of gaming apps that use TCP, and I was making the comment from
> the perspective of "let's not stuff audio and video into that service
class as
> well if we don't have to, and we don't have to".
> 
> James
> 
> 
> >Joe
> >

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 20 Mar 2013 16:27:59 +0000

> http://www.ietf.org/proceedings/86/slides/slides-86-tsvwg-5.pptx

My only comment on that slide is that the story I told in my previous note happened on inter-provider links. The slide is correct that there is not a defined class in 5127 for admitted video traffic.

---

From: <[email-masked]>
Date: Wed, 20 Mar 2013 19:47:39 +0100

David, Fred,

an appropriate class for routing is envisaged by Y.1566
and my draft is based on Y.1566. In fact, marking routing
traffic by CS6 was easy to agree.

The question is, how to treat traffic marked by CS6 at
interconnection links. David originally objected to having
such a routing class at interconnecton. I think we need
some discussion.

Routing information should be transmitted free of loss.
That could mean an own class marked by CS6, that could be
any other class resulting in low loss for TCP based
traffic. One could map this traffic from CS6 to
another fitting class and PHB, like Assured AF31.

There's also an issue with VPN treatment. Providers may
prefer not to transport customer routing traffic together
with their own routing traffic.

It may be good to add some text in -03 of my draft.
Objections?

Regards,

Rüdiger

---

From: <[email-masked]>
Date: Wed, 20 Mar 2013 19:56:08 +0100

Fred, James

RG>> The application decoupled class name I've suggested is "Priority".
JP> Nitpicking - that sends the wrong message, as DiffServ is *not* a priority service, it is a differentiated service. Brian C. is quick to point this out...

FB: More than a nitpick. This is actually important.

RG: Propose any name not linking this class to an application
    or application aggregate. That's difficult, at least for me.

FB: I suspect that calling it "priority" will have every idiot
    on the planet trying to use it for his or her pet application
    without regard to the service it offers or what their
    application's specific needs are.

RG: You clearly underestimate the bunch. They can read SLA numbers
    by now. It doesn't matter how you call the class.

Regards,

Rüdiger

---

From: <[email-masked]>
Date: Wed, 20 Mar 2013 20:12:21 +0100

James, David

I'm going to read 5865, once time allows. Just another
remark on EF and about definitions of network
sections:

- Backbone: no interface below Gbit/s.
- Access & Aggregation: Mbit/s to customer, but also
  lower Gbit/s, controlled by a network provider.
- in home network and LAN: customer domain.

I expect EF to be admission controlled in the network
provider domain (access, aggregation and backbone).

EF and voice-admit are identical in the network
provider domain and James would say rather similar,
but not identical from an overall perspective.
Am I completely wrong?

Regards,

Rüdiger

James

---

From: <[email-masked]>
Date: Wed, 20 Mar 2013 20:28:42 +0100

Jose,

thanks for your information. I'd prefer classes to be
described in terms of designed for traffic with /
without retransmits. But there's admission control too,
and I never heard of a game signling SIP or RSVP.
I think QoS for games requires more discussion.

Classes with properties suiting the requirements you
describe are specified.

Regards,

Rüdiger

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 20 Mar 2013 19:53:15 +0000

> with their own routing traffic.

That, I should think, would be between the provider of the VPN and the client. If the client objects, the client can mop the whole VPN into some service class of his interest.

> It may be good to add some text in -03 of my draft.

No objection to adding text to your draft. I would object to removing the service class, as you report David to be proposing and your draft would appear to be proposing. I think there could be a lot in AF3 that could sustain an isolated loss while one wanted to preserve inter-provider routing traffic.

---

From: <[email-masked]>
Date: Wed, 20 Mar 2013 22:25:02 +0100

My draft says there may be a provider internal class
for routing and network management. It does not exclude
a situation where traffic of such a class and codepoint
is sent to a network provider. That's an aspect I'd be
happy to settle.

I've been suggesting AF31 as a potential CS6 match at
interconnection. The idea is, that AF32 and AF33 may
carry traffic of applications able to deal with an
isolated loss. I'd expect the Assured (AF3) class to
be produced almost free of loss within a
provider network not differentiating the 3 PHBs.
Differentiation of AF3 PHBs may be useful to the sending
party at interconnection. These are rough thoughts by now.

Regards,

Rüdiger

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 20 Mar 2013 21:30:48 +0000

> party at interconnection. These are rough thoughts by now.

The same is true of CS6.

The reason we picked the number 110 000, by the way, was current use. If you want to change the number, it will take more than a stroke of the pen; it will take changing at least configuration if not software. What you wind up with is a class that carries both numbers until the old class goes away.

I'm not sure I see the point.

---

From: <[email-masked]>
Date: Wed, 20 Mar 2013 23:12:40 +0100

I don't exclude CS6 from being sent.
I know of the router limitations if it's about
setting DSCPs for internally created traffic.
That's not limited to BGP or IGP Protocols.

CS6 was easy to agree within ITU as those
providers I talked to use it. And they agreed
that they wouldn't be happy to carry customer
traffic in that class.

I never said I'd like to change the codepoint in
general. I'm discussing how to treat the
PHB/codepoint if received at interconnetion. I
recall that one of the starting points of our
current acitivities was Brians remark, that
changing DSCPs is the default DiffServ behaviour
at interconnecton interfaces.

I think we agree, here's an issue. We don't seem
to agree about the solution.

Regards,

Rüdiger

-----Original Message-----
From: Fred Baker (fred) [mailto:[email-masked]]
Sent: Wednesday, March 20, 2013 10:31 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: Re: RFC 4594 update: Routing class

The same is true of CS6.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 20 Mar 2013 23:05:21 +0000

On Mar 20, 2013, at 3:12 PM, [email-masked] wrote:

> I think we agree, here's an issue. 

I think we agree that there is a conversation to be had. I'm not sure what actual problem you're trying to solve. I mostly see a proposed solution, displayed in the slide you have in the proceedings.

---

From: "Black, David" <[email-masked]>
Date: Thu, 21 Mar 2013 00:02:37 -0400

To be clear, that slide was based on ITU-T Y.1566 and draft-geib-diffserv-intercon.
The unstated purpose of that slide was to stimulate discussion - which is now underway.
Slide URL: http://www.ietf.org/proceedings/86/slides/slides-86-tsvwg-5.pptx

The slides on draft-geib-diffserv-intercon are here:
	http://www.ietf.org/proceedings/86/slides/slides-86-tsvwg-2.ppt

Thanks,
--David

> Sent: Wednesday, March 20, 2013 7:05 PM
> To: [email-masked]
> Cc: [email-masked]
> I think we agree that there is a conversation to be had. I'm not sure what
> actual problem you're trying to solve. I mostly see a proposed solution,
> displayed in the slide you have in the proceedings.
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 21 Mar 2013 07:45:25 -0000

David, All,

Thanks for this thread, and thanks to Fred for picking up the baton.

Are there any specific questions you would like to ask to the Routing Area wrt
routing traffic, MPLS, or pseudowires?

Thanks,
Adrian

> Sent: 21 March 2013 04:03
> To: Fred Baker (fred); [email-masked]
> Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred
> > Baker (fred)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2013 08:20:00 +0000

> at interconnecton interfaces.

That is the architectural model, but of course there
is no issue if peering ISPs choose to agree that
CS6 maps to CS6 and that all routing traffic is labelled
with CS6. Since I understand that to be the essentially
universal current practice, naming it "Routing Class"
doesn't seem to be a big step. Attempting to change it
seems to be a major undertaking (with no obvious benefit).

    Brian

---

From: <[email-masked]>
Date: Thu, 21 Mar 2013 09:34:32 +0100

Fred,

its not simple to figure out what you ask for.

Today EBGP largely is marked as BE (as far as I
know, but I will check that). In many
domains internal routing or management traffic
is marked by CS6 and at least the network
provider representatives I talked to don't
want to transport customer traffic in that
class within their network.

Many routers today don't provide marking
options, if it is about marking internally
created traffic. Mostly that means these
routers set CS6 for this traffic.

I've suggested to standardise a limited set
of classes at interconnection. Traffic marked
by CS6 may occur at interconnections. The draft
I authored should offer some options how to
deal with this.

You
- think that todays practice of classifying EBGP by
  BE and leave router limitation on classification
  of internally created traffic by CS76 as it is.
- do not think anything else should be standardised?
- think standardisation as described above is useful?
- ???

Sorry if I'm thick on that. I'd like to understand your
position and currently I don't. Note that I'm not a
native speaker.

Regards,

Rüdiger

---

From: <[email-masked]>
Date: Thu, 21 Mar 2013 09:48:22 +0100

Hi Brian,

we agree that this traffic may appear at interconnection.
And yes, not changing CS6 is one option, which is
desireable in some cases and possibly generally agreed
in others.

As I mentioned, the network providers I talked to don't
want to share their internal routing PHB with customer
traffic. The number is limited but I so far had no
objection. That means, mapping of the CS6 routing PHB at
interconnection is a valid option too.

Now having said that it means, that the company I work
for would not be surprised, if traffic we send to an
interconnection partner is mapped to another PHB - it
should be a suitable one however.

Then I think, as this traffic is pretty important,
offering some standard proposals are useful.

Am I completely wrong with that?

Then you suggest to have an own class for this traffic...
yes I probably am pretty alone if I say, what about
just an own PHB? To me, the Assured Class properties
match the requirements. The class can at least be
engineered to do that.

Regards,

Rüdiger

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Thursday, March 21, 2013 9:20 AM
To: Geib, Rüdiger
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] RFC 4594 update: Routing class

    Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Mar 2013 11:19:22 -0700

Again, I don't like classes named for applications - or protocols, or 
groups of protocols. This ought to be something you can describe in 
terms of the service provided, not how the service is used.

Joe

---

From: "Black, David" <[email-masked]>
Date: Fri, 22 Mar 2013 03:07:00 -0400

Joe,

This is already a solved problem.  This traffic class is called "Network Control"
in RFC 4594 (which recommends CS6 for that class of traffic).  The use of "Routing"
as a class name here name is effectively shorthand for that "Network Control" class.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe
> Touch
> Sent: Thursday, March 21, 2013 2:19 PM
> To: Fred Baker (fred)
> Cc: [email-masked]
> > The origin of a class of traffic for routing traffic was a bug. The Cisco
> 7000 had an issue with its offloaded forwarding cards, of which it had two.
> When there was a route flap, it blew away the route cache and then rebuilt it
> in response to traffic it needed to forward. In that implementation, that
> meant that the Route Processor (the CPU) suddenly had all traffic from all
> sources flooded into it. The impact of that was to make it very difficult for
> the RP to actually re-populate the Route Cache. Doubleplus ungood. The work-
> around was to rate-limit traffic from the line cards to the RP. However, rate

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Mar 2013 08:13:44 -0700

Hi, David,

Routing != network control.

It's a subset thereof; I don't want the name to imply that we need 
another class for other sorts of network control traffic.

(and even network control is a bit "application"-oriented, but I'll 
accept that it's the more effective way to say "critical internal traffic")

Joe

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 Mar 2013 18:39:44 -0400

Having reviewed all the messages, I believe that the WG has rough

> (2) The newly-standardized Voice-Admit PHB is being added to the

See RFC 5865 for details of that Voice-Admit PHB.  I noticed an objection
from Ruediger Geib, but no others.

> changes/generalizations to the description.

Suggestions for new names that better characterize the traffic that should
use the class named "Telephony" in RFC 4594, but that do not imply inclusion
of video traffic in that class are encouraged.

Thanks,
--David (tsvwg co-chair)

> Black, David
> Sent: Friday, March 15, 2013 8:36 AM
> To: [email-masked]