Subject: [tsvwg] comments on L4S architecture draft

From: Wesley Eddy <[email-masked]>
Date: Mon, 6 Feb 2017 23:48:43 -0500

I have some comments to share on the architecture draft: 
https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00

These are mostly positive comments, and many can be considered 
longer-term, in my opinion, not urgent nor blocking adopting in TSVWG.

1. It seems to me that L4S can address some pain points that operators 
have.  I'm sure the authors have got some input on this from operators, 
but it might be good to include more of a deployment walkthrough in the 
draft.  It mentions incremental deployment as being possible, but I 
think there could be a more clear discussion of what incremental utility 
there is, how to start, etc.

2. I think the real "selling point" is that operators won't need to 
provision separate transport underlays for certain high-performance 
applications (e.g. that might use DCTCP) versus other traffic.  L4S can 
enable better performance with less pre-configuration, baked-in 
settings, or twiddling with knobs. The draft doesn't really seem to 
directly attack the current practices of partitioning resources and how 
labor-intensive and fragile this can be.  L4S could be a big improvement 
for some people.

3. In addition to being an architecture description, the draft also 
serves as a bit of a "work plan" for what needs to be done (e.g. in 
Section 4).  The wording is a bit strong sometimes, saying things "need" 
to be done, but really the benefits of L4S can accrue incrementally as 
some of that work happens, and some of the work items mentioned may not 
really be needed at all.  For instance, DCCP scalable CC doesn't need to 
be in place for L4S to have benefit, and L4S wouldn't fail just because 
none of the existing mostly-unused DCCP codebases implement the new 
CCID. What truly "needs" to happen to start showing benefits could be 
better distinguished from what ultimately could happen.

4. The caption on Figure 1 has incorrect numbering with regard to the 
figure (number 1 and 2 are swapped in the caption, I believe).  
Additionally, in the text above the figure, bullet numbering order of 2, 
1, 3 is stressful to read (though I think was probably done on purpose 
for left-right relation to the diagram?).

5. In the discussion of ECN at the beginning of section 5.1, it could be 
more clear that this is in regard to traffic in the L4S class, and that 
other traffic using the "classic" queue doesn't need to use ECN.

6. Some of the comparison/contrast statements with fq_codel don't seem 
quite right, since FQ is achieving a different goal than simply enabling 
scalable and classic traffic to coexist.  For instance, FQ is also 
limiting impact of very bad-behaving flows on other flows (e.g. bad 
flows may follow neither the scalable nor classic paradigms of CC!).

7. Another possible use case for section 6 might be networks where 
service function chaining is prevalent and delay across the network 
needs to be minimized because traffic is criss-crossing through possibly 
odd paths that are much different than just the shortest set of physical 
hops between source and destination.

8. Virtual switch implementations may be important in addition to physical.

9. Would onion routing systems also be a potential beneficiary of L4S, 
if they used scalable transports?  They normally have a lot of delay and 
delay variation.

10. The benefits and descriptions in the document make sense to me, but 
I also know of the history and related work that the document builds 
upon.  I wonder if it's as clear to other people coming fresh?  For many 
operations type of people, this may be the case, so feedback there would 
be useful, I think.

11. Some of the text represents a state of affairs that will change 
(e.g. page 7 discussing progress), and it should be considered whether 
this stuff would be of value to go into an RFC or not.

---

From: "De Schepper, Koen (Nokia - BE)" <[email-masked]>
Date: Fri, 17 Feb 2017 08:27:16 +0000

Hi Wes,

Thanks for these very useful comments. We will take them into account when writing the next version(s).

Koen.

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Wesley Eddy
> Sent: dinsdag 7 februari 2017 5:49
> To: [email-masked]
> Subject: [tsvwg] comments on L4S architecture draft
>