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]
Message-ID: <alpine.DEB.2.00.1106031428280.17529@wel-95.cs.helsinki.fi>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