[ih] TTL [was Exterior Gateway Protocol]

Jack Haverty jack at 3kitty.org
Sat Sep 5 14:58:04 PDT 2020


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
> <mailto: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
>     <mailto:Internet-history at elists.isoc.org>
>     https://elists.isoc.org/mailman/listinfo/internet-history
>




More information about the Internet-history mailing list