[Bloat] ECN issues

[Bloat] ECN issues

[Ingemar Johansson S]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Hi

I wonder, is there any new data around that gives any ideas how large the issues with ECN really are ?.

Issues that I am interested are ECN black holes and faulty remarking of ECN fields

The last one I have seen is this paper by Mirja, Brian and Sebastian Neuner
http://www.ict-mplane.eu/sites/default/files/public/publications/311ecndeployment.pdf

Is there any new data available ?.

/Ingemar
=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>
www.ericsson.com

"No man has a good enough memory
  to be a successful liar"
    Abraham Lincoln<http://www.brainyquote.com/quotes/authors/a/abraham_lincoln.html>
=================================


[-- Attachment #2: Type: text/html, Size: 7332 bytes --]

Re: [Bloat] ECN issues

[Hagen Paul Pfeifer]

> Ingemar Johansson S <ingemar.s.johansson@ericsson.com> 24. Juni 2015:
>
> Is there any new data available ?.

"Enabling Internet-Wide Deployment of Explicit Congestion Notification"[1]

Hagen

[1] http://ecn.ethz.ch/ecn-pam15.pdf

Re: [Bloat] ECN issues

[Dave Taht]

In my case I just managed to show that congestive (rather than path)
loss can be a factor in the reliability of even a low rate, CS6
prioritized, link local multicast routing protocol (babel), over
present day linux wifi, even using a modern fq+aqm+ecn system.

Enabling ECN markings in babel and watching for CEs while under load, here:

http://snapon.lab.bufferbloat.net/~d/newrouters/linuxcap.cap

I am not sure where to go with that, but I am deploying it at a small
scale anyway, as gathering link local rtt information somewhat
passively at the moment and point of congestion is important to guide
my other work on wifi. No plans for a paper or presentation, it was
just "interesting", let me know if you have any ideas in addition to
this

http://lists.alioth.debian.org/pipermail/babel-users/2015-April/001974.html

as to where to go with it.

Re: [Bloat] ECN issues

[Jonathan Morton]

> On 25 Jun, 2015, at 20:49, Dave Taht <dave.taht@gmail.com> wrote:
> 
> In my case I just managed to show that congestive (rather than path)
> loss can be a factor in the reliability of even a low rate, CS6
> prioritized, link local multicast routing protocol (babel), over
> present day linux wifi, even using a modern fq+aqm+ecn system.

The conventional wisdom certainly is that ECN should be left off simple 1-RTT request-response protocols, where there is presumed to be no way to convey and act on the congestion information in the future.

DNS is such a protocol, at least for simple queries that fit into UDP.  Ergo, DNS generally doesn’t use ECN at present.

But in practice, a DNS resolver makes several queries in rapid succession, and often the resolver itself has sufficient persistence to be able to relay congestion state from one query to the next (especially if it’s a proxy in a CPE router).  DNS is also a critical latency factor in many practical Internet applications, especially Web traffic.  ECN capability effectively increases reliability of delivery when the bottleneck has AQM, and DNS should respond well to that, since upon loss (of either request or response) it has to wait for a exponential-backoff timeout.

I think that’s a concept worth pursuing.

- Jonathan Morton

Re: [Bloat] ECN issues

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1659 bytes --]

On Thu, 25 Jun 2015, Jonathan Morton wrote:

>> On 25 Jun, 2015, at 20:49, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> In my case I just managed to show that congestive (rather than path)
>> loss can be a factor in the reliability of even a low rate, CS6
>> prioritized, link local multicast routing protocol (babel), over
>> present day linux wifi, even using a modern fq+aqm+ecn system.
>
> The conventional wisdom certainly is that ECN should be left off simple 1-RTT 
> request-response protocols, where there is presumed to be no way to convey and 
> act on the congestion information in the future.
>
> DNS is such a protocol, at least for simple queries that fit into UDP.  Ergo, 
> DNS generally doesn’t use ECN at present.
>
> But in practice, a DNS resolver makes several queries in rapid succession, and 
> often the resolver itself has sufficient persistence to be able to relay 
> congestion state from one query to the next (especially if it’s a proxy in a 
> CPE router).  DNS is also a critical latency factor in many practical Internet 
> applications, especially Web traffic.  ECN capability effectively increases 
> reliability of delivery when the bottleneck has AQM, and DNS should respond 
> well to that, since upon loss (of either request or response) it has to wait 
> for a exponential-backoff timeout.
>
> I think that’s a concept worth pursuing.

