Marc Delisle wrote: > > Hi, > > last week I had a NetMeeting session, image quality was poor and sound was bad. With MSN Messenger, > the sound was ok. > > >From the same station to another one in the lab, all was OK. > > We have a 100 Mbps optical link to the Internet, and the other guy was on cable modem. We have GbE > backbone here, with a 100 Mbps feed to the station. > > So I started to learn about tc, I defined a class to reserve some bandwidth (500Kbps) for this > station, and plan to test again in a few hours. > > Is it enough to reserve bandwidth? I read that latency could be an issue. Can I use tc to reduce > latency? While this is a little off-topic, and while Adrian Chung has addressed it a little bit, let me answer more fully. Our research has indicated that there are some real problems with both latency and jitter, when one uses H.323 videoconferencing. With NetMeeting (especially when both ends are NetMeeting) this can be relieved somewhat because NetMeeting will provide some degree of buffering. However, NetMeeting to something else (Picturetel, Polycom, Ohphone, VCon, etc.) does not, in our experience, produce the necessary handshaking to provide any dynamic buffer updates. Thus, what you get is the default buffer. Some of the other vendors have told us that they will start producing bad audio/video with packet loss of a little as 0.5%, or almost any out-of-sequence packet arrivals, as they are not really doing reodering or reassembly, but have merely moved their H.320 stack to a tcp/ip transport. Picturetel, by default, sets a TOS value of 5, which Cisco recognizes as "high priority payload" and handles preferentially, if queing is enabled in their default mode _ON_SOME_devices_. We have noted that VCon does not set TOS, while Ohphone does. Adrian's comment about lack of control is significant. While your local network may provide low latency, and small values of jitter, and the other end's cable network may provide similar conditions, the distance and number of hops, coupled with lack of queueing for priority payloads tends to remind you in the end that TCP/IP is, in fact, a best-effort network overall, and as congestion goes up, video suffers. We have seen evidence that even brief periods of congestion, as short as milliseconds in duration, can cause sufficient packet loss to provide really bad video, and on some vendors' systems, engender a complete screen blank and rewrite (which means a request across the net for an entire screen set to be rebroadcast... which means the potential for a brief storm of packets from sender, leading right back to microcongestion again). The LARTC provides a good mechanism for tagging, and bandwidth reservation, but is limited by what the networks external to us use. I expect, overall, a concensus between network device manufacturers (and that means, eventually, us, since LARTC, and the other Linux-based routing projects are starting to provide more and more installs) and the H.323 manufacturers about a TOS value that will be universal and will allow real preferential movement of videoconferencing and IP-telephony traffic. -- Gerry Creager -- gerry@xxxxxxxxxxx Network Engineering Academy for Advanced Telecommunications and Learning Technologies Texas A&M University 979.458.4020 (Phone) -- 979.847.8578 (Fax)
