Subject: [tcpm] TFO fastopen-02

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 03 Nov 2012 17:33:44 -0400

4.1.3 requires servers to cache cookies, but does not mandate anything 
about negative responses. 4.2.1 contains a "RECOMMEND", similar 
statements are made in various places in non-standards language.

It seems to me that the robustness of the method actually relies on a 
history cache of unsuccessful attempts to deal with paths/servers that 
do not support the new mechanism. Therefore the caching functions seem 
under-specified. I have concerns that this could result in additional 
useless retransmission of SYNs - noting that other protocol entities may 
also be responding to/interpretting  retransmissions (e.g. ECN, ICE, or 
IPv4 fall-back from IPv6), I think we should seek to avoid such 
persistent SYN retransmission.

I therefore think we require failures to be cached by a client and we 
should also specify a minimum time that an endpoint should cache an 
unsuccessful TFO exchange - hosts that can not maintain this cache (e.g. 
due to memory constraints) could entirely suspend new (uncached) use of 
TFO for the interface for the period. To me, this would be much more 
robust to problems with hosts that find themselves on paths that do not 
support TFO (including middleboxes that do not have this support).

I wonder if using the PMTU cache also implies that the first SYN may 
fail when there is a path change?

I did not see a discussion of the RTT cache - what are the unwanted 
implications of caching this value? It seems the path characteristic 
that is most likely to change with time. Presumably one implication is 
that clients behind a varying RTT paths may find themselves unable to 
use TFO (because of spurious SYN+TFO timeout).

I also agree with Michael Scharf that allowing the server to send 
initial window segments in response to Fastopen, does have congestion 
implications, perhaps these are small with typical up/downlinks but I do 
not yet see this as inconsequential in other cases (and TCP is a general 
purpose protocol). This would seem not to be an issue if the server sent 
1 or 2 segments... but that's not what the draft allows (e.g. IW=10). At 
first sight this seems an unreasonable increase in aggressiveness, and 
would I suggest require some normative text.

Gorry

----

PS, possible NiT?: The first MUST in 4,2,2, does not appear to be a 
protocol requirement.

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 6 Nov 2012 00:03:43 -0500

First of all. Thanks for reviewing the draft!

On Sat, Nov 3, 2012 at 5:33 PM, Gorry Fairhurst <[email-masked]> wrote:
> 4.1.3 requires servers to cache cookies, but does not mandate anything about
> negative responses. 4.2.1 contains a "RECOMMEND", similar statements are
> made in various places in non-standards language.
We will update these wordings. Thanks for catching that.

> history cache of unsuccessful attempts to deal with paths/servers that do
> not support the new mechanism. Therefore the caching functions seem
> also be responding to/interpretting  retransmissions (e.g. ECN, ICE, or IPv4
> fall-back from IPv6), I think we should seek to avoid such persistent SYN
> retransmission.
Let's define robustness first: it's robust as long as the client can
finish connect operation. TFO client always retries a regular SYN. If
that is not working then even regular TCP is failing.

We do advise using negative caching in the end of 4.1.3. The reason we
don't specify details are
1) the details of negative caching is not critical, as long as the
client or server retransmits regular SYN which we do specify.
2) it's about working around broken middle-boxes. It should not be
part of a TCP protocol.

But I am happy to talk our implementation in Linux tomorrow :)

>
> I therefore think we require failures to be cached by a client and we should
> also specify a minimum time that an endpoint should cache an unsuccessful
> TFO exchange - hosts that can not maintain this cache (e.g. due to memory
> constraints) could entirely suspend new (uncached) use of TFO for the
> interface for the period. To me, this would be much more robust to problems
> with hosts that find themselves on paths that do not support TFO (including
> middleboxes that do not have this support).
>
> I wonder if using the PMTU cache also implies that the first SYN may fail
> when there is a path change?
path can change any time and fail any packet. PMTU (or rather MSS)
caching does not imply that. It's certainly possible getting an ICMP
message too big on SYN-data. In this case, the TCP should just cache
the new MSS indicated in the ICMP. The draft isn't clear but our
implementation does do that. I'll update the draft about this. Thanks.

> implications of caching this value? It seems the path characteristic that is
> most likely to change with time. Presumably one implication is that clients
> behind a varying RTT paths may find themselves unable to use TFO (because of
> spurious SYN+TFO timeout).
The reason about RTT cache is to speed up the SYN retransmission in
case of the middle-box issue above. Cached RTT can be wrong, with or
without having payload in SYN, and causes spurious SYN retransmission.
The data in SYN is still delivered, but we send an extra SYN.

>
> I also agree with Michael Scharf that allowing the server to send initial
> window segments in response to Fastopen, does have congestion implications,
> perhaps these are small with typical up/downlinks but I do not yet see this
> as inconsequential in other cases (and TCP is a general purpose protocol).
> This would seem not to be an issue if the server sent 1 or 2 segments... but
> that's not what the draft allows (e.g. IW=10). At first sight this seems an
> unreasonable increase in aggressiveness, and would I suggest require some
> normative text.
We will add text about this case.

I'd like to remind that TFO is about SYN-data plus some basic defense
for simple attacks.
data in SYN is in RFC793. The congestion control should have
incorporated that. If middleboxes don't operate we may send some extra
SYNs, but the sky is not falling. The browsers you are using are
"speculatively" opening (idle) connections before they know what
requests to send. These connections are thrown away if the resources
are locally cached. The amount of unneeded SYNs are hundreds if not
thousands orders of magnitude larger. This is all because apps working
around handshake latency.

>
> Gorry
>
> ----
>
>
> PS, possible NiT?: The first MUST in 4,2,2, does not appear to be a protocol
> requirement.
agreed. will update.

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