LARTC - Jun 2001 - TC architecture made for Diffserv on linux is wrong !!! why?

I have studied  Diffserv  and made an experiment in Linux kernel 2.4.x
	but I have a question?

	At first, supposed the input link capacity of diffserv's edge(ingress)
router is more capacity than output link.

	that is, total Edge1's input BW is 20Mbps, total Edge1's ouput BW is
10Mbps


 	                     	 	       +++++++++++++++++++++++++++++++++++
	 +-------+ 10M Link            +            DS Domain                 	       +
 	| Host1     |----+                +                                      		   
+
	 |              |  	  |               +                         			       +
 	+-------+    	  |               +  +-------+     +------+     +-------+ +     
+-------+
  	            	  +---------> | Edge1  |-->| Core |-->| Edge2
|---------->|  Host3  |
	  	              +---------> |             |  ^ |          |  ^ |           
| +       ^        |             |
 	+-------+           |              +  +-------+   | +-----+   | +-------+ +   
|        +-------+
 	| Host2   |          |               +                    |                 | 
+       |
 	|             |-----+                +              10M Link     10M Link     
+    10M Link
 	+-------+  10M Link            +                                              
+
                     	                              
+++++++++++++++++++++++++++++++++++


	At second, Host1 sends AF1(2.5M), AF2(2.5M), AF3(2.5M), AF4(2.5M) - that is ,
total 10M traffic -  to Host3 host.
  		   Host2 sends best effort (6M) traffic to d1 host.
		   total sending traffic is 16M.

	At third,  Edge1's ingress using u32 filter and classfy AF1, AF2, AF3, AF4,
BF and marking classid on skb->tc_index.
	           This architechture is similar to
http://qos.ittc.ukans.edu/DiffSpec/node11.html
	           
	At this time, both  the user Host1, Host2's traffic is not guaranteed  in
existing tc architecture
		because the result of Host1,Host2 traffic metering is not marked in the
Edge1's input part,
		   queue of Edge1's output has  only a FIFO queue.

	As this output's sch_dsmark has a FIFO queue, Best effort traffic and AF
classes traffic is
		combined and does not guaranteed AF classes.

	Existing sch_ingress and sch_dsmark architecture in edge router(Edg1) is
		 following that... http://dcn.ssu.ac.kr/~peniel5/zboard/zboard.php?id=diffserv

	here, input device uses  sch_ingress, output device uses sch_dsmark
		as you see, mark of the traffic(af) is end part ( output device ) in this
picture.

	Therefore, in this circumstance, I think that existing TC structure in Linux
kernel 2.4.x is not availble.
	Do you have another idea?
	I think wrong thing?



	well.. I think I have  right idea.

	and.. finally,

	I have a suggestion!
	To solve  these demerits, I made  ingress marker in linux kernel 2.4.x.
	that is, I take DSCP marking part 's position in input device part .

	the result, architecture of these experiments and performance test 
                   ( existing architecture VS suggested architecture ) showed in
my web board

	my web board is http://dcn.ssu.ac.kr/~peniel5/zboard/zboard.php?id=diffserv

	I hope your opinion !!!!!

jinho Hwang wrote:
> 	As this output''s sch_dsmark has a FIFO queue, Best effort traffic
> and AF classes traffic is 
> 		combined and does not guaranteed AF classes.
Hmm, so why don''t you use CBQ/PRIO and maybe GRED then, i.e. something
that gives AF priority over BE ?
> 	To solve  these demerits, I made  ingress marker in linux kernel 2.4.x.
> 	that is, I take DSCP marking part ''s position in input device
part .
You don''t have to mark in order to classify based on the DS field.
Just use skb->tc_index to convey that information. You can set
skb->tc_index at ingress or at egress (with dsmark).

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Lausanne, CH                    wa@almesberger.net /
/_http://icawww.epfl.ch/almesberger/_____________________________________/