General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: David Lang <david@lang.hm>
Cc: Sebastian Moeller <moeller0@gmx.de>,
	Ingemar Johansson S <ingemar.s.johansson@ericsson.com>,
	"bloat\@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint)
Date: Sat, 16 Mar 2019 18:59:23 -0400	[thread overview]
Message-ID: <7025.1552777163@localhost> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1903141454550.4904@qynat-yncgbc>

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


David Lang <david@lang.hm> wrote:
    > if there is no resouce contention, they should be equal.

    > In practice, since the network devices are more likely to run into resource
    > contention (think locking overhead between cores if nothing else), it can
    > easily be faster to sort them at the destination.

The problem has been, as I understand it, is that many historic TCP receivers
think that receipt of packet X+n without having seen X, means that there is a
loss.  This can be solved with appropriate tuning of n, and by how long to
wait, but this has usually required some uber-expert action.

It seems to me that it could also be learnt heuristically how many might be
out of order by observing how long it takes to see packet X.

(Perhaps the newer stacks do this... when it comes to latest TCPs algorithms,
I'm strictly in the gawking section)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2019-03-16 22:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14  8:26 Ingemar Johansson S
2019-03-14  8:43 ` Sebastian Moeller
2019-03-14 19:23   ` Greg White
2019-03-14 21:43     ` Sebastian Moeller
2019-03-14 22:05       ` David Lang
2019-03-16 22:59         ` Michael Richardson [this message]
2019-03-17 10:23       ` Carsten Bormann
2019-03-17 11:45         ` Sebastian Moeller
2019-03-17 14:34           ` Carsten Bormann
2019-03-17 15:56             ` Sebastian Moeller
2019-03-17 17:09               ` Carsten Bormann
2019-03-17 19:57                 ` Sebastian Moeller
2019-03-18  0:05                   ` David Lang

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=7025.1552777163@localhost \
    --to=mcr@sandelman.ca \
    --cc=bloat@lists.bufferbloat.net \
    --cc=david@lang.hm \
    --cc=ingemar.s.johansson@ericsson.com \
    --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