Re: [tsvwg] Interaction of L4S with Diffserv

[Bob Briscoe <[e-mail]>]

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