[tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback

Markku Kojo <kojo@cs.helsinki.fi> Fri, 23 May 2008 19:38 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 [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 6DF1228C2A1; Fri, 23 May 2008 12:38:35 -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 D96E728C287 for <tcpm@core3.amsl.com>; Fri, 23 May 2008 12:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2fOh7r8L+DbM for <tcpm@core3.amsl.com>; Fri, 23 May 2008 12:38:33 -0700 (PDT)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi []) by core3.amsl.com (Postfix) with ESMTP id A47E228C127 for <tcpm@ietf.org>; Fri, 23 May 2008 12:38:32 -0700 (PDT)
Received: from wrl-76.cs.helsinki.fi (wrl-76.cs.helsinki.fi []) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 23 May 2008 22:38:27 +0300 id 00087BFB.48371D33.00006322
Received: by wrl-76.cs.helsinki.fi (Postfix, from userid 3011) id B52183444B; Fri, 23 May 2008 22:38:27 +0300 (EEST)
Received: from localhost (localhost []) by wrl-76.cs.helsinki.fi (Postfix) with ESMTP id B20863401C; Fri, 23 May 2008 22:38:27 +0300 (EEST)
Date: Fri, 23 May 2008 22:38:27 +0300
From: Markku Kojo <kojo@cs.helsinki.fi>
To: tcpm@ietf.org
In-Reply-To: <20080511011107.GA12264@elb.elitists.net>
Message-ID: <Pine.LNX.4.64.0805232020450.12576@wrl-76.cs.helsinki.fi>
References: <200805061312.PAA15671@TR-Sys.de> <20080511011107.GA12264@elb.elitists.net>
Mime-Version: 1.0
Cc: Ethan Blanton <eblanton@cs.purdue.edu>, vern@icir.org, mallman@icir.org
Subject: [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback
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-Archive: <https://www.ietf.org/mailman/private/tcpm>
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

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.


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

         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


tcpm mailing list