Subject: [tcpm] Timestamp semantic change

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 18 Nov 2011 00:45:18 +0000

Hi,

After this weeks TCPM session, Joe brought up an interesting observation.

The draft proposes to change the semantics of timestamps under certain circumstances - i.e. when both TS capabilities and SACK is negotiated.

Joe provided the following example, to perhaps revisit the way, which timestamp to reflect during reordering events:

At t0, a data segment is sent from the sender to the receiver; the receiver ACKs with TSecr indicating t0.
At t1, a data segment is sent, but delayed in the network.
At t2, a data segment is sent, and received. 
	With RFC1323, the ACK would carry TSecr=t0 (as that was the last in-sequence data packet received). 
	The draft suggests to reflect TSecr=t2 at this time, as that data packet triggered the ACK.
After the ACK was sent, the receiver now sees the data segment with t1.
	With RFC1323, the ACK triggered now has TSecr=t1, similar to what the draft stipulates.
Now, the question is, which value to put into an unsolicited data packet sent at this time from the receiver to the sender...

With RFC1323, the kept timestamp value (TS.recent) would be t1 (as the last data segment to advance the window); however, that may lead to higher RTTvar and higher RTO at the sender side, that strictly necessary...

It would be potentially better, to keep not the timestamp value of the last segment that advanced the window in the receiver, but the *highest* received Timestamp value. This would reduce the calculated RTTvar / RTO on the sender side, when the receiver sends data during reordering (loss) events. In particular, when the delta between t1 and t2 is large, this can have a significant impact.

I would like to discuss this with the group, if adding this to the semantic modifications makes sense; so far, I assumed that TS.recent would be updated just as with RFC1323 (whenever the window advances), but by the above description, that minor change may be beneficial too..

Best regards,

Richard Scheffenegger

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Nov 2011 18:34:54 -0800

Hi, all,

To clarify, we had converged to two different suggestions:

- TCP should retain the highest TS seen
	for use on emitting new segments

- when ACKing, TCP should use the TS from the packet causing the ACK

I.e., in the first case it's "highest"; in the second it's "most 
recently received".

Joe

On 11/17/2011 4:45 PM, Scheffenegger, Richard wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "SCHARF, Michael" <[email-masked]>
Date: Thu, 24 Nov 2011 23:49:40 +0100

Richard, joe,

I am trying to understand the motivation for these suggestions.

According to RFC 1323, the TSecr value received in a segment is used to
update the averaged RTT measurement only if the segment acknowledges
some new data.

In your scenario, the unsolicitated packet wouldn't advance the window
in the sender, right? If this was correct, why would it matter what
value to put into TSecr, if the sender doesn't use it to update its RTT
measurement? Or do I miss something?

There may be corner cases e. g. if ACKs get lost, but in that case it
probably makes really sense to have a conservative RTO - which is the
design rationale of RFC 1323. Is there a simple example in which your
suggestion really improves the RTT estimation?

BTW, this might also be related to the question how to actually update
RTTvar with timestamps. As noted by RFC 6298, this is not well
understood so far... For instance, a sender doesn't have to use every
TSecr...

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Friday, November 18, 2011 3:35 AM
> To: Scheffenegger, Richard
> Cc: [email-masked]
> Subject: Re: [tcpm] Timestamp semantic change
> 
> Hi, all,
> 
> I.e., in the first case it's "highest"; in the second it's 
> "most recently received".
> 
> Joe
> 
> > The draft proposes to change the semantics of timestamps 
> under certain circumstances - i.e. when both TS capabilities 
> and SACK is negotiated.
> >
> > Joe provided the following example, to perhaps revisit the 
> way, which timestamp to reflect during reordering events:
> >
> > At t0, a data segment is sent from the sender to the 
> receiver; the receiver ACKs with TSecr indicating t0.
> > 	With RFC1323, the ACK would carry TSecr=t0 (as that was 
> the last in-sequence data packet received).
> > Now, the question is, which value to put into an 
> unsolicited data packet sent at this time from the receiver 
> to the sender...
> >
> > With RFC1323, the kept timestamp value (TS.recent) would be 
> t1 (as the last data segment to advance the window); however, 
> that may lead to higher RTTvar and higher RTO at the sender 
> side, that strictly necessary...
> >
> > It would be potentially better, to keep not the timestamp 
> value of the last segment that advanced the window in the 
> receiver, but the *highest* received Timestamp value. This 
> would reduce the calculated RTTvar / RTO on the sender side, 
> when the receiver sends data during reordering (loss) events. 
> In particular, when the delta between t1 and t2 is large, 
> this can have a significant impact.
> >
> > I would like to discuss this with the group, if adding this 
> to the semantic modifications makes sense; so far, I assumed 
> that TS.recent would be updated just as with RFC1323 
> (whenever the window advances), but by the above description, 
> that minor change may be beneficial too..
> >
> > Best regards,
> >
> > Richard Scheffenegger
> >

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 25 Nov 2011 08:59:28 +0000

Hi Michael,

You are absolutely correct. In the context of RFC1323,the sole purpose of Timestamps (to the sender) is to deliver a conservative lower bound of the RTT. This is again used for the single purpose of calculating the RTO on the sender side.

Thus, there was no point of discussing which timestamp to reflect (during RFC1323 time), when it's basically ignored on the sender side.

But even back then, there were proposals to use the timestamps for more than simple RTO calculation - at the time, the lack of SACK signaling stopped these though. Timestamps were seen as a pure, self-contained signal for only one single purpose to the sender. But perhaps my perception of these long past events is wrong - if so, there are still members on that DL who could set the record straight.

However, the proposal in the draft would enable the use of timestamps as a valuable signal for additional heuristics - one way delay variance, pure network RTT during special events (reordering, loss, L2 recovery...). Thus it may be worthwhile to redefine the semantics of which timestamps to reflect under what circumstances, to deliver a higher quality signal (more information) back to the sender. Which is what the draft tries to do, and Joe's suggestion improves upon this general idea.

Applying the very same rules as in RFC1323 to arrive at a conservative RTO measurement would not benefit from these changes, but they would not significantly suffer either (or at all). The RTO calculation would only deliberately throw away Information  at the sender side, instead of masking it already on the receiver side. 

So I believe the question for an improved RTT (for the purpose of arriving at a conservative RTO) is not the correct one - and I admit the second part was implicit by the context of your message. But if we leave out the implied second part, and disentangle RTT measurement from RTO calculation, that would be a valid question indeed...

What heuristics / algorithms could benefit from a more instantaneous sampling of network RTT, which are simply not possible today?

The draft names two (LEDBAT, TCP Chirp) which would benefit; Others (i.e. Non-congestion loss events) may as well, but that territory appears to be much less well explored. 

This leads to the question you raised last - when should the sender actually update the variables used to calculate the RTO in a conservative way. The draft is not trying to answer this at this point in time though, instead hinting on how to interface the legacy RTO calculation with the newly available signals by evaluating SACK information.

The signals available within an (SACK-enabled) TCP sessions ACK should be enough to gate this decisions on the sender side, without the need that the receiver deliberately withholds information...

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> SCHARF, Michael
> Sent: Donnerstag, 24. November 2011 23:50
> To: Joe Touch; Scheffenegger, Richard
> Cc: [email-masked]
> In your scenario, the unsolicitated packet wouldn't advance the window in
> the sender, right? If this was correct, why would it matter what value to put
> into TSecr, if the sender doesn't use it to update its RTT measurement? Or do
> I miss something?
> 
> There may be corner cases e. g. if ACKs get lost, but in that case it probably
> makes really sense to have a conservative RTO - which is the design rationale
> of RFC 1323. Is there a simple example in which your suggestion really
> improves the RTT estimation?
> 
> RTTvar with timestamps. As noted by RFC 6298, this is not well understood so
> far... For instance, a sender doesn't have to use every TSecr...
> 
> Michael
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Joe Touch
> > under certain circumstances - i.e. when both TS capabilities and SACK
> > is negotiated.
> > >
> > unsolicited data packet sent at this time from the receiver to the
> > sender...
> > >
> > t1 (as the last data segment to advance the window); however, that may
> > lead to higher RTTvar and higher RTO at the sender side, that strictly
> > necessary...
> > >
> > value of the last segment that advanced the window in the receiver,
> > but the *highest* received Timestamp value. This would reduce the
> > calculated RTTvar / RTO on the sender side, when the receiver sends
> > data during reordering (loss) events.
> > In particular, when the delta between t1 and t2 is large, this can
> > have a significant impact.
> > >
> > to the semantic modifications makes sense; so far, I assumed that
> > TS.recent would be updated just as with RFC1323 (whenever the window
> > advances), but by the above description, that minor change may be
> > beneficial too..
> > >
> > > Best regards,
> > >
> > > Richard Scheffenegger
> > >