Subject: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-02

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 26 Aug 2009 15:37:11 +0200

Hi folks,

I upload a new version of our draft to the IETF repository:
http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt

As always, comments are more than welcome.

Alex

---

Main change from draft-zimmermann-tcp-lcd-01

The algorithm in Section 4.2 was slightly changed. Instead of reverting
the RTO by halving it, it is recalculated with help of the "Backoff_cnt"
variable. This fixes an issue that occurred when the retransmission  
timer
was backed off but bounded by a maximum value. The algorithm in the
previous version of the draft, would have "reverted" to half of that
maximum value, instead of using the value, before the RTO was doubled
(and then bounded).

---

Filename:	 draft-zimmermann-tcp-lcd
Revision:	 02
Title:		 Make TCP more Robust to Long Connectivity Disruptions
Creation_date:	 2009-08-26
WG ID:		 Independent Submission
Number_of_pages: 17

Abstract:
Disruptions in end-to-end path connectivity which last longer than
one retransmission timeout cause suboptimal TCP performance.  The
reason for the performance degradation is that TCP interprets segment
loss induced by connectivity disruptions as a sign of congestion,
resulting in repeated backoffs of the retransmission timer.  This
leads in turn to a deferred detection of the re-establishment of the
connection since TCP waits until the next retransmission timeout
occurs before attempting the retransmission.

This document describes how standard ICMP messages can be exploited
to disambiguate true congestion loss from non-congestion loss caused
by long connectivity disruptions.  Moreover, a revert strategy of the
retransmission timer is specified that enables a more prompt
detection of whether the connectivity to a previously disconnected
peer node has been restored or not.  The specified algorithm is a TCP
sender-only modification that effectively improves TCP performance in
presence of connectivity disruptions.

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Mon, 31 Aug 2009 17:47:45 +0300 (EEST)

> As always, comments are more than welcome.

I did read throught -01 before -02 was made available and I quickly went 
through the diffs for -02 (and also did read -00 earlier, was among those 
who had read it). I support adopting this id as WG item. After reviewing 
the Linux implementation too, I'd say it looks very straightforward, 
simple and clean to implement too (with rather little effort).

Then some comments:

2., 2nd paragraph.
I somewhat feel a bit strange on the importance that is placed in this ID 
for I-D.schuetz-... in defining the meaning "short" and "long" 
connectivity disruptions.

3., 2nd to last paragraph.
"This may very well be the case when TCP is recovering lost segments (...)."
It's very unclear to me whether you mean negative or positive statement 
here with the unclarity associated the use of "This".

4.2., 1st paragraph.
"... a timeout-based loss recovery has already been started but not 
completed". Are you sure that it is crystal clear what "not completing"
"timeout-based loss recovery" means?

4.2., the algorithm itself.
Why not just increase backoff_cnt unconditionally on rto and provide the 
proper cap in the "RTO := RTO_base * 2^(Backoff_cnt)" formula? It makes 
very little difference in practice and arquably can even be considered to 
be more "safe" to count lost retransmissions correctly if the rto cap was 
reached (and bypassed) before any icmps did come?

4.2., last paragraph.
IMHO the change to the "new started retransmission timer" isn't that good, 
however, I agree that changing it to something is necessary as the 
the previous use of "RTO" wasn't that good either. Perhaps something like 
"shortened" would be a good replacement to the "started"?

4.3., 4th paragraph.
A self-reference (see Section 4.3)?

Same paragraph.
I think that the sentence starting with "However, " is mis-comma'fied.

4.3., 5th paragraph.
Isn't it enough that any TCP flow with the same 4-tuple matches with
previous one's seqno (not required to be exactly the same flow with the 
correct seqno)? ...I guess it is most likely to happen with the same flow 
though.

Nits:

An revert -> A revert (2.)
..., back offs -> ..., backs off (4.2.)
scheme flood -> scheme to flood (7.)
to attempt to maliciously -> in attempt to maliciously (7.) ?

-- 
  i.