[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