One big problem I came across while thinking about putting in something to
send SACK options is that typically the IP headers are created before the
TCP headers, and then the data is filled in. And if the segment happens to
be queued, the TCP options in the header have to be updated just before
sending. Now since the SACK options are variable length, we don't know how
many SACK options will be needed when the segment is actually sent, so we
don't know what the length required for them will be while creating the
headers initially...
There's two possible ways to fix this:
1) Reserve the greatest possible length for the SACK options (3 or 4,
depending on what other options you're sending). Fill the unused space
with NOPs. This is a really ugly hack, but easy to do.
2) This is the one I really like: do what we already do for the link layer
headers. In other words, just reserve the space for the IP and TCP headers
and fill in the segment with data. Then, just before sending, create the
TCP header, then create the IP header, and then dev_queue_xmit() or
whatever... This is probably the way it should be anyways, it's just a
matter of putting the layers in their correct order ;)
The problem is (2) requires quite a bit of work and I never got around to
doing it. But I do think it's the Right Way.
Or am I horribly wrong? Also is anybody working on the SACK?
Comments/flames welcome,
-Vijay
On Thu, 5 Feb 1998, Alan Cox wrote:
> > What exactly is wrong with the TCP code? In reference to my T/TCP project
> > I decided to develop it on the 2.1 series, as the timescale and windowing
> > options were already implemented, are these something that isn't working?
>
> The window handling management is a bit brokem right now. Id suspect you'll
> find timescale a bit iffy too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu