Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-00.txt

From: [email-masked]
Date: Mon, 24 Jan 2011 10:30:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

	Title           : The NewReno Modification to TCP's Fast Recovery Algorithm
	Author(s)       : T. Henderson, et al.
	Filename        : draft-ietf-tcpm-rfc3782-bis-00.txt
	Pages           : 22
	Date            : 2011-01-24

RFC 5681 [RFC5681] documents the following four intertwined TCP
congestion control algorithms: Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery.  RFC 5681 explicitly allows
certain modifications of these algorithms, including modifications
that use the TCP Selective Acknowledgement (SACK) option [RFC2883],
and modifications that respond to "partial acknowledgments" (ACKs
which cover new data, but not all the data outstanding when loss was
detected) in the absence of SACK.  This document describes a specific
algorithm for responding to partial acknowledgments, referred to as
NewReno.  This response to partial acknowledgments was first proposed
by Janey Hoe in [Hoe95].

The purpose of this revision from [RFC3782] is to make errata changes
and to adopt a proposal from Yoshifumi Nishida to slightly increase
the minimum window size after Fast Recovery from one to two segments,
to improve performance when the receiver uses delayed acknowledgments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 24 Jan 2011 20:52:58 +0100

What a coincidence! Just at the moment I wrote my comments about
rfc3782bis, the notification came in...

Here are some ideas for further improvement. I don't feel strongly about any
of the following points, However, IMO RFC3782 is too complicated. RFC2582 is
much easier to understand. Why?
   * The Problem of "Avoiding Multiple Fast Retransmit" is better explain
   * We don't have in every second sentence an ns2 example call

* Sec 1: Lack of a proper problem description

What we have is this (2nd para)

"Problems can arise, therefore, when multiple packets are dropped
from a single window of data and the Fast Retransmit and Fast Recovery
algorithms are invoked."

But is what really the problem? AFAIK, the "original" problem was that Reno
run into an RTO, if we have more than two or three losses in a single window of data.
The main problem (AFAIK) was for example not, that we execute multiple times FRet in
one window (provided that we get enough DUPACKs)

* New Sec between Sec 2 and Sec 3: Basic idea of the algo

I love basic ideas! In that case the reader has some ideas how the algo
works, before he read it step by step.

Here, we could also directly mention that the following step 1), 1b) and 6) 
are require to fix *another* problem that the original one. The first time
I read RFC3782, is was not that easy to figure out that this steps fix another
issue.

* Sec 5: IMO delete it or move it to an appendix.

* Sec 6: Really, really complicated...

Take for example RFC2582 or [GF04] (only the intro). Much easier to understand. With
this two doc, you can understand the problem.

For example:
  - In RFC3782, 1st para: It confused the reader more than it helps. 
  - In RFC3782, 3rd para: Oh my god ;-) Regarding to RFC2582, why do we delete the most
    important sentence here: "Thus with NewReno, the problem of multiple Fast Retransmits
    from a single window of data can only occur after a Retransmit Timeout."

    Say the problem/goal: we want to block a FRet *after an RTO* until we reach recover.
  - In RFC3782, 4th para: It confused the reader more than it helps. Typically, the changes
    between versions are not intermixed with a problem description. Make an own Section where
    we can describe the diffs. BTW, we have already such a section.

* IMO Section 7,8,9,10,11 should move to an appendix

Alex

[GF04]: Resolving Acknowledgment Ambiguity in non-SACK TCP

Am 24.01.2011 um 19:30 schrieb <[email-masked]>
 <[email-masked]>:

> <Mail-Anhang>_______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

//
// 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-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//