Subject: RE: First SACK-permitted on <SYN,ACK>

From: David Borman <[email-masked]>
Date: Wed, 9 Aug 2000 11:43:23 -0500 (CDT)

A couple of things about TCP options in non-SYN packets, in regard
to the Timestamps option.

      o	There were multiple reasons for requiring that the
	Timestamps be exchanged in the SYN packet, not just
	to protect buggy implementations.  It also means that
	you don't waste bandwidth sending options that are just
	going to be ignored.

      o RFC 1323 doesn't require a timestamps option in every
	packet (but PAWS assumes that there is.)

      o	Starting a connection without the Timestamps option, and
	then later turning on Timestamps is not a big problem.  But
	stopping once you have started creates problems for PAWS...

Also, RFC 1122 requires that TCPs must be able to handle TCP options
in non-TCP segments, ignoring unknown options and not crashing if the
option length is bogus (see section 4.2.2.5).

The Timestamps option was the first TCP option to be passed in
non-SYN packets, so even though RFC-1122 requires that hosts handle
TCP options in non-SYN packets, at the time it was prudent to
have the exchange on the initial SYN for interoperabilty reasons. 

I don't have any objections to allowing TCP options in non-SYN
packets without prior negotiation in the SYN packets.  And specifically
with the Timestamps option, if we were to modify it to not require that
Timestamps be exchanged on the SYN, then it should be done with the
caveat that once Timestamps are enabled, they must remain enabled for
the rest of the connection.  You would probably only want to initiate
the enabling of Timestamps on a data packet, because when you get the
ACK for that data, it will contain a Timestamps option if the other
side supports it.  If it doesn't have a Timestamps option, then you
know the other side doesn't support them and you stop sending them.

			-David Borman, [email-masked]

> From: Bernie Volz <[email-masked]>
> Subject: RE: First SACK-permitted on <SYN,ACK>
> Date: Wed, 9 Aug 2000 10:00:18 -0400 
>
> I agree (prohibition should be dropped). It will help to force people to fix
> the implementations.
>
> - Bernie Volz
>   IPWorks, Inc.
>
> -----Original Message-----
> From: Alan Cox [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2000 9:05 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: First SACK-permitted on <SYN,ACK>
>
>
> > 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

---

From: Matt Mathis <[email-masked]>
Date: Wed, 9 Aug 2000 15:08:04 -0400 (EDT)

> know the other side doesn't support them and you stop sending them.

Yes, precisely!  This has been on my wish queue for years.....

Do we (you and I) have the cycles to push RFC1323bis?  Although this is a
relatively small code change, it is a fairly large document change because the
current text is structured around the idea of always disallowing new TCP
options on non-SYN packets.

Thoughts?
--MM--