I wasn't "there" at the time, but if
----- Original Message -----
From: "Robert Honore" <robert(_at_)digi-data(_dot_)com>
To: "Tony Hain" <alh-ietf(_at_)tndh(_dot_)net>
Cc: <ietf(_at_)ietf(_dot_)org>;
<ipng(_at_)sunroof(_dot_)eng(_dot_)sun(_dot_)com>
Sent: Tuesday, August 26, 2003 12:40 PM
Subject: Re: Solving the right problems ...
Problem is that right now, every time
an application needs such a service, the application programmer must
code his own provisions for it, and none of the propositions I have
seen
discussed so far seems to deal with that.
couldn't have been a quote about congestion control in 1980, I'm
surprised.
And now, of course, we accept that transport layers are responsible
for
congestion control.
This makes me think that having something underneath the application
take
care of multiple interfaces is likely a good idea.
I'd also go farther on Robert's point - if we don't think of something
fairly
quickly, there are likely to be a good number of applications that
expect to
handle multiple intefaces (with varying degrees of skill) lying around
when
we think of something later.
And this seems to me, to be very analogous to firewalls (we "needed"
them
because we didn't have end-to-end security, but once we had them, we
didn't need end-to-end security nearly as badly), NATs (we "needed"
them because we didn't have IPv6, but once we had them, we didn't
need IPv6 nearly as badly), and other sources of architectural
drift...
Spencer