Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Feb 2016 17:07:36 +1300

Hi,

>    Traditionally, DSCP values have been thought of as being site
>    specific, with each site selecting its own code points for
>    controlling per-hop-behavior to influence the QoS for transport-layer
>    flows. 

It isn't really "tradition"; it's defined that way in RFC 2474. I would
suggest something like

 DSCP values are in principle site specific, with each site selecting its
 own code points for controlling per-hop-behavior to influence the QoS for
 transport-layer flows.

Also, is this the place to mention that there is ongoing work on diffserv
interconnection between carriers (draft-ietf-tsvwg-diffserv-intercon)?
This is relevant, because if successful, we can expect the code points used
for interconnection to become very widely used.

> 2.  Relation to Other Standards

Largish nit: not all RFCs are standards. This should probably be:

 2.  Relation to Other Documents

>    The DSCP value set by the endpoint is not trusted by the network.  In
>    addition, the DSCP value may be remarked at any place in the network
>    for a variety of reasons to any other DSCP value, including default
>    forwarding (DF) value to provide basic best effort service.  The
>    mitigation for such action is through an authorization mechanism.
>    Such authorization mechanism is outside the scope of this document.

I don't think authorization is *the* mitigation; it's one possible
mitigation. Another possible mitigation is draft-ietf-tsvwg-diffserv-intercon,
for example.

>          Table 1: Recommended DSCP Values for WebRTC Applications
...
>    The above table assumes that packets marked with CS1 are treated as
>    "less than best effort".

Needless to say, this still gives me heartburn. Firstly, it is *not* CS1.
Its DSCP value is binary 001000 but the behavior abbreviation is LE, as
defined in RFC 3662. It's an example of a site-specific code point. IMHO
it should be called LE in the table and the text. There should be a statement
that the standard use of this code point is a *different* behavior called
CS1.

> It is common for CS1 to be treated the same as DF,...

Right, in which case marking your traffic LE and getting DF treatment is not
so bad. But it's completely compatible with RFC 2474 for CS1 to be treated
better than DF. I think that risk should be mentioned.

>    Implementers should also note
>    that excess EF traffic is dropped.  This could mean that a packet
>    marked as EF may not get through as opposed to a packet marked with a
>    different DSCP value.

But that's exactly why you use EF for traffic that wants timely delivery
more than it hates loss. People designing codecs kind of know this.

>    In summary, DSCP marking provides neither guarantees nor promised
>    levels of service.  The service provided to a packet is dependent
>    upon the network design along the path, as well as the network
>    conditions at every hop.

That's a bit of a gloomy ending. It might be fair to insert a sentence
in the middle, like: However, DSCP marking is expected to provide
a statistical improvement in the real-time service as a whole.

   Brian

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 14 Feb 2016 07:15:50 +0000

Brian,

>  own code points for controlling per-hop-behavior to influence the QoS 

Sounds good.  I've made this change to my local draft.

>for interconnection to become very widely used.

In general, it's best to not speculate, I think.  If they become so 
widely used, I doubt a reference would be necessary.  However, I'm not 
opposed to adding something if the group wants it.  Exactly what were 
you thinking?  I would hope this does not hold up the draft due to a 
missing reference.

>  2.  Relation to Other Documents

OK, I can do that.  Is "documents" preferred or should we say 
"specifications"?

>draft-ietf-tsvwg-diffserv-intercon,

OK, I changed "the" to "a".  This focus of this document is the web 
browser, so I think the trust issues here are separate from those of 
interconnection, or am I wrong?

>that the standard use of this code point is a *different* behavior 

This was used to be consistent with RFC 4594.  If LE is preferred, I can 
change it, but then should that mean we need to revised RFC 4594?   
Section 3.2 of RFC 3662 says there are one of several values that might 
be used for LE traffic, with CS1 being one choice.  So, is it wrong to 
specify CS1 here and RFC 4594?

>better than DF. I think that risk should be mentioned.
OK, how about right after that sentence I add:

"However, it is also possible per [RFC2474] for CS1 traffic to be given 
better treatment than DF, thus caution should be exercised when electing 
to use CS1."

Then I would start a new paragraph to talk about EF.

>more than it hates loss. People designing codecs kind of know this.

Is the warning harmful?  I think it's useful for those who do not know 
this.

>a statistical improvement in the real-time service as a whole.

