Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback
Randall Stewart <rrs@lakerest.net> Fri, 23 May 2008 19:49 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 94ECD28C2E1; Fri, 23 May 2008 12:49:00 -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 4C11428C2E1 for <tcpm@core3.amsl.com>; Fri, 23 May 2008 12:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 xvcPz8fQqj2Y for <tcpm@core3.amsl.com>; Fri, 23 May 2008 12:48:59 -0700 (PDT)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 221EC28C2A1 for <tcpm@ietf.org>; Fri, 23 May 2008 12:48:57 -0700 (PDT)
Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id m4NJkc4m052486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 May 2008 15:46:38 -0400 (EDT) (envelope-from rrs@lakerest.net)
DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=lakerest; t=1211571998; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=gncNnWoRg3erjkpPSxSMzSfb49+1xvTr9LPPX1cL4tPpQ1W0HhH3hLL ROVrXOcH8LOr3+LpzV5/WKYIvHL4NnQ==
Message-Id: <24EE6FA7-CE4D-406F-8F4E-9A0DA621AB01@lakerest.net>
From: Randall Stewart <rrs@lakerest.net>
To: Markku Kojo <kojo@cs.helsinki.fi>
In-Reply-To: <Pine.LNX.4.64.0805232020450.12576@wrl-76.cs.helsinki.fi>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 23 May 2008 15:46:37 -0400
References: <200805061312.PAA15671@TR-Sys.de> <20080511011107.GA12264@elb.elitists.net> <Pine.LNX.4.64.0805232020450.12576@wrl-76.cs.helsinki.fi>
X-Mailer: Apple Mail (2.919.2)
Cc: Ethan Blanton <eblanton@cs.purdue.edu>, tcpm@ietf.org, vern@icir.org, mallman@icir.org
Subject: Re: [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
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 On May 23, 2008, at 3:38 PM, Markku Kojo wrote: > 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 > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0369 (direct) _______________________________________________ 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