Re: TTL etc Fri, 14 January 1994 00:02 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa15640; 13 Jan 94 19:02 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15635; 13 Jan 94 19:02 EST
Received: from by CNRI.Reston.VA.US id aa21519; 13 Jan 94 19:02 EST
Received: by (5.65c/Spike-2.0) id AA17039; Thu, 13 Jan 1994 18:21:19 -0500
Precedence: bulk
Return-Path: <>
Received: from by (5.65c/Spike-2.0) id AA17023; Thu, 13 Jan 1994 18:21:16 -0500
Received: from by (5.65/13Jan94) id AA25072; Thu, 13 Jan 94 15:18:29 -0800
Received: by; id AA01386; Thu, 13 Jan 1994 18:18:28 -0500
Message-Id: <>
Subject: Re: TTL etc
In-Reply-To: Your message of "Thu, 13 Jan 94 15:12:54 EST." <>
Date: Thu, 13 Jan 94 18:18:22 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
X-Mts: smtp

Rob or Vadim,

Glad you guys have this transport details down.  Please bear with me
because I think this discussion is important for IPng in general per the
TTL field being used as a hop count or time field.

If at FDDI speeds the sequence number will wrap anyway if your going to
continue.  If it comes back 360 degrees late (was not discarded) I am
not clear why that would matter because each connection has its own
state.  So I am unclear why the sequence number is an issue for TTL in
the IP datagram?

I still think the problem should be solved at the transport.  Maybe the
link layer needs to await those packets that the transport layer has
decided are dead and reject them when they come in to throw out a real
strange solution.