Thus spake "Keith Moore" <moore@cs.utk.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? 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