Yeah, it is gloomy.  I'm not sure who wrote that, but somebody felt we 
needed this reminder of reality.  Personally, I don't like gloom and 
doom, especially since there are ways to effectively use DSCP. :-)

I'll add your suggested sentence.

Now, I've been "warned" before about publishing updated in the middle of 
a LC review.  I think the review period has now concluded.  Shall I 
publish what I have and give folks one more opportunity to look over the 
text?

Thanks!
Paul

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Feb 2016 08:40:33 +1300

Hi Paul,

On 14/02/2016 20:15, Paul E. Jones wrote:
> In general, it's best to not speculate, I think.  If they become so widely used, I doubt a reference would be necessary. 
> However, I'm not opposed to adding something if the group wants it.  Exactly what were you thinking?  I would hope this does not
> hold up the draft due to a missing reference.

I take your point about dangling references, although both are tsvwg drafts
so maybe the WG chairs have an opinion about whether this is a real concern. But
yes, no need to mention it here - see below.

> OK, I can do that.  Is "documents" preferred or should we say "specifications"?

I have no strong view on that.

> OK, I changed "the" to "a".  This focus of this document is the web browser, so I think the trust issues here are separate from
> those of interconnection, or am I wrong?

Well, it all depends, unfortunately. If the browser is in a domain that has no
diffserv support at all, and the next domain along does no diffserv conditioning
at ingress, but then does support diffserv interconnection at egres, and so
on further along the path, things may work out...

On balance a better reference here would be RFC7657 Section 3.2, which
discusses this aspect and does have an informational reference to -diffserv-intercon.

> This was used to be consistent with RFC 4594.  If LE is preferred, I can change it, but then should that mean we need to revised
> RFC 4594?   Section 3.2 of RFC 3662 says there are one of several values that might be used for LE traffic, with CS1 being one
> choice.  So, is it wrong to specify CS1 here and RFC 4594?

RFC 4594 simply describes CS1 as "Low-Priority - Any flow that has no BW assurance"
which is completely consistent with RFC 2474. However, I think its citations
of RFC 3662 are problematic. The underlying problem is that RFC 3662 is badly
written in this respect. This text is completely inconsistent with RFC 2474:

   If a CS PHB is used, note that this configuration will violate the
   "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have
   a less timely forwarding than CS0.  An operator's goal of providing
   an LE PDB is sufficient cause for violating the SHOULD.

What that *should* say is something like:

   If the DSCP value reserved for CS1 by RFC 2474 is used to indicate the LE
   PDB, this configuration will violate the "MUST" of section 4.3 of RFC 2474
   [RFC2474] and will nullify the intention of RFC 2474 of backwards
   compatibility with IP Precedence. An operator providing an LE PDB
   by overriding the standard meaning of the DSCP value reserved for CS1
   is intentionally violating RFC 2474.

So yes, if the community wants to get this right, RFC 4594 needs some cosmetic
work and RFC 3662 needs to be corrected and moved to standards track.
But for the present draft, I still think that suggesting to use the code
point reserved for CS1 in the vague hope that it will get the unstandardized
behaviour called LE is a very bad idea. In most networks it will get default
service, but in diffserv-aware networks it seems like a coin-toss whether
it gets slightly better or slightly worse service than default.

So what would I do in your shoes?

Firstly, I would label it LE in the table where you have CS1.

Secondly, I would note that LE is not standardized, and that the DSCP value
SHOULD be equated to DF unless it is known that the local network supports
LE, in which case it should be equated to whatever DSCP value is used
locally to support LE, which might or might not be the same as CS1.

> "However, it is also possible per [RFC2474] for CS1 traffic to be given better treatment than DF, thus caution should be
> exercised when electing to use CS1."
> 
> Is the warning harmful?  I think it's useful for those who do not know this.

Agreed, it's just that the phrasing seems to suggest this is a bug rather than
the intended behaviour.

> Yeah, it is gloomy.  I'm not sure who wrote that, but somebody felt we needed this reminder of reality.  Personally, I don't
> like gloom and doom, especially since there are ways to effectively use DSCP. :-)
> 
> Now, I've been "warned" before about publishing updated in the middle of a LC review.  I think the review period has now
> concluded.  Shall I publish what I have and give folks one more opportunity to look over the text?

Ah, that decision is above my pay grade...

