Subject: [tcpm] UTO: SHOULD send option in first segment after the SYN?

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Sep 2006 23:28:10 -0300

Folks,

Caitlin Bestler proposed that a host implementing the UTO SHOULD send 
an UTO on the first (data?) packet after the SYN.

This avoids requiring systems to keep UTO-related information for 
connections that have not yet been established.
And would likely make things work better in the presence of 
mechanisms such as SYN cookies.

We would like to hear what others think on this issue.

Thanks!

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 28 Sep 2006 21:45:49 +0100

Is it OK to set the option in a later segment, when the option was not 
first negotiated in a SYN?

Gorry

Fernando Gont wrote:

> And would likely make things work better in the presence of mechanisms 
> such as SYN cookies.
>

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 28 Sep 2006 14:10:11 -0700

Gorry Fairhurst wrote:
> Is it OK to set the option in a later segment, when the
> option was not first negotiated in a SYN?
> 

As I understand UTO, it is not a "negotiation":

>  Note that an exchange of TCP User Timeout Options between peers is
>  not a binding negotiation.  Transmission of a TCP User Timeout Option
>  is an advisory suggestion that the peer consider adapting its local
>  user timeout.

And more to the point:

>   A host that supports the TCP User Timeout Option SHOULD include one
>   in each packet that carries a SYN flag, but need not.  [MEDINA] has
>   shown that unknown options are correctly handled by the vast
majority
>   of modern TCP stacks.  It is thus not necessary to require
>   negotiation of the use of the TCP User Timeout Option during the
>   three-way handshake of a connection.  However, including a TCP User
>   Timeout Option in each segment that has the SYN flag set will result
>   in TCP being able to adopt a user timeout with knowledge of that
used
>   by the peer TCP, since the beginning of the data transfer phase.

The connection initiating SYN packet is not really a part of the data
transfer phase, and connection related timers are not necessarily
identical
from the state where only a SYN has been received to after the
connection
is fully established. SYN Cookies are just one implementation strategy
where the distinction between these states is extremely obvious.

Given that there is no need to pre-validate support for UTO, and that
the suggestion UTO value may be ignored on a SYN, I think placing the
initial UTO value on the first data carrying packet makes more sense.