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

From: John Heffner <[email-masked]>
Date: Wed, 14 Nov 2007 11:57:04 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: <[email-masked]>
Date: Fri, 16 Nov 2007 10:51:27 -0000

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, <[email-masked]> Networks Research Centre, BT
Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.
+44 1473 648734 

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

Toby,

   -John

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 16 Nov 2007 19:58:10 +0100 (MEZ)

At Fri, 16 Nov 2007 10:51:27 -0000 , <toby.moncaster at bt.com>  wrote:

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

That is exactly the scenario supported by the Space Communication
Transport Protocol (SCPS-TP) "BETS" extension to TCP, now shortly
discussed in Section 6.5.4 of draft-moncaster-tcpm-rcv-cheat-02:
The reciever does not need outdated data, and it announces this
(and supporting protocol behavior) by negotiating BETS via TCP
option #20; and thus, the sender is aware or the possibility of
receiving ACKs for data not arrived at the receiver, and can
suppress the test.

I suggest that particular applications interested in this "Real-Time
Streaming over TCP" should consider implementing enough parts of
SCPS-TP to support BETS to coordinate sender and receiver behavior
in a manner tailored to these specific requirements.
Partial implementation of SCPS-TP is facilitated by the fact that
most TCP extensions of SCPS-TP have to be negotiated per connection;
if you do not have implemented a feature, just don't negotiate it!

  Alfred.

---

From: John Heffner <[email-masked]>
Date: Mon, 19 Nov 2007 17:25:31 -0500

> arrive before acknowledging (rather than acknowledging before it

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

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

> 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