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

["Black, David" <[e-mail]>]

Karen,

> > What's the rationale for "certainly isn't viable" regarding different drop
> > precedences within a single SCTP session?
>
> [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

> -----Original Message-----
> From: Karen E. Egede Nielsen [mailto:[e-mail]]
> Sent: Sunday, July 20, 2014 9:20 PM
> To: Black, David; [e-mail]
> Cc: rmcat WG; [e-mail]
> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
> 
> Hi,
> 
> > -----Original Message-----
> > From: Black, David [mailto:[e-mail]]
> > Sent: 21. juli 2014 02:51
> > To: Karen E. Egede Nielsen; [e-mail]
> > Cc: rmcat WG; [e-mail]; Black, David
> > Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
> >
> > 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?
> [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,
> > --David (as an editor of draft-york, *not* as a tsvwg WG chair)
> >
> > > -----Original Message-----
> > > From: tsvwg [mailto:[e-mail]] On Behalf Of Karen E.
> > > Egede Nielsen
> > > Sent: Sunday, July 20, 2014 4:49 PM
> > > To: [e-mail]
> > > 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:[e-mail]] On Behalf Of internet-
> > > > [e-mail]
> > > > Sent: 23. juni 2014 21:12
> > > > To: [e-mail]
> > > > Cc: [e-mail]
> > > > 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/