Subject: Re: [tsvwg] Diffserv for interconnection

From: <[email-masked]>
Date: Fri, 21 Dec 2012 10:48:46 +0100

Dear Med,

after having read RFC5160, I'm happy that you agree that an
interconnection class and codepoint scheme and RFC5160
complement each other. I'll add a reference, when I update
my draft.

I may come back with questions on some details, but there's
one point which I'd like to discuss.

Your terminology is quite clear about

   Local-QoS-Class (l-QC)

   A QoS transfer capability across a single domain, characterized by
   a set of QoS performance parameters denoted by (D, J, L).  From a
   Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per
   Domain Behavior (PDB) [RFC3086].

>From what I know, a PDB may be optimised for cetrtain kinds of traffic:
pure VoIP RTP or TCP, to give examples. Traffic conditioning and
scheduling may be optimised on the recommended usage of a class. If
that's the case, then first there's the PDB or class specification on
a level closer to transport or application and then there's a
description by SLA properties.

Taking it the other way around: by just looking at SLA properties
D, J, L and a PDB name (which may not be standardised),
interconnection QoS may not always work as desired. Especially
with AF classes.

What I propose is to add some explaining text in a document we
would have to agree on (maybe my draft, could be any other). That
may be done in a way as proposed by http://tools.ietf.org/html/rfc3086#section-8.

What's left for me this year is wishing merry christmas to those
celebrating and a relaxed and good start into 2013 to those
who don't

Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 26, 2012 11:23 AM
To: Geib, Rüdiger; [email-masked]
Cc: LEVIS Pierre OLNC/OLPS; [email-masked]; JACQUENET Christian OLNC/OLN
Subject: RE: Diffserv for interconnection

Dear Ruediger,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De
>la part de [email-masked]
>Envoyé : lundi 26 novembre 2012 09:30
>À : [email-masked]
>Cc : LEVIS Pierre OLNC/OLPS; [email-masked]; JACQUENET
>Christian OLNC/OLN
>Objet : Re: [tsvwg] Diffserv for interconnection
>
>David,
>
>thanks. I submitted a draft on the issue and I'm also involved
>in the ITU liaision.
>
>Yes, to me IETF should pick up the subject of limited and
>"well enough defined"
>set of interconnection QoS classes.
>
>I've reread RFC5127. If it stays informational, I got no
>qualms with it. If a revised
>version of RFC5127 ist to be put on standards track, some
>parts of it must be
>better explained and possibly rewritten. If it is not touched,
>some parts of what
>is required in a revised 5127 from my point of view should
>become part of the
>interconnection work.
>
>I'm halfway through http://tools.ietf.org/html/rfc5160 and the
>authors asked how I'd
>position my proposal with regard it. It is a more abstract
>document about
>inter provider QoS agreements.

Med: FWIW, the rationale we adopted in RFC5160 is as follows:

* Network Providers are free to define their own traffic engineering policies and their QoS class of services in their domains.
* Diffserv is only a means among other to achieve differentiated forwarding
* The number and the definition of QoS classes is not universal
* Network Providers are not obliged to expose their internal class of services to external parties
* When extending some QoS classes beyond the boundaries of a given domain, it is required to establish contractual agreements between network providers, otherwise the traffic will be handed as BE.
* These agreements will be the place where class identification is discussed and agreed.
* Remarking is likely to be always enforced in both exit border router and entry border router: local class of services are not advertised outside the domain.
* Providers need a tool to help deciding how to bind one/multiple local QoS classes with adjacent class of service: hence the concept of meta-QoS-Class.
* CoS identifier is not sufficient to provide QoS: additional parameters are to be agreed between network providers. Examples of these parameters are: constraints on the traffic (eg., tcp-friendly), network resources for the class / overall traffic using this class, etc.

So far I think, RFC5160 and the
>proposals of my
>draft would complement each other.

Med: Agreed. I personally see a value in standardizing a very limited set of interconnection classes. In addition to the interconnection class name/identifier discussion point, it is important also to have a detailed definition of the class itself (in terms of attributes, target services, traffic conditions, etc.). Perhaps, try the http://tools.ietf.org/html/rfc3086#section-8 ;-)?

>
>Regards,
>
>Rüdiger
>
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Black, David
>Sent: Saturday, November 24, 2012 11:51 PM
>To: [email-masked]
>Subject: [tsvwg] Diffserv for interconnection
>
>Hello - this is your new tsvwg co-chair again, with <co-chair hat on>.
>
>The Atlanta tsvwg minutes are at:
>        http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg
>
>This message is about my second action item, on use of Diffserv for
>network interconnection.
>
>Excerpt from the minutes (explanation below):
>---------------
>Topic: interconnect liaison with ITU-T
>- (James Polk) describing set of code points (?) for the
>interconnection
>        of core providers.
>- (Gorry Fairhurst) asks if we should make a new set of
>recommendations for
>        a particular interface.
>- (David Black) thinks we should. As Chair, he asks the room
>if we should
>        work on this?  The room (by show of hands) indicates yes.
>        So we'll put this on the list
>(Joel Halpern)  thinks we don't need to do anymore at this meeting.  We
>        should state "this is an interesting problem, and we should do
>        something about this"
>---------------
>
>So the immediate question is what was "this" in Joel's comment?
>
>The short answer is that it's slide 6 in this set of slides:
>        http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf
>
>The rationale for doing "this" is also on that slide - it's basically
>scaling/reuse of configuration, so that a carrier or operator can apply
>a single diffserv configuration to interconnections with multiple other
>networks.  Also see draft-geib-tsvwg-diffserv-intercon-00 .
>
>The item that I recall asking about was whether the IETF
>should work on a
>single set of recommended diffserv behavior (PHBs) and
>codepoints (DSCPs)
>for use in carrier interconnection?
>
>The sense of the room in Atlanta (as noted in the minutes) was that the
>IETF should work on this, with details of how to do that TBD - in
>particular there was no assumption about the relationship of this work
>to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken,
>this new work may or may not be carried out by revising RFC 5127).
>
>If anyone disagrees with the sense of the room in Atlanta, now would
>be a good time to speak up.
>
>If the sense of the room in Atlanta is confirmed, the next action is
>for me to work through the ITU-T SG12 liaison (primarily the draft of
>y.qosmap) and consult with Ruediger about what makes sense before
>bringing a proposal for what to do back to this list.
>
>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: "Black, David" <[email-masked]>
Date: Fri, 28 Dec 2012 17:38:53 -0500

