Subject: Re: [Dart] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt

From: "Black, David" <[email-masked]>
Date: Sun, 20 Jul 2014 20:51:12 -0400

Karen,

<WG chair hat off>, [+dart list]

> I wonder if the recommendations of this document should not relate to the
> viability (or rather the opposite) of
> handling different RTCWEB data channels individually from a DSCP markings
> perspective. Or more generally
> relate to the fact that media streams within the same congestion control
> context cannot be handled individually.
> Right now such considerations are not in the document. If the intention is
> for such consideration to come
> in documents from the dart wg, then it would be very important to  have a
> reference to this dependency - or ?

IMHO, such a reference is necessary, although the dart WG draft will be
informational.  The reference should be added once there is an official dart
WG draft (likely to happen this week).

> Something else:
>
> Right now the document stipulates that packets within the same media stream
> may be marked with different DSCP codepoints, i.e.,
> it is said:
> 
>    One may select difference drop precedences for the
>    different packets in the media flow.  Therefore, all packets in the
>    stream SHOULD be marked with the same priority but can have
>    difference drop precedences.
> 
> which indeed is in compliance with the recommendations put forward in
> draft-york-dart-dscp-rtp-00 in that
> it ensures that the DSCP markings  do not result in re-ordering  within the
> media flow, but has it been ascertained, from a CC
> perspective that usage of different drop precedence within the same CC
> context is viable ?

Good question - I will include that in my slides for the dart WG meeting.

> >From the RTCWEB data channel perspective this certainly isn't viable (being
> SCTP based),
> whether it is viable from an RMCAT CC perspective is something that we in
> the RMCAT wg would need to
> make more clear.

What's the rationale for "certainly isn't viable" regarding different drop
precedences within a single SCTP session?

Thanks,
--David (as an editor of draft-york, *not* as a tsvwg WG chair)

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Karen E. Egede
> Nielsen
> Sent: Sunday, July 20, 2014 4:49 PM
> To: [email-masked]
> Cc: rmcat WG
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
> 
> Hi,
> 
> Please accept the following comments:
> 
> I wonder if the recommendations of this document should not relate to the
> viability (or rather the opposite) of
> handling different RTCWEB data channels individually from a DSCP markings
> perspective. Or more generally
> relate to the fact that media streams within the same congestion control
> context cannot be handled individually.
> Right now such considerations are not in the document. If the intention is
> for such consideration to come
> in documents from the dart wg, then it would be very important to  have a
> reference to this dependency - or ?
> 
> Something else:
> 
> Right now the document stipulates that packets within the same media stream
> may be marked with different DSCP codepoints, i.e.,
> it is said:
> 
>    One may select difference drop precedences for the
>    different packets in the media flow.  Therefore, all packets in the
>    stream SHOULD be marked with the same priority but can have
>    difference drop precedences.
> 
> which indeed is in compliance with the recommendations put forward in
> draft-york-dart-dscp-rtp-00 in that
> it ensures that the DSCP markings  do not result in re-ordering  within the
> media flow, but has it been ascertained, from a CC
> perspective that usage of different drop precedence within the same CC
> context is viable ?
> 
> >From the RTCWEB data channel perspective this certainly isn't viable (being
> SCTP based),
> whether it is viable from an RMCAT CC perspective is something that we in
> the RMCAT wg would need to
> make more clear.
> 
> BR, Karen
> 
> > -----Original Message-----
> > From: tsvwg [mailto:[email-masked]] On Behalf Of internet-
> > [email-masked]
> > Sent: 23. juni 2014 21:12
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >  This draft is a work item of the Transport Area Working Group Working
> > Group of the IETF.
> >
> >         Title           : DSCP and other packet markings for RTCWeb QoS
> >         Authors         : Subha Dhesikan
> >                           Cullen Jennings
> >                           Dan Druta
> >                           Paul Jones
> >                           James Polk
> > 	Filename        : draft-ietf-tsvwg-rtcweb-qos-02.txt
> > 	Pages           : 7
> > 	Date            : 2014-06-23
> >
> > Abstract:
> >    Many networks, such as service provider and enterprise networks, can
> >    provide per packet treatments based on Differentiated Services Code
> >    Points (DSCP) on a per-hop basis.  This document provides the
> >    recommended DSCP values for browsers to use for various classes of
> >    traffic.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/

---

From: "Black, David" <[email-masked]>
Date: Sun, 20 Jul 2014 22:00:28 -0400

Karen,

> [Karen] Ok - "certainly not viable" is too strong formulation.
> Having different drop precedences within the same SCTP CC context would,
> given that SCTP CC presently is drop driven only,
> results in that the whole data channel is impacted, from a CC perspective,
> by the highest drop precedence. But I realize that whether this is
> acceptable is a question indeed.

I think you're on to something here.  If the drop precedences only came into
play after the decision to drop a packet had been made, their effect would
probably be minimal, as they would only affect what to drop in a session, not
how much to drop.  OTOH, DiffServ AF is not intended to operate in that fashion
- the rationale for the 3 drop precedences per AF class was based on envisioning
the output of two-threshold rate shaper:
	AFx1 - Within base or committed traffic profile
	AFx2 - Beyond base/committed, but within excess or burst traffic profile
	AFx3 - Completely out of profile

Hence the relative mix of those drop precedences can be expected to affect
the overall drop rate/probability seen in a session where those precedences
are mixed.

Thanks,
--David

> From: Karen E. Egede Nielsen [mailto:[email-masked]]
> Sent: Sunday, July 20, 2014 9:20 PM
> To: Black, David; [email-masked]
> Cc: rmcat WG; [email-masked]
> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
> 
> Hi,
> 
> > From: Black, David [mailto:[email-masked]]
> > Sent: 21. juli 2014 02:51
> > To: Karen E. Egede Nielsen; [email-masked]
> > Cc: rmcat WG; [email-masked]; Black, David
> > Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
> >
> > Karen,
> >
> > > I wonder if the recommendations of this document should not relate to
> > > the viability (or rather the opposite) of handling different RTCWEB
> > > data channels individually from a DSCP markings perspective. Or more
> > > generally relate to the fact that media streams within the same
> > > congestion control context cannot be handled individually.
> > > Right now such considerations are not in the document. If the
> > > intention is for such consideration to come in documents from the dart
> > > wg, then it would be very important to  have a reference to this
> > > dependency - or ?
> >
> > > Right now the document stipulates that packets within the same media
> > > stream may be marked with different DSCP codepoints, i.e., it is said:
> > >
> > > it ensures that the DSCP markings  do not result in re-ordering
> > > within the media flow, but has it been ascertained, from a CC
> > > whether it is viable from an RMCAT CC perspective is something that we
> > > in the RMCAT wg would need to make more clear.
> >
> [Karen] Ok - "certainly not viable" is too strong formulation.
> Having different drop precedences within the same SCTP CC context would,
> given that SCTP CC presently is drop driven only,
> results in that the whole data channel is impacted, from a CC perspective,
> by the highest drop precedence. But I realize that whether this is
> acceptable is a question indeed.
> 
> >
> > Thanks,
> > > From: tsvwg [mailto:[email-masked]] On Behalf Of Karen E.
> > > Egede Nielsen
> > > I wonder if the recommendations of this document should not relate to
> > > the viability (or rather the opposite) of handling different RTCWEB
> > > data channels individually from a DSCP markings perspective. Or more
> > > generally relate to the fact that media streams within the same
> > > congestion control context cannot be handled individually.
> > > Right now such considerations are not in the document. If the
> > > intention is for such consideration to come in documents from the dart
> > > wg, then it would be very important to  have a reference to this
> > > dependency - or ?
> > >
> > > Something else:
> > >
> > > Right now the document stipulates that packets within the same media
> > > stream may be marked with different DSCP codepoints, i.e., it is said:
> > >
> > > it ensures that the DSCP markings  do not result in re-ordering
> > > within the media flow, but has it been ascertained, from a CC
> > > whether it is viable from an RMCAT CC perspective is something that we
> > > in the RMCAT wg would need to make more clear.
> > >
> > > BR, Karen
> > >
> > > >  This draft is a work item of the Transport Area Working Group
> > > > Working Group of the IETF.
> > > >
> > > > submission until the htmlized version and diff are available at
> > > > tools.ietf.org.
> > > >

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jul 2014 23:08:33 +1200

> the overall drop rate/probability seen in a session where those precedences

Yes. And it was clearly aimed at layered video, such that there was
a benefit to the end user in dropping the least important layer
during lossy periods. With anything like a TCP-like congestion
control algorithm in sight, the effects may be completely bizarre.

   Brian

---

From: Michael Welzl <[email-masked]>
Date: Mon, 21 Jul 2014 14:13:31 +0200

> control algorithm in sight, the effects may be completely bizarre.

Reordering could make this even worse. Could different drop precedences cause reordering?

Cheers,
Michael

---

From: "Black, David" <[email-masked]>
Date: Mon, 21 Jul 2014 09:02:17 -0400

> Reordering could make this even worse. Could different drop precedences cause

No, packets MUST NOT be reordered among the three drop precedences within
an AF class (e.g., AF2x).  See RFC 2597 and draft-york.

Thanks,
--David

> From: Michael Welzl [mailto:[email-masked]]
> Sent: Monday, July 21, 2014 8:14 AM
> To: Brian E Carpenter
> Cc: Black, David; Karen E. Egede Nielsen; rmcat WG; [email-masked];
> [email-masked]

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 21 Jul 2014 03:20:16 +0200

Hi,