Re: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP)

[Fred Baker <[e-mail]>]

I'm sure you're wiser than I. I'm just thinking that in a context where cwnd<4 (pretty normal at my house when uploading to Picasa, which is an obvious file-transfer test, because the RTT is relatively short) sending after two dup-acks inserts a relatively large delay on the line in the event that it is a wrong guess. If you're going to increase the chance of guessing wrong, it seems like you might want to minimize the side-effect of being wrong.

On Apr 27, 2010, at 4:16 AM, Mark Allman wrote:

> 
>> In cases in which cwnd < 4, it seems like your biggest concern is to
>> elicit the information necessary to trigger the retransmission without
>> unnecessarily burdening the path. That is in essence why we use three
>> dup-acks as a trigger - it is "enough" information to ensure that with
>> high probability it is not being triggered by simple packet
>> reordering.  
>> 
>> Would it make sense to, when cwnd < 4 or all of the data available to
>> transmit is in flight, in response to a SACK, send a segment
>> containing exactly the TCP header, and one byte of SACKed data? The
>> receipt of the SACK says that it is highly likely that the missing
>> segment cleared the bottleneck, and would trigger an additional
>> dup-ack containing the SACK record in question (which might trigger
>> another of the same type of segment). If the missing segment is in
>> fact lost, doing that would allow you to trigger three dup-acks in
>> three RTTs even if you only had two segments outstanding (cwnd=2 or
>> that's all the data you have). You only take the RTO if you literally
>> have a single segment outstanding. If the missing segment in fact
>> arrived but the ACK was lost, it would trigger the ACK. 
> 
> My quick response is ...
> 
>  - ER explicitly defers to Limited Transmit (RFC 3042) when possible,
>    which is sorta what you describe, but not with dummy sorts of
>    packets, but with packets off the top.  But, the point is the
>    same---to try to drive the ACK process to a less ambiguous state.
> 
>  - I am not a big fan of dummy packets that really don't accomplish any
>    work [*] (and, not just here; they've been proposed in a number of
>    contexts).  My mental model says one of these packets you sketch
>    above is about as much work as a data carrying packet and so why not
>    just retransmit and be done with it?  Yeah, if we're wrong because
>    of small scale reordering then we needlessly injected a packet.
>    But, using the scheme above to try to better ensure the right action
>    is taken we also injected a packet (or two).  And, in either case,
>    the cwnd is so small cutting it isn't a huge deal, it seems to me.
> 
>    [*] By work I mean in the context transfer process, not in terms of
>        the underlying mechanisms to get that done.  So, in my mind
>        "work" == data packets or their ACKs and not control things such
>        as you sketch.
> 
> allman
> 
> 
> 

http://www.ipinc.net/IPv4.GIF