Voip traffic is a relatively low bandwidth application. But competing traffic is. I do think realtime video conferencing will become more prevalent in coming years and I think this will cause new bandwidth shortage issues.
Qos for Voip is not that big of a issue on broadband networks for soho situations. The reason is because one is connecting via either DSL or Cable. Cable uses doccis 2.0 which has it's own qos mechanisms such a s framed pipline polling. There is also another qos protocol in docsis 2.0 that makes sure that the all users get roughly equal bandwidth access. DSL connects to a dslam which is usually connected to a sonet ring. The same applies to cable as well. In many cases a ATM connectionis being utilized and so therefore some ATM qos features are being utilized. Intranets are a differnt issue since there is a lot more users competing for bandwidth. --- boblq <[EMAIL PROTECTED]> wrote: > On Monday 17 April 2006 11:20 pm, Andrew Lentvorski > wrote: > > boblq wrote: > > > On Monday 17 April 2006 06:04 pm, Stewart > Stremler wrote: > > >> TCP is hard to replace ... > > > > > > I agree. > > > > > >> you end up implementing something that looks > > >> an awful lot like TCP. > > > > > > Not necessarily. One may blow off ack/nak and go > with > > > forward error correction ... and thus have a > whole new > > > thing with some very different attributes and > issues. > > > > Surprisingly, you can't blow off ack/nack even > with forward error > > correction. The problem is that you *must* do > rate/congestion control > > otherwise your system goes pathological in a > hurry. Rate/congestion > > control requires that you ack at least some > packets. At that point, you > > might as well ack/nack lots of packets. > > > > TCP is really close to minimally optimal. Now, I > just implement TCP > > rather than trying to be "simpler". > > > > The only alternative I have seen is the Delay > Tolerant Networking stuff. > > Vint Cerf seems to think that TCP/IP won't work > for interstellar stuff. > > > > http://www.dtnrg.org/wiki > > > > -a > > I have been working with VOIP recently. As I was > looking at RTP > the old message above came drifting up from the back > of my > memory. > > RTP is UDP based and is _not_ reliable i.e. it is > allowed to drop > packets. It does not do ack/nak and hence does not > worry about > congestion control. > > Some background. > http://www.voip-info.org/wiki-RTP > http://www.cs.columbia.edu/~hgs/rtp/faq.html > > Given the growing volume of VOIP traffic I wonder if > this is > not a potential serious cause of congestion. > Obviously another > issue is QOS or rather its nonexistence. > http://en.wikipedia.org/wiki/Quality_of_service > > I am curious what the real issues are here and what > actual experience > people have with them. There is quite a bit of > research going on > because of the importance of this problem. I found > this > http://www3.ietf.org/proceedings/06mar/slides/dccp-2.pdf > > There are other approaches including multi-tier > networks. > > Comments, > > BobLQ > > > > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
