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