[net.mail.headers] loop detection by hop count

POSTEL@USC-ISIB.ARPA (02/17/86)

I think that loop detection by hop count is a bad idea.  The problem
is that it will work for awhile, until we have forgotten all about it,
then some messages that ought to go through won't.  The world will get
bigger, and what was once a reasonable choice for "max hops" will be
smaller than the diameter of the mail world.

--jon.

-------

milazzo@rice.ARPA (Paul Milazzo) (02/18/86)

Jon Postel writes:

        "The problem is that [loop detection by hop count] will work
        for awhile, until we have forgotten all about it, then some
        messages that ought to go through won't."

Well, I've seen some amazingly long UUCP paths recently, and that they
will get longer still seems difficult to contest.  However, the same
objection can be made to dropping packets with TTL <= 0, and the
interim solution of increasing the hop count threshold can be pushed
rather a long way.

More importantly, however, the original topic was loop detection in
*mailing lists*, and there the hop count mechanism is completely
inappropriate.  With a hop count of 30 and a queue interval of 10
minutes, a loop in a piece of personal mail will be broken within five
hours.  The same is true of a mailing list, save for a small side
effect:  as many as 30 copies of the message might be mailed to
thousands of list recipients.

In short, since even one duplicate of a mailing list message represents
an enormous waste of resources, distribution list software should
employ algorithms which can detect a loop on the first iteration.

				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX
Domain:	milazzo@rice.EDU
BITNET:	milazzo@ricenet, milazzo@ricecsvm
UUCP:	{cbosgd,convex,hp-pcd,sun,ut-sally,waltz}!rice!milazzo