RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

Hi Rob,

The rationale behind our mechanism is that the latency in receiving the
skipped segment matters far less than any latency caused in the
potential signalling of a congestion event occurring during the honesty
test. This aspect is never significant with TCP SACK because there can
be enough information in a single acknowledgment to signal both that a
segment is missing, and that a later segment has experienced congestion.

The mechanism you have presented in [Sherwood05] defers sending the
skipped segment until TCP-SACK or a dup ack signals it is missing ,
which will take about one RTT. It will take another RTT for the skipped
segment to be duly acknowledged.

If SACK is not used, the problem is that the receiver cannot signal any
congestion event for about one RTT, from the time when it detects the
skipped segment is missing until the time it receives it. TCP can only
advance the acknowledgement number when it receives in-order data
(strictly data which advances the receive window). In other words your
test will generate a stream of dup acks all for the segment before the
skipped segment until such time as the skipped segment is actually
received.  

The advantage of the mechanism in [draft-moncaster-tcpm-rcv-cheat-00] is
that it reduces the time it takes for the source to send the skipped
segment to a (random) fraction of the congestion window, which on
average will be less than half an RTT.

Forcing a receiver to send a single duplicate ack does partially show
their honesty in that it makes it hard for them to send optimistic acks.
However it still allows them to conceal actual segment losses as they
will generally not suffer any penalty (fast retransmit) until they have
sent three duplicate acknowledgements.

Toby

-----Original Message-----
From: Rob Sherwood [mailto:capveg@cs.umd.edu] 
Sent: 21 February 2007 22:30
To: Moncaster,T,Toby,CXR9 R
Cc: capveg@cs.umd.edu; tcpm@ietf.org
Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

On Wed, Feb 21, 2007 at 03:46:10PM -0000, toby.moncaster@bt.com wrote:
> Hi Rob,
> 
> We were under the impression that you were keen that the skipped 
> segments solution be implemented with SACK enabled as otherwise there 
> is a risk that it could delay the notification of congestion by up to 
> 1 RTT more. Apologies if we have got this wrong.

I'm not sure that I see that risk.  I think both this point and the
point below rely on the same aspect of TCP: when an out of order segment
arrives, the receiver immediately sends a duplicate ACK for the
previously acknowledged segment.  Thus, as long as the receiver sends a
single duplicate ack for the skipped segment, then the sender know it is
honest.  Because there is no delay in the dup ack generation, the
penalty for receiving the skipped segment is at most 1 RTT.

> "Any TCP sender SHOULD check the honesty of its receivers using the 
> probabilistic test periodically and randomly. In particular, it would 
> be advantageous for any sender that is heavily loaded to identify if 
> it is taken advantage of by an attack by a dishonest receiver".

This wording is definitely clearer.

> Final point, as Gavin McCullagh has already pointed out, apart from 
> legacy Tahoe TCP implementations a receiver can be reasonably safe if 
> it sends less than 3 duplicate ACKs for a missing segment as this will

> not trigger fast re-transmit. Consequently we have specified that the 
> displacement should be at least this large.

Maybe I'm the one who is confused, but as I understand it, a single
duplicate ACK (for the correct segment) is enough to differentiate an
honest receiver from a malicious one, so why do you need multiple
duplicate acks?   Fast retransmit should never be an issue, because 
the sender should not perform congestion control in response to a
malicious receiver test.  

- Rob
.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm