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

From: Fernando Gont <[email-masked]>
Date: Thu, 01 Dec 2005 04:52:13 -0800

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: [email-masked] || [email-masked]

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 02 Dec 2005 14:13:48 +0000

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

Gorry

>> relieve the need for new code - Applications still need to add (some) 
>> code to use the new socket option.
> 
A proposal to make this the default behaviour for all applications on an 
end-host makes me feel uneasy.

> 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. 
> options are within the allowed higher and lower limits, choose the 
> higher of the two",
> 
> 
> 
>> application. This seems wrong. I suggest it is important to consider 
>> whether this is "sane" - it needs thought.
> 
> 
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.
> 
> 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)
> 
> 
> 
> 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".
> 
> 
> 
I am happy with this, if The WG believes that "normal" TCP stacks can 
handle this, without introducing problems, then I have nmo objection.
> 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).
> 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.
> 
> 
> 
> 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.
> 
> 
> 
- Yes and is also a rather bizarre illustration of the point, 
considering the Path RTT >> "normal Internet MSL" ;-)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 02 Dec 2005 20:37:16 -0800

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

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

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

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

>handle this, without introducing problems, then I have nmo objection.

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

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

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 5 Dec 2005 09:53:33 -0500

> I don't get your point. :-?

I don't either.  If the "normal Internet MSL" is 2 minutes, then the
propagation-based RTT between the Earth and Moon of roughly 5.5 seconds
is well within an MSL.

I actually think that changing the text to say "geostationary" would be
an odd example, since from the ground it's rather difficult to go out of
touch with one of these in comparison to other orbits.  The case of a
polar orbit (for instance) where you can predict the amount of time when
the satellite is below the horizon and the time when it'll come back up
is a better example.  In this case, you can use a combination of UTO (to
keep the connection alive) and retransmit-now (to kick the connection),
to gain a little bit of efficiency, and simplify the application by
letting it use TCP in comparison to CFDP or others.

-Wes
 
-- 
Wesley M. Eddy
Verizon Federal Network Systems
http://roland.grc.nasa.gov/~weddy
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 05 Dec 2005 15:12:48 +0000

> letting it use TCP in comparison to CFDP or others.

OK, so the original text was:

    For example, an orbiting node on a satellite might
    experience disconnections due to line-of-sight blocking by other
    planetary bodies.  The disconnection periods of such a node may be
    easily computable from orbital mechanics.

And my original point, was perhaps not clear, but we now seem to have 
come full circle, and so let me try again:

If you think this is a good example of why UTO is useful (and I am not 
sure it really is such a good example), then I would have much prefered 
the I-D to have said something like "non-geostationary satellite" - to 
differentiate it from the more common form of satellite used to provide 
Internet services.

Gorry

---

From: Ted Faber <[email-masked]>
Date: Thu, 8 Dec 2005 14:28:08 -0800

> transport-layer timeouts.

TCP provides an interface that the application can use to set this
timeout in RFC793.  Breaking applications that made use of it should not
be done lightly, even if there are alternative mechanisms that those
applications could have used.

IMHO, with my chair hat off.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Thu, 08 Dec 2005 16:51:13 -0800

>applications could have used.

Agreed.

But we agreed that the application-specified UTO would take precedence. And 
that, in the event a system-wide toggle existed, it would default to off.

So if you were using UTO, either the application programmer or the system 
administrator decided to do so.

(From a theoretical point of view, I'd probably argue that an application 
that really *breaks* because the user timeout ends up being longer than 2 
minutes or whatever, then it's already broken. And, even then, we have 
higher and lower limits for the UTO, which one would hope will keep the UTO 
"within acceptable values". But well, as I pointed out above, this would 
not even be the case.)

Kindest regards,

---

From: Ted Faber <[email-masked]>
Date: Fri, 9 Dec 2005 10:25:31 -0800

> administrator decided to do so.

I think you mean that if you're using UTO negotiation it's because of an
active decision, which is IMHO, correct.

> "within acceptable values". But well, as I pointed out above, this would 

If you're arguing that implementation of the user timeout is more likely
to be flaky than more core features of the protocol, I agree.  Relying
on the urgent pointer has similar practical issues.  So does relying on
the UNIX sleep or usleep timers.

The mechanism described in 793 and 1122 is a perfectly reasonable
definition of a timeout system that an application could use to take
action if data's not delivered in a timely fashion.  In a system where
those mechanisms are implemented to spec, I don't see why using them
would break an application.  And that seems to be what you're saying.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 12 Dec 2005 12:58:40 +0000

Ted Faber wrote:
>>>>>Do you mean there are no cases where application semantics can change 
>>>
>>>as a
>>>

> would break an application.  And that seems to be what you're saying.

I agree - my concern was application of a SMALLER value (from the remote 
end) than currently defined by standard mechanism - and the impact this 
could have on an unsuspecting application.

Gorry

---

From: Ted Faber <[email-masked]>
Date: Mon, 12 Dec 2005 15:56:03 -0800

> could have on an unsuspecting application.

Hmmmmm.

On the one hand, I'd say that if an application cares, it should set the
value explicitly.  On the other hand, an application that didn't set a
value for UTO becasue any reasonable value was fine would probably be
unhappy if a 5ms UTO had been negotiated for it. :-)

If I recall correctly, they do have a min/max kind of set up that
encourages systems not to push their defaults down.  I can see a good
argument that UTO negotiation should *never* reduce the default min UTO
of a system to avoid violating POLA.  Is this restriction what you're
arguing for, Gorry?  (If so, Lars/Fernando, do you have
objections/counter-arguments?)

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Dec 2005 01:24:32 -0800

>active decision, which is IMHO, correct.

Exactly.It never "kicks in by default".

>action if data's not delivered in a timely fashion.

The point is that if you;re really concerned about data being delivered, 
you should be implementing an application layer timeout mechanism.
If there's no TCP timeout, it does not mean that the data were delivered.

>In a system where
>would break an application.

Say I really need to know that the remote app got these data I have just 
sent. So I rely on TCP's timeout. Now the remote app crashed, but the 
remote app didn't. The application design is broken. I'd be assuming taht 
the remote app got the data, when it didn't.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Dec 2005 01:27:48 -0800

>could have on an unsuspecting application.

I understand. And for that reason it's that the lower limit for the UTO 
should be set correctly.

Of the top of my head, I realize that maybe the current draft does not 
mention which value should be the minimum we should use for the lower 
limit, though.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Dec 2005 01:34:32 -0800

>objections/counter-arguments?)

Of the top of my head, I don't recall we proposed any value for the lower 
limit.

Anyway, that's what we had in mind when including the equation for choosing 
the UTO: "As long as it is within acceptable limits, choose the larger of 
the two".

The idea is that if you don't set the UTO explicitly, then your local UTO 
should be set to the default UTO (which may even be larger than the minimum 
allowed UTO, i.e., the lower limit). This means that, your user timeout 
will be, at least, the default. And, at most, that of the upper limit.

If you do set the UTO explicitly (i.e., you know what you're doing), then 
the user timeout will be, at least, that of the lower limit, and, at most, 
that of the upper limit.

(I realize that this is probably not explained in the draft, though).

Does it make sense?

Kindest regards,

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 14 Dec 2005 14:17:28 +0000

So, a summary of my take and responding to some of this (which I hope we 
now have right). I'd be happy with new text saying something along the 
lines of:

* MIN RTO is system-defined (with a warning that small requires 
caution;-) ).
* The RECOMMENDED value for MIN RTO is follow RFCxxx.

* UTO negotiation SHOULD be OFF by default.
* UTO negotiation MAY be via a system config.
* RECOMMEND negotiation is enabled via an API call from the application.
* Upper and lower bounds may be set, but MUST NOT go below system MIN RTO
* MUST use MIN RTO, if UTO negotiation is not enabled.

?

Gorry

Fernando Gont wrote:

> Of the top of my head, I don't recall we proposed any value for the 
> lower limit.
> 
> Anyway, that's what we had in mind when including the equation for 
> choosing the UTO: "As long as it is within acceptable limits, choose the 
> larger of the two".
> 
> The idea is that if you don't set the UTO explicitly, then your local 
> UTO should be set to the default UTO (which may even be larger than the 
> minimum allowed UTO, i.e., the lower limit). This means that, your user 
> timeout will be, at least, the default. And, at most, that of the upper 
> limit.
> 
> If you do set the UTO explicitly (i.e., you know what you're doing), 
> then the user timeout will be, at least, that of the lower limit, and, 
> at most, that of the upper limit.
>

---

From: Ted Faber <[email-masked]>
Date: Wed, 14 Dec 2005 09:20:43 -0800

> * MUST use MIN RTO, if UTO negotiation is not enabled.

That's a nice, succinct description of constraints on UTO.  They sound
reasonable to me, and I'd love to hear from others.

---

From: Ted Faber <[email-masked]>
Date: Wed, 14 Dec 2005 09:19:52 -0800

> If there's no TCP timeout, it does not mean that the data were delivered.

I understand the difference between a transport ack and acknowledgements
from higher layers.  Some applications (correctly!) use transport state
to synchronize application state.

Consider a file transfer appliaction that opens a TCP connection for
each file.  The connection is closed when the file is saved to disk.  A
transmitter knows the file has been delivered correctly if and only if
the receiver closes its connection correctly.  The receiver knows the
whole file has been transmitted when the sender closes its side of the
connection (a receiver never closes its connection before a sender
does).  Voila, application synchronization using TCP signalling. 

Such an application may well want to use TCP's existing UTO mechanism as
a timeout.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 14 Dec 2005 20:30:24 +0100

> reasonable to me, and I'd love to hear from others.

I think all of this is reasonable to put in. Some of the things we  
already say or try to say, but maybe the language isn't clear enough.

(Sorry for not responding earlier to this threat, I'm swamped with  
year-end project stuff.)

Lars
--
Lars Eggert                                     NEC Network Laboratories

---

From: Fernando Gont <[email-masked]>
Date: Fri, 16 Dec 2005 10:32:00 -0800

>to synchronize application state.

Well, I'm not sure to what extent this is "correct".

For example, if BGP connections were "decoupled" from the underlying TCP 
connection, then we'd not care about reset attacks against TCP, for 
example. (Or, well, at least we'd not be so "scared")

>does).  Voila, application synchronization using TCP signalling.

This assumes that the underlying transport protocol allows each direction 
of the connection to be closed independently of the other.
I'd not put such a requirement on the underlying transport protocol if I 
were to design an application layer protocol.

>Such an application may well want to use TCP's existing UTO mechanism as

The timeout may help in some scenarios, but still does not solve the usual 
requirement of the application layer.

If the point of using the TCP timeout is just to avoid waiting forever, 
okay. But, in the more general case of an application wanting to know what 
the result of the last command sent was, you will still need the 
application-layer thing.

Kindest regards,

---

From: Ted Faber <[email-masked]>
Date: Fri, 16 Dec 2005 13:26:19 -0800

> Well, I'm not sure to what extent this is "correct".

Correct is hard to dispute.  If TCP behaves properly and the application
behaves as I specified, both ends know if the transfer succeeds or
fails; that's correct.

I think you mean that you find it distasteful. :-)  I can't argue with
that.

> example. (Or, well, at least we'd not be so "scared")

I understand that you can incorrectly use code an application using TCP.
That doesn't mean you can't code an application that uses it correctly.

> of the connection to be closed independently of the other.

That's why I identified the transport as TCP, which has this property.
The inclusion of that property is intentional.  Depending on
non-existant properties is certainly a bad design. :-)

> were to design an application layer protocol.

There are good reasons for an engineer not to design an app the way I
suggested.  I don't think it's particularly clean myself, but I do think
it's correct and I do think it's done.  And it has the benefit of not
having to redesign TCP's state synchronization machinery at the
application.

> the result of the last command sent was, you will still need the 

Again, I'm not arguing that all applications must be designed the way I
layed out.  There are certainly applications that can't be.  You said
that the app must be broken w/o additional application layer processing,
which I took to mean that breaking applications w/o that processing by
changing UTO semantics was acceptable to you.  I presented a single
instance of an application that used TCP signalling to signal
application level state as a counter example.  I just want those sorts
of applications taken into account when we discuss UTO changes.  That's
my whole point.