Subject: Re: [tcpm] Fwd: New Version Notification fordraft-hurtig-tcpm-rtorestart-01.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 3 Nov 2011 09:57:31 +0000

Hi Per,

I was wondering if our proposed semantic changes of RFC1323 in draft-scheffenegger-tcpm-timestamp-negotiation-03.txt would allow all the byte-oriented, non-linux derived stacks to benefit from your proposal as well...

With RFC1323, the timestamp value echoed back to the sender contains the TSval of the oldest, in-sequence received segment. As such, the TSecr in an ACK cannot directly be used to find the time when a particular segment was actually sent and covered in the ACK. This leads to the very stateful approach taken in linux (the 2nd issue is, that RFC1323 TSecr is not protected against spoofing/alteration, opening a nice attack surface against any time-based algorithm).

Unfortunately, in my experience, the majority of tcp stacks does not hold per-segment state information.

Our proposal is to also modify the semantics of RFC1323, which timestamp should be reflected in an ACK - provided the TCP session is also using SACK (SCTP always uses SACK). Thus the TSecr will contain the exact timestamp when the last segment triggering the ACK was sent.

So each ACK gives a more accurate probe of the current network RTT, potentially allowing better estimates of the RTO that may not need to artificially delayed by 1 RTT before expiring...

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Per Hurtig (work) [mailto:[email-masked]]
> Sent: Sonntag, 30. Oktober 2011 17:30
> To: tcpm
> Subject: [tcpm] Fwd: New Version Notification fordraft-hurtig-tcpm-
> rtorestart-01.txt
> 
> Hi all,
> 
> we've updated the TCP/SCTP RTO restart draft. The main difference
> between this version and the previous one is that the modified restart
> approach only is conducted for data-limited traffic and that the intended
> status of the draft has changed to experimental. Hope we can discuss it in
> Taipei.
> 
> Regards,
> Per
> 
> ---------- Forwarded message ----------
> From: [email-masked]
> Date: Sat, 29 Oct 2011 12:28:48 -0700
> Subject: New Version Notification for draft-hurtig-tcpm-rtorestart-01.txt
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> 
> A new version of I-D, draft-hurtig-tcpm-rtorestart-01.txt has been
> successfully submitted by Per Hurtig and posted to the IETF repository.
> 
> Filename:	 draft-hurtig-tcpm-rtorestart
> Revision:	 01
> Title:		 TCP and SCTP RTO Restart
> Creation date:	 2011-10-29
> WG ID:		 Individual Submission
> Number of pages: 9
> 
> Abstract:
>    This document describes a modified algorithm for managing the TCP and
>    SCTP retransmission timers, that provides faster loss recovery when a
>    connection&#39;s amount of outstanding data is small.  The modification
>    allows the transport to restart its retransmission timer more
>    aggressively in situations where fast retransmit can not be used.
>    This enables faster loss detection, and recovery, for connections
>    that are short-lived or application-limited.
> 
> 
> 
> 
> The IETF Secretariat
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Per Hurtig (work)" <[email-masked]>
Date: Tue, 15 Nov 2011 12:43:32 +0100

Hi Richard,

I read your draft, and I really like it. I think it would be nice to
to use your changes to simplify the implementation of the modified
restart, at least for stacks that do not hold per-packet state info

Regards,
Per

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 15 Nov 2011 13:49:41 -0800

I think this proposal is interesting but would like to see some
larger-scale TCP measurements to support this argument, since it's
been debated in several papers:
[LS00] first discovered this "bug"
In Ekström, H., & Ludwig, R. (2004). The peak-hopper: A new endto-end
retransmission timer for reliable unicast transport. In Proceedings of
the IEEE INFOCOM. The author reverted his point in [LS00] and claimed
it offers a safety margin due to two other under-estimation issues in
current 2988 RTO calculation.
Section 4.3 of your paper  "SCTP: designed for timely message
delivery?", you seem to agree that this cushion make sense in TCP?

Thanks.

On Sun, Oct 30, 2011 at 9:30 AM, Per Hurtig (work) <[email-masked]> wrote:
> approach only is conducted for data-limited traffic and that the
> intended status of the draft has changed to experimental. Hope we can
> discuss it in Taipei.
>
> Regards,
> Per
>