From: Jeremy Harris <jgh@wizmail.org>
To: ecn-sane@lists.bufferbloat.net
Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
Date: Wed, 7 Aug 2019 12:57:20 +0100 [thread overview]
Message-ID: <dbff5fbc-982f-1249-1620-ce2ede69d3bc@wizmail.org> (raw)
In-Reply-To: <alpine.DEB.2.20.1908071202570.21828@uplift.swm.pp.se>
On 07/08/2019 11:06, Mikael Abrahamsson wrote:
> I also encourage if we can reach overall consensus that transports
> should take into account that packets can be re-ordered and what
> timescales would be acceptable for this to happen (1ms? 10ms? 100ms?
> Even more? Less? Not at all?)
The major issue I see is that the interface between transport and
its client layer needs to become more complex for that.
I could, for example, imagine a pure (FTP-complexity) file transfer
application over TCP being able to receive out-of-order received
TCP segments and hand them direct to the kernel using pwrite
(assuming TCP SACK in use). But the socket interface would need
to present sequencing information along with the segments; it being
no longer implied by the sequence of satisfied reads.
The timescale for acceptable re-ordering for that case is "indefinite".
But it's only one case, and a pretty limited one.
--
Cheers,
Jeremy
next prev parent reply other threads:[~2019-08-07 11:57 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 [this message]
2019-08-07 12:03 ` Mikael Abrahamsson
2019-08-07 12:14 ` Sebastian Moeller
2019-08-07 12:25 ` Mikael Abrahamsson
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=dbff5fbc-982f-1249-1620-ce2ede69d3bc@wizmail.org \
--to=jgh@wizmail.org \
--cc=ecn-sane@lists.bufferbloat.net \
/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