netdev - Re: Skipping past TCP lost packet in userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Jun 2011 14:51:40 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Josh Lehan <linux@...llan.com>
cc:	netdev <netdev@...r.kernel.org>
Subject: Re: Skipping past TCP lost packet in userspace

On Wed, 1 Jun 2011, Josh Lehan wrote:

> On 05/31/2011 10:23 AM, Yuchung Cheng wrote:
> > This paper may have a solution to your problem
> > "Minion—an All-Terrain Packet Packhorse to Jump-Start Stalled Internet
> > Transports"
> > http://csweb1.fandm.edu/jiyengar/lair/papers/minion-pfldnet2010.pdf
> 
> Nice, thanks for pointing me to this.  I appreciate the helpful answer,
> instead of just saying "use UDP" or "use SCTP".  That's not the point.
> 
> For better or for worse, TCP is realistically the only viable protocol
> for streaming to the largest possible audience these days, hence my
> question about adding this feature to the Linux TCP implementation.
> 
> As for the Linux receiver, I was thinking of 2 features:
> 
> 1) Assuming the application has already read all data that would be
> possible without blocking, perform something like an ioctl() to peek at
> the data, and peek to see if there is any out-of-order data behind a gap.
> 
> 2) If the out-of-order data is enough to be useful to the application,
> another ioctl() could be done, to ask the kernel to jump over the gap
> and deliver the data to the application.  At this point the missing data
> would be considered lost.  The data behind the gap would then be
> delivered to the application as part of its normal reading stream.  The
> TCP sequence numbers would advance, as usual, just as if the missing
> data had been there all along.

And you'd send a cumulative ACK without the actual data segment...? 
...That's gonna break many middleboxes which would want to see that 
data segment too ...And there goes your "viability" (though with luck it 
will _sometimes_ work as rexmit of the data segment is already in flight). 

...The fact is that such change into TCP wire behavior is no longer TCP 
enough to work reliably.

In addition, such a non-legimite cumulative ACK probably violates number 
of TCP RFCs or at least assumptions made in them... e.g., for starters, 
please explain which timestamp you would be putting there into that 
particular cumulative ACK?


-- 
 i.