[e2e] [tcpm] RTTM + timestamps

Scheffenegger, Richard rs at netapp.com
Sat Jul 30 13:03:47 PDT 2011


Detlef,

> >>   However, solving the retransmission ambiguity problem -
> > The problem is solved, isn't it? Eifel?
> >
> 
> The timer ambiguity was originally solved by Karn & Partridge. To my
> understanding, this ambguity does not even occur when timestamps are
> used. Do you agree?


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. 

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

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. Thus the timestamp 
clock tick delay must be shorter than the RTT.
With common timestamp clock granularities of
10..100 ms, it's easy to see that this may work for 
intercontinental paths, but not for continental, regional or 
local paths (not to mention data center / LAN environments).

Thus there are two issues: 
o) The typical timestamp granularity is too coarse for a 
high fraction of sessions; 
o) Secondly, the current timestamp semantics do not allow 
discrimination of non-contiguous received segments between 
original vs. retransmitted segment, because of a deliberate 
loss of accuracy to "solve" the RTTM issue during loss 
episodes. Note that the latter is redundant, if the session 
is using SACK. With SACK, timestamp semantics can be changed 
during loss/reorder episodes at least, without introducing 
any RTTM ambiguity.


Richard

(*) originally, timestamps and selective acknowledgement were
discussed in one RFC, which would have allowed synergistic
semantics. Later, SACK was split off (see RFC1072 evolving 
to RFC1323/2018) and there was not much interest at the time in
this topic.




More information about the end2end-interest mailing list