Re: TTL Uses ???

Steve Deering <deering@parc.xerox.com> Fri, 14 January 1994 19:01 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10993; 14 Jan 94 14:01 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10987; 14 Jan 94 14:01 EST
Received: from world.std.com by CNRI.Reston.VA.US id aa16787; 14 Jan 94 14:01 EST
Received: by world.std.com (5.65c/Spike-2.0) id AA02339; Fri, 14 Jan 1994 12:36:56 -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: <deering@parc.xerox.com>
Received: from alpha.Xerox.COM by world.std.com (5.65c/Spike-2.0) id AA02322; Fri, 14 Jan 1994 12:36:53 -0500
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14779(2)>; Fri, 14 Jan 1994 09:36:28 PST
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 14 Jan 1994 09:36:20 -0800
To: bound@zk3.dec.com
Cc: catnip@world.std.com, deering@parc.xerox.com
Subject: Re: TTL Uses ???
In-Reply-To: bound's message of Fri, 14 Jan 94 07:52:35 -0800. <9401141552.AA18732@xirtlu.zk3.dec.com>
Date: Fri, 14 Jan 1994 09:36:14 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <94Jan14.093620pst.12171@skylark.parc.xerox.com>

> Can anyone list the internet apps that depend on TTL or actually look at
> from the IP datagram?  
> 
> Here are some purely guesses:
> 
> traceroute
> tcpdump
> netstat

Jim,

IP multicast applications use the TTL field to limit the transmission
distance of multicast packets.  Combined with "TTL thresholds" in the
multicast routers on the boundaries of administrative domains, this
provides a very useful scoping function for multicasts.  Note, however,
that this is third function overloaded onto TTL (along with loop-breaking
and maximum-lifetime enforcement), and it is an ugly hack.  The right way
to accomplish the scoping function, in my opinion, is through the
multicast addressing, and therefore SIPP multicast addresses have
an explicit scope subfield.  We did not do that for IP because the
28-bits of address space available for IP multicast addresses is too
small to afford the wastage of substructuring.

Even with scoped multicast addresses, applications might still want to
use the TTL for fine-grain limiting of multicast propagation distance,
for example, for performing an "expanding ring search" (e.g.., initiate
a search for a resource by sending a multicast with TTL 1, then 2, 4, ...
until an answer is received or a miximum search diameter is exceeded).

> I am still wondering also if TCP connects are only depending on the fact
> that ICMP time exceeded/datagram dropped or watching the TTL timer?
> 
> In all this theory it just dawned on me to check how much pain re
> porting apps will be caused by this???

Don't worry about it.  Almost all current IP routers treat the TTL field
simply as a hop count, and not very many people are losing sleep over that.
If it should become a serious concern, the right place to fix it is in
TCP, as Robert said.  TCP doesn't trust IP to deliver its packets in
order, unduplicated, or undamaged; why whould it trust it to limit
their lifetimes?  The problem is easy to fix in TCP with bigger sequence
numbers or timestamps, but impossible to solve in IP (because IP can run
over arbitrary subnetworks and it cannot always know, learn or limit the
length of time it takes a packet to traverse one of those subnetworks).

Anyway, the IPng Directorate should be delighted to see that CATNIP, SIPP,
and TUBA have all converged on an 8-bit hop-limit field.  :-)

Steve