My understanding is that RSVP is targeted to solve the problem of offering
services such as audio/video conferencing, audio/video streaming such as
radio/television, and telephony services on the Internet and private
networks that use IP.
A "problem to start with" is offering these services in the current
Internet does not yet work.
Um, this comes as a bit of a surprise to me.
My understanding of why I'm glad Sprint is participating in the VON
coalition is that telephony services on the Internet *do* work,
proof by existence. The services are not optimal, but they are
no longer toys, either.
Moreover, the various people doing audio and video things
are not going to be in the realm of "interesting experiments"
forever, and hopefully not for very long.
RSVP is not a gating requirement, nor is it a magic bullet.
The key factors in making any point-to-point realtime services
available in the short run are: 1/ adequate response to congestion
on the part of the transmitter (i.e., back off when acks are delayed
and slow-start when they're missing, just like TCP only without
the retransmissions), 2/ infrastructure improvement, notably
i: better buffering and buffer-management in routers, so that
delayed acks can be seen at all, rather than the chronic loss
we experience now, ii: more bandwidth, iii: more routing stability,
to eliminate the worst problems associated with flutter and
fluctuation, 3/ software software software, to make point-to-point
realtime easy and cheap to use, and to more useful (for instance,
by letting IP networks carry PBX-to-PBX voice as a voice-network
bypass, or having means to allow someone with an Internet-connected
computer call out to someone with POTS, or vice-versa, at roughly
local rates), 4/ doing all this quickly enough not to get bogged
down in anything other than how to engineer things rapidly and
well enough to be usable.
Multicast, whether point-to-multipoint or multipoint-to-multipoint,
is a more difficult matter, in part because the multicasting facilities
in IPv4 are awkward for enormous use (think of millions of multicast
groups of from a handful to several thousand receivers, and multiple
transmitters trying to reach exactly the same audience. think of
a few thousand pps too. that helps.).
RSVP is not really anything of a help with respect to either
unicast or multicast traffic, except perhaps as potential
economic backpressure, since the resources that need reserving
typically amount to buffering and a stable route, perhaps more
than sheer bandwidth. At least two vendors are working on
interesting, probably-useful and radically different means
of addressing this sort of thing without resorting to RSVP
or anything very much like it, and certainly nothing that
aspires to work independently from routing.
Again, neither the absence of RSVP or non-committee-generated
philosophical alternatives will stop people from doing point-to-point
or even various forms of multicasting of real-time information,
and expecting old things and new things to work.
Personally, I like seeing things blown apart by new applications.
It doesn't do much for my sleep cycles or necessarily for the happiness
of the base of users who remember what the Internet was like before
the enormously popular WWW was unleashed, but added utility is imho
a hugely important part of the Internet. The trick is how to add utility
without wrecking the whole system, or indulging in wasteful faddishness
to support the egos of people who invent interesting but not very