From: Werner Almesberger <wa@almesberger.net>
To: lartc@vger.kernel.org
Subject: [LARTC] tcng - what's next
Date: Fri, 21 Jun 2002 05:29:03 +0000 [thread overview]
Message-ID: <marc-lartc-102463715420120@msgid-missing> (raw)
[ Background: tcng is a system that allows traffic control
configurations to be expressed in a much more natural way than
with iproute2/tc, while retaining full compatibility. tcng can
generate tc configuration commands, so no kernel changes are
required. http://tcng.sourceforge.net/ ]
I started tcng about one and a half years ago at EPF Lausanne, as
part of a research project. Back then, the main goals were to
provide a more friendly configuration language, and also to allow
better abstraction between the configuration process and the
underlying traffic control implementation.
Then, work on tcng continued for one year on a contract with Bivio
Networks, where I was graciously allowed to release most of my
work to the public. The main result of this was the so-called
"external interface" that can be used to drive hardware
accelerators.
Also, I got a lot of useful input from Jacob Teplitsky and others,
and major usability and performance improvements were made during
that time. Most importantly, while the original design assumed that
all traffic control configurations would mirror the structure of
traffic control in the Linux kernel, tcng now allows much better
abstraction for classification.
Now that my contract with Bivio Networks has ended, I'm continuing
tcng as a hobbyist project. While I consider tcng to be
sufficiently mature for serious use, there are still a few issues
I plan to tackle, among them:
- phase out "kernel-style" classification (the missing link for
this is that "if" can't handle meta-data like skb->nfmark yet)
- treat classifications as the construction of a finite state
machine instead of the current ad hoc algebra. This is a hairy
graph theoretical problem, but I expect major scalability
improvements once I've solved this.
- add loops to the classification mechanism (e.g. to walk through
IPv4 options or IPv6 headers)
- try to find a way to express queuing in an abstract and
structured way, much like classification
- and, of course, there are many minor misfeatures to address
Since tcng is much broader than just Diffserv, I'm moving any
discussion and announcements over to the LARTC mailing list
(http://lartc.org/#mailinglist). I'm posting this message and the
next release announcement to both lists.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://icapeople.epfl.ch/almesber/_____________________________________/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
reply other threads:[~2002-06-21 5:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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-102463715420120@msgid-missing \
--to=wa@almesberger.net \
--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.