Re: [aqm] Immediate ECN: Autotuning AQM for RTT

[Bob Briscoe <[e-mail]>]

Rong,

At 07:26 09/11/2013, Rong Pan (ropan) wrote:
>I just got a better understanding of Bob's proposal. Great direction
>indeed! I fully agreed that doing the smoothing at the end hosts and
>simple network congestion signals is the best way to achieve low averaging
>latency.
>
>We do need these three working groups working together to get this done.
>But since folks usually attend all these three meetings at IETF, I am
>hopeful that IETF can make it happen with all our efforts together here.

It seems the IETF is willing to move quickly on this. We brought this 
work to the IETF earlier than I would normally have liked, given the 
urgency. We will try continue to move quickly, but it would be great 
if different groups could work in parallel. For instance, if your 
group and/or others could focus on testing this out with PIE.

more...


>Bob,
>
>a technical question. If we do no averaging for ECN, and hosts use the
>tradition ECN-capable TCP, I am afraid its window might get cut too much
>to achieve any reasonable throughput. Any thought on how to handle that?
>Or maybe you already covered in your slides and I missed it?

Bear in mind that altho traditional ECN hosts (we call them classic 
ECN) cut their rate by half in response to one CE mark they only do 
this once per RTT, then they ignore all the other marks in the same 
RTT. DCTCP only cuts its rate a little per mark, but it does so for 
every mark.

So it's not obvious what the outcome will be, but I'm hopeful that 
classic ECN hosts will achieve sufficient througput when competing 
with DCTCP, for some definition of 'sufficient'. Testing incremental 
deployment cases like this is next on our list of experiments to do.

I intended to say this on slide 13 (there's a brief footnote to this 
effect), but I had to cut short, because I had to squeeze a 20min 
presentation into the last 15 mins of tsvwg.

Regards


Bob


>Thanks,
>
>Rong
>
>
>
>On 11/7/13 12:03 PM, "Bob Briscoe" <[e-mail]> wrote:
>
> >Folks,
> >
> >"Immediate ECN" slides:
> ><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pptx>
> ><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pdf>
> >
> >PS. This talk fell off the end of the TSVAREA agenda. It's mostly
> >relevant to AQM, but I didn't originally bring it to AQM, because it
> >affects 3 wgs: tsvwg, aqm & tcpm.
> >
> >In the AQM wg, there was dismay about CableLabs not including
> >anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and
> >how ECN can take out the 100ms of delay that CoDel and PIE introduce
> >- it's essentially about auto-tuning for RTT.
> >
> >It gives an interim recommendation for hardware designers that there
> >should be a second instance of the AQM algo for ECN packets so that
> >it can be configured with different parameters (think of WRED instead of
> >RED).
> >
> >Specifically, for ECN packets:
> >interval = 0 (for CoDel)
> >max_burst = 0 (for PIE)
> >
> >
> >Bob
> >
> >PS. We have a paper under submission, which we can supply on request.
> >We plan to document this in the IETF too.
> >
> >
> >
> >
> >________________________________________________________________
> >Bob Briscoe,                                                  BT
> >
> >_______________________________________________
> >aqm mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT