Re: Proxies and loops

First, I apologize for jumping into the middle of this thread.  I'd like
to make a couple of comments about how TTL and Forwarded are relevant
to the Harvest cache.

>    The Forwarded: header can actually be used to detect loops. However,
>    
>    * it is not compulsory (although a node willing to avoid loops will
>      certainly insert it and detect the loop);
>    * in principle, it does not prevent the occurrence of arbitrarily
>      long paths (although a node can decide not to pass a request which
>      has been "Forwarded:" too many times);
>    
>    and these reasons make me like better the use of a *compulsory*
>    TTL field as a loop detector (which is also simpler to manage).
>
>When I first read your proposal for a TTL field, I had the same
>reaction that Roy seems to have had: this isn't really necessary.
>The Forwarded: header allows any proxy to detect loops through
>itself, and can support that task without being mandatory.
>
>And do we have any evidence that forwarding loops are a real problem?
>Routing loops occur because our routing protocols are automatic and
>dynamic, and so can do stupid things rapidly and for transient periods.
>HTTP forwarding loops, on the other hand, would be created by humans
>and should thus be both less frequent and less transient.

I think that HTTP forwarding loops may become a real problem.  As
we have been getting our six national caches (http://www.nlanr.net/Cache/)
operational the past few weeks, forwarding loops were unintentionally
created due to a bug in the software.  But I doubt that such bugs
will often be the cause of forwarding loops.  Rather they will be due
to configuration errors.

For now HTTP cache configuration is a fairly manual process, but I 
doubt it will remain so.  I can already see the need for a cache
to have a default "next hop" with the ability to switch to an
alternate next hop if the default becomes unavailable.

A TTL header would not help Harvest to eliminate loops.  When the
loop is completed and the cache gets a second request for the same URL,
this second client-side request becomes "attached" to the first request
(on the server-side).  The caches will deadlock until one of them times
out.  The forwarded header would solve this problem quite easily
(except for the hassle of parsing it).


>However: after I thought about this some more, I realized that there
>is an entirely different reason to include a TTL header in HTTP.
>
>There are two main uses for the TTL field in IP headers: first,
>to avoid routing loops and long-delayed packets.  Second, to make
>"traceroute" work.  I would bet that most TTL "failures" in today's
>Internet are from traceroute users, not routing loops.
>
>Traceroute has proved to be an essential tool in debugging IP-level
>problems.  We ought to be thinking about providing analogous debugging
>tools at the HTTP level.  For example, "how come the users on my

I totally agree that a HTTP-traceroute will be very useful.  However, I
don't think we need TTL to do it.  If I understand correctly,
traceroute uses increasing TTLs because the IP LSRR option is/was not
always implemented, and the fixed IP header size limit only allowed
something like nine addresses to be recorded.  Since HTTP doesn't
suffer from either of those problems, wouldn't it be better to just
have the Forwarded lines included in the response header?  Then you
only need to make one request.

Duane W.

Received on Sunday, 17 December 1995 02:10:34 UTC