Subject: [tcpm] FW: New Version Notification for draft-scheffenegger-tcpm-timestamp-negotiation-04.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 16 Jul 2012 08:53:23 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Montag, 16. Juli 2012 10:43
To: Scheffenegger, Richard
Cc: [email-masked]
Subject: New Version Notification for draft-scheffenegger-tcpm-timestamp-negotiation-04.txt

A new version of I-D, draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
has been successfully submitted by Richard Scheffenegger and posted to the
IETF repository.

Filename:	 draft-scheffenegger-tcpm-timestamp-negotiation
Revision:	 04
Title:		 Additional negotiation in the TCP Timestamp Option field during the TCP handshake
Creation date:	 2012-07-16
WG ID:		 Individual Submission
Number of pages: 34
URL:             http://www.ietf.org/internet-drafts/draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
Status:          http://datatracker.ietf.org/doc/draft-scheffenegger-tcpm-timestamp-negotiation
Htmlized:        http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-04
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-scheffenegger-tcpm-timestamp-negotiation-04

Abstract:
   A number of TCP enhancements in so diverse fields as congestion
   control, loss recovery or side-band signaling could be improved by
   allowing both ends of a TCP session to interpret the value carried in
   the Timestamp option.  Further enhancements are enabled by changing
   the receiver side processing of timestamps in the presence of
   Selective Acknowledgements.

   This documents updates RFC1323 and specifies a backwards compatible
   way of negotiating for Timestamp capabilities, and lists a number of
   benefits and drawbacks of this approach.

The IETF Secretariat

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 23 Jul 2012 19:23:35 +0200

Hi all,

In order to trigger some discussion on that draft, here are some questions on draft-scheffenegger-tcpm-timestamp-negotiation-04 (as naive and memoryless individual):

* Very, very globally: We apparently have 4 spare bytes in the SYN option if TS are used. This draft suggests a really intelligent way of using those bits. However, if we touch TCP timestamp semantics, wouldn't it be a better, though more disruptive approach to replace the TS option by a new option with less bytes at least in the initial in the SYN? 4 bytes of 40 is 10%... I also recall some interest in late enablement of timestamps earlier this year; this draft seems to suggest quite the opposite...

* Is there really a need to announce the clock speed in the SYN? We need the SYN for atomic negotiation of features. I could imagine that for the clock speed a post-SYN option could be used as well. Thoughts?

* I also wonder whether there is some data on how much better explicit signaling of the clock speed is than learning from heuristics (sorry if I should have missed that data).

* Some thought on security considerations: Can a host mess up a delay measurement by announcing a wrong clock frequency? What would be the implications?

* The masking of the timestamps seems to be motivated by a heuristic that is deployed in some stacks, but AFAIK not described in an RFC. Maybe it would make sense first to have some draft that specifies that behavior?

* The draft is a "one-in-a-box" proposal for one-way delay measurement and improved SACK processing. I wonder whether it could make sense to allow separate enablement of those features. For instance, would it make have some benefit if a host just announces its clock frequency but leaves the TS echoing semantics unchanged?

* Given that the draft changes the TS echoing semantics, it has to update the RTTM to get some additional offset for the delayed ACKs. Currently, the draft suggests: "R = RTT * ( 1 + 1/(cwnd/smss) )". Is my understanding correct that this formula assumes that every second segment is acked? According to RFC 1122, acking every second segment is only a SHOULD. The MUST just mandates that the additional delay is less than 0.5 seconds. Thus, is it possible that "R = RTT + 0.5s" is needed in some scenarios? Or is there even a need to signal the delACK strategy to the remote end, so that it can adapt its RTTM/RTP calculation? This could be challenging...

Sorry if I should have missed something.

Thanks

Michael

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scheffenegger, Richard
> Sent: Monday, July 16, 2012 10:53 AM
> To: tcpm ([email-masked])
> Subject: [tcpm] FW: New Version Notification for 
> draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
> 
> Subject: New Version Notification for 
> draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
> 
> 
> A new version of I-D, 
> draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
> Title:		 Additional negotiation in the TCP 
> Timestamp Option field during the TCP handshake
> URL:             
> http://www.ietf.org/internet-drafts/draft-scheffenegger-tcpm-t
> imestamp-negotiation-04.txt
> Status:          
> http://datatracker.ietf.org/doc/draft-scheffenegger-tcpm-times
> tamp-negotiation
> Htmlized:        
> http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-
> negotiation-04
> Diff:            
> http://tools.ietf.org/rfcdiff?url2=draft-scheffenegger-tcpm-ti
> mestamp-negotiation-04
> 
> Abstract:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 26 Jul 2012 14:39:02 +0000

Hi Michael,

> I also recall some interest in late enablement of timestamps
> earlier this year; this draft seems to suggest quite the opposite...
> 
> * Is there really a need to announce the clock speed in the SYN? We need
> the SYN for atomic negotiation of features. I could imagine that for the
> clock speed a post-SYN option could be used as well. Thoughts?

In this draft, the 1323 TS option is overloaded with additional meaning during the initial handshake (actually only announcing local settings, when the SYN bit is set). Reducing the TS negotiation to a bare minimum was not the aim of this draft, rather some unused bytes are redefined/overloaded to facilitate a (legacy compatible) negotiation.

This overload scheme requires a means to differentiate between the normal use of timestamps, and the "announcement" / negotiation phase. In the draft, this is implicitly done by modifying the signaling only when the SYN bit is set. So you are correct, the draft as it is now, rules out late negotiation of timestamps.

