Re: [tsvwg] comments on L4S architecture draft

[Bob Briscoe <[e-mail]>]

Wes,

Thank you v much for these comments. Inline...

On 07/02/17 04:48, Wesley Eddy wrote:
> 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.
I've addressed all your other points, but I would have needed to be in a 
more relaxed and creative mood to write this well, so I've just added 
some place-holder bullets for the next revision.
>
> 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.
In S. 5.2 we said

       Also, because L4S
       is for all traffic, it needs none of the management baggage
       (traffic policing, traffic contracts) associated with favouring
       some packets over others.  This baggage has held Diffserv back
       from widespread end-to-end deployment.

But I've assumed you are saying you want to see something about zero 
config in the Intro. Done.
>
> 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.
Agreed, and dealt with.
>
> 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?).
Yeah. Originally the numbering lined up with the requirements in the 
Appendix. But the requirements got renumbered in subsequent edits, so 
I've destressed the bullet numbering for you.
>
> 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.
Done.
>
> 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!).
I have altered it to clarify that fq regulates the interplay between 
flows by default whereas, in the L4S approach, policing can be added as 
a separate policy choice.
>
> 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.
I haven't said it this way, because it's a bit negative. Paraphrasing, 
you're saying, if your delay due to routing is rubbish, you've got less 
delay budget left for queuing delay.

Instead, I've generalized and given a more positive spin:
"Applications with a fixed delay budget can communicate over longer 
distances, or via a longer chain of service functions or onion routers, 
if queuing delay is lower."
>
> 8. Virtual switch implementations may be important in addition to 
> physical.
Not added. I don't think it would add anything to list all the different 
types of implementation that might be necessary - nothing L4S specific 
about such a list.

>
> 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.
OK. I won't add anything yet. We'll try to get wider review - probably 
at least during IESG processing.
>
> 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.
Yeah. I've started to try to make it more timeless. But as new things 
come up, I am adding them (e.g. possibility of L4S variant of QUIC). So 
as all the related stuff matures, it should gradually take the form of a 
list of pointers to related components, without having to comment on 
their maturity.

Thanks for this nice set of points.

Cheers



Bob

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