Re: (it must be lost)

Matt Crawford <crawdad@munin.fnal.gov> Fri, 14 January 1994 01:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16161; 13 Jan 94 20:24 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16157; 13 Jan 94 20:24 EST
Received: from world.std.com by CNRI.Reston.VA.US id aa22809; 13 Jan 94 20:24 EST
Received: by world.std.com (5.65c/Spike-2.0) id AA01131; Thu, 13 Jan 1994 19:12:17 -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: <crawdad@munin.fnal.gov>
Received: from munin.fnal.gov by world.std.com (5.65c/Spike-2.0) id AA01115; Thu, 13 Jan 1994 19:12:14 -0500
Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA12472 (5.65c+/IDA-1.4.4 for catnip@world.std.com); Thu, 13 Jan 1994 18:10:01 -0600
Message-Id: <199401140010.AA12472@munin.fnal.gov>
To: catnip@world.std.com
Subject: Re: (it must be lost)
In-Reply-To: Your message of Thu, 13 Jan 94 14:04:34 PST. <199401132204.AA17395@remmel.NSD.3Com.COM>
Date: Thu, 13 Jan 94 18:10:00 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Matt Crawford <crawdad@munin.fnal.gov>

> > I would propose "logarithmic" time -> TTL translation; i.e.
> > 
> > 	1/16 sec delay equals 1 hop
> > 	1/8 sec == 2 hops
> > 	1/4 sec == 3 hops
> > 
> > etc.  I'm not sure what the implications of that scheme are.
> 
> Aside from possibly confusing traceroute, this looks ok.

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.

Suppose you make the time -- hop mapping turn linear at some
reasonable point.  Perhaps let each additional second after (32
sec/10 hops) or (64 sec/11 hops) count as an entire hop again.

_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab