[tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few editorials

Alfred Hönes <ah@tr-sys.de> Tue, 06 May 2008 13:13 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from core3.amsl.com (localhost []) by core3.amsl.com (Postfix) with ESMTP id 558B628C13A; Tue, 6 May 2008 06:13:33 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 1F4383A6FDD for <tcpm@core3.amsl.com>; Tue, 6 May 2008 06:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.251
X-Spam-Level: *
X-Spam-Status: No, score=1.251 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id t-S4caWGPho9 for <tcpm@core3.amsl.com>; Tue, 6 May 2008 06:13:23 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de []) by core3.amsl.com (Postfix) with ESMTP id D180528C388 for <tcpm@ietf.org>; Tue, 6 May 2008 06:13:11 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: $/16.3) id AA181579561; Tue, 6 May 2008 15:12:41 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA15671; Tue, 6 May 2008 15:12:39 +0200 (MESZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200805061312.PAA15671@TR-Sys.de>
To: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu
Date: Tue, 06 May 2008 15:12:39 +0200
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Cc: tcpm@ietf.org
Subject: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few editorials
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Taking another round on the updated 2581bis draft,
and reconsidering the flow of arguments, I found a few
small editorial issues that still could/should be improved.

(1)  Section 1, 2nd paragraph

Typo:   s/in turned/in turn/

(2)  Section 1, 3rd paragraph

The first paragraph names the four 'classical' congestion control
algorithms.  The third paragraph resumes the discussion, and
arguably the algorithm for restarting after a long idle period
could be conceived as a fifth congestion control algorithm.
The draft does not do that explicitely, and I do not request that.
But to make the reasoning more clear, I suggest to replace "the"
by "these" in the first line of the third paragraph:

    In addition to specifying the congestion control algorithms, this
    document specifies what TCP connections should do after a relatively
    long idle period, [...]
---                              vv
|   In addition to specifying these congestion control algorithms, this
    document specifies what TCP connections should do after a relatively
    long idle period, [...]

(3)  Section 1, 4th paragraph

I do not have at hand the particular editions of the
"TCP/IP Illustrated" books refered to by [Ste94] and [WS95],
but I have concerns regarding whether or not these good old opusses
in fact do precisely reflect the significantly updated recommendation
given in the last paragraph of Section 4.1, namely to return to slow
start after an idle period if "TCP has not *sent* data in an interval
exceeding the retransmision timeout".  (emphasis added)

The current position of this 4th paragraph in Section 1, below the
'announcement' of the 'after-idle-restart' algorithm might lead the
reader to the conclusion that these books already contain, and show
the implementation of, this revised algorithm.

If that is not true, and to avoid this possible misconception,
it would perhaps be wise to shuffle the paragraphs in Section 1
to position the current 4th paragraph immediately below the first
paragraph.  (On this case, the change in item (2) above becomes even
more important for clarity.)

(4)  Section 1 -- further re-shuffling

During the above considerations I got the impression that it also
might be prudent for the sake of clarity in the reasoning to move
the second paragraph, "This document obsoletes ..." to behind the
three paragraphs dealing with the prevalent components of the
document, to immediately above the second-to-last paragraph,
"This document is organized as follows. ..."

In other words: Taking (3) and (4) together, my net recommendation
is to swap the second and the fourth paragraph in Section 1.

(5)  Section 3.1 -- additional instance of clarification

Subsidiary to one of the recent clarifications adopted by the
draft in a couple of places, I suggest once more to re-state that
clarification of "outstanding" immediately below formula (4),
e.g. by changing:

    where, as discussed above, FlightSize is the amount of outstanding
    data in the network.
    where, as discussed above, FlightSize is the amount of outstanding
    (i.e., not yet cumulatively acknowledged) data in the network.

(6)  Section 6

I suggest to harmonize the text, generally talking about RFC 2581
in past tense.  To this end, please change:

         ...  The intention of [RFC2581] is to not change ...
         ...  The intention of [RFC2581] was to not change ...

Kind regards,


| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |

tcpm mailing list