Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: "jinho Hwang" <peniel5@dcn.ssu.ac.kr>
To: lartc@vger.kernel.org
Subject: [LARTC] [diffserv] At present , TC architecture made for Diffserv on linux is wrong
Date: Thu, 21 Jun 2001 02:03:03 +0000	[thread overview]
Message-ID: <marc-lartc-99309200424728@msgid-missing> (raw)

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]



From old times, 
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 e1's input BW is 20Mbps, total e1's ouput BW is 10Mbps

         s1 ---------l
	    10M	 l
		 l-----------  e1----------e2 ------------- d1
		 l    10M      ^        10M             10M
        s2 ----------l                 l
                 10M                   l
			       l
			edge router (e1)
                            --------------------------
                           l    input   :  output    l
		   l    part     :    part      l
                           l               :                l
                           --------------------------
                      		

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

At this time, both  the user s1, s2's traffic is not guaranteed  in
existing tc architecture
because the result of s1,s2 traffic metering is not marked  in the e1's
input part, 
	   queue of e1'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(e1) 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 !!!!!






[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2780 bytes --]

                 reply	other threads:[~2001-06-21  2:03 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-99309200424728@msgid-missing \
    --to=peniel5@dcn.ssu.ac.kr \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox