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

[Fernando Gont <[e-mail]>]

At 06:13 a.m. 02/12/2005, Gorry Fairhurst wrote:

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

No, neither me nor the draft ever proposed that. But, thinking out loud, it 
might me a good idea to be able to enable the UTO option on a system-wide 
basis. Of course, the toggle would default to "off".
Being aware of my intermitent connectivity, I could enable it on a system 
wide basis, to let all my connections survive the disconnections, even if 
the applications themselves do not enable the UTO option explicitly.



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

Well, I'm not sure why I wrote that sentence. I'd agree on that of the 
mechanism being "per direction".



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

A timeout is mechanism that may be used to provide a given type of service. 
But a timeout is does not provide a service by itself.
An application may be asking for a data-transfer with an error rate of less 
than X, a jitter less than Y, a throughtput higher than Z, a delay less 
than M, etc. But I cannot see a case in which an application may be 
interested in something like "If the underlying protocol cannot transfer my 
data in less than X seconds, abort the connection" as a *service* provided 
by the layer bellow.

There are many reasons for which that would simply not make sense. One of 
them is that even if the data themselves are transferred to the remote TCP, 
the remote *application* may have crashed. So you still need 
application-layer timeouts.

This sounds to me like when people use TCP keepalives just to avoid 
implementing an application-layer heartbeat. The two serve completely 
different purposes.



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

The application should care about application-layer timeouts, not about 
transport-layer timeouts.
Same case as above.



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

That's the results of [MEDINA], IIRC.



>>>/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" ;-)

I don't get your point. :-?

Kindest regards, and thanks for your feedback, again!

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






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