[tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt

[Lars Eggert <[e-mail]>]

Wesley,

Wesley Eddy wrote:
> Is there really a need to allow the first ACK to carry an ATO?  It
> should be enough to just allow them on the SYN and SYN-ACK.  If a host
> sends an ATO of X on a SYN and gets back an ATO of X-Y on the SYN-ACK, it
> probably won't want to go any shorter than X-Y, as that's already shorter
> than it requested.

thanks for the feedback. Allowing an ATO exchange using either the 
SYN/SYN-ACK segment pair or the SYN-ACK/ACK pair gives both the 
initiator and responder of a TCP connection (the client and server, if 
you will) the option of starting an ATO negotiation. Restricting it to 
the SYN/SYN-ACK means that only the initiator can request an ATO 
negotiation. This may be OK for most current uses of the option, but a 
more general solution can be useful.

A negotiation always involves two segments. So in the example you give, 
the initiator cannot currently continue the negotiation using the first 
ACK. It made its offer in the SYN and got the response in the SYN-ACK.

> If the SYN-ACK carries a value too-low, then it's just tough luck,
> because it's likely a web server (or similar) saying "I'm too busy to
> just keep your state around forever, but I am willing to hold onto it
> for exactly this long".

That's true, and I should point out in the draft that using the option 
to negotiate lower-than-default timouts is useful for exactly such cases.

> Removing the ability to send an ATO on the first ACK would rid the draft
> of some inconsistency (ie between figure 2 and the first paragraph of 2.1).

I see no inconsistency - but the wording may need some improvement. The 
idea is that an INITIATOR can only use a segment with the SYN flag for 
its ATO offer, i.e., the SYN and SYN-ACK. The RESPONDER will respond in 
the very next segment, which obviously cannot be the initial SYN but 
must be either the SYN-ACK or first ACK.

Does this clarify the intent?

Lars
-- 
Lars Eggert                                     NEC Network Laboratories