[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 [127.0.0.1] (localhost [127.0.0.1]) 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 [127.0.0.1]) 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-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [128.214.9.1]) 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 [128.214.166.196]) (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 [127.0.0.1]) 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. 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few edi… Alfred Hönes
- Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few… Ethan Blanton
- Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few… Ethan Blanton
- [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback Markku Kojo
- Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback Randall Stewart
- Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback Randall Stewart