[dispatch] A new initiative in the transport area: do DISPATCHers want such strategic work?

[Bob Briscoe <[e-mail]>]

DISPATCHers,

We have a question at the end, addressed to DISPATCH people as 
'customers' of the transport layer.
Particularly about apps wanting low latency (i.e. nearly everything).
*
**Background*

If you saw our stand at Bits N Bites, or the demo in the active queue 
management (AQM) WG in Prague, you will know what we're talking about...

We showed a video feed from a panoramic camera at a football match 
delivered down a broadband access. You could pan and zoom the HD picture 
with finger gestures and the delay was so low it seemed to stick to your 
finger, while 100 flows per second of Web traffic and more than a dozen 
long-running flows were all being downloaded thru the same 40Mb/s access 
line. This wasn't Diffserv - not QoS at the expense of other traffic, so 
no need for permission to use a class. This was AQM for /all/ the 
packets in all the flows - all getting the same ultra-low delay.

We didn't modify the apps at all, we just switched the stack underneath 
the TCP apps to a 'scalable' TCP. The interactive video app just 
auto-adjusted its buffer 'cos it detected very low delay and jitter. The 
stats are pretty stunning: zero congestion loss and ultra-low queuing 
latency (99th percentile of about 1 millisecond) with no reduction in 
link utilization either.

The insight is that 'classic' TCPs (New Reno, Cubic etc.) have been 
scaling badly - the sawteeth are getting longer and the responsiveness 
has been getting slower as flow rates increase. The trick is to classify 
the old 'classic' TCP traffic behind a `semi-permeable membrane'. For 
flow-rate it's like the same queue, but for queuing delay it's a second 
queue. Then all the 'modern' apps can migrate to using the good queue, 
where r-t apps can safely coexist with apps using (scalable) TCP, 
(scalable) SCTP, RTP, etc. and they all get low delay, whether for Web 
browsing, gaming, interactive video, voice, http adaptive streaming, etc.
*
**The Question*

This initiative is going to need standardisation across 3 different WGs 
in the transport area (AQM, TCPM and TSVWG), with incremental changes in 
access networks and updates to host stacks (we used DCTCP as the 
scalable TCP, which is already in Windows Server and there's a patch for 
Linux). So we're looking for feedback on this question:
==> From the ART/RAI viewpoint, does the potential benefit make it worth 
being this ambitious?

*More Info*

We've asked if we can give a heads-up about this in DISPATCH in 
Yokahoma. The work we're proposing is outside ART, but dispatch is the 
closest we've got to an RAI area meeting. And I promised the chairs I 
would start this thread on the dispatch mailing list, so people can 
prepare and ask questions.

Drafts:
The simple dual-queue algo (~15 lines of pseudocode in appendix) 
implemented as a Linux multiqueue qdisc:
     <draft-briscoe-aqm-dualq-coupled 
<https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled>>
The packet identifier:
     <draft-briscoe-tsvwg-ecn-l4s-id 
<https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id>>
The fix to TCP-ECN feedback:
     <draft-kuehlewind-tcpm-accurate-ecn 
<https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn>> 
(RFC7560 <https://tools.ietf.org/html/rfc7560> sets the requirements)

Background paper with rationale in english and maths, plus experimental 
evaluation:
<http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf>

Meetecho video of Koen's talk & demo in IETF-93 AQM WG (starts @ about 
33 mins):
     <http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#AQM>

Cheers



Bob & Koen

On 19/10/15 20:20, Bob Briscoe wrote:
> Mary, Cullen,
>
> Draft is here:
> <https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled> (might 
> get updated tonight if we get it together)
> Hopefully some DISPATCHy people saw the Bits-N-Bites demo in Prague.
>
> But we'll also introduce it on the list and respond to questions - 
> after I get some sleep after the draft deadline...
> I'm pulling together a Web page with pointers to other backgroud 
> material too.
>
> Cheers
>
>
> Bob
>
> On 17/10/15 07:45, Mary Barnes wrote:
>> We have not yet finalized the agenda/topics for IETF-94. Cullen and I 
>> can raise this during our discussion with the ADs for which we're 
>> actually a bit overdue.  Given what we have on the table right now, 
>> we ought to have some time.  One suggestion, I would make that would 
>> help support the discussion of this topic would be if you guys could 
>> go ahead and post a note to the DISPATCH WG mailing list now and that 
>> will give folks some time to consider and that might help you get 
>> more input during the f2f session (and is consistent with the 
>> DISPATCH WG model of not presenting brand new topics during the f2f 
>> meeting)
>> Regards,
>> Mary.
>>
>> On Fri, Oct 16, 2015 at 4:13 PM, Cullen Jennings <[e-mail]> wrote:
>>
>>
>>     Mary, Thoughts?
>>
>>     Bob, Is there a draft people could read about this?
>>
>>     (Mary is traveling right now too so not sure when she can respond)
>>
>>     > On Oct 15, 2015, at 12:11 PM, Bob Briscoe
>>     <[e-mail]> wrote:
>>     >
>>     > Cullen,
>>     >
>>     > Ta - so is there room for a slot for us in Yokahoma?
>>     > A nice long time like 20mins would be preferred, but we would
>>     understand if it had to be cut to a more normal 10-15mins.
>>     >
>>     > We'll go into a huddle to think up a title.
>>     >
>>     >
>>     > Bob
>>     >
>>     > On 15/10/15 15:13, Cullen Jennings wrote:
>>     >> Hi Bob,
>>     >>
>>     >> The RAI area never had an "area WG" and we used Dispatch for
>>     this. With the merge to become ART I think we will still continue
>>     to use dispatch for conversation where we want to get out to the
>>     whole area.
>>     >>
>>     >> Reading the charter, I agree it does not fit, but I still
>>     think it's the best place.
>>     >>
>>     >> Cullen
>>     >>
>>     >>
>>     >>
>>     >>
>>     >>> On Oct 15, 2015, at 5:19 AM, Bob Briscoe
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>     >>>
>>     >>> Mary, Cullen (as dispatch chairs),
>>     >>>
>>     >>> Koen and I (and others in the transport area) are trying to
>>     find a way to get feedback/support from nominal 'customers'.
>>     >>>
>>     >>> I don't know how the ART area works these days, but in Prague
>>     Cullen told me that DISPATCH might be what we're looking for.
>>     However, having read the charter I'm not so sure. We're not
>>     proposing a new RAI WG. But we're trying to get the transport
>>     area to think strategically, so we want to know if that would be
>>     supported by 'customers' of the services offered by the transport
>>     layer.
>>     >>>
>>     >>> Our proposed direction is going to need standardisation
>>     across 3 different WGs in the transport area (AQM, TCPM and
>>     TSVWG), with incremental changes in access networks and senders
>>     and receivers. So we're looking for feedback on this question:
>>     >>> ==> From the ART/RAI viewpoint, does the potential benefit
>>     make it worth being this ambitious?
>>     >>>
>>     >>> We give background to what we're trying to do below.
>>     >>> Then you can say if you think a heads-up presentation in the
>>     DISPATCH session in Yokahoma would be appropriate/useful.
>>     >>>
>>     >>>
>>     >>>
>>     >>> Bob & Koen
>>     >>>
>>     >>>
>>     >>> ==Background==
>>     >>>
>>     >>> If you saw our stand at Bits and Bytes or the demo in the AQM
>>     WG in Prague, you will know what we're talking about...
>>     >>> We showed a video feed from a panoramic camera at a football
>>     match delivered down a DSL access. You could pan and zoom the HD
>>     picture with finger gestures and the delay was so low it seemed
>>     to stick to your finger, while 100 flows per second of Web
>>     traffic and more than a dozen long-running flows were all being
>>     downloaded thru the same 40Mb/s access line - all getting the
>>     same ultra-low delay.
>>     >>>
>>     >>> We didn't modify the apps at all, we just switched some to a
>>     'scalable' TCP underneath them. The video app just auto-adjusted
>>     its buffer 'cos it detected very low delay and jitter. The stats
>>     are pretty stunning: zero congestion loss and ultra-low queuing
>>     latency with no reduction in link utilization for /all/ packets.
>>     Even throwing very high TCP load at it, it is hard to stop it
>>     being near-perfect.
>>     >>>
>>     >>> If you know Diffserv, think of it like this: you can get
>>     pretty much as good as Diffserv EF and better than AF, but for
>>     /all/ traffic. So you don't have to limit Diffserv EF to a small
>>     fraction of the capacity by separating out TCP traffic. in fact
>>     we need zero management or config; two queues (no per-flow
>>     queues); and less ops per packet than the simplest AQM (RED).
>>     >>>
>>     >>> The insight is that 'classic' TCPs (New Reno, Cubic etc.) are
>>     scaling badly - the sawteeth are getting bigger and the
>>     responsiveness is getting slower as flow rates increase. So we
>>     provide a migration path to 'scalable' TCPs instead. The trick is
>>     to ensure there is no 'classic' TCP in the same queue as all the
>>     'modern' traffic. But it's OK to mix scalable TCPs with 'modern'
>>     traffic.
>>     >>>
>>     >>>
>>     >>>
>>     >>>
>>     >>> --
>>     >>> ________________________________________________________________
>>     >>> Bob Briscoe http://bobbriscoe.net/
>>     >>>
>>     >
>>     > --
>>     > ________________________________________________________________
>>     > Bob Briscoe http://bobbriscoe.net/
>>     >
>>
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/


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