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

[Gorry Fairhurst <[e-mail]>]

A few comments are in-line (but not to all points yet).

Gorry


Fernando Gont wrote:

> 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.
> 
A proposal to make this the default behaviour for all applications on an 
end-host makes me feel uneasy.

> 
>> 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". 
Are you saying that it must be configured for BOTH directions then? - 
This is not my understanding.

> 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.
> 
I don't agree. The application uses a transport service, this proposed 
change modifies that service.

> In any case, the option will not make things any worse. 
Do you mean there are no cases where application semantics can change as 
a result of using this option. That's a bold statement (i.e. big is 
always best?).

> 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.
> 
I am happy with this, if The WG believes that "normal" TCP stacks can 
handle this, without introducing problems, then I have nmo objection.
> 
> 
>> 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)
- Yes and is also a rather bizarre illustration of the point, 
considering the Path RTT >> "normal Internet MSL" ;-)

> 
> 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