Subject: Re: Important question re: new TCP options on data segments

From: "Howard Berkey" <[email-masked]>
Date: Wed, 09 Aug 2000 11:01:52 PDT

>On Wed, 9 Aug 2000, Alan Cox wrote:
>
>> > This prohibition on late TCP options is thwarting at least 2 
reasonable
>> > proposals for TCP options, including the RST error code.
>> 
>> I think the prohibition should just be dropped given the hostile 
nature of
>> the net today. Any box with that bug is basically unusable on the 
Internet
>> anyway
>
>Duh!  Sometime it is real important to rethink old decisions in new 
contexts.
>
>Ok, lets ask the question the other way:
>
>Can anybody think of *any* compelling argument agaist droping the 
prohibition
>against new TCP options appearing after a SYN?
>

Given that any new post-SYN options are (of course) optional and can be 
safely ignored by a receiving TCP, I see no reason why the restriction 
should be kept.

---

From: David Borman <[email-masked]>
Date: Wed, 9 Aug 2000 13:52:20 -0500 (CDT)

> Date: Wed, 09 Aug 2000 10:17:45 -0700
> From: Rick Jones <[email-masked]>
> Subject: Re: Important question re: new TCP options on data segments
>
> Matt Mathis wrote:
> > Can anybody think of *any* compelling argument agaist droping the prohibition
> It means I have to be prepared to look for "unexpected" options in my
> mainline data path.

That's already required by RFC 1122.

> I'm not certain it ensures there is enough space for all the options one
> might want to carry. True, it means that the options added in the middle
> would not have to fight for space with the MSS option or the window
> scale option, but it may still have to duke it out with a SACK option
> and timestamps.

If worse comes to worse, we can define a TCP option to extend the TCP
option space in a backwards compatable manner.  We did it for the
window field, and there are several ways we can do it for the Data
Offset field.  But that's not to say that I'm advocating putting in
oodles of TCP options...

			-David Borman, [email-masked]

---

From: Bernie Volz <[email-masked]>
Date: Wed, 9 Aug 2000 15:35:58 -0400

The MSS/MTU change isn't that difficult to deal with since this is an issue
for the SENDER, not the receiver. The sender knows (or should be able to
know) in advance what options it might send and thus can adjust the maximum
"data" size accordingly.

-----Original Message-----
From: Alan Cox [mailto:[email-masked]]
Sent: Wednesday, August 09, 2000 2:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Important question re: new TCP options on data segments

> It means I have to be prepared to look for "unexpected" options in my

Only if you support it

> scale option, but it may still have to duke it out with a SACK option

Actually you made me realise a worse problem. It isnt the options and option
space that is a pain, its the sudden change of MSS relative to the MTU due
to additional header overhead

---

From: "Howard Berkey" <[email-masked]>
Date: Wed, 09 Aug 2000 13:34:25 PDT

prohibition
>It means I have to be prepared to look for "unexpected" options in my

To be robust (and follow the spirit of "be liberal in what you 
accept"), you already have to anyway.

Remember, you don't have to actually DO anything with the later 
options;  you just have to not die when they arrive.  Options are, in 
general, optional.

>
>I cannot help but think about how planes like the B17 kept getting
>heavier, more complex, and (iirc) just a little slower as people added
>this feature and that feature...
>

Continuing your analogy, by being robust the B17 could take a lot of 
punishment fired at it before it went down :-)

---

From: David Borman <[email-masked]>
Date: Wed, 9 Aug 2000 15:30:27 -0500 (CDT)

> Date: Wed, 9 Aug 2000 19:53:29 +0100 (BST)
> From: Alan Cox <[email-masked]>
...
> to additional header overhead

Without going into the whole "MSS is not MTU" discussion...  Assuming an
MSS based on the MTU, the advertised MSS value is MTU - 40, you *do not*
adjust your advertised MSS value to account for either TCP or IP options
that you think the other side might send.

Instead, the sender is responsible for adjusting down the amount of TCP
data that it puts into the packet to account for any TCP and IP options
that are also being included.