Subject: [AVTCORE] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02

From: Ben Campbell <[email-masked]>
Date: Sat, 9 Aug 2014 13:48:13 -0500

Hi,

The DART working group has started a last call for draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational draft describes considerations for the use of DiffServ code points in situations where one multiplexes multiple RTP packet streams, and potentially other protocol streams, that share the same 5-tuple. 

Since this draft is likely of interest to several working groups, I would like to solicit additional reviews from participants of TSVWG, AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback to the effect of "this is ready to progress") to the DART working group mailing list.

Thanks!

Ben.

Begin forwarded message:

> Resent-From: [email-masked]
> From: Ben Campbell <[email-masked]>
> Subject: WGLC: draft-ietf-dart-dscp-rtp-02
> Date: August 9, 2014 at 12:50:16 PM CDT
> Resent-To: [email-masked], [email-masked], [email-masked]
> To: [email-masked]
> Cc: [email-masked], [email-masked], Richard Barnes <[email-masked]>
> 
> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's available on the data tracker at the following URL:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/
> 
> The WGLC will conclude on 22 August, 2014. Please send your comments to the authors and the DART mailing list. If you've reviewed it and think it's good to go, please say so.
> 
> Thanks!
> 
> Ben.
>

---

From: Dave Taht <[email-masked]>
Date: Tue, 12 Aug 2014 16:56:51 -0700

This is also of some interest to me at least, and perhaps some members
of the AQM working group who are working out weighted fair queuing and
wred like approaches to these needs.

Anyway, I do try to track thinking in this area in the ongoing
development of cerowrt's sqm system, which has pluggable modules for
all the known aqm and fq schedulers, and a three tier system modeled
on wondershaper for managing traffic,
which uses what diffserv markings that I have observed make sense...

Some relevant links:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310

http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management

Missing from this discussion so far is what is actually deployed out
there... I am only familiar with stuff like the above as an
egress/ingress queue management system...

AND: in the case of linux based wireless routers, none of the AF
codepoints are respected explicitly, and how the codepoints are mapped
are described by 802.11e - and that is far more about scheduling
priority for airtime rather than drop probability.

It is kind of hard to wrap your head around how 802.11e actually
works, but, this is a start:

http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel_access_.28EDCA.29

In linux wifi at least:

CS0, CS3 are mapped into the BE hw queue
CS1, CS2 are mapped into the BK hw queue
CS4, CS5 are mapped into the VI hw queue
CS6, CS7 are mapped into the VO  hw queue

Bit patterns for the other classes to whatever extent they map into
CSX are mapped into the underlying hardware queue.

I am not saying this is an optimal state of affairs, (as notably VO
should be as completely disabled as possible in the 802.11n and ac
age), and am very interested in how other OSes (ios, osx, windows),
and router/switch OSes do it, but the wireless scheduling aspect of
all these codepoints does not seem to be well touched upon.

On a personal note I tend to think that having 17+ ways to slice up
traffic is about 13 or 14 too many, particularly those targetting a
drop probability. When you have drop rates well below a few percentage
points, adding another percentage point of granularity seems futile.

Lastly, there is also an implementation issue in linux presently in
that doing extensive diffserv classification basically requires
one iptables or tc rule per class, which is inefficient.  Someone (not
me!) doing some code for doing diffserv saner there would go a long
way...

On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Aug 2014 16:17:37 +0100

Hi,

[I’m not on the DART list, so please cc me in replies]

This draft looks good overall, but I did have some comments, primarily about the discussion of RTP multiplexing. 

The four bullet points in Section 2.1 that follow “The RTCWEB protocol suit encompasses a number of forms of multiplexing” seem to confuse RTP sessions,
RTCP, and transport-layer flows. I suggest they be changed to:

