--On Wednesday, 30 April, 2003 21:49 -0700 Spencer Dawkins
<spencer_dawkins(_at_)yahoo(_dot_)com> wrote:
Steve Deering had a nice set of slides in London about the
horrible things that we were doing to "the wasp waist" (IP),
but that doesn't mean that "wasp waists" don't have real
advantages.
We like to say in TSV that having applications handle
congestion control is wrong because if 19 applications out of
20 do it correctly, the guy who hoses it up, hoses it for
everyone.
Although the potential for disaster on interface selection is
limited, what we're trying to do isn't trivial, and the chances
a stack can do a better job than a random application seem
pretty large to me. I'd vote for Stephen's "latter".
Of course, there is an intermediate position (see my note of
several days ago) in which we enable the applications to give
the stack more information about the criteria on which it would
like a selection to be made. It is irrelevant in the "well,
there are three addresses/topology locators/paths, but only one
will connect" case. But, if there are different addresses that
can be used to establish connectivity, and, e.g., some are
faster and higher cost while others are cheaper but are slower
or involve more packet losses, the application is likely to be
in a good position (with or without explicit user input) to know
what will serve its needs best.
john
--- Stephen Sprunk <stephen(_at_)sprunk(_dot_)org> wrote:
Which is harder, having the stack give the app a list of
source and
destination addresses and then expect the app to figure out
which to use, or
have the stack attempt various combinations of source and
destination
addresses and just notify the application which one(s) worked?
Something tells me the latter is both easier and more likely
to be
implemented correctly.