[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0911171412380.7024@wel-95.cs.helsinki.fi>
Date: Tue, 17 Nov 2009 14:18:57 +0200 (EET)
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To: David Miller <davem@...emloft.net>
cc: eric.dumazet@...il.com, william.allen.simpson@...il.com,
Netdev <netdev@...r.kernel.org>, joe@...ches.com
Subject: Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie
option, extend existing struct's
On Mon, 16 Nov 2009, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Mon, 16 Nov 2009 23:26:04 +0100
>
> > So adding DATA to SYN packets might be problematic for part of our tcp
> > stack.
>
> I can almost guarentee it won't work. For one thing getting a SACK
> response to a SYN+DATA packet will explode quite nicely for one thing.
Now I'm really lost??? How can you get SACKs for that in the first
place since they are either lost or delivered in unison???
> A lot of the other retransmit queue handling would need to be audited
> as well. So much code assumes that if we see sent data in the
> retransmit queue, there won't be SYN or SYN+ACK things in there to
> contend with.
...Valid ACKs will either remove that SYN+DATA segment completely, other
ACK could (or should) just be dropped. I kind of fail to see what is the
problem here.
--
i.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists