|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: MFS WorldCom/WilTel/LDDS
| 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 workable ideas... Sean. - - - - - - - - - - - - - - - - -
|