Subject: [tsvwg] L4S & Diffserv - incremental deployment

From: "Black, David" <[email-masked]>
Date: Fri, 13 Jul 2018 16:48:54 +0000

<WG_Chair_Hat=OFF>

Bob,

Regarding draft-briscoe-tsvwg-l4s-diffserv, writing as an individual, not as a WG chair.

The draft currently seems to focus on the end-state of full deployment of L4S with Diffserv.  I'm also interested in enabling incremental deployment of L4S - being able to enable/disable L4S based on DSCP value looks like a promising mechanism for that.  Towards that end, the examples in Section 4 don't seem to cover all of the possibilities in a partial deployment of L4S, where its use/non-use is controlled by DSCP.

Section 6 could benefit from some related thought and editing:

- Section 6.1: The guidance on not remarking DSCPs is scoped to L4S functionality.  Obviously, Diffserv can and does remark DSCPs, so the advice should be that only Diffserv functionality remarks DSCPs, not L4S.

- Section 6.2: This seems to be entirely about implementation, including what to do on current hardware.   I'd like to see a statement that at the protocol specification level, Diffserv classification SHOULD precede ECN classification in order to enable L4S enable/disable on a per-DSCP basis, with the full 8-bit (DSCP + ECN) classifier being a possible implementation and constraints of existing hardware (can't do that) being a possible reason to not follow the SHOULD.

</WG_Chair_Hat=OFF>

Thanks, --David
----------------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 18 Jul 2018 16:01:24 -0400

David,

Thanks for taking the time to read and comment...

On 13/07/18 12:48, Black, David wrote:
> The draft currently seems to focus on the end-state of full deployment 
> of L4S with Diffserv.  I’m also interested in enabling incremental 
> deployment of L4S - being able to enable/disable L4S based on DSCP 
> value looks like a promising mechanism for that.  Towards that end, 
> the examples in Section 4 don’t seem to cover all of the possibilities 
> in a partial deployment of L4S, where its use/non-use is controlled by 
> DSCP.
>
I'm also primarily interested in enabling early use of L4S with 
Diffserv, while hosts are starting to deploy scalable congestion 
controls that can use ECT(1). That's what Table 1 is about, and the text 
around it in section 3. Low Latency Diffserv Classes within a DualQ 
Bandwidth Pool 
<https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-01#section-3>.

As you can see, EF is identified as the most likely DSCP that existing 
'non-queue-building' apps could use to get into the low latency queue 
(e.g. a low-rate stream of sync datagrams for an online game).

Is there something I've done wrong that didn't allow you to see why this 
section was what you wanted to read.
I didn't want to explicitly talk about an incremental deployment roadmap 
for L4S, cos the RFC series is meant to be timeless.

> - Section 6.1: The guidance on not remarking DSCPs is scoped to L4S 
> functionality.  Obviously, Diffserv can and does remark DSCPs, so the 
> advice should be that only Diffserv functionality remarks DSCPs, not L4S.
>
We'll certainly make that clear.

> - Section 6.2: This seems to be entirely about implementation, 
> including what to do on current hardware.   I’d like to see a 
> statement that at the protocol specification level, Diffserv 
> classification SHOULD precede ECN classification in order to enable 
> L4S enable/disable on a per-DSCP basis, with the full 8-bit (DSCP + 
> ECN) classifier being a possible implementation and constraints of 
> existing hardware (can’t do that) being a possible reason to not 
> follow the SHOULD.
>
We've had long email discussion on this before. I'm going to find you in 
a corridor to understand why we're talking past each other on this.

Bob

> [email-masked] <mailto:[email-masked]>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Black, David" <[email-masked]>
Date: Thu, 19 Jul 2018 00:13:20 +0000

Bob,

It sounds like we don't have a fundamental disagreement.   That's good - I should reread the draft and propose some small text changes that would address my concern, which is reflected in both the overall comment on Section 4 and the specific comment on Section 6.2.

What I'm looking for is roughly:

*        By itself, use of ECT(1) is not sufficient to cause traffic to use the L4S Queue in a Dual Queue AQM.

*        The network operator can enable or disable L4S Queue usage for ECT(1)-marked traffic on a DSCP-by-DSCP basis.
The above bullets are oversimplified in that they're easy to mis-read as implying that there is one L4S Queue - there may be more than one, e.g., as indicated by Figure 2 in the draft.

I can't promise that I'll be able to reread the draft and propose text before the TSVWG meeting tomorrow, but I will put it on my "To Do" list ...

Thanks, --David

From: Bob Briscoe [mailto:[email-masked]]
Sent: Wednesday, July 18, 2018 4:01 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [tsvwg] L4S & Diffserv - incremental deployment

David,

Bob,

The draft currently seems to focus on the end-state of full deployment of L4S with Diffserv.  I'm also interested in enabling incremental deployment of L4S - being able to enable/disable L4S based on DSCP value looks like a promising mechanism for that.  Towards that end, the examples in Section 4 don't seem to cover all of the possibilities in a partial deployment of L4S, where its use/non-use is controlled by DSCP.
I'm also primarily interested in enabling early use of L4S with Diffserv, while hosts are starting to deploy scalable congestion controls that can use ECT(1). That's what Table 1 is about, and the text around it in section 3.  Low Latency Diffserv Classes within a DualQ Bandwidth Pool<https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-01#section-3>.

As you can see, EF is identified as the most likely DSCP that existing 'non-queue-building' apps could use to get into the low latency queue (e.g. a low-rate stream of sync datagrams for an online game).

Is there something I've done wrong that didn't allow you to see why this section was what you wanted to read.
I didn't want to explicitly talk about an incremental deployment roadmap for L4S, cos the RFC series is meant to be timeless.

- Section 6.2: This seems to be entirely about implementation, including what to do on current hardware.   I'd like to see a statement that at the protocol specification level, Diffserv classification SHOULD precede ECN classification in order to enable L4S enable/disable on a per-DSCP basis, with the full 8-bit (DSCP + ECN) classifier being a possible implementation and constraints of existing hardware (can't do that) being a possible reason to not follow the SHOULD.
We've had long email discussion on this before. I'm going to find you in a corridor to understand why we're talking past each other on this.

Bob

</WG_Chair_Hat=OFF>

Thanks, --David

--