Re: [tcpm] draft-ietf-tcpm-tcp-uto-02

[Fernando Gont <[e-mail]>]

At 09:30 a.m. 12/11/2005, Gorry Fairhurst wrote:

>2) I don't yet see a compelling reason why this has to be negotiated at the
>TCP-layer.

We are altering a transport-protocol parameter.



>This needs to be made clear. The new method does not completely
>relieve the need for new code - Applications still need to add (some) code
>to use the new socket option.

You could set up the option with a system-wide toggle, for example.



>3) If I understand, the mechanism is also per-direction of data transfer -
>that is there is no *necessity* for both end hosts to agree on the same
>values - although there are cases where they may both wish to (e.g.)
>increase the default.

It's not actually "per direction". But the option is just an advisory. 
i.e., you need not use the same value the remote peer is advertising.
The draft contains a RECOMMENDED mechanism to choose the actual user 
timeout. The formula means, basically, "if both the local and remote UTO 
options are within the allowed higher and lower limits, choose the higher 
of the two",



>4) My biggest worry that the current mechanism allows a remote party to
>alter the behaviour of a sender, without the prior consent of the host
>application. This seems wrong. I suggest it is important to consider whether
>this is "sane" - it needs thought.

In principle, it's the transport protocol that should handle this issue. 
The application itself should not care about this network-specific parameter.

In any case, the option will not make things any worse. You have upper and 
lower limits for the user timeout. And it is assumed that, within those 
limits, things cannot go wrong. Under the recommended scheme, receiving an 
UTO won't cause connections to be aborted unnecessarily, as you will always 
choose the larger of the two UTOs. OTOH, the upper limit is supposed to 
prevent you from adopting a user timeout that is too large.



>On the other hand, if the application calls-down the socket API saying this
>is allowed, then this is fine, and I would have no problems on this point.

In the case there's no socket API call and no system-wide toggle set to 
"on", the upper limit could be set up so that it equals the current User 
Timeout, as specified in the existing RFCs. This will basically mean that 
even upon receipt of an UTO, you won't actually alter the user timeout for 
the connection. (under the RECOMMENDED scheme, at least)



>1) The wording describes sending the option in either/both the SYN v.
>established states. The protocol should be made clearer about this.

There had been some discussion on whether sending the option in the SYN 
segment should be required.
The consensus was, IIRC, to make it a SHOULD rather than a MUST.


>If an end-host SENDS the option in a SYN packet, is it expected in the
>SYN-ACK?

I'd say it SHOULD be included, as above.  Lars?



>- One thing that I think needs thought is that in the currently defined
>method the Option in a SYN indicates "I may tell you that I wish to use a
>different UTO" - In fact the exact opposite is much more useful tgo the
>remote party: A SYN packet that carries an option saying "MY UTO is XXXX,
>you may change it".

I will go back to the draft, but... the option in the SYN segment basically 
says "I suport UTO, my current user timeout is XXXX".



>2) A separate point, relating to options is that normal TCP behaviour
>REQUIRES an option to be present in the SYN to use it later. Is it REQUIRED
>to send this option in the SYN packet to be allowed to later use this once
>the session is established?

The WG consensus was, IIRC, not to make it a requirement.



>4) Too low a UTO can be VERY harmful to the network service. I believe it is
>very important to establish and define a sensible minimal value. All to many
>times applications developers write and test code in a LAN environment and
>only later deploy in the general Internet. We should not provide another
>opportunity for people to use TCP in cute ways that will break on arbitrary
>Internet paths!  I think the minimum UTO must be REQUIRED.

Requiring a minimum UTO means we should also make the recommended mechanism 
for choosing the UTO a "requirement", I think. (the recommended mechanism 
basically means "choose the larger of the two UTOs, and apply higher and 
lower limits to it).
I'd agree with this. Lars?



>5)  I really feel uneasy about the idea of responding to a UTO option with
>another UTO option. This seems bad protocol design, and should at least be
>damped by imposing a minimum time before the response can be sent.
>
>Why do this? - I change my end, I request you to change yours. Is that not
>it done?

Actually, IIRC this was included in the draft for further feedback, as had 
been raised on the mailing-list.

As for my own view on this issue, I agree with yours. If I change the user 
timeout, I'd send an UTO. Done.



>6) Are there situations in which you wish to allow the UTO to be reduced
>once the session has started.  Allowing reduction of the UTO below the
>actual PRTT (whatever that means in practice) provides a DOS vulnerability.

In principle, the UTO will reflect the length of the periods of 
disconnection. If these periods change (for good) during the life of a 
connection, then it would make sense to reduce them. However, of course you 
have raised a good point. But I'd assume that the lower limit for the UTO 
will address your case. As stated in the draft, the limits need not be 
fixed. So, at any point, the lower limit should be, at least, the actual PRTT.



>7) Are there any interoperability issues with NATs/Middleboxes when this is
>included on a SYN packet?

[MEDINA] has shown that there are not.



>/on a satellite/on a non-geostationary satellite/
>- All satellites orbit, but the vast majority used for telecoms take an
>orbit that is goeostationary.

IIRC, this had been a contribution of (NASA's) Wesley Eddy. "Satellite" 
need not be a communications satellite, but could also be planetary body 
(i.e., a node operating from the Moon experiences periods of disconnection)

P.S.: Skipped a few comments, but will come back to them.

BTW, Thanks so much for your detailed feedback!

Kindest regards,

--
Fernando Gont
e-mail: [e-mail] || [e-mail]





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