Re: network controls are necessary

["Joel M. Halpern" <joel@stevecrocker.com>]

Thinking about this question (of what the host might know / want) I think 
that there are several things that should be teased apart:

1) The address pair does not work because there really is no connectivity 
over that path.  In that case, presumably routing will catch up pretty 
quickly.  In the mean time, it is probably unlikely that trying random 
combinations will produce better results.

2) The "doesn't work" is in some sense other than connectivity.  This has 
been alluded to by some folks in the discussion.  Trying to get some kind 
of service behavior out of address selection is clearly a matter of using 
the wrong tool for the wrong problem.

3) There is a corner case of some unusual failure that means that some 
locator for the remote host is not useable, but still appears fine in 
routing.  The mechanisms for resolving locators ought to deal with that, 
not the connecting host.

For clarity, I would actually prefer to have the hosts have nothing at all 
to do with the locator selection.  The host may need a mechanism to say 
"this communication appears not to be working" to cause the routing system 
to take appropriate local steps.

Yours,
Joel M. Halpern

At 11:05 AM 12/6/2002 -0500, Bill Sommerfeld wrote:
> > If we really want the hosts to make the choice (a concept I am doubtful 
> of)
> > I suppose we could invent a query / response protocol for the purpose of
> > asking a routing intelligent server what source /dest pair from a given 
> set
> > of sources and dests would be a good pair to use.
>
> one problem with that interface is that if the host determines that
> the recommended address pair doesn't work and wants to try something
> else, it has no idea whether to blacklist the source, the destination,
> or both, when it next asks.
>
> and it would be good for scalability if the host could know when it
> was appropriate to cache the results.
>
>                                                 - Bill