Re: [iccrg] [tsvwg] IETF104 ICCRG TCP Prague presentation

[Jonathan Morton <[e-mail]>]

> On 4 Apr, 2019, at 8:29 pm, Greg White <[e-mail]> wrote:
> 
> When an SCE sender and a non-ECT sender share a single queue, the non-ECT sender will be driving the queue delay to the classic AQM target, and the SCE sender will experience the same queue delay as the non-ECT sender. 

This is true.  However, this is no worse a situation, in terms of peak delay, than a single-queue AQM is today.

The immediate benefit to SCE is the ability to use path capacity left unused by a conventional multiplicative-decrease response, without incurring a latency hit relative to conventional TCP, and without losing TCP-friendly characteristics.  This is easily seen when a single SCE flow occupies the link (we measured roughly 50% greater goodput versus plain NewReno over 30 seconds), and is not materially degraded when a second SCE flow joins it.

What we have not yet had the opportunity to test is the behaviour of an SCE flow versus a non-SCE flow sharing a single queue.  The interactions here are expected to be subtle, involving a mixture of SCE and CE responses.  An important property, however, is that we are sure that conventional TCPs will not be squeezed out of the path by SCE flows - rather, we are working to avoid the opposite scenario.

Just as soon as GitHub stops breaking on us…

> I've not been able to imagine a dual queue implementation that can identify SCE senders so that they can achieve reliable ultra-low delay (unless you are suggesting that SCE senders are all required to mark their traffic with a particular DSCP).

SCE senders are not required to use any particular DSCP.  Nor are they enjoined from doing so.

Understand this: SCE's primary purpose is not to ensure minimal queue delays in all possible circumstances.  It is to improve the quality of congestion control in a thoroughly backwards-compatible manner.  Relying too heavily on Diffserv, which is rarely implemented at bottlenecks today, would defeat that goal.

The combination of SCE with a DSCP associated with an appropriate PHB could work with your preferred DualQ architecture, as an *enhancement* to standard SCE or ECN behaviour.  The only additional requirement is that the DSCP survives the path as far as the bottleneck.  I suggest that the cable industry is in a better position than most Internet entities to solve the latter problem.

 - Jonathan Morton