Re: [tcpm] gen-art review of draft-ietf-tcmp-tcp-uto-09.txt

Lars Eggert <lars.eggert@nokia.com> Fri, 28 November 2008 13:08 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 578C128C0D9; Fri, 28 Nov 2008 05:08:49 -0800 (PST)
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 7B0753A6AAE; Fri, 28 Nov 2008 05:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 EopL5F4SsHYG; Fri, 28 Nov 2008 05:08:47 -0800 (PST)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 577383A6809; Fri, 28 Nov 2008 05:08:47 -0800 (PST)
Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mASD8DYm000775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 28 Nov 2008 15:08:14 +0200 (EET) (envelope-from lars.eggert@nokia.com)
Message-Id: <2F5BD485-E44D-4346-8D21-762C0F42602D@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Scott Brim <swb@employees.org>
In-Reply-To: <20081124164002.GD45553@cisco.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 28 Nov 2008 15:08:13 +0200
References: <20081124164002.GD45553@cisco.com>
X-Mailer: Apple Mail (2.929.2)
X-Virus-Scanned: ClamAV 0.94/8691/Fri Nov 28 02:09:03 2008 on fit.nokia.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Fri, 28 Nov 2008 15:08:17 +0200 (EET)
Cc: General Area Review Team <gen-art@ietf.org>, tcpm@ietf.org, fernando@gont.com.ar, mallman@icir.org
Subject: Re: [tcpm] gen-art review of draft-ietf-tcmp-tcp-uto-09.txt
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: multipart/mixed; boundary="===============0297495912=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Hi, Scott,

thanks for the comments.

On 2008-11-24, at 18:40, ext Scott Brim wrote:
>  - Since a UTO can apparently be sent at any time, what happens if a
>    UTO is received that shortens the timeout and there are
>    unacknowledged packets that are already beyond the new timeout
>    value?

Good point. There are basically two choices: Apply the new UTO already  
to the current timeout event, or start using the new UTO for future  
timeout events. I believe that simply starting to use the new value  
immediately is easiest for implementors, but because reaction to UTOs  
is purely a local thing, I'm not sure if the draft should require any  
specific behavior. We can mention the two choices, if folks think that  
would be useful - tell us.

>  - Is it intended that the ENABLED flag applies to both sending and
>    receiving the UTO?  It seems to be, but I want to be sure.  If
>    that is the intention, could you make it clearer?
>
>    It certainly applies to a received UTO:
>
>      "This adaptation only happens if the other end of the connection
>      has explicitly allowed it (both ENABLED and CHANGEABLE are
>      true)."
>
>    but it seems to apply to sending a UTO as well:
>
>      "Before opening a connection, an application that wishes to use
>      the UTO option enables its use by setting ENABLED to true."

Correct, it applies for both sending and receiving. Can we make this  
clearer in the text somehow?

> (2) Editorial:

I applied all of these in my working copy.

Thanks,
Lars
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm