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

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Apr 2004 17:41:56 +0200

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

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 21 Apr 2004 11:12:01 -0400

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".  No matter how politely you ask in an ATO on a
ACK you send back, I don't think it'll be convinced to oblige you with
the longer ATO (and you'll have no way of knowing since it's not allowed
to send any more ATO options back at that point).

-Wes

---

From: Joseph Ishac <[email-masked]>
Date: Wed, 21 Apr 2004 13:35:09 -0400

From my understanding:

Page 3, Last Paragraph should read:

Either/Or
  and not
Both/And (or the "as well as" used in the text)

Reason being that both the initiator and responder cannot initiate a
negotiation of an ATO.  As the initiator, the ATO if any, must be in the
SYN.   As a result the SYN/ACK will carry the reply to that ATO if any.
The responder cannot 'initiate an ATO' if the initiator has already done
so.  However the responder can 'initiate an ATO' if the initiator simply
sends a SYN without an ATO request.

That's my take on the proposal... using the terminology in the draft.
Confusion probably arises from the use of 'initiator' and 'responder' in
the text.

Also, I don't remember if I read it specifically, or if I just implied
it... If an ATO is negotiated, I'm assuming both sides use that value.

Finally, is it worth specifying what action should be taken if the ATO
response is *larger* than the original request.  Is the ATO rejected or
accepted at the initial value?

-Joseph

> Does this clarify the intent?

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

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 21 Apr 2004 11:53:57 -0400

> ACK. It made its offer in the SYN and got the response in the SYN-ACK.

Ah, that makes more sense.

> Does this clarify the intent?

Yes quite a bit.  Although I see the lack of sending an ATO option on the
initial SYN as indicating either "I don't care" or "I don't grok the ATO
option", and so in both cases, it won't really matter what the ATO in the
SYN-ACK is, because the other side will either be cool with it or not
understand it.

Keeping with the spirit of other TCP options, it might be best to put the
ATO option in the SYN if you understand it, and not put it at all in the
SYN-ACK if it wasn't in the SYN, on the goal of not breaking fragile stacks
with options they can't parse.  That would also remove the need to worry
about the option coming in on non-SYN options.  It's typical to use different
option parsing routines for syn-set and syn-unset segments (sort of slow and
fast paths through the option parsing), and so disallowing an ATO option on
the first ACK also simplifies implementation.

-Wes

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Apr 2004 12:03:06 +0200

Joseph,

> Both/And (or the "as well as" used in the text)

you're correct, this clarifies the intent - change made.

> sends a SYN without an ATO request.

Exactly right.

> Confusion probably arises from the use of 'initiator' and 'responder' in

I delibertated wether to use client/server or initiator/responder during 
the description. The latter seemed more accurate, but the former may be 
more easily understood. Maybe a short paragraph defining the two terms 
would help?

> it... If an ATO is negotiated, I'm assuming both sides use that value.

This is mentioned in two places, for both the initiator and responder, 
but stating it explicitly upfront can't hurt.

> accepted at the initial value?

Following the "be liberal in what you accept" guideline I guess the 
regular default timeout should be used instead of rejecting and 
resetting the connection.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Apr 2004 16:43:55 +0200

Wesley,

> the first ACK also simplifies implementation.

I agree that's a valid concern, and a possible approach. The ATO in the 
SYN could even contain a magic/invalid value to signal to the peer that 
ATOs are understood but no specific ATO is requested.

However, if the ATO exchange is limited to the SYN/SYN-ACK exchange, 
only clients ever get a chance to start an ATO negotiation. That limits 
the generality and maybe usefulness of the option.

Many other TCP options are somewhat different in this respect, because 
they just use the handshake to establish whether or not an extension is 
supported and that knowledge then influences later protocol behavior.

Lars

---

From: Joseph Ishac <[email-masked]>
Date: Fri, 23 Apr 2004 19:13:29 -0400

> more easily understood. Maybe a short paragraph defining the two terms 

An added explanation in the text may be beneficial.  In particular, I
think it's confusing because (like you mention) no other options are
like this (well... that I know of).  

Also, I'm with Wes' note earlier on trying to consolidate this all into
the SYN and SYN/ACK.

If the 'initiator of the connection' or client can support ATO then it
should advertise it on the SYN.  It should just set the value to what it
would tolerate had it been responding to a request.  If they don't care,
they could just set it to the default value they would be using anyways.

I don't think a magic value would be needed.  What may be need instead
is a flag that exists within the option to distinguish it between a
request and an offer.

The way I understand it, both A and B can have at most two values in
mind for the ATO.
X) Value that I'd like to request given the chance (set by maybe a sock
opt or some other knowledge... and dependent on resources)
Y) Max value that I can apply too an incoming request (based on
resources, number of connections, and heuristics)

Those 2 values being independent of any other nodes' 2 values and known
before the next connection is even made or received.

Example:

A (X1,Y1) --> B (X2,Y2)

SYN
SYN/ACK + X2
ACK + ???

Case 1) Say ??? is silent: this could have been accomplished by the "B"
simply inferring that ATO wasn't supported on "A"s empty SYN

Case 2) Say ??? is less than X2: meaning "A" is expressing it's max (Y1).
Had "A" expressed it's max in the SYN the result would be the same.

Case 3) Say ??? matches X2: meaning that you were below "A"s
max.  The same result would have occurred had "A" started with its
max in the SYN, as "B" would knock it down to X2.

The only problem with case 3 is that "B" needs to know that the value in
the SYN is not a request.  Hence, the thought of using a flag to
distinguish the two.

> resetting the connection.

Right, falling back on the defaults seems fine.

-Joseph

---

From: Mark Allman <[email-masked]>
Date: Sun, 25 Apr 2004 10:50:05 -0400

> Also, I'm with Wes' note earlier on trying to consolidate this all
> into the SYN and SYN/ACK.

I just read the draft and my concern with this business of carrying the
ATO on the ACK has less to do with consistency or beauty, but rather
with the ACK of the SYN+ACK being unreliable.  It is pretty easy to
construct a case whereby the two endpoints will be out of sync because
the ACK is lost.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Apr 2004 10:32:20 +0200

> construct a case whereby the two endpoints will be out of sync because

Joseph has also send a very detailed note about this. I'll take a stab 
at rewriting things for the -01 revision accordingly when I have a few 
cycles.

Thanks,
Lars