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

[Gorry Fairhurst <[e-mail]>]

The authors requested a review of the UTO mechanism.


First my comments on the case for the method:

1) One major problem with this document is that it is hard to see what it is
about, until you are well into the document. If I understand correctly, it
is about a TCP Option for a receiver to request a sender to alter the time
interval it will wait for a data segment to be acknowledged.

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

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.

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.

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.

--------

Now comments on the protocol:

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

If an end-host SENDS the option in a SYN packet, is it expected in the
SYN-ACK?
- 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".

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?

3) [anchor3]. This (the case for other timer changes) needs explained, if
the WG does need to define more than a UTO and this is also needed let's do
it in a consistent way (in this document, or decide not to). - I believe the
decision needs to be made!

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.

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?

I think that we can not afford for an incompatibility throwing packets
backwards and forwards for ever, if that means defining another TCP Option,
to inform of the change, then that needs to be thought about.

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.

Another thing to note here, if I understand, is that reducing the UTO may
immediately cause the session to close (if data was unacknowledged).

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

Best wishes,

Gorry Fairhurst

P.S.

One way to fix the Min UTO problem would be to set the units of measure as
minutes ....  ;-)


----

Some NiTs, 

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

/This document specifies.../
IMHO, this should come at the start, and would help clarify what the I-D is
about.

I do not see the necessity of the following refs:

[SCHUETZ-THESIS]
[SCHUETZ-CCR]
[DRIVE-THRU].

There check the use of SHOULD and MUST in capitals [RFC2119].





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