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

[<[e-mail]>]

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

* 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>)

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. 

Hope this answers your questions?

Toby

________________________________________________________________________
____
Toby Moncaster, <[e-mail]> Networks Research Centre, BT
Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.
[phone] 

-----Original Message-----
From: John Heffner [mailto:[e-mail]] 
Sent: 14 November 2007 16:57
To: Moncaster,T,Toby,CXR9 R; tcpm
Subject: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test

Toby,

I'm not sure I completely understand some of the claims in Section
6.2.2, particularly: "That is to say, a receiver can either honestly
report the missing packets or it can suffer a reduced throughput by
delaying segments and increasing the RTT," and "Equally, a receiver that
delays transmission of the duplicate acknowledgements until it is sure
it is being tested will leave an obvious pattern of acknowledgements
that the sender can identify."

If I were designing a receiver to try to defeat this test, I would delay
response by six segments, or a short timeout, whichever is less.  If I
observe reordered segments, I would send the ACK/SACK that the sender
would expect.  Additionally, I would ACK any lost segments, and any
received segments as normal, only delayed by the time to receive the
following six segments.

You seem to have thought about this strategy, but I'm not sure I see how
the claims in section 6.2.2 apply.  I don't think this strategy will
increase the RTT so much that it will cause significant performance
reduction.  And I'm not sure how delaying the ACKs will leave an obvious
pattern that the sender can identify.  Am I missing something?

   -John


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