[ih] TTL [was Exterior Gateway Protocol]

[vinton cerf]

no disagreement about discard - just that TTL wasn't interpreted as time
but hop count in the implementations with which I am familiar; I am sure we
discussed the possibility of making TTL a real "time to live" but clock
sync and accuracy across the Internet seemed out of reach short of relying
on NTP. When GPS came along that created a possibility of trying to sync
many clocks but I am not aware of any implementations of TTL that used such
a method.

v

On Sat, Sep 5, 2020 at 5:58 PM Jack Haverty <jack at 3kitty.org> wrote:

> I don't know much about RTP, but isn't it a host-host protocol
> communicating using IP datagrams?   So the IP routers don't really
> participate in it (except likely for multicast, which I never worked with).
>
> What I was describing was behavior within the router mesh, where a router
> is permitted to discard a datagram whenever it deems it appropriate to do
> so.  The EGP/IGP structure gave wide leeway for designing and configuring
> the internal mechanisms within any particular AS.   The discussion I recall
> was about how to handle datagrams within a particular AS to get the most
> useful work out of the underlying comm lines.
>
> It was better to discard a datagram as soon as you figured out that it
> wasn't going to be useful.   Making that decision based on TTL and
> information from the routing table state was one possibility.  Another I
> remember was eliminating duplicates, by examing the queues in the router to
> see if the incoming datagram was already there, still waiting to be sent
> out.
>
> That was an expected (and observed) scenario in situations such as a
> router interconnecting a fast LAN to a much slower long-haul net which
> provided back-pressure, e.g., Ethernet to ARPANET.   Queues built up,
> sometimes containing multiple copies of the same datagram.
>
> /Jack
>
> On 9/5/20 2:37 PM, vinton cerf wrote:
>
> i don't think traffic is discarded except for hop count or lack for
> forwarding path unless RTP does something with timers?
>
> v
>
>
> On Sat, Sep 5, 2020 at 5:34 PM Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> 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
>>
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>
>