Subject: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-02.txt

From: Per Hurtig <[email-masked]>
Date: Mon, 2 Jul 2012 08:45:51 +0200

Hi all,

we've now updated the modified RTO restart draft to not require
implementations to save the transmission times of every segment. There
are also some changes to the discussion section and various small text
changes.

Per

A new version of I-D, draft-hurtig-tcpm-rtorestart-02.txt
has been successfully submitted by Per Hurtig and posted to the
IETF repository.

Filename:        draft-hurtig-tcpm-rtorestart
Revision:        02
Title:           TCP and SCTP RTO Restart
Creation date:   2012-06-28
WG ID:           Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-hurtig-tcpm-rtorestart-02.txt
Status:          http://datatracker.ietf.org/doc/draft-hurtig-tcpm-rtorestart
Htmlized:        http://tools.ietf.org/html/draft-hurtig-tcpm-rtorestart-02
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-hurtig-tcpm-rtorestart-02

Abstract:
   This document describes a modified algorithm for managing the TCP and
   SCTP retransmission timers that provides faster loss recovery when a
   connection's amount of outstanding data is small.  The modification
   allows the transport to restart its retransmission timer more
   aggressively in situations where fast retransmit cannot be used.
   This enables faster loss detection and recovery for connections that
   are short-lived or application-limited.

The IETF Secretariat

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 2 Jul 2012 12:20:46 -0700

>    are short-lived or application-limited.
I asked similar questions for every revision but didn't see the response in
the list or the newest draft:

I am concerned about this following hypothetical scenario:

t0.0s: bursts packets 1-20, mount RTO to 2second
t1.8s: gets ack of packets 2,4,6,8,10,12,14,16, 18 every 200ms.
       Ack of 18 arrives at 1.8s

This draft will mount an RTO of 200ms for packet 19 on ack18, which
is likely to be spurious. The problem is that T_earliest could be
starting from large send a while back even when current FlightSize
is small. Moreover, I don't think this is rare so I suspect the
performance benefit will be offset by the spurious RTO.

The (un-cited) references [EL04] thus argues current standard
offers a safe margin. Some data or response to this question is
appreciated. Thanks.

Yuchung
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Michael Welzl <[email-masked]>
Date: Fri, 06 Jul 2012 11:25:21 +0200

Hi Yuchung,

First of all, my apologies for answering so slowly, and for forgetting 
to answer your previous similar comment.
What happened then is that each of us authors assumed that the other 
would take care of it, and in the end, I had forgotten about it.

See my answer in line below:

> performance benefit will be offset by the spurious RTO.
( I wonder what made you pick 20, not 10 packets for your example? ;-)   )

Seriously: you raise a very valid concern here, a concern which we 
haven't yet investigated (hence: no data).
However, it seems to me that the situation you describe can really only 
happen when the sender transmits a sudden burst of data without waiting 
for new incoming ACKs. So this could be fixed by disabling the mechanism 
in Slow Start, right? What do you think?

(or, maybe better, define usage in Slow Start as a more experimental, 
"aggressive" variant of our scheme, and only have it enabled in 
Congestion Avoidance by default)

> offers a safe margin. Some data or response to this question is
Thanks a lot for spotting that! Of course it wasn't the intention to 
have EL04 uncited.

Cheers,
Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 6 Jul 2012 12:05:40 -0700

Hello,

On Fri, Jul 6, 2012 at 2:25 AM, Michael Welzl <[email-masked]> wrote:
> Hi Yuchung,
>
> First of all, my apologies for answering so slowly, and for forgetting to
> answer your previous similar comment.
> What happened then is that each of us authors assumed that the other would
> take care of it, and in the end, I had forgotten about it.
>
>>> Status:
>>> http://datatracker.ietf.org/doc/draft-hurtig-tcpm-rtorestart
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-hurtig-tcpm-rtorestart-02
>>> Diff:
> Seriously: you raise a very valid concern here, a concern which we haven't
> yet investigated (hence: no data).
> happen when the sender transmits a sudden burst of data without waiting for
> new incoming ACKs. So this could be fixed by disabling the mechanism in Slow
> Start, right? What do you think?

I think there are some situations where TCP sends burst of packets.
ACK lost/compression,
recovery from packet loss, small pause of application.. Is it ok to
exclude these situations?

Thanks,
--
Yoshifumi

---

From: Per Hurtig <[email-masked]>
Date: Sun, 8 Jul 2012 14:24:28 +0200

Hi,

For a "careful" variant of the algorithm I would agree that it's ok to
exclude these scenarios. However, it would still be interesting to
have an "aggressive" version of the algorithm that is enabled in burst
situations as well.

Per

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 9 Jul 2012 12:19:37 -0700

> recovery from packet loss, small pause of application.. Is it ok to
in particular TSO and application pauses (or user-level pacing) make bursts
common so I am concerned not to address that. slow start after idle
can not prevent pauses within RTO (it happens on YouTube serving already).

> exclude these situations?
It's probably not OK but not difficult to deal with that either, e.g.,
sender can simply avoid offsetting the RTO for such large send in the
proposal.

But in principle isn't RTO meant for SND.UNA. This draft essentially
suggests RTO for every packet. It'd be interesting to see some real
data benchmarks. Thanks.

---

From: Mark Allman <[email-masked]>
Date: Tue, 10 Jul 2012 11:13:52 -0400

> is small. 

I hear you.  But, I don't buy your framing.  You keep the RTO at a
constant throughout the process.  But, with a variance like you describe
above it certainly seems plausible that the RTO will balloon.  And, the
way the document is framed when 18 arrives we restart the timer with
RTO-T_earliest.  But, if RTO is > 2sec then the timeout will be >
200ms.  

So, I don't think it is as easy as you have portrayed it. 

allman