Subject: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnection-00.txt

From: <[email-masked]>
Date: Tue, 6 Nov 2012 09:41:08 +0100

Dear TSVWG chairs,

as mentioned in an earlier message, a new ID about interconnection qos which I failed to finalise before submission cutt-off is now available:

http://www.ietf.org/id/draft-geib-tsvwg-diffserv-intercon-00.txt

This is not a request for a time slot.

Comments are welcome of course.

I've received a question about Layer 2 services in there. Ethernet over IP/MPLS products are present in the market I'm aware off (some QoS codepoints are required for classification then). The initial idea for the interconnection qos resulted from national Layer 2 interconnection negotiations. If you read MEF23.1, you'll find a rich set of proposed classification functions, ranging up to Layer 4. I think, IP, MPLS and Ethernet QoS is linked and intertwined.

Regards,

Rüdiger

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Nov 2012 12:19:32 +0000

Some thoughts on this draft, based on a preview over the weekend:

1. I think it is a reasonable idea to specify a small set of traffic classes
that could be the default set in peering relationships. Getting consensus
on the best set could be tricky, of course.

2. I may be old fashioned, but I don't really understand why we bother
with layer 2 values at all. If diffserv is working properly, layer 2 can
just give the same service to all packets. (Unless there are non-IP services
on the same wire.) In fact I'd rather that layer 2 doesn't try to impose
any queue or drop behaviour other than FCFS.

(ECN passed up from layer 2 to layer 3/4 makes sense. What I don't see is
the advantage in mapping traffic classes down rather than just treating
layer 2 as intrinsically best effort. Layer 3 should be respecting the
appropriate queueing discipline for each traffic class already.)

3. Finding good names for the selected traffic classes is indeed hard;
even if you call them A, B and C there is an implied semantic. You could
try names like Elastic, Inelastic and Network Control maybe.

Regards
   Brian Carpenter
   Cell phone during IETF85: +1 847 219 0880

---

From: <[email-masked]>
Date: Tue, 6 Nov 2012 13:53:08 +0100

Brian,

thanks for your comments.

My response is related to Ethernet QoS. Ethernet QoS may be part of
an end to end IP path in some cases:

- if IP runs over Ethernet and a provider offers Ethernet over MPLS
  service. One solution is to assign QoS to a VLAN ID, another one
  may be to map DSCP to P-Bits and P-Bits to MPLS TC.

- as soon as there's a bottleneck in a network segment which doesn't
  apply IP/MPLS transport, QoS differentiation on Layer 2 may be
  desireable. Access and interconnection interfaces may be layer 2
  based. The question is, whether any Ethernet swichting or
  multiplexing will occur. If this isn't the case and the receiving
  edge terminates the virtual Ethernet link, P-Bits don't make sense.

Thanks for supporting the basic principles of interconnection QoS classes
and finding application agnostic class names. I'd be glad if there's more
support for the ideas at the meeting. I prefer not to start discussion
on details prior to the Thursday meeting.

Regards,

Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, November 06, 2012 1:20 PM
To: [email-masked]
Subject: Re: [tsvwg] Informational: draft-geib-tsvwg-diffserv-interconnection-00.txt

Regards
   Brian Carpenter

---

From: Joe Touch <[email-masked]>
Date: Fri, 09 Nov 2012 11:01:03 -0800

> any queue or drop behaviour other than FCFS.

Because your assumption that IP diffserv is sufficient holds only when 
layer 2 is composed solely of point-to-point links AND all L2 packets 
consist only of IP.

You addressed the latter point, but not the former. When the L2 is 
either switched (ethernet) or coordinated MAC (802.11), the diffserv 
from L3 needs to be mapped to L2 so that competing flows from different 
sources that are merged onto a single L2 link provide that muxing 
mechanism the info needed to decide what to prioritize.

Joe