From a purely pragmatic point of view, if a router will mark a packet as ECN 
instead of dropping it, DNS packets should be marked with ECN because other 
requests are serialized on the DNS lookup, so a dropped packet/timeout results 
in a very user-visible delay.

David Lang

Re: [Bloat] ECN issues

[Juliusz Chroboczek]

> The conventional wisdom certainly is that ECN should be left off simple 
> 1-RTT request-response protocols,

Just to avoid any misunderstandings:

   - Babel does not use ECN; the marking is due to Dave's local hack;

   - Babel is an asynchronous protocol that runs (mostly) over multicast,
     not a request-response protocol, so there's no obvious way to carry
     an echo bit in it;

   - Babel is designed to work well over extremely lossy links (with the
     standard implementation working reasonably well at 85% pre-ARQ loss).

[Shouldn't we be dropping people from the CC?]

-- Juliusz

Re: [Bloat] ECN issues

[Ingemar Johansson S]

Hi

And thanks all for the info both on and off list. I believe that I have enough information. The main objective for me was to get an understanding how serious the issues that various boxes in the middle (e.g NATs/FWs ) mess with the ECN bits really is. Seems to me, based on the info I received thus far that this is becoming more and more an non-issue ?. 

Realized that I have seen the below paper before,  somehow I mixed it up with the older paper, have to blame it on my own teflon-memory ... Thanks for refreshing my memory

/Ingemar

> -----Original Message-----
> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> Sent: den 25 juni 2015 19:31
> To: Ingemar Johansson S
> Cc: bloat@lists.bufferbloat.net; iccrg@irtf.org; Bob Briscoe
> (bob.briscoe@bt.com); ietf@trammell.ch; Dave Taht
> (dave.taht@gmail.com); cheshire@apple.com
> Subject: Re: ECN issues
> 
> Hi Ingemar,
> 
> there is a newer paper we published last year (and gave a quick presentation
> at the last ICCRG meeting):
> 
> http://wan.poly.edu/pam2015/papers/4.pdf
> 
> https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-1.pdf
> 
> In the mean time we did more measurements using BitTorrent clients
> instead. The results are very similar. We might be able to quickly present
> some new results at the next session (if the session takes place and there is
> still space).
> 
> Does this help or are you looking for some specific information?
> 
> Mirja
> 
> 
> > Am 24.06.2015 um 13:34 schrieb Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com>:
> >
> > Hi
> >
> > I wonder, is there any new data around that gives any ideas how large the
> issues with ECN really are ?.
> >
> > Issues that I am interested are ECN black holes and faulty remarking
> > of ECN fields
> >
> > The last one I have seen is this paper by Mirja, Brian and Sebastian
> > Neuner
> > http://www.ict-mplane.eu/sites/default/files/public/publications/311ec
> > ndeployment.pdf
> >
> > Is there any new data available ?.
> >
> > /Ingemar
> > =================================
> > Ingemar Johansson  M.Sc.
> > Senior Researcher
> >
> > Ericsson AB
> > Wireless Access Networks
> > Labratoriegränd 11
> > 971 28, Luleå, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > ingemar.s.johansson@ericsson.com
> > www.ericsson.com
> >
> > "No man has a good enough memory
> >   to be a successful liar"
> >     Abraham Lincoln
> > =================================

Re: [Bloat] ECN issues

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

It's enough of a non-issue for Apple to consider turning ECN on by default
in their next OS releases. The subsequent sharp uptick in ECN traffic
(since there's a lot of Apple devices out there) should help to eliminate
the rest.

It's also enough of a non-issue for me personally to turn ECN on by default
on all my machines. Of course, I get particular benefit from doing so since
I usually have cake running at my bottleneck.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 514 bytes --]

Re: [Bloat] [iccrg] ECN issues

[Scheffenegger, Richard]

Hi Ingemar,

I was to make that very same point; from my earlier collaboration with Mirja and Brians efforts, I think the prevalence of gear that still uses a notion of a TOS byte, and rewrites it for a L4 flow is actually higher than ECN impacting connection set up etc.

So, on some paths you may believe you negotiate ECN, but one half-link may bleach the IP-header ECN bits.

Again, this is detectable for the receiver (currently, no mechanism to convey this info back to a TCP sender), and affected sessions would revert back to loss-based CC.



Such ECN-unresponsive, loss-responsive flows may pose an issue to AQMs that do some differentiated handling of ECN vs non-ECN packets though...

Best regards,
  Richard



> -----Original Message-----
> From: iccrg [mailto:iccrg-bounces@irtf.org] On Behalf Of Mirja Kühlewind
> Sent: Montag, 29. Juni 2015 14:56
> To: Ingemar Johansson S
> Cc: cheshire@apple.com; iccrg@irtf.org; Dave Taht (dave.taht@gmail.com);
> Bob Briscoe (bob.briscoe@bt.com); bloat@lists.bufferbloat.net;
> ietf@trammell.ch
> Subject: Re: [iccrg] ECN issues
> 
> Hi Ingemar,
> 
> we did only test connection setup up and some small transmissions so far.
> We did not measurement anything with longer connection though. However,
> from these results I'd also say there are no mayor issues anymore. There
> are still some boxes that overwrite the IP ECN bits because they still
> think it's part of the ToS field. However, those cases are rather easy to
> detect because all packets should have the same marking. Linux implements
> an easy fallback where ECN is disabled if the SYN is ECN marked. That's
> probably not the perfect solution but mostly helps the problem.
> 
> Mirja
> 
> 
> > Am 25.06.2015 um 21:02 schrieb Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com>:
> >
> > Hi
> >
> > And thanks all for the info both on and off list. I believe that I have
> enough information. The main objective for me was to get an understanding
> how serious the issues that various boxes in the middle (e.g NATs/FWs )
> mess with the ECN bits really is. Seems to me, based on the info I
> received thus far that this is becoming more and more an non-issue ?.
> >
> > Realized that I have seen the below paper before,  somehow I mixed it
> > up with the older paper, have to blame it on my own teflon-memory ...
> > Thanks for refreshing my memory
> >
> > /Ingemar
> >
> >> -----Original Message-----
> >> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> >> Sent: den 25 juni 2015 19:31
> >> To: Ingemar Johansson S
> >> Cc: bloat@lists.bufferbloat.net; iccrg@irtf.org; Bob Briscoe
> >> (bob.briscoe@bt.com); ietf@trammell.ch; Dave Taht
> >> (dave.taht@gmail.com); cheshire@apple.com
> >> Subject: Re: ECN issues
> >>
> >> Hi Ingemar,
> >>
> >> there is a newer paper we published last year (and gave a quick
> >> presentation at the last ICCRG meeting):
> >>
> >> http://wan.poly.edu/pam2015/papers/4.pdf
> >>
> >> https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-1.pdf
> >>
> >> In the mean time we did more measurements using BitTorrent clients
> >> instead. The results are very similar. We might be able to quickly
> >> present some new results at the next session (if the session takes
> >> place and there is still space).
> >>
> >> Does this help or are you looking for some specific information?
> >>
> >> Mirja
> >>
> >>
> >>> Am 24.06.2015 um 13:34 schrieb Ingemar Johansson S
> >> <ingemar.s.johansson@ericsson.com>:
> >>>
> >>> Hi
> >>>
> >>> I wonder, is there any new data around that gives any ideas how
> >>> large the
> >> issues with ECN really are ?.
> >>>
> >>> Issues that I am interested are ECN black holes and faulty remarking
> >>> of ECN fields
> >>>
> >>> The last one I have seen is this paper by Mirja, Brian and Sebastian
> >>> Neuner
> >>> http://www.ict-mplane.eu/sites/default/files/public/publications/311
> >>> ec
> >>> ndeployment.pdf
> >>>
> >>> Is there any new data available ?.
> >>>
> >>> /Ingemar
> >>> =================================
> >>> Ingemar Johansson  M.Sc.
> >>> Senior Researcher
> >>>
> >>> Ericsson AB
> >>> Wireless Access Networks
> >>> Labratoriegränd 11
> >>> 971 28, Luleå, Sweden
> >>> Phone +46-1071 43042
> >>> SMS/MMS +46-73 078 3289
> >>> ingemar.s.johansson@ericsson.com
> >>> www.ericsson.com
> >>>
> >>> "No man has a good enough memory
> >>>  to be a successful liar"
> >>>    Abraham Lincoln
> >>> =================================
> 
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg