Subject: [dispatch] Proposed mini-WG: DiffServ considerations for real-time communications

From: Richard Barnes <[email-masked]>
Date: Sun, 2 Mar 2014 18:38:15 +0000

Dear DISPATCH,

The RAI and TSV ADs and several WG chairs have been discussing how to
address several transport concerns arising from draft-ietf-rtcweb-transport
and draft-dhesikan-tsvwg-rtcweb-qos (née draft-ietf-rtcweb-qos).  One thing
that emerged from that discussion is the need for a document to describe
certain realities regarding DiffServ and (possibly) multiplexed flows.
 Unforunately, such a document does not fall within the charters of current
RAI WGs, since it it is relevant to many WGs.

So we would like to propose the formation of a mini-WG in the RAI area to
develop this document.  A charter is below; I will ask the DISPATCH chairs
to call for consensus at the meeting tomorrow.

Thanks,
--Richard

----- BEGIN Charter -----
DART - DSCP Applied to RTP Transports

DIffServ code points (DSCP) can be used in some situations to provide
quality of service (QoS). Packets with different marketings can be
reordered, which can cause poor interaction with a transport that is
responsive to reordering. When RTP streams or other real-time media
 (sub-)flows are used with different DSCP values with the same transport
5-tuple, there are interactions with the transports. There are also
environments where the DSCP markings are removed or remarked.

This WG will write a document that explains the limitations that exist with
DSCP when used with RTP in general as well in the specific RTCWeb cases.
The WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC,
CLUE, and RTCWEB.

Aug 2014 - Send Information draft to IESG on DSCP usage consideration
----- END Charter -----

---

From: James Polk <[email-masked]>
Date: Sun, 02 Mar 2014 21:10:47 -0600

At 12:38 PM 3/2/2014, Richard Barnes wrote:
>Dear DISPATCH,
>
>The RAI and TSV ADs and several WG chairs have 
>been discussing how to address several transport 
>concerns arising from 
>draft-ietf-rtcweb-transport and 
>draft-dhesikan-tsvwg-rtcweb-qos (née 
>draft-ietf-rtcweb-qos).  One thing that emerged 
>from that discussion is the need for a document 
>to describe certain realities regarding DiffServ 
>and (possibly) multiplexed flows.  Unforunately, 
>such a document does not fall within the 
>charters of current RAI WGs, since it it is relevant to many WGs.
>
>So we would like to propose the formation of a 
>mini-WG in the RAI area to develop this 
>document.  A charter is below; I will ask the 
>DISPATCH chairs to call for consensus at the meeting tomorrow.
>
>Thanks,
>--Richard
>

I couldn't help myself (I know how much you love 
it when I do that), but there are too many 
inaccuracies in the short (draft) charter below.

I offer (boldly, because you didn't ask for it) 
what I think is a better version of a draft, 
incorporating your text and ideas. I realize its 
length is nearly half the size of the ID this WG produces.  ;-)

----- BEGIN Charter -----

Various transport protocols exist today for 
various reasons; mostly because there was a need 
for a behavior that the IP layer just could not 
provide, or a behavior that another transport 
protocol didn't have (at the time, in some 
cases). For example, both a type of congestion 
control and an ability to reorder at the receiver 
out of order packets necessitated the need for 
the development of a transport layer to handle 
both capabilities better. The result was TCP. 
There are now multiple transport protocols (i.e., 
TCP, UDP, SCTP, etc.) that have various 
behaviors. These behaviors are not the same 
depending on the network circumstance a/each 
packet finds itself in as it traverses through the network.

With the IP layer, and not part of the 5-tuple 
identifier, DiffServ code points (DSCP) can be 
used in situations to provide quality of service 
(QoS), but in fact it is a class of service (COS) 
differentiation they provide. These 64 different 
values are found within the old TOS byte. There 
is nothing in the DSCP field but zeros most of 
the time (i.e., Best Effort). As specified within 
RFC 2474 and 2475 is called a per hop behavior 
(PHB). Hence most packets receive a best effort 
PHB. An important aspect of a PHB is that it is 
just that, and a packet, and indirectly its user, 
needs to be prepared to have its DSCP remarked to 
another value one or more times, or any time it traverses a layer node.

With the desire to now explore other than best 
effort DSCP markings of RTP streams or other 
real-time media (sub-)flows, certain realities, 
say for example reordering of packets within a 
stream or flow, not all transport protocols 
behave the same. Some will have their DSCP of a 
non-zero value set to zero by some router before 
the destination, or another non-zero value that 
is different from the packet that it was originally set to.

This WG will write a document that explains the 
limitations that exist with DSCP when used with 
RTP in general as well in the specific RTCWeb 
cases. The WG will coordinate with relevant WGs, 
including TSVWG (Diffserv's home WG), AVTCORE, MMUSIC, CLUE, and RTCWEB.

----- END Charter -----

>DIffServ code points (DSCP) can be used in some 
>situations to provide quality of service (QoS). 
>Packets with different marketings can be 
>reordered, which can cause poor interaction with 
>a transport that is responsive to reordering. 
>When RTP streams or other real-time 
>media  (sub-)flows are used with different DSCP 
>values with the same transport 5-tuple, there 
>are interactions with the transports. There are 
>also environments where the DSCP markings are removed or remarked.
>
>This WG will write a document that explains the 
>limitations that exist with DSCP when used with 
>RTP in general as well in the specific RTCWeb 
>cases. The WG will coordinate with relevant WGs, 
>including TSVWG, AVTCORE, MMUSIC, CLUE, and RTCWEB.
>
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Mar 2014 07:20:08 +0100

On 03/02/2014 07:38 PM, Richard Barnes wrote:
> address several transport concerns arising from
> draft-ietf-rtcweb-transport and draft-dhesikan-tsvwg-rtcweb-qos (née
> draft-ietf-rtcweb-qos).  One thing that emerged from that discussion
> is the need for a document to describe certain realities regarding
> DiffServ and (possibly) multiplexed flows.  Unforunately, such a
> document does not fall within the charters of current RAI WGs, since
> it it is relevant to many WGs.
>
> So we would like to propose the formation of a mini-WG in the RAI area
> to develop this document.  A charter is below; I will ask the DISPATCH
> chairs to call for consensus at the meeting tomorrow. 

1) Will the agenda be updated?

2) Obviously 24 hours from proposal to call for consensus is a bit
short; what's the proposed timeframe for the consensus call on the list?

3) Do we need a WG here, or a mailing list + an individual submission?

>  (sub-)flows are used with different DSCP values with the same
> transport 5-tuple, there are interactions with the transports. There
> are also environments where the DSCP markings are removed or remarked.
>
> This WG will write a document that explains the limitations that exist
> with DSCP when used with RTP in general as well in the specific RTCWeb
> cases. The WG will coordinate with relevant WGs, including TSVWG,
> AVTCORE, MMUSIC, CLUE, and RTCWEB.
>

-- 
Surveillance is pervasive. Go Dark.

---

From: Mary Barnes <[email-masked]>
Date: Mon, 3 Mar 2014 02:12:03 -0600

Responses below [MB].

> 1) Will the agenda be updated?
[MB] The plan was to include a slide on this in the charts presented by the
chairs which will be uploaded shortly[/MB]

>
> 2) Obviously 24 hours from proposal to call for consensus is a bit short;
> what's the proposed timeframe for the consensus call on the list?
>
[MB]  I agree. I think it's quite reasonable to highlight this in the
DISPATCH meeting, but I think that a 2 week call for consensus (and
consideration of feedback such as that from James Polk) is reasonable.
[/MB]

> 3) Do we need a WG here, or a mailing list + an individual submission?
[MB] The current proposal is a "mini WG" with a narrow scope and shorter,
more agrressive timeline than a typical WG.   My understanding is that the
work was deemed to be of more interest than work items that typically
result in an AD sponsored document. [/MB]

> cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE,
> MMUSIC, CLUE, and RTCWEB.
>
> dispatch mailing [email-masked]://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> --

---

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Mar 2014 10:37:50 +0000

On Mon, Mar 3, 2014 at 8:12 AM, Mary Barnes <[email-masked]>wrote:

> [MB] The plan was to include a slide on this in the charts presented by
> the chairs which will be uploaded shortly[/MB]
>
>>

Some of the ADs involved in the discussion felt it was important to have a
WG as a focus for discussion on this draft, since it does have impacts on
several WGs in at least two areas.  However, as Mary notes, the hope here
is to have the timeline be not much longer than an AD-sponsored draft would.

--Richard