Subject: [Tsvwg] Re: TCP end-to-end Semantics - OPTIONS

From: Lloyd Wood <[email-masked]>
Date: Tue, 16 Jan 2001 20:06:40 +0000 (GMT)

[most of this thread has little to do with satellites, so I've cc'd
tsvwg, and suggest discussion moves there.]

On Tue, 16 Jan 2001, Dr G Fairhurst wrote:

> If you can find out why you want to do it, and what benefit you get, why
> not consider a TCP option?

Because there's no space left.

The problem with TCP options is that there's limited space for them,
and what with SACK and timestamps, the 40 available bytes for options
soon fill up.

Has anyone given any thought to negotiating accepted size of the TCP
options field when a connection is initiated, or, slightly more crufty
but perhaps better from a legacy viewpoint, negotiating use/acceptance
of an option field indicating that further option information can be
carried elsewhere in the TCP segment, either following the options
field directly (ease of processing) or after any data in the segment?

(The latter is possibly more backwards-compatible for old code that
might assume a limit on option size, but since checksums have to be
adjusted anyway that's probably a moot point. Possibly better for
spoofing/NAT implementations en-route, though.)

This would allow more SACK information to be provided - useful in
itself. So you might have either:

a) optional option at TCP connection setup indicating maximum number
of TCP options sender is willing to process. Default (no given options
limit advertised) is four as present; both ends can set their max
tolerance. Weeny wireless receivers that know they're on
header-compressed links might demand a limit of one or two, etc.

Defining an explicit option size acceptance limit in initial
negotiation and using the null terminator - that's what it's for! -
strikes me as slightly more in the spirit of RFC1263 than the more
baroque alternative below; all a spoofer has to do is not pass the
option on during the initial exchange, so it's backwards-compatible.

b) negotiated use of willingness to accept options 'extension header'
at startup, then in a packet with a lot of options, you'd have:

option field:     timestamp
                  window size
                  optional option indicating use of optional options
optional options: sack
                  sack
                  sack
                  [..]
                  sack. Loads and loads of sack.
                  everything else we can think of.
data.

Yes, MSS payload computation has to be adjusted, but this strikes me
as an easy win for cases where most of your data transfer is one-way
and you're just sending acks where you can piggyback a lot of useful
option information. Nothing wrong with a hundreds-byte ack packet if
it contains useful information that the other end can process.

And then we can worry less about sender heuristics guessing SACK state
from the miserly three records available, too.

Suggestion b) strikes me as vaguely analogous to use of GRE; it's a
generic get-out-of-closed-space be-it-protocol-bits-or-option-bytes
extension-header fix.

L.

hey, if T/TCP with SACK ever takes off, we'll need all the option
space we can get.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg