Re: [LARTC] Optimize NetMeeting traffic with tc?

[Gerry Creager N5JXS <gerry@cs.tamu.edu>]

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@cs.tamu.edu
Network Engineering
Academy for Advanced Telecommunications and Learning Technologies		
Texas A&M University	979.458.4020  (Phone) -- 979.847.8578  (Fax)

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/