For late negotiation, some kind of reliable signaling would be required, to carry out that function.

If the WG concludes that smaller TS negotiation option (akin to SACK permitted option) would be preferable, that could be addressed in a new version of the draft.

> * I also wonder whether there is some data on how much better explicit
> signaling of the clock speed is than learning from heuristics (sorry if I
> should have missed that data).

Well, the heuristics I have investigated typically assume either a single timestamp clock interval (good enough for closed experiments), or select one of a limited set of predefined timestamp clock intervals. An implicit assumption in these heuristics is, that the network conditions don't change too much during the training phase. However, such an assumption may be skewed (e.g. slow-path during flow setup (SYN/SYNACK), fast-path during regular data exchange; path changes during training phase etc). Further, new timestamp clock intervals, or unusual ones used by less common stacks, won't be included in such a predefined, limited set...

However, papers I have read on the (receiver side) use of timestamps for timing purposes usually focus on their new mechanisms, rather than how to obtain a good input signal. 

> * Some thought on security considerations: Can a host mess up a delay
> measurement by announcing a wrong clock frequency? What would be the
> implications?

This is a very good observation - however it can only be answered in the context of a specific mechanism using timestamps as input. Mirja may have more information as to the effects of a constant skew in one-way delay variance for TCP chirp...

> * The masking of the timestamps seems to be motivated by a heuristic that
> is deployed in some stacks, but AFAIK not described in an RFC. Maybe it
> would make sense first to have some draft that specifies that behavior?

Actually, the motivation has to do with the use of timestamps in more core mechanisms like congestion control. The draft has the relevant reference - early versions of CUBIC used timestamps directly to determine the congestion epoch (to determine the inflection point). An attach was shown where a malicious receiver can speed up the inflection point of Cubic by manipulating the timestamp values. The solution in Linux / Cubic at the time was to NOT use timestamps directly, but rather make the timestamp option a token into a lookup table, which the sender can resolve.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.3152&rep=rep1&type=pdf, page 11:

"[Linux] 2.6.23   The use of received timestamp option value from RTT calculation is removed for preventing possible malicious receiver attacks that reports wrong timestamps to reduce RTTs for more throughput."

> * Given that the draft changes the TS echoing semantics, it has to update
> the RTTM to get some additional offset for the delayed ACKs. Currently,
> the draft suggests: "R = RTT * ( 1 + 1/(cwnd/smss) )". Is my understanding
> correct that this formula assumes that every second segment is acked?

Correct.

> According to RFC 1122, acking every second segment is only a SHOULD. The
> MUST just mandates that the additional delay is less than 0.5 seconds.
> Thus, is it possible that "R = RTT + 0.5s" is needed in some scenarios? Or
> is there even a need to signal the delACK strategy to the remote end, so
> that it can adapt its RTTM/RTP calculation? This could be challenging...

The formula was a initial attempt to keep the RFC1323 RTTM calculation (for RTO purpose only) mostly intact, when timestamps are immediately reflected... We do have other drafts in current discussion to update the way how to deal with RTOs (when to restart timers). More sophisticated RTTM methods could also be deployed (making use of the network-only RTT measurement). The largest deviation is expected for small windows (<= 4 packets in flight), so a different approach could be a constant offset when the window is small... But this draft really is around the modified signaling (and arriving at a different rtt input signal that more closely tracks network conditions).

Best regards,

Richard Scheffenegger
> 
> * Very, very globally: We apparently have 4 spare bytes in the SYN option
> if TS are used. This draft suggests a really intelligent way of using
> those bits. However, if we touch TCP timestamp semantics, wouldn't it be a
> better, though more disruptive approach to replace the TS option by a new
> option with less bytes at least in the initial in the SYN? 4 bytes of 40
> is 10%... 
> I also recall some interest in late enablement of timestamps
> earlier this year; this draft seems to suggest quite the opposite...
> 
> * Is there really a need to announce the clock speed in the SYN? We need
> the SYN for atomic negotiation of features. I could imagine that for the
> clock speed a post-SYN option could be used as well. Thoughts?
> 
> * I also wonder whether there is some data on how much better explicit
> signaling of the clock speed is than learning from heuristics (sorry if I
> should have missed that data).
> 
> * Some thought on security considerations: Can a host mess up a delay
> measurement by announcing a wrong clock frequency? What would be the
> implications?
> 
> * The masking of the timestamps seems to be motivated by a heuristic that
> is deployed in some stacks, but AFAIK not described in an RFC. Maybe it
> would make sense first to have some draft that specifies that behavior?
> 
> * The draft is a "one-in-a-box" proposal for one-way delay measurement and
> improved SACK processing. I wonder whether it could make sense to allow
> separate enablement of those features. For instance, would it make have
> some benefit if a host just announces its clock frequency but leaves the
> TS echoing semantics unchanged?
> 
> * Given that the draft changes the TS echoing semantics, it has to update
> the RTTM to get some additional offset for the delayed ACKs. Currently,
> the draft suggests: "R = RTT * ( 1 + 1/(cwnd/smss) )". Is my understanding
> correct that this formula assumes that every second segment is acked?
> According to RFC 1122, acking every second segment is only a SHOULD. The
> MUST just mandates that the additional delay is less than 0.5 seconds.
> Thus, is it possible that "R = RTT + 0.5s" is needed in some scenarios? Or
> is there even a need to signal the delACK strategy to the remote end, so
> that it can adapt its RTTM/RTP calculation? This could be challenging...
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Scheffenegger, Richard
> > has been successfully submitted by Richard Scheffenegger and posted to
> > the IETF repository.
> >