[tsvwg] Comments on draft-ietf-tsvwg-aqm-dualq-coupled-13

[Ingemar Johansson S <[e-mail]>]

Hi

I have read through draft-ietf-tsvwg-aqm-dualq-coupled-13.

In general I find the document well written with just a few remarks/comment/questions listed below. 

 

+ One thing that strikes me is that packet pacing is not mentioned in the draft. Packet pacing is implemented in Prague, BBRv2 and SCReAM and the obvious benefit is that packet bursts from individual flows become a smaller problem. On the other hand DCTCP does not inherently assume packet pacing although it can be enabled and is highly recommended in e.g. HULL. There can also be cases where packet pacing is not preferable as it can increase e2e latency, one such example is very low latency streaming of video where it can be beneficial to just burst the video frames to save some serialization delay in links with high statistical multiplexing. 
Does the L4S marker assume packet pacing?, I don’t think so and perhaps this should not be elaboratet upon in this draft as packet pacing is a general networking topic bigger than DualQ ?.

 

+ Section 1.4 mentions a VR use case “VR goggles was remotely receiving a feed from a 360-degree camera in a racing car”. While I find the football demo (a real eye opener), I don’t seem to find the VR demo ?

 

+ Page 15; Quote “As a consequence,  DualPI2 has attracted more development and evaluation attention than  Curvy RED, leaving the Curvy RED design incomplete and not so fully evaluated.” This makes sense in 2020 but in 10 years from now?. For anybody familiar with IETF  it will be known  that this is discussion text but for people not so familiar it may not be the case. I have over the years seen discussion text in e.g. RFC3168 taken completely outside its context, it is quite apparent that this text reflected the status when one of my kids was just a little toddler but still it can be brought up 😊  

 

+ Section 2.5.1: “work-conserving”. Luckily I know what the term is, it was not the case 10 years ago though. Is the reader assumed to know what it is ? I know a simple search on the internet gives the answer so it perhaps does not need an explanation

 

+ Section 2.5.1.1 : “if the packet is ECT(0), the L AQM SHOULD apply CE-marking using a probability appropriate to Classic congestion control and appropriate to the target delay in the L queue” My first though was .. how is this done but then I believe I get it, does this mean that the pseudo code needs to compute a p’_LC = p’L^2 for this purpose and apply marking with probability p’_LC on packets with ECT(0) ?

 

+ Section 4.1.1. : Scheduling weights , is there any studies on weights such as 1/8 ?

 

+ Appendix A : The pseudocode looks very good and is easy to understand with the help from the surrounding text. Notice however that there is a mix of code conventions, for instance Tupdate, RTT_max. Looking back at RFC8298 I see that the pseudo code there has variable names such as bytes_in_flight and constants such as MIN_CWND. 

 

+ Appendix B: Question, will this section be relevant in the future?, it appears that you have focused mainly on the PI2 that is explained in Appendix A. Does Curvy RED have some benefits over PI2 that makes it relevant to have it in the draft?

 

+ Nit.. The bullet list sometimes begin with a capital letter e.g ‘If..’ and sometimes not (‘if..’)

 

/Ingemar

================================

Ingemar Johansson  M.Sc. 

Master Researcher

 

Ericsson Research

RESEARCHER

GFTL ER NAP NCM Netw Proto & E2E Perf

Labratoriegränd 11

977 53, Luleå, Sweden

Phone [phone]

SMS/MMS [phone]

[e-mail]

www.ericsson.com <http://www.ericsson.com/> 

 

Talk about a dream, try to make it real

                  Bruce Springsteen

=================================