From: Gerry Creager N5JXS <n5jxs@tamu.edu>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] voice based queuing
Date: Tue, 02 Jul 2002 03:31:44 +0000 [thread overview]
Message-ID: <marc-lartc-102558068211442@msgid-missing> (raw)
In-Reply-To: <marc-lartc-102557948410773@msgid-missing>
ganesh kumar godavari wrote:
> hello group,
>
> i want to know if there is any way i can determine using iptables if
> the ip packet contains voice?
>
> i want to know this as i want to do some queuing for output packets and
> the voice packets are given high preference next ftp,telnet,ssh.....
>
>
> i want to know if this is possible using iptables and tc. if so how. if
> i can identify the packet to be voice then i can do the rest using tc.
I've followed (from afar, things are busy) your quest.
The issues are several.
1. The ports used, except for setup, are dynamic, as the Microsoft page
told you (although NetMeeting is hardly a good example of a compliant
H.323 app).
2. You can do stateful inspection of headers and have a good shot at
finding RTP and RTCP packets, and then mark those.
Where you probably need to go is toward marking all from the H.323
hosts. You will need to spend some time with TOS/DiffServ, and 802.1p.
Also, be aware that if you do not have priority queuing from endpoint to
endpoint (also known as E2E) you will not see an appreciable improvement
in handling.
We are engaged in a couple of efforts to identify Voice and Video Over
IP, and mark it for priority queuing on our campus. Cisco has a nice
simple strategy they're apparently trying to make a "standard" but it's
at odds with diffserv marking. If you go with the Cisco markings, and
you enable your queue disciplines based on the markings,
_throughout_the_entire_network_ then you may see some improvement.
Can you di this with LARTC, yes, I believe so. Sorry I cannot be more
certain, but while it's on my list to test, I'm still a bit busy... The
trick is getting the appropriate packets marked properly at the edge,
rather than trying to mark them at the core. And why, one might ask, is
this so? Well, we see a lot of congestion at the edge in wiring closet
aggregation switches. If these switches cannot handle priority queuing
AND they experience periods (even short ones) of congestion, then most
of the effort you're going to is for naught.
Gerry Creager
network Engineering
AATLT, Texas A&M University
College Station, Texas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2002-07-02 3:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-02 3:09 [LARTC] voice based queuing ganesh kumar godavari
2002-07-02 3:31 ` Gerry Creager N5JXS [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-102558068211442@msgid-missing \
--to=n5jxs@tamu.edu \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.