On Wed, 17 Jun 1998 [email protected] wrote:
> The concept of reserving bandwidth or guaranteeing delay
> via RSVP is one of the silliest to grace the IETF (and
> a lot of silly ideas appear in the IETF forum viz
> <A HREF="http://members.aol.com/Telford001/#CLASS">"Who is Telford?"</A>).
Cute page! I admire your passion, but I can't say that I agree that
RSVP is a silly concept. Perhaps it is not a terribly scalable/widely
applicable solution to most problems but...
> But I cannot imagine taking bandwidth or latency reservations
> seriously in the context of noisy links.
On the contrary, imagine this (slightly contrived but important example):
I've got a noisy/lossy link (very possible) *and* I'm taking pains to
make the most of my link capacity/performance; the very *last* thing
that I want in a long-delay environment is a congested router downstream
from my noisy link tossing my segments on the machine room floor...
If I've got a dozen of terrabytes of geological data blazing a
trail from a ship or a satellite, I'd rather *not* have to worry
about congestion on the path. Take away the noisy link and
eliminating congestion-based losses on long-delay paths is still
a good idea.
Further, with RSVP (or something conceptually similar), I can consider
doing things with rate-control, and dealing with loses without worrying
about the ambiguities of whether segments were lost because of congestion
or corruption, etc.
So, while RSVP *may* be an inappropriate solution for many situations,
it is a good part of some important point-solutions.
(Splitting the connection is another, but not mutually exclusive
approach to such a situation - but once again, that would cause
this thread to redirect once more)
Best Regards,
Eric
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST