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