Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01
Yuchung Cheng <ycheng@google.com> Wed, 13 April 2011 19:48 UTC
Return-Path: <ycheng@google.com>
X-Original-To: tcpm@ietfc.amsl.com
Delivered-To: tcpm@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F45EE07CB for <tcpm@ietfc.amsl.com>; Wed, 13 Apr 2011 12:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.977
X-Spam-Level:
X-Spam-Status: No, score=-107.977 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2olLIYPg2mI2 for <tcpm@ietfc.amsl.com>; Wed, 13 Apr 2011 12:48:37 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id 3067EE083D for <tcpm@ietf.org>; Wed, 13 Apr 2011 12:48:37 -0700 (PDT)
Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p3DJmZgj020526 for <tcpm@ietf.org>; Wed, 13 Apr 2011 12:48:36 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302724116; bh=bqgxJkXXy4vI+sny+qovHAB1Vok=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=fSFK6eyfos0SLVCUXe8Tc/udomogFSvQx0abLPGjPs8caVWDRics462gxxju+z5h8 zx1+bPoErkS3gu7Sew8ZQ==
Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by kpbe20.cbf.corp.google.com with ESMTP id p3DJlXo8018621 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tcpm@ietf.org>; Wed, 13 Apr 2011 12:48:34 -0700
Received: by gxk8 with SMTP id 8so515407gxk.23 for <tcpm@ietf.org>; Wed, 13 Apr 2011 12:48:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=xDfA+0JVx6gxirKlEE4ww9CLpiZ8Eu9u5BWy0AJEyIs=; b=Ezr71Sak1Zy9mVoZjvXVW7D/3+3qRuwUMeOLsItX3kHilVn6d47ZPj6bWOuFIrt+L0 H5+PTsfObNcOe/MI+0fQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=xAArSj7PTI4/UomI4c3ovaSAv7f5dteGqNgXUVI1CGNJM0Y40Wo1BeA5PsPFp3DzgJ Y/SkhKVGKGv7x1wYXVqw==
Received: by 10.150.182.12 with SMTP id e12mr824994ybf.389.1302724114122; Wed, 13 Apr 2011 12:48:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.109.8 with HTTP; Wed, 13 Apr 2011 12:48:14 -0700 (PDT)
In-Reply-To: <20110413182449.GA4240@colt>
References: <20110413182449.GA4240@colt>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 13 Apr 2011 12:48:14 -0700
Message-ID: <BANLkTi=c80RgQFdXj=Bx5Gpd3RHQRCX9=Q@mail.gmail.com>
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 13 Apr 2011 19:48:38 -0000
Hi Ethan, I have two questions: 1) IsLost (SeqNum): This routine returns whether the given sequence number is considered to be lost. The routine returns true when either DupThresh discontiguous SACKed sequences have arrived above 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence numbers greater than 'SeqNum' have been SACKed. Otherwise, the routine returns false. Does RFC require DupThresh discontinuous sack blocks? e.g., For example, if a sender sends 4 data packets send pkt1: 1-100 send pkt2: 101-200 send pkt3: 201-300 send pkt4: 301-400 receive ack: ack1 with one sack block 101-400. does IsLost(1) returns true? 2) If the incoming ACK is a duplicate acknowledgment and the TCP is not currently in loss recovery, the TCP MUST increase DupAcks by one and take the following steps: (1) If DupAcks >= DupThresh, go to step (4). (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns true---indicating at least three segments have arrived above the current cumulative acknowledgment point, which is taken to indicate loss---go to step (4). can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is true. I guess it depends on your answer of my first question. Thanks, Yuchung
- [tcpm] Comments on draft-blanton-tcpm-3517bis-01 Ethan Blanton
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Yuchung Cheng
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Mark Allman
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Ilpo Järvinen
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Ethan Blanton
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Mark Allman
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Ilpo Järvinen
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Yuchung Cheng
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Ethan Blanton
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Yuchung Cheng
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Alexander Zimmermann
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Scheffenegger, Richard
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Markku Kojo
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Alexander Zimmermann
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Mark Allman
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Alexander Zimmermann
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Ilpo Järvinen
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Anantha Ramaiah (ananth)
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Mark Allman
- [tcpm] Comments on draft-blanton-tcpm-3517bis-01 Matt Mathis
- Re: [tcpm] Comments on draft-blanton-tcpm-3517bis… Matt Mathis