* Re: [LARTC] Optimize NetMeeting traffic with tc?
2001-10-03 13:33 [LARTC] Optimize NetMeeting traffic with tc? Marc Delisle
@ 2001-10-03 14:46 ` Adrian Chung
2001-10-03 15:17 ` Gerry Creager N5JXS
2001-10-03 15:29 ` Hernan Brun
2 siblings, 0 replies; 4+ messages in thread
From: Adrian Chung @ 2001-10-03 14:46 UTC (permalink / raw)
To: lartc
On Wed, Oct 03, 2001 at 09:33:25AM -0400, Marc Delisle wrote:
> 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?
Reserving bandwidth would normally be a smaller part of the problem
with Netmeeting, but in your case, you've got plenty of bandwidth.
Latency is a larger issue, and while you can use 'tc' to define QoS
and try to control latency outbound from your link, you have no
control over what happens once the Netmeeting packets hit the
Internet, especially when they hit the cable network, which might more
than likely be where most of the latency gets picked up.
--
Adrian Chung (adrian at enfusion-group dot com)
http://www.enfusion-group.com/~adrian
GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17
[rogue.enfusion-group.com] up 62 days, 1:52, 5 users
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] Optimize NetMeeting traffic with tc?
2001-10-03 13:33 [LARTC] Optimize NetMeeting traffic with tc? Marc Delisle
2001-10-03 14:46 ` Adrian Chung
@ 2001-10-03 15:17 ` Gerry Creager N5JXS
2001-10-03 15:29 ` Hernan Brun
2 siblings, 0 replies; 4+ messages in thread
From: Gerry Creager N5JXS @ 2001-10-03 15:17 UTC (permalink / raw)
To: lartc
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/
^ permalink raw reply [flat|nested] 4+ messages in thread