A side comment independent of the site-local discussion.
Thus spake "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
nope, the app. the stack doesn't know whether the app
prefers stability
or efficiency, unless the app tells it which it prefers.
but at least
the app probably has an idea which one is better.
The app developer often doesn't know these things either --
if the app
understands this new API at all, I think it'd most often end
up as a user
knob, meaning we could just call it a stack option and leave
the app out of
things entirely.
this is fundamentally different than expecting either the
host or the app
to choose between multiple source or destination addresses, each
pair imposing apparently (to the host and app) arbitrary
constraints
on what the network will pass.
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?
=> There is another option: _Abstract_ the API to the app
to reflect the "benefits" or "meaning" of either option. For instance,
if you compare the MIP home address and CoA, you can abstract
the meaning of these addresses to indicate things like whether
the connection needs to be "stable" or not. There are other
cases where the stack might already know what a well-known
app might need. So there maybe a need for both sides to
provide input. And things get more complex of course when
the app has many requirements.
If we have to make a general rule then I'd prefer the
app to decide. But I'm not sure that there is a need
for a general rule here.
Hesham
Something tells me the latter is both easier and more likely to be
implemented correctly.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to
majordomo(_at_)sunroof(_dot_)eng(_dot_)sun(_dot_)com
--------------------------------------------------------------------