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

Fernando Gont <fernando@gont.com.ar> Tue, 13 December 2005 09:56 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6ty-0002fb-6T; Tue, 13 Dec 2005 04:56:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6tw-0002em-FO for tcpm@megatron.ietf.org; Tue, 13 Dec 2005 04:56:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28565 for <tcpm@ietf.org>; Tue, 13 Dec 2005 04:55:55 -0500 (EST)
Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em6ut-0000rO-Ue for tcpm@ietf.org; Tue, 13 Dec 2005 04:57:52 -0500
Received: (qmail 21956 invoked from network); 13 Dec 2005 09:57:18 -0000
Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 13 Dec 2005 09:57:18 -0000
Message-Id: <6.2.0.14.0.20051213012758.048ed298@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 13 Dec 2005 01:34:32 -0800
To: Ted Faber <faber@ISI.EDU>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02
In-Reply-To: <20051212235603.GB1156@hut.isi.edu>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: Lars Eggert <lars.eggert@netlab.nec.de>, tcpm@ietf.org, "mallman@icir.org" <mallman@icir.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>
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At 03:56 p.m. 12/12/2005, Ted Faber wrote:

>If I recall correctly, they do have a min/max kind of set up that
>encourages systems not to push their defaults down.  I can see a good
>argument that UTO negotiation should *never* reduce the default min UTO
>of a system to avoid violating POLA.  Is this restriction what you're
>arguing for, Gorry?  (If so, Lars/Fernando, do you have
>objections/counter-arguments?)

Of the top of my head, I don't recall we proposed any value for the lower 
limit.

Anyway, that's what we had in mind when including the equation for choosing 
the UTO: "As long as it is within acceptable limits, choose the larger of 
the two".

The idea is that if you don't set the UTO explicitly, then your local UTO 
should be set to the default UTO (which may even be larger than the minimum 
allowed UTO, i.e., the lower limit). This means that, your user timeout 
will be, at least, the default. And, at most, that of the upper limit.

If you do set the UTO explicitly (i.e., you know what you're doing), then 
the user timeout will be, at least, that of the lower limit, and, at most, 
that of the upper limit.

(I realize that this is probably not explained in the draft, though).

Does it make sense?

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org






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