From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Jeremy Harris <jgh@wizmail.org>, ecn-sane@lists.bufferbloat.net
Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
Date: Wed, 7 Aug 2019 14:25:58 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1908071418000.21828@uplift.swm.pp.se> (raw)
In-Reply-To: <B16EFAEB-978B-46A1-A484-77C503B8519F@gmx.de>
On Wed, 7 Aug 2019, Sebastian Moeller wrote:
> I guess I am overly naive, but as far as I can tell only TCP has
> this strong shuffling-sensitivity, UDP itself does not care
> (applications still might dislike packet shuffling). Could the
I know applications that require packets (using UDP) to be arriving in
order, because an out of order packet is considered a lost packet. These
applications are designed with the presumtion that the network deliver the
packets in order (at least within the 5 tuple).
I guess basic TCP (without SACK) can be argued as the same property?
> intermediate hops not simply block TCP and just pass on UDP? This should
> at least avoid the medium idling while waiting for the straggling
> packets. I guess that is tricky in that a medium's ARQ might not look
> past its own headers, "sequence identifiers" and checksums, clearly that
> is not enough to get to the protocol ID (add to this IPv6 extension
> headers and the required deep dive).
I think the argument can be made that TCP actually is less sensitive to
packet reordering (with SACK) than UDP. With TCP it's fairly well
understood what happens, with UDP we have no idea, because we don't know
what application is running.
> The fact that is not implemented yet, indicates to me that the ECT(1)
> thing is also not likely to make more inroads, what am I missing?
The whole concept of "let's try to figure out what traffic can be
delivered out of order and what needs to be in order" is a fairly new
concept. I am not surprised this hasn't been implemented yet. There is
absolutely no current consensus on what traffic can be re-ordered or not.
L4S suggests an implicit mark on "new" transports that are allowed to be
re-ordered. I have not seen any such proposal before. Typically the L2/ARQ
designers are sitting there designing their thing without knowing anything
about L3 or L4 basically. Having this kind of cross-layer approach is kind
of new from what I can see.
--
Mikael Abrahamsson email: swmike@swm.pp.se
next prev parent reply other threads:[~2019-08-07 12:25 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 0:01 [Ecn-sane] Comments on L4S drafts Holland, Jake
2019-06-07 18:07 ` Bob Briscoe
2019-06-14 17:39 ` Holland, Jake
2019-06-19 14:11 ` Bob Briscoe
2019-07-10 13:55 ` Holland, Jake
2019-06-14 20:10 ` [Ecn-sane] [tsvwg] " Luca Muscariello
2019-06-14 21:44 ` Dave Taht
2019-06-15 20:26 ` [Ecn-sane] [tsvwg] CoIt'smments " David P. Reed
2019-06-19 1:15 ` [Ecn-sane] [tsvwg] Comments " Bob Briscoe
2019-06-19 1:33 ` Dave Taht
2019-06-19 4:24 ` Holland, Jake
2019-06-19 13:02 ` Luca Muscariello
2019-07-04 11:54 ` Bob Briscoe
2019-07-04 12:24 ` Jonathan Morton
2019-07-04 13:43 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-04 14:03 ` Jonathan Morton
2019-07-04 17:54 ` Bob Briscoe
2019-07-05 8:26 ` Jonathan Morton
2019-07-05 6:46 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-05 8:51 ` Jonathan Morton
2019-07-08 10:26 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-08 20:55 ` Holland, Jake
2019-07-10 0:10 ` Jonathan Morton
2019-07-10 9:00 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-10 13:14 ` Dave Taht
2019-07-10 17:32 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-17 22:40 ` Sebastian Moeller
2019-07-19 9:06 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-19 15:37 ` Dave Taht
2019-07-19 18:33 ` Wesley Eddy
2019-07-19 20:03 ` Dave Taht
2019-07-19 22:09 ` Wesley Eddy
2019-07-19 23:42 ` Dave Taht
2019-07-24 16:21 ` Dave Taht
2019-07-19 20:06 ` Black, David
2019-07-19 20:44 ` Jonathan Morton
2019-07-19 22:03 ` Sebastian Moeller
2019-07-20 21:02 ` Dave Taht
2019-07-21 11:53 ` Bob Briscoe
2019-07-21 15:30 ` [Ecn-sane] Hackathon tests Dave Taht
2019-07-21 15:33 ` [Ecn-sane] [tsvwg] Comments on L4S drafts Sebastian Moeller
2019-07-21 16:00 ` Jonathan Morton
2019-07-21 16:12 ` Sebastian Moeller
2019-07-22 18:15 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-22 18:33 ` Dave Taht
2019-07-22 19:48 ` Pete Heist
2019-07-25 16:14 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-26 13:10 ` Pete Heist
2019-07-26 15:05 ` [Ecn-sane] The state of l4s, bbrv2, sce? Dave Taht
2019-07-26 15:32 ` Dave Taht
2019-07-26 15:37 ` Neal Cardwell
2019-07-26 15:45 ` Dave Taht
2019-07-23 10:33 ` [Ecn-sane] [tsvwg] Comments on L4S drafts Sebastian Moeller
2019-07-21 12:30 ` Bob Briscoe
2019-07-21 16:08 ` Sebastian Moeller
2019-07-21 19:14 ` Bob Briscoe
2019-07-21 20:48 ` Sebastian Moeller
2019-07-25 20:51 ` Bob Briscoe
2019-07-25 21:17 ` Bob Briscoe
2019-07-25 22:00 ` Sebastian Moeller
2019-07-26 10:20 ` [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs Sebastian Moeller
2019-07-26 14:10 ` Black, David
2019-07-26 16:06 ` Sebastian Moeller
2019-07-26 19:58 ` Black, David
2019-07-26 21:34 ` Sebastian Moeller
2019-07-26 16:15 ` Holland, Jake
2019-07-26 20:07 ` Black, David
2019-07-26 23:40 ` Jonathan Morton
2019-08-07 8:41 ` Mikael Abrahamsson
2019-08-07 10:06 ` Mikael Abrahamsson
2019-08-07 11:57 ` Jeremy Harris
2019-08-07 12:03 ` Mikael Abrahamsson
2019-08-07 12:14 ` Sebastian Moeller
2019-08-07 12:25 ` Mikael Abrahamsson [this message]
2019-08-07 12:34 ` Jeremy Harris
2019-08-07 12:49 ` Mikael Abrahamsson
[not found] ` <5D34803D.50501@erg.abdn.ac.uk>
2019-07-21 16:43 ` [Ecn-sane] [tsvwg] Comments on L4S drafts Black, David
2019-07-21 12:30 ` Scharf, Michael
2019-07-19 21:49 ` Sebastian Moeller
2019-07-22 16:28 ` Bless, Roland (TM)
2019-07-19 17:59 ` Sebastian Moeller
2019-07-05 9:48 ` Luca Muscariello
2019-07-04 13:45 ` Bob Briscoe
2019-07-10 17:03 ` Holland, Jake
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/ecn-sane.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1908071418000.21828@uplift.swm.pp.se \
--to=swmike@swm.pp.se \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=jgh@wizmail.org \
--cc=moeller0@gmx.de \
/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