[ih] TTL [was Exterior Gateway Protocol]

[Jack Haverty]

Unfortunately I can't remember where or when that discussion happened.  
It might have been in some meeting not involved in RTP, but perhaps
thinking about how to make the underlying gateway system more efficient
by discarding useless datagrams as soon as possible.  The "meeting" I
remember might even have been in a hotel bar or some restaurant. 

I remember that TCP was split apart to create TCP/IP, in order to permit
the creation of UDP, which was done to provide application access to a
more basic datagram service in addition to TCP's virtual circuit
service, for scenarios such as packet voice.   That split motivated
subsequent thinking about how to deal in the gateways with the different
traffic requirements, using the information provided by IP fields such
as TOS and TTL.  

E.g., if a gateway received a packet with a TTL that it knew, from its
routing tables, could not be delivered to the ultimate destination "in
time", then it was advantageous to throw it away right then, even though
the TTL was still non-zero.   That kind of discussion may not have
overlapped much with the RTP community.

I wonder if today's routers behave that way...?

/Jack

On 9/5/20 2:06 PM, Stephen Casner wrote:
> On Sat, 5 Sep 2020, Jack Haverty via Internet-history wrote:
>
>> 4/ TTL was also intended for use with different TOS values, by the
>> systems sending voice over the Internet (Steve Casner may remember
>> more).  The idea was that a packet containing voice data was useless if
>> it didn't get to its destination in time, so TTL with a "fastest
>> delivery" TOS enabled the sender to say "if you can't deliver this in
>> 200 milliseconds, just throw it away and don't waste any more
>> bandwidth".   That of course wouldn't work with "time" measured in hops,
>> but we hoped to upgrade soon to time-based measurements.
> I don't recall any discussion of that idea while we were developing
> RTP.  As you say, the units being in hops rather than time would make
> this mechanism imprecise, and the variability in the diameter of the
> network would make it hard to use.  Multicast complicates that even
> further.
>
>                                                         -- Steve