Subject: [tcpm] Toby Moncaster I-D: draft-moncaster-tcpm-rcv-cheat-00 (a late comment)

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Mar 2007 11:30:53 +0100

I meant to send this much earlier, but it kind-of got stuck in my 
laptop, and delayed (sorry folks for it being out of order - and that 
may be it overlaps with some of what has now been said).

Gorry

----

draft-moncaster-tcpm-rcv-cheat-00

Dear Toby,

I enjoyed reading this draft, thanks for taking the effort to do this.

One of the attractive sides to this approach is that it can interact 
with TCP stacks to determine whether they are behaving in ways one could 
judge as acceptable.

I'm not sure I quite hold with the statement in the abstract that this 
"does not modify the TCP protocol" - that may be true of the 
state-machine, but it could arguably be said to change the wire-line 
protocol. This has some side effects:

1) It makes debugging TCP harder
2) It will create oddities in decoding traces
3) It changes the properties of tcp (to some extent - e.g. some eduction 
of the robustness to re-ordering).
4) It creates dependencies on sets of features that would need to be
implemented in future TCP.
5) It also talks about sender-side changes that may be needed to enhance
security.

I am yet to be convinced that oppotunistic ACKs are "beneficial", except 
  when you ahve a TCP-performance-enhancing-proxy, that buffers data, 
and they do a whole lot more than this (up to a split-tcp:-) ).

One thing that strikes me is that the protocol uses a side-effect of TCP 
- i.e. DupAck Threshold. This value has remained fixed for a long time,
although it could change, and we have debated this in the past - there 
was previous work on this topic (making the DupAck threshold vary under
re-ordering). Be aware also of the rules for sending ACKs - which allow 
one ACK per segment, one each two full-sized MSS's worth of data, and 
things in-between, and that such rules have already been "stretched" in 
end hosts and network middleboxes as per RFC3449, (although these 
shouldn't impact DupACKs)

Requirements

Section 4, requirement 3. Not sure this is a requirement? - of course 
the receiver must NOT be able to easily cheat.

Reordering

The idea of using re-ordering capability to detect non-conformance 
suggests the scheme makes a receiver less robust to reordering (as the 
draft says). This concerns me - I suggest ordering is bimodal - 
sometimes you get a lot, sometimes you get little.

ECN-N

6.2.2 & 5.2 - You have noted the difference between ECN-N and this 
behaviour during congestion, however I thought that there was also a 
difference for the initial part of a flow / short-lived flows. It was my 
understanding that ECN-N was active during normal feedback - and 
therefore was a continuous monitoring of the state of the receiver / 
forward router path - whereas, my understanding was that the test 
decsribed was a discrete test for established flows, and was run at 
specific times. Is this so?

6.2.3 TCP Timestamp during testing

Does this really invalidate the TS option?

----

So... My opinions (thoughts)

1) My current thoughts are that this seems to present a potential 
stand-alone tool for detecting "correct" behaviour of a receiver. This 
could be helpful in working out whether a (remote) client implementation 
is doing the correct thing. I like such tools, and think they are good 
to develop, and we may wish to examine how safe they are (is it OK to 
expect this behaviour, etc) and what their characteristics are (what 
they measure, what they can not measure) in an IETF context?

2) The issue raised seems to apply to various protocols (not all 
transport protocols). This method is dependent on the transport, 
compared to ECN-Nonce that offers a method that is independent.

3) However, I **DO** doubt this should be a "feature" of a compliant TCP 
User Stack.  If we need this feature, is this the correct thing to do? 
TCP behaviour has changed many times, and IMHO it would seem right to 
allow this continued evolution. "Finger-printing" TCP behaviour to 
provide evidence of cheating seems to me to provide strong features that 
allow working with existing stacks, but could lead to stagnation of the 
protocol spec, and extra cycles in a receiver (a big deal, where this 
matters). On the other hand, adding a new feature  provides limited 
(no?) backwards support for existing stacks, but has good benefits when 
it comes to evolution of the spec. That's a trade-off, I'd advocate that 
we allow TCP to continue to evolve!

Best wishes,

Gorry

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