>    The RTP streams that comprise a WebRTC session can be multiplexed 
>    together in a number of ways:
> 
>    1.  Individual source streams are carried in one or more individual
>        RTP streams. These RTP streams can be multiplexed onto a single
>        transport-layer flow or sent as separate transport-layer flows.
>        This memo only considers the case where the RTP streams are to be
>        multiplexed onto a single transport-layer flow, forming a single
>        RTP session;
> 
>    2.  The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed onto
>        the same transport-layer flow as the RTP stream with which it is 
>        associated, as described in [RFC5761], or it may be sent on a 
>        separate transport-layer flow;
> 
>    3.  The RTP and RTCP traffic can be multiplexed with other protocols 
>        via UDP encapsulation over a common pair of UDP ports as described 
>        in [RFC5764] as updated by
>        [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and
> 
>    4.  The data may be further encapsulated via STUN [RFC5389] and TURN
>        [RFC5766] for NAT (Network Address Translator) traversal.

In the following paragraph (penultimate paragraph in Section 2.1), I suggest changing “unidirectional UDP packet flow” to “transport-layer flow” since it will not be unidirectional (since RTCP also flows in the reverse direction), and might not use UDP. 

In the first paragraph of section 2.2, I suggest changing “multiplexed over RTP sessions” to “multiplexed in a single RTP session” and “multiplexing of source streams in RTP sessions” to “multiplexing of source streams in a single RTP session”. 

In Section 6, the second bullet point refers to “an RTCP session”. There is no such thing. Rather, within a single RTP session there are RTCP packets sent that give information about the RTP streams that are being sent, and that report on the reception quality of RTP streams being received. Using a single PHB and DSCP for all RTCP packets within an RTP session might make sense, but it’s important to note that one role of RTCP is to provide an estimate of the round-trip time seen by the media, so the PHB/DSCP will have to be chosen with care to avoid biasing that estimate too much.

Editorial: the protocol is called WebRTC, but the working group is RTCWEB. Accordingly, I think all instances of “RTCWEB” in this draft need to change to “WebRTC”.

Cheers,
Colin

On 9 Aug 2014, at 19:48, Ben Campbell <[email-masked]> wrote:
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Aug 2014 15:48:25 -0500

Hi,

I concur with all of Colin's comments, save one question below:

>>       [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and

Can we clarify what "other protocols" are expected? Are we just talking about WebRTC data-channels over SCTP/DTLS, or other things? If the latter, are we talking things we expect to do today, or in immediate futures, or extensions that might happen someday?

---

From: "Black, David" <[email-masked]>
Date: Thu, 21 Aug 2014 21:06:14 -0400

Colin - many thanks for the review.  I'll pick up your proposed changes, perhaps
with minor edits.

Ben,

> Can we clarify what "other protocols" are expected? Are we just talking about
> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, are we
> talking things we expect to do today, or in immediate futures, or extensions
> that might happen someday?

WebRTC will only multiplex its data channels, and this numbered list is about
WebRTC, so this text should focus on those data channels - I'll revise the draft
accordingly.

Other text elsewhere in the draft is broader (e.g., SCTP/UDP without DTLS, which
is of interest, even though WebRTC always uses DTLS).

Thanks,
--David

> -----Original Message-----
> From: Dart [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Monday, August 18, 2014 4:48 PM
> To: Colin Perkins
> Cc: [email-masked]; [email-masked]; [email-masked]
> WG
> Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02
> 
> Hi,
> 
> > [I'm not on the DART list, so please cc me in replies]
> >
> > The four bullet points in Section 2.1 that follow "The RTCWEB protocol suit
> encompasses a number of forms of multiplexing" seem to confuse RTP sessions,
> Can we clarify what "other protocols" are expected? Are we just talking about
> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, are we
> talking things we expect to do today, or in immediate futures, or extensions
> that might happen someday?
> 
> >>
> > In the following paragraph (penultimate paragraph in Section 2.1), I suggest
> changing "unidirectional UDP packet flow" to "transport-layer flow" since it
> will not be unidirectional (since RTCP also flows in the reverse direction),
> and might not use UDP.
> >
> > In the first paragraph of section 2.2, I suggest changing "multiplexed over
> RTP sessions" to "multiplexed in a single RTP session" and "multiplexing of
> source streams in RTP sessions" to "multiplexing of source streams in a single
> RTP session".
> >
> > In Section 6, the second bullet point refers to "an RTCP session". There is
> no such thing. Rather, within a single RTP session there are RTCP packets sent
> that give information about the RTP streams that are being sent, and that
> report on the reception quality of RTP streams being received. Using a single
> PHB and DSCP for all RTCP packets within an RTP session might make sense, but
> it's important to note that one role of RTCP is to provide an estimate of the
> round-trip time seen by the media, so the PHB/DSCP will have to be chosen with
> care to avoid biasing that estimate too much.
> >
> > Editorial: the protocol is called WebRTC, but the working group is RTCWEB.
> Accordingly, I think all instances of "RTCWEB" in this draft need to change to
> "WebRTC".
> >
> > Cheers,
> > Colin
> >
> >
> >
> >
> >
> >> The DART working group has started a last call for draft-ietf-dart-dscp-
> rtp-02, ending on August 22. This informational draft describes considerations
> for the use of DiffServ code points in situations where one multiplexes
> multiple RTP packet streams, and potentially other protocol streams, that
> share the same 5-tuple.
> >>
> >> Since this draft is likely of interest to several working groups, I would
> like to solicit additional reviews from participants of TSVWG, AVTCORE,
> MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback
> to the effect of "this is ready to progress") to the DART working group
> mailing list.
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> >> Begin forwarded message:
> >>
> >>> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02.
> It's available on the data tracker at the following URL:
> >>>
> >>> The WGLC will conclude on 22 August, 2014. Please send your comments to
> the authors and the DART mailing list. If you've reviewed it and think it's
> good to go, please say so.
> >>>
> >>> Thanks!
> >>>
> >>> Ben.
> >>>
> >>
> Dart mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dart