Regards
   Brian

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Feb 2016 04:44:57 +0000

Brian,

>>browser, so I think the trust issues here are separate from

This particular paragraph deals with endpoint trust and the fact it 
might be re-marked.  I think if we want to talk more about network 
treatment, we should say something in the following section.  There is a 
paragraph that starts with "If a packet enters a network that has no 
support..."  Perhaps there or a new paragraph following.

If you could suggest text, that would be good.  I'm rather confident 
that if I suggest something, it will be wrong on some technical point. 
:-)

>>  This was used to be consistent with RFC 4594.  If LE is preferred, I 
>>can change it, but then should that mean we need to revised
>>  RFC 4594?   Section 3.2 of RFC 3662 says there are one of several 
>>values that might be used for LE traffic, with CS1 being one

OK, I've noted this in the spec.  Doing what you suggest would simplify 
the language related to CS1 (perhaps replacing the second paragraph 
below the table with works the reflect what you just stated above.  
However, this leaves us without a value.  I'm not sure who wanted CS1 
from the outset, but it's there.

I guess we need to see if folks can agree with replacing CS1 (and the 
explicit value that carries) with LE and leaving the value unspecified.  
I think we should not say it's equal to DF, though, as there is then no 
differentiation between "very low" and "low".  Maybe just say that the 
value is network-dependent?  I don't know.

>Agreed, it's just that the phrasing seems to suggest this is a bug 

Ok, how about we add "This is not a flaw, but how excess EF traffic is 
intended to be treated." at the end of that paragraph?

Paul

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Feb 2016 10:53:54 +1300

Hi Paul,
On 15/02/2016 17:44, Paul E. Jones wrote:
> This particular paragraph deals with endpoint trust and the fact it might be re-marked.  I think if we want to talk more about
> network treatment, we should say something in the following section.  There is a paragraph that starts with "If a packet enters
> a network that has no support..."  Perhaps there or a new paragraph following.
> 
> If you could suggest text, that would be good.  I'm rather confident that if I suggest something, it will be wrong on some
> technical point. :-)

I think it only needs a few words pointing to the full discussion:

There is benefit in marking traffic even if it only benefits the
first few hops. The implications are discussed in Section 3.2 of [RFC7657].

> OK, I've noted this in the spec.  Doing what you suggest would simplify the language related to CS1 (perhaps replacing the
> second paragraph below the table with works the reflect what you just stated above.  However, this leaves us without a value. 
> I'm not sure who wanted CS1 from the outset, but it's there.

The whole confusion stems from a few careless words in RFC 3622.
Suggesting to support LE is a fine idea; calling its code point CS1
is confusing.

> I guess we need to see if folks can agree with replacing CS1 (and the explicit value that carries) with LE and leaving the value
> unspecified.  I think we should not say it's equal to DF, though, as there is then no differentiation between "very low" and
> "low".

Which is indeed likely to be the case in practice.

> Maybe just say that the value is network-dependent?  I don't know.

Yes; that is the exact implication of RFC 2474 and what the operators active
in the diffserv WG said they wanted. My concern is that people often fail to
understand this and end up with magical expectations about the effect of
setting a DSCP value.

> Ok, how about we add "This is not a flaw, but how excess EF traffic is intended to be treated." at the end of that paragraph?

Sure, that would be fine for me.

    Brian

---

From: "Black, David" <[email-masked]>
Date: Thu, 18 Feb 2016 21:00:38 +0000

WGLC on this draft has concluded, and the only comments that I've seen have been
from Brian Carpenter in this thread.  I have a couple of things to note towards resolving
them (these comments are made as WG chair, but dissenting opinions, rants,
observations of things I've missed, etc. are welcome and encouraged - on the list
is preferable to private email).

Adding a sentence to refer to Section 3.2 of RFC 7657 seems like a fine thing to do.

> >> locally to support LE, which might or might not be the same as CS1.

I'm concerned that this is unlikely to be workable for browser implementations,
where a simple static codepoint table is what's wanted (How does a downloaded
browser figure out whether "the local network supports LE"?  It can't ...).  
 
Brian is of course correct about the tortured history of the LE PDB, but I'm reasonably
confident that this draft (tsvwg-rtcweb-qos) needs a static codepoint, not some
version of "it depends" ...

I see two reasonable options:
- Use CS0 (000000) [same as DF] and indicate that this may change in the future.
- Use CS1 (001000) with all the warnings and caveats that have been discussed.
	There's more at the end of Section 3 in RFC 7657 which is already cited
	in the discussion after table 1, although  an additional noted
	that this material is at the end of Section 3 could be useful.

Prior to Brian's comments, the draft was headed for the latter.

There is some background work towards improving RFC 4594, which should include
trying to bring a bit more clarity and consistency to the LE PDB situation (and that
4594bis effort could be used as a vehicle to update the CS1 text in RFC 32662), but
there isn't a good ETA for a -00 4594bis draft, and a normative reference to that
draft from this tsvwg-rtcweb-qos draft seems like a poor idea from a timing
perspective.

I lean towards using CS1 with the rationale being an analog of a classic Winston
Churchill quote:

	“Democracy is the worst form of government, except for all the others.”

	i.e., "CS1 is the worst codepoint, ...

Once we figure out what to do here, a -13 version of the tsvwg-rtcweb-qos draft should be
posted to reflect the agreed-upon changes.

Thanks, --David

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, February 15, 2016 4:54 PM
> To: Paul E. Jones; Black, David; [email-masked]
> Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13
> 
> Hi Paul,
> >>>  OK, I changed "the" to "a".  This focus of this document is the web browser,
> so I think the trust issues here are separate from
> > This particular paragraph deals with endpoint trust and the fact it might be re-
> marked.  I think if we want to talk more about
> > network treatment, we should say something in the following section.  There is
> a paragraph that starts with "If a packet enters
> > If you could suggest text, that would be good.  I'm rather confident that if I
> suggest something, it will be wrong on some
> > technical point. :-)
> 
> >>>  This was used to be consistent with RFC 4594.  If LE is preferred, I can change
> it, but then should that mean we need to revised
> >>>  RFC 4594?   Section 3.2 of RFC 3662 says there are one of several values that
> might be used for LE traffic, with CS1 being one
> > OK, I've noted this in the spec.  Doing what you suggest would simplify the
> language related to CS1 (perhaps replacing the
> > second paragraph below the table with works the reflect what you just stated
> above.  However, this leaves us without a value.
> > I guess we need to see if folks can agree with replacing CS1 (and the explicit
> value that carries) with LE and leaving the value
> > unspecified.  I think we should not say it's equal to DF, though, as there is then
> no differentiation between "very low" and
> > "low".
> 
> > Ok, how about we add "This is not a flaw, but how excess EF traffic is intended
> to be treated." at the end of that paragraph?
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Feb 2016 11:37:44 -1000

Argh - my sincere apologies, I missed that the WGLC has ended! I have a comment, and I wonder if it could still be incorporated? It’s nothing blocking and not super urgent, but I do think it would be a helpful text addition.

People have repeatedly asked me if this draft conflicts with our work on coupled congestion control:
draft-ietf-rmcat-coupled-cc
and I have not made comments on the draft because I think that there is no conflict. Anyway our (coupled-cc) draft states that, if the shared bottleneck is assumed as a result of multiplexing, it would operate only on (multiplexed) flows that also share the same DSCP value.

However, there’s a textual thing there - I think this draft, together with draft-ietf-rtcweb-transports (note to self: don’t miss WGLC of this one!!), too strongly indicates that using the DSCP is pretty much the only thing that can be done to adhere to prorities. In particular, I think this paragraph isn’t correct:

***
   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?

***
   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...

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].
*** 

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 …

Cheers,
Michael

> On 18. feb. 2016, at 11.00, Black, David <[email-masked]> wrote:
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 18 Feb 2016 22:55:46 +0000

Michael,

It's not too late - I'd much rather deal with this as a late WG Last Call comment by comparison
to putting it off until IETF Last Call.

The proposed text changes below strike me as reasonable, but I'd very much like to hear Paul's
views on them, as he's more familiar with the media (as opposed to data) aspects of WebRTC.

Thanks, --David

> From: Michael Welzl [mailto:[email-masked]]
> Sent: Thursday, February 18, 2016 4:38 PM
> To: Black, David
> Cc: Brian E Carpenter; Paul E. Jones; [email-masked]
> Argh - my sincere apologies, I missed that the WGLC has ended! I have a
> comment, and I wonder if it could still be incorporated? It’s nothing blocking and
> not super urgent, but I do think it would be a helpful text addition.
> 
> and I have not made comments on the draft because I think that there is no
> conflict. Anyway our (coupled-cc) draft states that, if the shared bottleneck is
> assumed as a result of multiplexing, it would operate only on (multiplexed) flows
> that also share the same DSCP value.
> 
> However, there’s a textual thing there - I think this draft, together with draft-ietf-
> rtcweb-transports (note to self: don’t miss WGLC of this one!!), too strongly
> indicates that using the DSCP is pretty much the only thing that can be done to
> adhere to prorities. In particular, I think this paragraph isn’t correct:
> 
> ***
> when it says that Application priority doesn’t refer to priority in the network
> transport. Doesn’t this also contradict this later paragraph?
> 
> ***
> 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...
> 
> 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 …
> 
> Cheers,
> Michael
> 
> 
> 
> 
> browser,
> change
> >>>>>>>     marked as EF may not get through as opposed to a packet marked
> with
> >> a
> >>>>>>>     different DSCP value.
> >>>>>>
> intended

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Feb 2016 12:13:22 +1300

Hi David,

> Prior to Brian's comments, the draft was headed for the latter.

If the rough consensus is to recommend 001000 that's OK. But I really think
we are propagating confusion by naming it CS1, because that is the name
of a different behaviour. It's LE (001000).

    Brian

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 18 Feb 2016 23:35:17 +0000

Michael,

>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.

>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.

>    [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: "Paul E. Jones" <[email-masked]>
Date: Thu, 18 Feb 2016 23:53:26 +0000

Brian,

>of a different behaviour. It's LE (001000).

Let me preface my reply by saying that I don't want to hold up the 
document by asking...

James Polk was actively working on RFC 4954bis, restructuring some of 
the code points and groups, etc.  I know he spent a lot of hours 
thinking about what he wanted, but I don't know how far he got in 
writing it down.  He did publish a few drafts, but I suspect he had 
other changes that never made it into the draft.  The latest draft 
published was 
https://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-03.

In August 2015, Fred Baker sent a note to the list about revising 4594.  
There seemed to be general agreement that it was starting to show signs 
of aging AND that it would be a lot of work.  I don't know what the 
thoughts were around revising it, whether it's entirely different or 
along the lines of what James had started.

But, perhaps this is just one more reason why those who are experts in 
this area should perhaps spend some cycles to revise that text?  
Personally, I think there would be some benefit in having an updated 
spec that is standards track.

Paul

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Feb 2016 13:03:55 +1300

On 19/02/2016 12:53, Paul E. Jones wrote:
> Let me preface my reply by saying that I don't want to hold up the document by asking...
> 
> James Polk was actively working on RFC 4954bis, restructuring some of the code points and groups, etc.  I know he spent a lot of
> hours thinking about what he wanted, but I don't know how far he got in writing it down.  He did publish a few drafts, but I
> suspect he had other changes that never made it into the draft.  The latest draft published was
> In August 2015, Fred Baker sent a note to the list about revising 4594.  There seemed to be general agreement that it was
> starting to show signs of aging AND that it would be a lot of work.  I don't know what the thoughts were around revising it,
> whether it's entirely different or along the lines of what James had started.
> 
> But, perhaps this is just one more reason why those who are experts in this area should perhaps spend some cycles to revise that
> text?  Personally, I think there would be some benefit in having an updated spec that is standards track.

I agree, but let's keep that of the critical path for *this* draft.

I'm think about filing an erratum against RFC 3662, because it started the
confusion by falsely using the name of a PHB to refer to a codepoint value.

    Brian

---

From: "Black, David" <[email-masked]>
Date: Fri, 19 Feb 2016 00:22:32 +0000

> > But, perhaps this is just one more reason why those who are experts in this
> area should perhaps spend some cycles to revise that

I agree with both, and I'd envision WG discussion of the proposed erratum.

Thanks, --David

> Sent: Thursday, February 18, 2016 7:04 PM
> > James Polk was actively working on RFC 4954bis, restructuring some of the code
> points and groups, etc.  I know he spent a lot of
> > hours thinking about what he wanted, but I don't know how far he got in
> writing it down.  He did publish a few drafts, but I
> > In August 2015, Fred Baker sent a note to the list about revising 4594.  There
> seemed to be general agreement that it was
> > starting to show signs of aging AND that it would be a lot of work.  I don't know
> what the thoughts were around revising it,
> > But, perhaps this is just one more reason why those who are experts in this
> area should perhaps spend some cycles to revise that

---

From: "Black, David" <[email-masked]>
Date: Fri, 19 Feb 2016 00:48:55 +0000

> 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.

> >    assist it in either selecting the DSCP value or adjusting the network

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.

Thanks, --David

> 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]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Feb 2016 14:15:18 +1300

