[Tsvwg] RFC1323.bis [was: Updating timestamps (ts_recent)]

At 22:33 13.08.2003, Duke, Martin wrote:

> >
> > The real RTT samples as seen by "somebody traveling in the
> > packet", and as
> > they arrive at the TCP sender are:
> > RTT(A)=100
> > RTT(C)=100
> > RTT(B)=120
> > RTT(E)=100
> > RTT(D)=120
> >
> > The RTT samples taken by a TCP sender using the rule I suggested are:
> > RTT(A)=100
> > RTT(C)=100
> > RTT(B)=110(-10)
> > RTT(E)=100
> > RTT(D)=110(-10)
> >
> > The RTT samples taken by a TCP sender using RFC1323 are:
> > RTT(A)=100
> > RTT(C)=120(+20)
> > RTT(B)=120
> > RTT(E)=140(+40)
> > RTT(D)=120
>
>Remember that using RFC 1323, only 3 measurements are taken because 2 of 
>the ACKs do not ack new data.
>
>Using RFC 1323, the measurements are taken from the 1st, 3rd, and 5th 
>ACKs, and are
>
>RTT(A) = 100
>RTT(B) = 120
>RTT(D) = 120
>(Packets C and E do not update ts_recent)

True. And if we would continue to use RFC1323's rule of only taking RTT 
samples from ACKs for new data then with any of the echo schemes only the 
ACKs for A, B, and D got sampled.

>So I don't see what the problem is in your example.

RFC1323's sender rule of only taking RTT samples from ACKs for new data is 
one half of the problem I see. The other half of that problem is RFC1323's 
receiver echo rule (B)).

The combination of both halves of that problem lead to the fact that during 
a typical loss recovery, when an RTT worth of DUPACKs return, the sender 
can't sample the RTT. So far, I haven't seen a good reason for why this has 
to be like that.

I would therefore like to see RFC1323 changed in such a way that (1) the 
TCP sender is allowed to sample the RTT from DUPACKs, and (2) that the TCP 
receiver echos the most recently received TSval in DUPACKs. Clearly, having 
(1) without (2) makes little sense, and vice versa.

The problem you raised is different, but related, and relevant, I believe.

BTW, whatever RFC1323.bis gets created, it might be a good idea to include 
RFC1323.bis-capability-indication in the initial SYN/SYN-ACK handshake.

Another open issue with RFC1323, I think, is the question of whether 
*every* segment MUST carry a TS option once that was negotiated in the 
SYN/SYN-ACK handshake.

///Reiner 

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