From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B61743B29E for ; Sat, 16 Mar 2019 18:59:24 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 95E5A3826B; Sat, 16 Mar 2019 18:59:01 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E47A0B9A; Sat, 16 Mar 2019 18:59:23 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E1D08989; Sat, 16 Mar 2019 18:59:23 -0400 (EDT) From: Michael Richardson To: David Lang cc: Sebastian Moeller , Ingemar Johansson S , "bloat\@lists.bufferbloat.net" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 22:59:24 -0000 --=-=-= Content-Type: text/plain David Lang 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyNf8sACgkQgItw+93Q 3WVHTwf/dvfQ+2aHVsPzAsgZOQdxrYvNxh4CLB63knuiu7QOu0WLuKq5bCpQlbxC pKU9NT795BXjytmQ/N58rDvWvwZEvB8OdW3yjkeDXJluxd1S5Is7h+ZNRVbgA/9e rjnxFGFfwCB/+jyPc5zUWnoaviI1ISxPtdviv5Qz/nLg2M07wZZOFDEF4MetK3Ob c9hbxx0VPVEEkdqGewNjgn6pDX087mDdO2UUZlmbzDfzyZhJ16NIzsojV93UaJRd CHLmTzoRX7QRtLh6GO97ZhlEibz5wxMV8mraC5PTNXcFBjHxFghZucQC+6Bb3p+I ECC/22ekRLwqlizq/azULXIaGaZjCg== =ggjF -----END PGP SIGNATURE----- --=-=-=--