General list for discussing Bufferbloat
 help / color / mirror / Atom feed
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

      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