Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-13 - one last change

From: "Black, David" <[email-masked]>
Date: Tue, 1 Mar 2016 19:54:30 +0000

Something like Brian's change should be done - while the change is fairly small,
given the amount of attention that CS1 and LE have garnered, I concur that a
direct citation of (and reference to) RFC 3662 ought to be in the version of
the draft that we send to the IESG.

Authors - please make that change (or some approximation of it), and the
I'll hand the resulting -14 version of the draft off to our ADs with the RFC
publication request by the end of this week.

Thanks, --David

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, February 29, 2016 5:12 PM
> To: Black, David; [email-masked]
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-13 - please check
> 
> On 01/03/2016 09:34, Black, David wrote:
> > If you had any comments on the -12 version of this draft, please check -13.
> 
> Hmm. Maybe this was discussed earlier but I suddenly noticed that there is
> no reference to RFC 3662. That seems odd to me. Friendly suggestion:
> 
> OLD:
>    The above table assumes that packets marked with CS1 are treated as
>    "less than best effort".
> 
> NEW:
>    The above table assumes that packets marked with CS1 are treated as
>    "less than best effort", such as the LE behaviour described in [RFC3662].
> 
> That's an Informational reference.
> 
> Sorry I missed this last time.
> 
>    Brian
> 
> >
> > I'm going to give this a few days and then submit the RFC publication request
> for this
> > draft by the end of this week.  This draft has been in this WG for long enough,
> it's
> > time to move it onward.
> >
> > Thanks, --David
> >
> >> -----Original Message-----
> >> From: Paul E. Jones [mailto:[email-masked]]
> >> Sent: Monday, February 29, 2016 2:47 PM
> >> To: Black, David; Anna Brunstrom; Michael Welzl
> >> Cc: [email-masked]; Brian E Carpenter
> >> Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb
> 13
> >>
> >> Folks,
> >>
> >> I published a new version of the draft.  Hopefully, I did capture all of
> >> the input, though there is certainly a possibility that  missed
> >> something, given all the back-and-forth.
> >>
> >> Please review -13 and let me know if there is anything I missed or if
> >> something needs to be re-worded.
> >>
> >> Paul
> >>
> >> ------ Original Message ------
> >> From: "Black, David" <[email-masked]>
> >> To: "Anna Brunstrom" <[email-masked]>; "Michael Welzl"
> >> <[email-masked]>
> >> Cc: "[email-masked]" <[email-masked]>
> >> Sent: 2/26/2016 10:50:42 AM
> >> Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends
> >> Feb 13
> >>
> >>>>  And this is the same as for the data channel, the SCTP scheduler
> >>>>  is used for flows with the same DSCP value.
> >>>
> >>> Actually the SCTP scheduler functions more broadly, as all flows in the
> >>> data channel use the same DSCP at any point in time, hence the SCTP
> >>> scheduler spans all of them.  That DSCP can change over time, as
> >>> further
> >>> described in the draft.
> >>>
> >>>>  I am ok with the current text and leaving the "and". As the
> >>>> relationship
> >>>>  between the DSCPs and coupled cc is anyway discussed in more detail
> >>>> in
> >>>>  RFC 7657, I guess there is no need to repeat it here.
> >>>
> >>> Good - the authors should have enough information now to post a revised
> >>> version
> >>> of the draft that reflects all of the topics discussed.  Once that
> >>> appears, I'll work
> >>> on sending in the RFC publication request to hand it off to our ADs.
> >>>
> >>> Thanks, --David
> >>>
> >>>
> >>>>  -----Original Message-----
> >>>>  From: Anna Brunstrom [mailto:[email-masked]]
> >>>>  Sent: Thursday, February 25, 2016 6:40 PM
> >>>>  To: Black, David; Michael Welzl
> >>>>  Cc: [email-masked]
> >>>>  Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 -
> >>>> ends Feb 13
> >>>>
> >>>>  On 2016-02-25 21:16, Black, David wrote:
> >>>>  >>> Nonetheless, within the set of media flows that use the same
> >>>> DSCP,
> >>>>  application
> >>>>  >>> priority may be a useful input to the coupled congestion
> >>>> controller.
> >>>>
> >>>>  True. And this is the same as for the data channel, the SCTP
> >>>> scheduler
> >>>>  is used for flows with the same DSCP value.
> >>>>
> >>>>  >> s/may be/is definitely
> >>>>  >> :-)    => DSCPs *may* work or not, whereas - when you do know
> >>>> you're going
> >>>>  >> across the same bottleneck - priorities *always* work out very
> >>>> precisely with
> >>>>  >> coupled cc.
> >>>>  > Michael - That's what I understood, but I thought I'd let you say
> >>>> it ;-).
> >>>>  >
> >>>>  > Anna - if there are text changes that you would like to see, please
> >>>> provide
> >>>>  specific wording.
> >>>>
> >>>>  I am ok with the current text and leaving the "and". As the
> >>>> relationship
> >>>>  between the DSCPs and coupled cc is anyway discussed in more detail
> >>>> in
> >>>>  RFC 7657, I guess there is no need to repeat it here.
> >>>>
> >>>>  Thanks,
> >>>>  Anna
> >>>>
> >>>>  >
> >>>>  > Thanks, --David
> >>>>  >
> >>>>  >> -----Original Message-----
> >>>>  >> From: Michael Welzl [mailto:[email-masked]]
> >>>>  >> Sent: Thursday, February 25, 2016 4:38 AM
> >>>>  >> To: Black, David
> >>>>  >> Cc: Anna Brunstrom; [email-masked]
> >>>>  >> Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 -
> >>>> ends Feb
> >>>>  13
> >>>>  >>
> >>>>  >>
> >>>>  >>> On 25 Feb 2016, at 01:38, Black, David <[email-masked]>
> >>>> wrote:
> >>>>  >>>
> >>>>  >>>> If you set different DSCP values for the different flows, you
> >>>> are less
> >>>>  >>>> likely to be able to use coupled congestion control to manage
> >>>> the
> >>>>  >>>> priorities.
> >>>>  >>> That's not only "less likely" ... it's actually a bad idea, as
> >>>> explained in more
> >>>>  detail
> >>>>  >>> in section 5.1 and the first bullet of section 6 of RFC 7657
> >>>> (Michael W. helped
> >>>>  >>> write that text).
> >>>>  >> It depends:
> >>>>  >>
> >>>>  >> Within the same AF class, you may end up in the same bottleneck
> >>>> queue but
> >>>>  >> have different drop precedence values for the various coupled
> >>>> flows; how to
> >>>>  >> correctly couple flows could then make for interesting research
> >>>> but hasn't
> >>>>  been
> >>>>  >> investigated yet. With DSCPs that may put you in different queues,
> >>>> a
> >>>>  >> measurement based shared bottleneck detection mechanism such as
> >>>> draft-
> >>>>  ietf-
> >>>>  >> rmcat-sbd-03 could work: just because DSCPs MAY put you in
> >>>> different
> >>>>  queues,
> >>>>  >> the could also be ignored in the network, and even if they're not
> >>>> then this
> >>>>  might
> >>>>  >> not happen at the bottleneck.
> >>>>  >>
> >>>>  >> I think I ended up recommending to not couple when DSCPs are
> >>>> different as a
> >>>>  >> general simplification in the DART group.
> >>>>  >>
> >>>>  >>
> >>>>  >>> Nonetheless, within the set of media flows that use the same
> >>>> DSCP,
> >>>>  application
> >>>>  >>> priority may be a useful input to the coupled congestion
> >>>> controller.
> >>>>  >> s/may be/is definitely
> >>>>  >> :-)    => DSCPs *may* work or not, whereas - when you do know
> >>>> you're going
> >>>>  >> across the same bottleneck - priorities *always* work out very
> >>>> precisely with
> >>>>  >> coupled cc.
> >>>>  >>
> >>>>  >> Cheers,
> >>>>  >> Michael
> >>>>  >>
> >>>>  >>
> >>>>  >>>> But it may still be
> >>>>  >>>> possible to use both in some cases, so in that sense using and
> >>>> is not
> >>>>  >>>> necessarily wrong, but a bit misleading. In the common case I
> >>>> think you
> >>>>  >>>> would not be able to use both different DSCP values and coupled
> >>>> cc.
> >>>>  >>> That may be - it depends on how many media flows there are and
> >>>> how much
> >>>>  >>> they're spread across the DSCP values.
> >>>>  >>>
> >>>>  >>> As  noted above, the existing text is not wrong - if there's a
> >>>> specific change
> >>>>  >>> that you want to see, please propose specific wording.
> >>>>  >>>
> >>>>  >>> Thanks, --David
> >>>>  >>>
> >>>>  >>>> -----Original Message-----
> >>>>  >>>> From: Anna Brunstrom [mailto:[email-masked]]
> >>>>  >>>> Sent: Monday, February 22, 2016 6:09 PM
> >>>>  >>>> To: Black, David
> >>>>  >>>> Cc: [email-masked]
> >>>>  >>>> Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12
> >>>> - ends
> >>>>  Feb
> >>>>  >> 13
> >>>>  >>>> On 2016-02-22 04:19, Black, David wrote:
> >>>>  >>>>>> Reading this conversation made me wonder if the AND could be
> >>>>  confusing.
> >>>>  >>>>>> The text may perhaps be interpreted as the typical case is to
> >>>> use the
> >>>>  >>>>>> priority for selecting different DSCP values for different
> >>>> flows and at
> >>>>  >>>>>> the same time use it as input for coupled congestion control,
> >>>> whereas
> >>>>  >>>>>> normally you would use one mechanism or the other I assume?
> >>>>  >>>>> Well, for the data channel analogs, "both" is definitely
> >>>> correct, as
> >>>>  >>>>> the application priority is input to both the SCTP stream
> >>>> scheduler and to
> >>>>  >>>>> DSCP determination.  What's the situation for media?
> >>>>  >>>> If you set different DSCP values for the different flows, you
> >>>> are less
> >>>>  >>>> likely to be able to use coupled congestion control to manage
> >>>> the
> >>>>  >>>> priorities. You can not couple the flows based on using the same
> >>>>  >>>> five-tuple and DSCP (as is described in
> >>>> draft-ietf-rmcat-coupled-cc) and
> >>>>  >>>> you may no longer share a common bottleneck. But it may still be
> >>>>  >>>> possible to use both in some cases, so in that sense using and
> >>>> is not
> >>>>  >>>> necessarily wrong, but a bit misleading. In the common case I
> >>>> think you
> >>>>  >>>> would not be able to use both different DSCP values and coupled
> >>>> cc.
> >>>>  >>>>
> >>>>  >>>> Anna
> >>>>  >>>>
> >>>>  >>>>> Thanks, --David
> >>>>  >>>>>
> >>>>  >>>>>> -----Original Message-----
> >>>>  >>>>>> From: Anna Brunstrom [mailto:[email-masked]]
> >>>>  >>>>>> Sent: Friday, February 19, 2016 5:33 AM
> >>>>  >>>>>> To: Black, David; [email-masked]; Michael Welzl
> >>>>  >>>>>> Cc: [email-masked]
> >>>>  >>>>>> Subject: Re: [tsvwg] TSVWG WGLC:
> >>>> draft-ietf-tsvwg-rtcweb-qos-12 -
> >>>>  ends
> >>>>  >> Feb
> >>>>  >>>> 13
> >>>>  >>>>>> Hi,
> >>>>  >>>>>>
> >>>>  >>>>>> On 2016-02-19 01:48, Black, David wrote:
> >>>>  >>>>>>> Paul writes:
> >>>>  >>>>>>>
> >>>>  >>>>>>>> I'm definitely perfectly OK with making those changes if the
> >>>> group is.
> >>>>  >>>>>>> Assuming no further objections are seen on the list, that
> >>>> should be
> >>>>  done.
> >>>>  >>>>>>>
> >>>>  >>>>>>> I would like to see one edit to Michael's first new chunk of
> >>>> text:
> >>>>  >>>>>>>
> >>>>  >>>>>>>>> Anyway, my suggestion would be to update the first
> >>>> paragraph as
> >>>>  >> follows:
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>>      The application priority, indicated by the columns
> >>>> "very low",
> >>>>  "low",
> >>>>  >>>>>>>>>      "Medium", and "high", signifies the relative
> >>>> importance of the
> >>>>  flow
> >>>>  >>>>>>>>>      within the application.  It is an input that the
> >>>> browser receives to
> >>>>  >>>>>>>>>      assist it in either selecting the DSCP value or
> >>>> adjusting the network
> >>>>  >>>>>>>>>      transport behavior.
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>> Please change the last two lines to:
> >>>>  >>>>>>>
> >>>>  >>>>>>>       assist in selecting the DSCP value and adjusting the
> >>>> network
> >>>>  >>>>>>>       transport behavior.
> >>>>  >>>>>>>
> >>>>  >>>>>>> I'm changing the "either/or" construct to an "and" construct
> >>>> because
> >>>>  the
> >>>>  >>>>>>> application priority always assists with both aspects for the
> >>>> data
> >>>>  channel,
> >>>>  >> via
> >>>>  >>>>>>> that priority being an input to the SCTP scheduler (as noted
> >>>> further on
> >>>>  in
> >>>>  >>>>>>> Michael's message), and it appears that the same is true for
> >>>> media
> >>>>  flows
> >>>>  >>>>>>> via that priority being an input to the coupled congestion
> >>>> control
> >>>>  manager.
> >>>>  >>>>>> Reading this conversation made me wonder if the AND could be
> >>>>  confusing.
> >>>>  >>>>>> The text may perhaps be interpreted as the typical case is to
> >>>> use the
> >>>>  >>>>>> priority for selecting different DSCP values for different
> >>>> flows and at
> >>>>  >>>>>> the same time use it as input for coupled congestion control,
> >>>> whereas
> >>>>  >>>>>> normally you would use one mechanism or the other I assume?
> >>>>  >>>>>>
> >>>>  >>>>>> Of course, if this text anyway refers to  NETWORK transport
> >>>> and not to
> >>>>  >>>>>> coupled cc, there should be no confusion. But perhaps
> >>>> somewhere in
> >>>>  the
> >>>>  >>>>>> draft it could be good to note that the use of different DSCP
> >>>> values for
> >>>>  >>>>>> different flows may limit the possibility to use coupled
> >>>> congestion
> >>>>  >>>>>> control for these flows?
> >>>>  >>>>>>
> >>>>  >>>>>> Just a thought.
> >>>>  >>>>>>
> >>>>  >>>>>> Cheers,
> >>>>  >>>>>> Anna
> >>>>  >>>>>>
> >>>>  >>>>>>
> >>>>  >>>>>>> Thanks, --David
> >>>>  >>>>>>>
> >>>>  >>>>>>>> -----Original Message-----
> >>>>  >>>>>>>> From: Paul E. Jones [mailto:[email-masked]]
> >>>>  >>>>>>>> Sent: Thursday, February 18, 2016 6:35 PM
> >>>>  >>>>>>>> To: Michael Welzl; Black, David
> >>>>  >>>>>>>> Cc: Brian E Carpenter; [email-masked]
> >>>>  >>>>>>>> Subject: Re: [tsvwg] TSVWG WGLC:
> >>>> draft-ietf-tsvwg-rtcweb-qos-12 -
> >>>>  >> ends
> >>>>  >>>> Feb
> >>>>  >>>>>> 13
> >>>>  >>>>>>>> Michael,
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>>      The application priority, indicated by the columns
> >>>> "very low",
> >>>>  >>>>>>>>> "low",
> >>>>  >>>>>>>>>      "Medium", and "high", signifies the relative
> >>>> importance of the
> >>>>  flow
> >>>>  >>>>>>>>>      within the application.  It is an input that the
> >>>> browser receives to
> >>>>  >>>>>>>>>      assist it in selecting the DSCP value.  Application
> >>>> priority does
> >>>>  >>>>>>>>> not
> >>>>  >>>>>>>>>      refer to priority in the network transport.
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>> when it says that Application priority doesn’t refer to
> >>>> priority in the
> >>>>  >>>>>>>>> network transport. Doesn’t this also contradict this later
> >>>> paragraph?
> >>>>  >>>>>>>> This is one of those touchy topics where the slightest
> >>>>  misrepresentation
> >>>>  >>>>>>>> causes a line to form at the mic :-)
> >>>>  >>>>>>>>
> >>>>  >>>>>>>> The history with this, if I recall correctly, was that the
> >>>> application
> >>>>  >>>>>>>> has some notion of what it views as the priority of a flow.
> >>>> However,
> >>>>  >>>>>>>> assigning a DSCP value is not equal to indicating a
> >>>> priority.  Rather,
> >>>>  >>>>>>>> the DSCP value is used by the network to perform treatment
> >>>> of the
> >>>>  >> packet
> >>>>  >>>>>>>> at a given hop and that's not a "priority", per se.
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>>      It is worth noting that the application priority is
> >>>> utilized by the
> >>>>  >>>>>>>>>      SCTP scheduler for data channel traffic per
> >>>>  >>>>>>>>>      [I-D.ietf-rtcweb-data-channel].
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> So: it’s worth noting that app priority is used for the
> >>>> data channel,
> >>>>  >>>>>>>>> yet "app priority doesn’t refer to priority in the network
> >>>> transport”?
> >>>>  >>>>>>>>> What’s that then supposed to mean? Maybe I’m missing
> >>>>  something...
> >>>>  >>>>>>>> The application does has some notion of priority and it can
> >>>> do things
> >>>>  >>>>>>>> locally.  The only point was, as I noted above, was that
> >>>> application
> >>>>  >>>>>>>> priority does not translate to meaning DSCPs have some
> >>>> notion of
> >>>>  >>>>>>>> priority.
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>> Anyway, my suggestion would be to update the first
> >>>> paragraph as
> >>>>  >>>>>>>>> follows:
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>>      The application priority, indicated by the columns
> >>>> "very low",
> >>>>  >>>>>>>>> "low",
> >>>>  >>>>>>>>>      "Medium", and "high", signifies the relative
> >>>> importance of the
> >>>>  flow
> >>>>  >>>>>>>>>      within the application.  It is an input that the
> >>>> browser receives to
> >>>>  >>>>>>>>>      assist it in either selecting the DSCP value or
> >>>> adjusting the
> >>>>  >>>>>>>>> network
> >>>>  >>>>>>>>>      transport behavior.
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>>
> >>>>  >>>>>>>>> and the second as follows:
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>>>      It is worth noting that the application priority is
> >>>> utilized by the
> >>>>  >>>>>>>>>      coupled congestion control mechanism for media flows
> >>>> per
> >>>>  >>>>>>>>>      [citation to: draft-ietf-rmcat-coupled-cc]
> >>>>  >>>>>>>>>      and the SCTP scheduler for data channel traffic per
> >>>>  >>>>>>>>>      [I-D.ietf-rtcweb-data-channel].
> >>>>  >>>>>>>>> ***
> >>>>  >>>>>>>> I'm definitely perfectly OK with making those changes if the
> >>>> group is.
> >>>>  >>>>>>>>
> >>>>  >>>>>>>>> Again, very sorry for sending this too late. This doesn’t
> >>>> change
> >>>>  >>>>>>>>> anything about the actual mechanism proposed, so if it
> >>>> can’t be
> >>>>  >>>>>>>>> incorporated, it’s not the end of the world - hopefully I
> >>>> wont miss
> >>>>  the
> >>>>  >>>>>>>>> deadline to suggest text for draft-ietf-rtcweb-transports …
> >>>>  >>>>>>>> Oh, no worries at all.  I still have a few edits to make
> >>>> that Ben
> >>>>  >>>>>>>> requested.  They should not take long.  I can make those and
> >>>> these
> >>>>  you
> >>>>  >>>>>>>> suggest and publish a new draft this weekend (when I get
> >>>> time to
> >>>>  >>>>>>>> actually work on the document).
> >>>>  >>>>>>>>
> >>>>  >>>>>>>> Paul
> >>>>
> >>>
> >

---

From: "Black, David" <[email-masked]>
Date: Thu, 10 Mar 2016 04:28:58 +0000

Quick reminder to the draft authors - I'm looking for a -14 version of  the
tsvwg-rtcweb-qos draft with the one small text change described below.

I will promptly submit that version to our ADs for RFC publication (towards IETF
Last Call).  Please submit  that -14 version within about the next  week so that
this draft  can be on its way before the Buenos Aires meetings (final draft
submission cutoff date for  the Buenos Aires meetings is March 21).

Thanks, --David

> From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
> Sent: Tuesday, March 01, 2016 2:55 PM
> To: Brian E Carpenter; [email-masked]
> Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-13 - one last change
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 10 Mar 2016 16:43:57 +0000

David,

I apologize for not seeing the request last week.  I just submitted -14 
that included Brian's suggested text.  If there is anything I missed, 
I'm happy to submit a -15 to address any oversight.

Paul

------ Original Message ------
From: "Black, David" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 3/9/2016 11:28:58 PM
Subject: Re: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-13 - one last change

>>draft-ietf-tsvwg-rtcweb-qos-12
>>  > >>>> - ends
>>  > >>>>  Feb
>>  > >>>>  >> 13

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2016 07:43:56 +1300

Looks good to me, thanks!

Regards
   Brian

On 11/03/2016 05:43, Paul E. Jones wrote:
>  David,
> 
> I apologize for not seeing the request last week.  I just submitted -14 that included Brian's suggested text.  If there is
> anything I missed, I'm happy to submit a -15 to address any oversight.
> 
> Paul
>