> I agree with both, and I'd envision WG discussion of the proposed erratum.

Of course. Would you prefer me to post a draft of the erratum here, or
post it directly to the RFC Editor site?

    Brian

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Feb 2016 15:23:22 -1000

Thanks to both of you!

I’m fine with David’s edit. Paul, just a side note: it seems that the issue was caused by me (as a transport guy) reading “network TRANSPORT” while you apparently meant “NETWORK transport”   :-)
That is, I thought the sentence containing “network transport” refers to the behavior of the transport protocol, but I understand from your response that it refers to the in-network behavior (and I agree with all you say about that).

Anyway, I think nothing bad happens with my suggested changes and I’m thankful that you folks think they can be taken onboard!

Cheers,
Michael

> On 18. feb. 2016, at 14.48, Black, David <[email-masked]> wrote:
> 
> Paul writes:
>

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 19 Feb 2016 11:32:33 +0100

Hi,

> 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

---

From: "Black, David" <[email-masked]>
Date: Mon, 22 Feb 2016 03:19:17 +0000

> 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?

Thanks, --David

> From: Anna Brunstrom [mailto:[email-masked]]
> Sent: Friday, February 19, 2016 5:33 AM
> To: Black, David; [email-masked]; Michael Welzl
> Cc: [email-masked]

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 23 Feb 2016 00:08:37 +0100

> 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

---

From: "Black, David" <[email-masked]>
Date: Thu, 25 Feb 2016 00:38:34 +0000

> 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).

Nonetheless, within the set of media flows that use the same DSCP, application
priority may be a useful input to the coupled congestion controller.

> But it may still be

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

> 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
> >>>> Michael,
> >>>>
> >>>>> ***

---

From: "Black, David" <[email-masked]>
Date: Thu, 25 Feb 2016 00:51:53 +0000

> of a different behaviour. It's LE (001000).

I believe that 001000 is the rough consensus, as opposed to 000000, as 001000
has been in the draft for a rather long time, and I've seen no one other than Brian
advocate changing it.

On terminology, alignment with RFC 4594 is important, IMHO, as independent of
what is in RFC 3662, the de-facto standardization of 001000 as the default DSCP for
LE service is in RFC 4594.   NB: The use of "de facto" in that sentence recognizes
that RFC 4594 is informational not standards-track, nonetheless, RFC 4594 is what
enshrined 001000 as the default DSCP for LE service in practice.

Thanks, --David

> Sent: Thursday, February 18, 2016 6:13 PM
> To: Black, David; Paul E. Jones; [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Thu, 25 Feb 2016 10:37:37 +0100

> On 25 Feb 2016, at 01:38, Black, David <[email-masked]> wrote:
> 

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.

> 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

---

From: "Black, David" <[email-masked]>
Date: Thu, 25 Feb 2016 20:16:38 +0000

> :-)    => 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.

Thanks, --David

> Sent: Thursday, February 25, 2016 4:38 AM
> To: Black, David
> Cc: Anna Brunstrom; [email-masked]
> 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.
> 
> 
> :-)    => 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

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 26 Feb 2016 00:40:14 +0100

>>> 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.

> 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

---

From: "Black, David" <[email-masked]>
Date: Fri, 26 Feb 2016 15:50:42 +0000

> And this is the same as for the data channel, the SCTP scheduler

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.

> 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

> Sent: Thursday, February 25, 2016 6:40 PM
> To: Black, David; Michael Welzl
> Cc: [email-masked]
> >>>>>>> application priority always assists with both aspects for the data
> channel,
> >> via

---

From: Michael Welzl <[email-masked]>
Date: Fri, 26 Feb 2016 19:25:33 +0100

> On 26. feb. 2016, at 16.50, Black, David <[email-masked]> wrote:
> 

