From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Mirja Kühlewind" <mirja.kuehlewind@tik.ee.ethz.ch>,
"Ingemar Johansson S" <ingemar.s.johansson@ericsson.com>
Cc: "cheshire@apple.com" <cheshire@apple.com>,
"iccrg@irtf.org" <iccrg@irtf.org>,
"Bob Briscoe \(bob.briscoe@bt.com\)" <bob.briscoe@bt.com>,
"bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>,
"ietf@trammell.ch" <ietf@trammell.ch>
Subject: Re: [Bloat] [iccrg] ECN issues
Date: Sun, 19 Jul 2015 08:21:12 +0000 [thread overview]
Message-ID: <f64d413e378b4b21b19f673fe9f7aca0@hioexcmbx05-prd.hq.netapp.com> (raw)
In-Reply-To: <6D65AC6E-4AA1-4F8C-B758-D63EEC59A0E2@tik.ee.ethz.ch>
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
prev parent reply other threads:[~2015-07-19 8:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 11:34 [Bloat] " Ingemar Johansson S
2015-06-24 11:48 ` Hagen Paul Pfeifer
[not found] ` <04ED8D23-53C3-4F12-9647-3A07FFB43352@tik.ee.ethz.ch>
2015-06-25 17:49 ` Dave Taht
2015-06-25 18:15 ` Jonathan Morton
2015-06-25 18:52 ` David Lang
2015-06-26 11:05 ` Juliusz Chroboczek
2015-06-25 19:02 ` Ingemar Johansson S
2015-06-25 22:07 ` Jonathan Morton
[not found] ` <6D65AC6E-4AA1-4F8C-B758-D63EEC59A0E2@tik.ee.ethz.ch>
2015-07-19 8:21 ` Scheffenegger, Richard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f64d413e378b4b21b19f673fe9f7aca0@hioexcmbx05-prd.hq.netapp.com \
--to=rs@netapp.com \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.briscoe@bt.com \
--cc=cheshire@apple.com \
--cc=iccrg@irtf.org \
--cc=ietf@trammell.ch \
--cc=ingemar.s.johansson@ericsson.com \
--cc=mirja.kuehlewind@tik.ee.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox