Re: (it must be lost)

Fred Baker <fbaker@acc.com> Fri, 14 January 1994 03:27 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18099; 13 Jan 94 22:27 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18094; 13 Jan 94 22:27 EST
Received: from world.std.com by CNRI.Reston.VA.US id aa24681; 13 Jan 94 22:27 EST
Received: by world.std.com (5.65c/Spike-2.0) id AA14295; Thu, 13 Jan 1994 21:28:37 -0500
Errors-To: catnip-request@world.std.com
X-Orig-Sender: catnip-request@world.std.com
Reply-To: catnip@world.std.com
Precedence: bulk
Return-Path: <fbaker@acc.com>
Received: from fennel.acc.com by world.std.com (5.65c/Spike-2.0) id AA14280; Thu, 13 Jan 1994 21:28:34 -0500
Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA11466; Thu, 13 Jan 94 18:28:16 PST
Message-Id: <9401140228.AA11466@fennel.acc.com>
X-Sender: fbaker@fennel.acc.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Jan 1994 18:28:43 -0800
To: catnip@world.std.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Subject: Re: (it must be lost)

>If I have to send my traffic with an initial TTL of 40 or more to get
>across the diameter of the net, and if "etc" denotes an unbounded
>geometric progression, my packets could sit in various queues for
>literally hours before delivery.

I have a suggestion: why don't we turn this on its head?

This, BTW, is not an original suggestion with me, I read it in a
specification in 1981 for an otherwise
not-politically-correct-and-so-I-won't-name-it internet protocol.

Suppose that we say, by divine fiat, that it is not legal for a router to
hold a message longer than some period of time, say six seconds or
something outrageous like that.

If you put an initial TTL of 40 in the packet, the "time" to live is now
40*6=240 seconds. If by dint of much effort and great creativity some
router manages to forward it in only two seconds, or two milliseconds, the
next router still has no more than six seconds to queue it. This solves the
TCP lifetime problem without actually having to interpret hops as time.

The problems with interpreting TTL as "time to live" rather than "visit
count" are:

      - you wind up wanting to decrement by more than one in some cases, and
        that can get painful, which is why no-one-or-at-least-not-very-many
        actually do it. The Router Requirements Draft, last I checked, said
        "TTL is visit count."

      - You have lots of arguments like this one, and they don't go away

      - And BTW, read RFC 970, "on packet switches with infinite storage", for
        a problem created by considering TTL as time.

      - If TTL is itself time, then the time unused in one switch is available
        to the next - If I say "time this packet out after 60,000 milliseconds"
        and the first 58 hops each take 10 milliseconds, the 59th hop has
        59.480 seconds to toy it - not at all what was intended.

But putting an upper bound on a single queue delay allows everyone to
decrement by one, gives everyone a reasonable period to deal with it,
guarantees a maximum lifetime, and doesn't incur Nagle's problem.

=============================================================================
                        "In sound wisdom there are two sides"
                                        Bildad, Job 8