I don’t get how this is broader than coupling? I don’t see why the DSCP could not change over time for coupled flows as long as they all have the same value. While we may not have text saying that this is allowed, I don’t think we have text saying it’s forbidden either…

> on sending in the RFC publication request to hand it off to our ADs.

I agree

Cheers,
Michael

---

From: "Black, David" <[email-masked]>
Date: Fri, 26 Feb 2016 21:34:35 +0000

> I don’t get how this is broader than coupling? I don’t see why the DSCP could not
> change over time for coupled flows as long as they all have the same value. While
> we may not have text saying that this is allowed, I don’t think we have text saying
> it’s forbidden either…

That's not the distinction - the distinction is:

- Data: At any time, the SCTP association uses exactly one cell in Table 1 of the
	draft, the rightmost cell of those applicable to the data flows.  That results
	in a single DSCP with the SCTP scheduler operating across all data flows,
	although the SCTP community is interested in making this more flexible
	in the future (so that multiple DSCPs can be used in the same SCTP association).

- Media: Multiple cells in Table 1 may be in use at the same time - there would be
	an instance of the coupled congestion controller for the flows in each cell,
	operating on the flows that use that cell of the table.

The Media case is preferable, IMHO, so I support the idea of enabling SCTP to
use multiple DSCPs in a single association.

> > on sending in the RFC publication request to hand it off to our ADs.

Excellent.

Thanks, --David

> Sent: Friday, February 26, 2016 1:26 PM
> To: Black, David
> I don’t get how this is broader than coupling? I don’t see why the DSCP could not
> change over time for coupled flows as long as they all have the same value. While
> we may not have text saying that this is allowed, I don’t think we have text saying
> it’s forbidden either…
> 
>

---

From: [email-masked]
Date: Sat, 27 Feb 2016 13:07:26 -0000

> I don’t get how this is broader than coupling? I don’t see why the
> DSCP could not change over time for coupled flows as long as they all have
> the same value. While we may not have text saying that this is allowed, I
> don’t think we have text saying it’s forbidden either…
>
+1.  Personally, I prefer intentionally neither to forbid nor condone
changing the DSCP in this document, but agree with the current text to
discourage frequent changes for SCTP  and leave RFC 7657 to help explain
that some choices are likely to be less disruptive than others.

Gorry

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Feb 2016 19:46:31 +0000

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

>>  >>> Nonetheless, within the set of media flows that use the same 
>>DSCP,
>>  application
>>  > Anna - if there are text changes that you would like to see, please 
>>provide
>>  specific wording.
>>
>>  >> Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - 
>>ends Feb
>>  13
>>  >>
>>  >>
>>  >>> That's not only "less likely" ... it's actually a bad idea, as 
>>explained in more
>>  detail
>>  >> correctly couple flows could then make for interesting research 
>>but hasn't
>>  been
>>  >> 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
>>  >>> Nonetheless, within the set of media flows that use the same 
>>DSCP,
>>  application
>>  >>>>>> Subject: Re: [tsvwg] TSVWG WGLC: 
>>draft-ietf-tsvwg-rtcweb-qos-12 -
>>  ends
>>  >> Feb
>>  >>>> 13
>>  >>>>>> Hi,
>>  >>>>>>
>>  >>>>>>> Assuming no further objections are seen on the list, that 
>>should be
>>  done.
>>  >>>>>>>
>>  >>>>>>>>> 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
>>  >>>>>>> I'm changing the "either/or" construct to an "and" construct 
>>because
>>  the
>>  >>>>>>> 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.
>>  >>>>>> coupled cc, there should be no confusion. But perhaps 
>>somewhere in
>>  the
>>  >>>>>>>> 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
>>  >>>>>>>>>      assist it in selecting the DSCP value.  Application 
>>priority does
>>  >>>>>>>>> not
>>  >>>>>>>> the DSCP value is used by the network to perform treatment 
>>of the
>>  >> packet
>>  >>>>>>>>> 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
>>  >>>>>>>>>      assist it in either selecting the DSCP value or 
>>adjusting the
>>  >>>>>>>>> network
>>  >>>>>>>>>      transport behavior.
>>  >>>>>>>>> ***
>>  >>>>>>>>>
>>  >>>>>>>>> incorporated, it’s not the end of the world - hopefully I 
>>wont miss
>>  the
>>  >>>>>>>> requested.  They should not take long.  I can make those and 
>>these
>>  you