Re: [tcpm] draft-ietf-tcpm-tcp-uto-02

Fernando Gont <fernando@gont.com.ar> Thu, 21 September 2006 15:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQ5L-0000oP-CP; Thu, 21 Sep 2006 11:03:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQ5K-0000oE-AF for tcpm@ietf.org; Thu, 21 Sep 2006 11:03:30 -0400
Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQQ58-00072S-Fb for tcpm@ietf.org; Thu, 21 Sep 2006 11:03:30 -0400
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A6684115BAF7; Thu, 21 Sep 2006 12:06:48 -0300 (ART)
Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8LF310d028042; Thu, 21 Sep 2006 12:03:01 -0300
Message-Id: <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 20 Sep 2006 17:23:44 -0300
To: gorry@erg.abdn.ac.uk, gorry@erg.abdn.ac.uk
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02
In-Reply-To: <45116707.9050301@erg.abdn.ac.uk>
References: <BF9BD734.4234%gorry@erg.abdn.ac.uk> <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: Lars Eggert <lars.eggert@netlab.nec.de>, tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Gorry,

Thanks so much for your comments. You'll find my responses inline....


>It seems you have responded to most (if not all) my substantial 
>comments,  and also tightened the
>language, I like these improvements, and to me, this seems much 
>safer in this respect.
>
>I would like to check one point:
>Section 3.1:
>
>/Very short user timeout values can affect TCP transmissions over
>high-delay paths.  If the user timeout occurs before an
>acknowledgment for an outstanding segment arrives, possibly due to ..../
>
>- This rev of the draft also includes a change to mandate 
>the  minimum value to be at least the RTO value, which should at 
>least help in this case?

Agreed. However, the document argues to enforce a minimum *L_LIMIT* 
value of at least one RTO, with L_LIMIT being a parameter of the 
RECOMMENDED (ie, not mandatory) scheme for selecting the user timeout.

So two possible ways to fix this would be:

a) State that the minimum allowed value for the user timeout is one 
RTO (in any case.... not just in the recommended scheme)
b) Make the recommended scheme mandatory.

I would personally argue in favour of (a). But well, opinions are welcome.




>End of section 1:
>
>I think phrase below is good guidance, but could be strengthened:
>/If such a system-wide toggle were provided, it would default to "off".
>
>Perhaps some text something like:
>
>An implementation that provides a system-wide toggle, should assign 
>the default value to disable this feature.

How about:
"An implementation that provides a system-wide toggle, SHOULD assign 
the default value to disable this feature"
(ie, RFC2119 speak)



>/It must be noted that the two endpoints of the connection will not
>necesarilly adopt the same user timeout./
>
>- Could be better worded, but agreed.

Any suggestions?

Thanks so much!

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm