[tcpm] Re: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test

[John Heffner <[e-mail]>]

[e-mail] wrote:
>  
> Hi John,
> 
> When we originally wrote the test we did think that the increase in RTT
> estimate might act as a strong enough disincentive to those receivers
> that were actively seeking to misbehave. However we realised this
> probably wasn't the case, especially given the relatively coarse
> granularity of most TCP timers. We obviously need to update the draft to
> reflect this. Our current view is that the main protection afforded by
> this test is as follows:
> 
> * Those receivers seeking to use optimistic acknowledgement are forced
> to not use it as they may unwittingly optimistically acknowledge a
> segment that was delayed. In turn they can't try and defeat the test in
> the manner you suggest as this relies on them waiting for the data to
> arrive before acknowledging (rather than acknowledging before it
> arrives).

Right.  This works for detecting receivers doing optimistic acking.  I'm 
concerned here only with receivers acking sequence numbers <= than the 
highest received.


> * Those receivers that are seeking to conceal congestion losses must
> have decided they don't need the missing data. This suggests either they
> are streaming media off the sender or they are collaborating with the
> sender. In the first instance I am not convinced it would be appropriate
> for the sender to be performing the test as that may disrupt the
> streaming (though more thought is needed here). In the second case the
> sender and receiver are cooperating and so the sender would be unlikely
> to want to challenge the conformance of the receiver. (Aside: There is a
> subsidiary possibility which is that the receiver may be able to get the
> missing data from some other source such as a parity file set on a
> different server. This test can't overcome that possibility. The only
> feasible defence then is to use cumulative nonces as described by Savage
> et al in "TCP Congestion Control with a Misbehaving Receiver"
> <http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf>)

I think this is a pretty good explanation of why the opt-acking has not 
been a major practical problem. :)


> Further to this the test also allows for occasional delays larger than
> 6. If a receiver is actively seeking to defeat the test as above then it
> will never be able to tell when a test is happening or when it is
> natural re-ordering. In this case the receiver will get trapped into
> sending a stream of duplicate acknowledgements to defeat the test when
> in fact there was a genuine reordered segment. Thus it is not the actual
> test that catches the receiver out but the natural behaviour that
> underlies the test. The very existence of the test means a misbehaving
> receiver is forced to assume any reordering is in fact a result of the
> test (in order to defeat the test) and thus it is forced to respond to
> all reordering as if it were a test thus making it compliant. 

I'm not sure I follow this.  Assuming the sender ignores the SHOULD in 
the draft and delays more than 6, the misbehaving receiver can adjust 
its strategy accordingly.  The worst case bound is doubling RTT at the 
receiver.  For anything but an interactive flow, this is not likely a 
strong disincentive.

I do not believe a receiver behaving in the manner I described -- 
delaying acknowledgements by some fixed amount (up to 1 RTT), sending 
appropriate dup-acks for reordered segments but acking lost segments as 
if they arrived -- is compliant, even though it responds to all 
reordering as if it were a test.  Does this make sense, or am I missing 
something?


An additional comment about the probabilistic test:
It assumes that a compliant receiver sends dup-acks on every 
out-of-order segment.  This behavior is unspecified in RFC793, a MAY in 
RFC1122, and changed to a SHOULD in RFC2581.  Labeling receivers that 
don't obey the SHOULD in RFC2581 as "misbehaving" seems severe, and if 
such a test were widely deployed, is likely to lead to further 
ossification of TCP.  I can imagine some scenarios where it may be 
useful to delay acknowledgement of out-of-order segments, particularly 
if you see persistent reordering.

   -John


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