Re: [tsvwg] Interaction of L4S with Diffserv

[Brian E Carpenter <[e-mail]>]

Bob,

> was the l4s-diffserv draft at least comprehensible and possibly even useful?

Sorry; my comment "Basically I think it works" was a bit casual but was intended to say "yes" to both of those points.

Regards
   Brian

On 27-Mar-19 22:14, Bob Briscoe wrote:
> Brian,
> 
> 
> Thank you for taking a look so quickly.
> 
> Given you gave permission, I've fwd'd to tsvwg.
> 
> 
> I've added an item in my todo list to fix all those instances of incorrect implication of global usability (I've done the ecn-l4s-id ones in the authors' copy already).
> 
> 
> As you say, nothing depended on that misunderstanding of the meaning of pool 1.
> 
> 
> Aside from codepoint issues, was the l4s-diffserv draft at least comprehensible and possibly even useful?
> 
> 
> 
> Bob
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Brian E Carpenter <[e-mail]>
> *Sent:* 27 March 2019 01:20:48
> *To:* Bob Briscoe
> *Cc:* Wesley Eddy; Black, David; Gorry Fairhurst; Bob Briscoe
> *Subject:* Re: Interaction of L4S with Diffserv
>  
> Hi all,
> 
> I had a short, superficial look at this. Basically I think it works,
> but I'm no L4S expert. I've also become aware that there's controversy
> and strong feeling about the ECN usage, but I'm not taking a position
> on that.
> 
> I have one main comment on the draft, which certainly impacts at
> least one other L4S draft that I needed to glance at. And one smaller
> comment embedded below. You're welcome to forward this if useful.
> 
>>> Table 1 lists the Diffserv service classes that have been allocated
>>> global use Diffserv codepoints (DSCPs) from Pool 1.
>  
> There is no such thing as a "global-use" DSCP". DSCPs are
> specifically defined as domain-local. There are RECOMMENDED
> code points but every domain is free to ignore those
> recommendations. There are operational guidelines in
> RFC4594 etc but every operator is free to ignore them.
> 
> This needs rephrasing accordingly, something like:
> 
>  Table 1 lists the Diffserv service classes that correspond
>  to recommended Diffserv codepoints (DSCPs) from Pool 1
>  and their underlying PHBs. In principle the actual DSCP
>  values can vary between network domains, but in this document
>  we use the recommended DSCP values as proxies for both
>  the corresponding PHB and the corresponding service class.
> 
> There may be other places in this (and other) drafts that
> need the same fix. See below for one that I found.
> Wherever you have something like "standardized global-use
> DSCPs" it needs to say "recommended standard DSCP values".
> 
> [I'm sorry about all this, but the operators in the old
> diffserv WG absolutely insisted on this property for
> DSCP assignments.]
> 
>>> {6}:   [I-D.ietf-tsvwg-le-phb] updates RFC 4594 to deprecate using
>>>          CS1 for Lower Effort (LE).
> 
> Correct. So CS1 in its normal meaning needs to be in the table.
> You won't go far wrong by treating it the same as CS0. But in fact
> the meaning of CS1 is domain-dependent so you can't generalise.
> 
> In draft-ietf-tsvwg-ecn-l4s-id-03, Appendix B.2 I found:
> 
>>> Global-use DSCP:  These do not tend to be honoured across network
>>>   interconnections more than local-use DSCPs.
> 
> Again, there is no such thing as a "Global-use DSCP". DSCPs
> are specifically defined as domain-local. If two adjacent
> domains happen to use the same DSCP to identify the same
> PHB, they may choose to have a mutual SLA that avoids the
> need to re-write that specific DSCP value at their mutual
> boundary. No RFC has changed this since it was defined that
> way by RFC2474.
> 
> There's a reference in the text to "the global-use range".
> There is no such range.
> 
> It's true that operators may choose to follow the
> suggestions in RFC4594 etc. But they are only suggestions,
> subject to operator agreements.
> 
> This doesn't change the argument of Appendix B.2 but it
> really needs to be corrected. I think the two cases you
> are trying to distinguish aren't really distinct: any DSCP
> may be re-written at any domain boundary. That's necessary
> and sufficient for the argument you are making.
> 
> Regards
>    Brian Carpenter
> On 18-Mar-19 13:49, Bob Briscoe wrote:
>> Brian,
>> 
>> David Black asked me to produce this (currently individual) draft to explain how L4S might change the way Diffserv is used, and how they might complement or conflict with each other.
>> 
>> The cable industry recently made L4S a mandatory part of DOCSIS 3.1, and it is now being implemented by all the cable equipment vendors. So, in pretty short order, it's worth making sure we aren't doing anything that might conflict.
>> 
>> You represent the audience the l4s-diffserv draft is aimed at, so when I suggested we get you to review it, Wes Eddy encouraged me to go ahead.
>> 
>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>> Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services
>>     https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02
>> 
>> Abstract
>> 
>>    L4S and Diffserv offer somewhat overlapping services (low latency and
>>    low loss), but bandwidth allocation is out of scope for L4S.
>>    Therefore there is scope for the two approaches to complement each
>>    other, but also to conflict.  This informational document explains
>>    how the two approaches interact, how they can be arranged to
>>    complement each other and in which cases one can stand alone without
>>    needing the other.
>> 
>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>> 
>> If you're not familiar with L4S, you'll need to read the L4S architecture draft, which is one of the three primary L4S drafts approaching WGLC in tsvwg:
>>     https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03
>>     https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06
>>     https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08
>> 
>> These all refer to the L4S-Diffserv draft, but they do not depend on it.
>> 
>> There is one other draft relevant to L4S and Diffserv:
>>     Identifying and Handling Non Queue Building Flows in a Bottleneck Link
>>     https://tools.ietf.org/html/draft-white-tsvwg-nqb-01
>> 
>> 
>> Bob
>> 
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>> 
>