[altq 684] interesting behavior

[Nobuaki Takahashi <taka@kaynet.ecc.u-tokyo.ac.jp>]

Hello!

I encountered an interesting behavior using ALTQ and thought
if I can get some comments from someone.

What I have been doing is to reserve bandwidth in IP network
for ATM data stream. (I am now experimenting ATM over IP, in
this context, ATM over IP means transporting ATM data stream
over IP network.) For ATM data stream, Sony IEEE1394 Link
Unit is used. This application requires high QoS service, for
example, if packet (AAL message) loss is more than 0.1%, the
application would not work at all. ATM data stream generated
by Sony IEEE1394 is encapsulated by gateways I have made.

I setup experimental configuration shown below:

     A         E
      \       /
       C-----D
      /       \
     B         F

A-F are ordinary PC/AT computers, and the OS is FreeBSD3.4-R.
A-C and E-D are Gigabit Ethernet, and ti interface are used.
B-C, C-D, and D-F are Fast Ethernet, and all of the interfaces
are xl. ALTQ is enabled on C.

From A to E, ATM data stream is transported. A and E are
ATM-IP gateways and Sony IEEE1394 Link Unit are linked to each
of the gateways ATM natively. From B to F, UDP traffic is 
transported, which is for torturing ATM data stream. This 
experiment's objective is if ATM application, which requires 
data stream from A to E, works or not, when ALTQ at C is enabled. 
For UDP data stream, I implemented very simple server-client 
programs which transport UDP data stream as much as it can. It 
was experimentally observed if there is no other traffic, UDP 
traffic from B to F is about 82Mbps. ATM data stream's traffic 
is larger than 30Mbps, therefore, congestion occurs at C-D line.

First, I tried to transport ATM data stream from A to E. The
ATM application works perfect in this case. And then, I enabled
ALTQ at C, which just guarantees bandwidth from A to E. The
configuration file I used is very simple like this:

===========================================================
interface xl1 bandwidth 100M cbq
class cbq xl1 root_class NULL pbandwidth 100
class cbq xl1 def_class root_class borrow pbandwidth 95 default
class cbq xl1 udp_class def_class pbandwidth 90
	filter xl1 udp_class 192.168.3.2 0 0 0 17
===========================================================
(Note: ATM data stream uses UDP and filter shown above reserves
bandwidth for ATM data stream)

Apparently, this configuration file setup guaranteed bandwidth
for ATM data stream, where guaranteed bandwidth is at least more 
than 80Mbps.

It is expected that ATM application works properly when this
configuration is setup.

... as a matter of fact, the ATM application did not work properly,
when ALTQ was enabled. According to netstat -w 1, when ALTQ is
enabled, number of received packets at E becomes larger. I cannot
understand this behavior.

What is very interesting is what I have observed next. I had a
small hope that ATM application will work, when UDP traffic from
B to F is enabled (probably according to the common sense, it
does not work properly, since UDP traffic is for torturing ATM
data stream). And then, when the "interrupting" UDP traffic
is transported, the ATM application started working.

I guess the reason ATM application worked is because of the more
frequent (device?) interruption at C.

It would be great if I can get some comment concerning this issue,
the reason why ATM application did not work when ALTQ was enabled
and why ATM application started working when interrupting UDP
data stream is started transporting.
Plus thanks very much for reading this long Email, if there is
someone who have read this Email entirely.

Sincerely,
Nobuaki Takahashi

--
  高橋伸明  taka@kaynet.ecc.u-tokyo.ac.jp
  http://www.kaynet.ecc.u-tokyo.ac.jp/~taka/