[e2e] [tcpm] RTTM + timestamps

[Detlef Bosau]

On 07/30/2011 10:03 PM, Scheffenegger, Richard wrote:
>
> Timer (RTTM?) ambiguity != retransmission ambiguity.
>
> The semantics of RFC1323 explicitly make it impossible to
> disambiguate a received retransmission from a delayed
> original transmission, whenever there is still a preceding
> hole in the received sequence space.
>

I see the point, however: Following page 13 of RFC 1323, we have:

>             A TSecr value received in a segment is used to update the
>             averaged RTT measurement only if the segment acknowledges
>             some new data, i.e., only if it advances the left edge of the
>             send window.

Neither a retransmission nor a pure ACK caused by a hole will lead to 
the acknowledgement of yet unacknowledged data. Do you agree here?
Either way, the sender will simply ignore the TSecr.



> But these semantics were designed, to always result in
> conservative RTT estimates, even when dealing with
> delayed ACKs and ACK loss, without requiring any
> other signal.(*)
>

O.k., IIRC I asked for the meaning of "conservative" here. Having looked 
at the RFC, the answer is: conservative regarding congestion control. 
I.e. a sender must not send to much data. So, the RTT should rather be 
overestimated than underestimated.

Admittedly, this means that we avoid congestion - at the expense of a 
better throughput.

> Furthermore, the disambiguation (which will only work for
> the first hole under RFC1323) will only work when the
> timestamp value has changed between the original
> transmission and the retransmission.

At least, for TCP RTTM, this disambiguation is simply not necessary, 
because the TSecr, you refer to, are not taken into account.

What you perhaps refer to is the case that a first sending attempt for a 
packet failed while the second is successful.
The first attempt will not cause an acknowledgment to be sent, while the 
first successful retransmission will lead to a reasonable RTTM.

Hence, in case of several transmissions being necessary for a packet, 
you will measure a proper "ping pong time" for the very first successful 
transmission. Is this correct? (Perhaps, I have to think it over for the 
delayed ack case.)

So, looking at the Karn & Partridge paper, we avoid both, case "3.1", 
measuring from the first transmission, which makes the RTO too 
conservative, and "3.2", measuring from the most recent transmission, 
which makes the RTO too aggressive.

Detlef

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de
------------------------------------------------------------------