Subject: Re: [tcpm] FW: New Version Notification for draft-heitzhe-tcpm-vm-rto-00.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 12 Nov 2014 23:56:06 +0000

Hi Jakob,

I read your draft; the references section is imho missing a reference to H. Ekström, R. Ludwig, "The Peak-Hopper", INFOCOM 2004; 
http://www.cs.helsinki.fi/u/gurtov/reiner/PeakHopper_draft0207.pdf
as is a detailed discussion why that modification or rfc6298 is not applicable.

A comparison of this new mechanism with the (adjusted) EDWA of RFC6298  or other schemes should be given. Also, although the introduction clearly states that this mechanism is mostly for virtulized environments, a formal applicability statement might be good. Ie. can that algorithm applied safely for non-VM environments? What is the impact of omitting the RTT variance signal into the RTO calculation?

(And, was the baseline truly RFC6298, or the Linux RTO algorithm, which is subtly different and adjust much quicker to lower RTOs once the lower limit is removed)

Technically: the last sentence of section 2 say: "A window of data is the largest ever advertised window of a session." First, I think this definition should be moved to point 2 above; but even then, it's not clear to me if this really is a sensible choice; with many TCPs advertising many 100 kB or even MB of window for application-limited flows, the interval (20*advertised window) could be many seconds or even minutes, when the RTO would be adjusted down...

In particular, for latency-sensitive, low-bandwidth and application-limited flows, that announce a comparatively large window, this appears to artificially delay the completion time of that kind of transactions. Also, taking an spurious RTO, with the changes to the CC state not being unwound by ie. Eiffel-reaction, is much less critical in that circumstances than for bulk transfers.

The draft is also not clear on its interaction with per-packet RTT measurement vs. one-per-window (send window, not advertised window) RTT measurement.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Jakob Heitz
> (jheitz)
> Sent: Sonntag, 19. Oktober 2014 14:41
> To: [email-masked]
> Cc: Chuan He
> Subject: [tcpm] FW: New Version Notification for draft-heitzhe-tcpm-vm-
> rto-00.txt
> 
> Hi TCPM,
> 
> We were experimenting with TCP code in a VM setting.
> We reduced the minimum RTO, because average RTT should be much lower than
> 1 second.
> We got lots of spurious retransmissions in a heavily loaded host.
> As a result, we developed an alternative to the exponential weighted
> moving average algorithm to determine the RTO. It operates well without
> any minimum RTO setting.
> 
> Please take a look and comment.
> 
> --Jakob
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, October 19, 2014 4:52 PM
> To: Jakob Heitz (jheitz); Chuan He; Chuan He; Jakob Heitz (jheitz)
> Subject: New Version Notification for draft-heitzhe-tcpm-vm-rto-00.txt
> 
> 
> A new version of I-D, draft-heitzhe-tcpm-vm-rto-00.txt has been
> successfully submitted by Jakob Heitz and posted to the IETF repository.
> 
> Name:		draft-heitzhe-tcpm-vm-rto
> Revision:	00
> Title:		TCP Retransmission Timer for Virtual Machines
> Document date:	2014-10-19
> Group:		Individual Submission
> Pages:		5
> URL:            http://www.ietf.org/internet-drafts/draft-heitzhe-tcpm-vm-
> rto-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-heitzhe-tcpm-vm-
> rto/
> Htmlized:       http://tools.ietf.org/html/draft-heitzhe-tcpm-vm-rto-00
> 
> 
> Abstract:
>    A Round Trip Time (RTT) estimate that decays performs badly in a
>    bursty environment. A round trip time estimator that does not decay
>    for a period of time is proposed.
> 
>    It does not require a minimum value to be configured. It works
>    equally well when the typical RTT is 100uS as when it is 10 seconds.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm