Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs

[Sebastian Moeller <moeller0@gmx.de>]

> On Aug 7, 2019, at 14:03, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Wed, 7 Aug 2019, Jeremy Harris wrote:
> 
>> (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.
> 
> Yes, the socket stream interface guarantees ordered delivery of that stream. That doesn't mean other 5 tuple connections running over the same media need to be held up just because a packet is missing from this first stream. A lot of medias guarantees complete ordering, even between flows/streams. If we loosen this requirement then muxed transports or other stream can continue even if there is a packet missing and being ARQed on the media.

	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 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).
 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?

Best Regards
	Sebastian


> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane