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

From: Alfred Hönes <[email-masked]>
Date: Tue, 6 May 2008 15:12:39 +0200 (MESZ)

Taking another round on the updated 2581bis draft,
    draft-ietf-tcpm-rfc2581bis-04,
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,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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:  [email-masked]                     |
+------------------------+--------------------------------------------+

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

---

From: Ethan Blanton <[email-masked]>
Date: Thu, 8 May 2008 18:55:58 -0400

> small editorial issues that still could/should be improved.

Alfred,

Thank you very much for taking the time to review this document again.
Your comments look eminently reasonable; we will consider each of them
individually and get back to you (and the WG) with the changes soon.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Ethan Blanton <[email-masked]>
Date: Sat, 10 May 2008 21:11:08 -0400

Alfred,

The following are our responses to your comments.  If there are no
remaining technical issues with this document, we consider it
finished.

Thank you for your input.

Ethan

> Typo:   s/in turned/in turn/

Fixed.

>     document specifies what TCP connections should do after a relatively

Changed.

> is to swap the second and the fourth paragraph in Section 1.

Changed.

>     (i.e., not yet cumulatively acknowledged) data in the network.

This remains unchanged.  We feel it is clear enough as written,
particularly in conjunction with other TCP documents.

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

Somewhat more extensive changes were made here.  The paragraph in
question now reads:

    [RFC2001] was extensively rewritten editorially and it is not
    feasible to itemize the list of changes between [RFC2001] and
    [RFC2581]. The intention of [RFC2581] was to not change any of the
    recommendations given in [RFC2001], but to further clarify cases
    that were not discussed in detail in [RFC2001]. Specifically,
    [RFC2581] suggested what TCP connections should do after a
    relatively long idle period, as well as specified and clarified
    some of the issues pertaining to TCP ACK generation.  Finally, the
    allowable upper bound for the initial congestion window was raised
    from one to two segments.

---

From: Markku Kojo <[email-masked]>
Date: Fri, 23 May 2008 22:38:27 +0300 (EEST)

I finally took a closer look into the latest version of 
rfc2581bis. It seems to me that it sufficiently covers 
the earlier explicit comments that I made, including the 
usage of FlightSize in equation 4 when limited transmit is
in use.

It seems, however, that using FlightSize as defined in 
the document still is problematic also in other cases
where the actual amount of outstanding data in the network
differs from FlightSize as I originally hinted.

Example scenario:

TCP sender is in normal state and cwnd = FlightSize = 16 MSS.
First two segments in the window are lost, no other data
or ACK segments are lost.

1) On the arrival of 1st and 2nd dupack, the TCP
   sender transmits a new data segment on each dupack

   FlightSize = 18

2) When the 3rd dupack arrives:
     1st unacknowledged segment is fast rexmitted
     ssthresh <- 8, cwnd <- 11

3) On arrival of each subsequent dupack cwnd is increased:
     after 5 additional dupacks have arrived, TCP sender
     starts injecting new data segments in to the network,
     one data segment on each subsequent dupack

     This inflates FlightSize

4) After all 16 dupacks have arrived -> FlightSize = 24

5) Cumulative Ack for fast rexmitted segment arrives:
     cwnd <- ssthresh = 8, FlightSize = 23, but
     the correct estimate of outstanding segments in the
     network is 8 (or 10 if we consider that the rexmitted
     segment and the 2nd lost segment are still in flight)
      
6) RTO expires for the 2nd lost segment (which is now the
   first unacknowledged segment):

     According to equation 4 TCP sender calculates new
     value for ssthresh

        ssthresh <- 23/2

     yielding new ssthresh > current ssthresh which
     is not correct, I think.

Alternatively:

6) The eight new data segments transmitted during the fast 
   recovery will trigger further dupacks (8 dupacks):
     if the 3rd dupack arrives before RTO expires, TCP 
     sender enters fast retransmit again and

         ssthresh <- ~11, cwnd <- ~14  
      
   When the cumulative Ack for the 2nd rexmitted segment
   arrives

         cwnd <- ssthresh = 11

   which again is more than allowed.

In addition to the example given above and in general, 
using FlightSize in equation 4 potentially yields wrong 
outcome if TCP sender is in an earlier loss recovery
when RTO expires - either in Fast Recovery or in RTO 
recovery and RTO expires for another segment (not for the 
same RTO-ed segment).

The current text in the document 

 "When a TCP sender detects segment loss using the retransmission
  timer and the given segment has not yet been retransmitted, the
  value of ssthresh MUST be set to no more than the value given 
  in equation 4: 

        ssthresh = max (FlightSize / 2, 2*SMSS)      (4)"

literally prevents the TCP sender from using the equation 4
for such cases (RTO on fast rexmitted segment or RTO on
segment rexmitted during RTO recovery), but I think this
was not the original intent for the text modification 
from RFC 2581. Instead, the intent was to preclude the use 
of equation 4 only when RTO expires again for the RTO-ed
segment. 

Thanks,

/Markku

---

From: Randall Stewart <[email-masked]>
Date: Fri, 23 May 2008 15:46:37 -0400

Markku:

You are a bit late...

RFC4960 is long out...

We are no longer in a BIS period...

I will look at your comments ... but thats my first off the cuff
response ...

R

> of equation 4 only when RTO expires again for the RTO-ed

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0369 (direct)

---

From: Randall Stewart <[email-masked]>
Date: Fri, 23 May 2008 15:48:12 -0400

Never mind..

I see you are not talking about RFC2960.. but 2581.. opps..

Hmm.. I wonder why my filter did not send this to my tcpm box..

Never mind my previous response :-0

R