This topic has also had sufficient "soak time" and hence having seen no
objections, the Atlanta "hum" on diffserv for interconnection is confirmed
as the rough consensus of the tsvwg WG:

> The item that I recall asking about was whether the IETF should work on a
> single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs)

> bringing a proposal for what to do back to this list.

I will send a separate note on RFC 5160 shortly, and do intend to work
through the liaison material in order to get a proposal for what to do
out to the list in time for it to be an input to the liaison response
to SG12 that is due at the end of February. 

Thanks,
--David (tsvwg WG co-chair)

> From: Black, David
> Sent: Saturday, November 24, 2012 5:51 PM
> To: [email-masked]
> Cc: Black, David
> Subject: Diffserv for interconnection
> 
> - (James Polk) describing set of code points (?) for the interconnection
> 	of core providers.
> - (Gorry Fairhurst) asks if we should make a new set of recommendations for
> 	a particular interface.
> - (David Black) thinks we should. As Chair, he asks the room if we should
> The item that I recall asking about was whether the IETF should work on a
> single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs)

---

From: "Black, David" <[email-masked]>
Date: Fri, 28 Dec 2012 18:21:18 -0500

<tsvwg WG co-chair hat OFF>

I've also taken a look at RFC 5160, and have some comments as an
individual who's worked on QoS at the IETF, not as a WG co-chair.

Like Ruediger, I'm pleased to see agreement on the value of
"standardizing a very limited set of interconnection classes".

I note that RFC 5160 was published as an RFC Editor independent
submission, so its status is indicated by the IESG Note on page 1:

   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and notes that the decision to publish is not based on IETF
   review apart from IESG review for conflict with IETF work.  The RFC
   Editor has chosen to publish this document at its discretion.  See
   RFC 3932 for more information.

I do appreciate the authors introducing RFC 5160 as interesting input,
and as input, it's interesting (thank you), but I don't believe that
it should be treated as more than interesting input.  For that reason,
while there are a number of things in RFC 5160 that I don't agree with
(e.g., I concur with Ruediger's critique of the D,J,L framework), much
of that is not relevant to this discussion, as I see no problem with
considering interesting input and then deciding to do something else.

The core mechanism for interconnection QoS in RFC 5160 is the cross-domain
binding of Local QoS Classes described in Section 5.2.  As I understand
Ruediger's critique of current Diffserv interconnection practices, that
cross domain binding mechanism is an example of the per-peer QoS mapping
that currently prevails - for a discussion of why that can be problematic,
see Section 3 of draft-geib-tsvwg-diffserv-intercon-00.txt .  RFC 5160
then proceeds to constrain that per-peer QoS mapping via a notion of
Meta-QOS-Classes, but it doesn't seem to proceed beyond an abstract
level in developing that concept in Section 5.3.

In contrast, to render the proposed Diffserv for interconnection work
into RFC 5160's terminology framework, the proposed work is to use the
existing Diffserv specifications as the basis for standardizing a small
number of Meta-QOS-Classes (Diffserv PHBs) and associated codepoints
(Diffserv DSCPs) for use in network interconnection.  This is intended
to enable a network operator to map traffic between their network-internal
QoS management framework and a single standardized set of PHBs and
codepoints at network edges in order to obtain QoS behavior across
interconnections with other networks (as opposed to having to do such
mapping on a per-peer-network basis).

Thanks,
--David (as individual, not WG co-chair)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, December 21, 2012 4:49 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Diffserv for interconnection
> 
> Dear Med,
> 
> may be done in a way as proposed by
> http://tools.ietf.org/html/rfc3086#section-8.
> 
> * Network Providers are free to define their own traffic engineering policies
> and their QoS class of services in their domains.
> * When extending some QoS classes beyond the boundaries of a given domain, it
> is required to establish contractual agreements between network providers,
> otherwise the traffic will be handed as BE.
> * Remarking is likely to be always enforced in both exit border router and
> entry border router: local class of services are not advertised outside the
> domain.
> * Providers need a tool to help deciding how to bind one/multiple local QoS
> classes with adjacent class of service: hence the concept of meta-QoS-Class.
> * CoS identifier is not sufficient to provide QoS: additional parameters are
> to be agreed between network providers. Examples of these parameters are:
> constraints on the traffic (eg., tcp-friendly), network resources for the
> class / overall traffic using this class, etc.
> 
> 
> Med: Agreed. I personally see a value in standardizing a very limited set of
> interconnection classes. In addition to the interconnection class
> name/identifier discussion point, it is important also to have a detailed
> definition of the class itself (in terms of attributes, target services,
> traffic conditions, etc.). Perhaps, try the
> http://tools.ietf.org/html/rfc3086#section-8 ;-)?
> 
> >
> >Regards,
> >
> >Rüdiger
> >
> >
> >