netdev - Re: HFSC link sharing behavior related query

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 02 Jul 2009 18:36:01 +0200
From:	Michal Soltys <soltys@....info>
To:	Sanket Shah <sanketshah5124@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: HFSC link sharing behavior related query

Sanket Shah wrote:
> Hi,
> 	We are doing experiments on hfsc in various network scenarios. Some
> of the results are not as per our expectation/understanding of our
> hfsc behavior.
> 
> -----------------------------------------------------------------------------------------------------------------------
> 	Scenario 1:
> 
> 		1: (hfsc qdisc)
> 		|
> 		|
> 		1:1 (hfsc root class) (rt 0, ls 40, ul 40)
> 		|
> 	----------------------------------------------------------------
> 	|								|
> 	1:2 (rt 10, ls 1, ul 20)				1:3 (rt 30, ls 1, ul 40)
> 	|								|
> 	2: (sfq qdisc)						3: (sfq qdisc)
> 
> 	In above scenario,
> 		1:2 and 1:3 both are doing http download and we are getting following results.
> 
> 		1:2 - 10 kbps
> 		1:3 - 30 kbps		
> 			That is as per the expectation.
> 
> 	After 5 minutes we are changing ls and ul of 1:1 from 40 to 100. (rt
> 0, ls 100, ul 100)
> 		
> 		For first 2 minutes after above change,
> 
> 			1:2 - 20 kbps
> 			1:3 - 80 kbps
> 				In this case ul curve is getting violated for 2 mins.
> 
> 		After 2 minutes,
> 
> 			1:2 - 20 kbps
> 			1:3 - 50 kbps
> 				That is expected.
> 
> 	Is it an expected behavior ?
> 	why ul curve got violated ?
> 

Regarding this scenario, I have 4 stages (all expected, afaics):

1) 10 : 30 (beginning)
2) 70 : 30 (right after changing 1:1, beacuse of:
		vt far apart between 1:2 and 1:3
		ft artificially limited)
3) 20 : 80 (once 1:2's ft catches up)
4) 20 : 40 (once both ft "stabilize")

This is the effect of two things:

1) LS curve is in 1 to 1 ratio ; looking at initial bandwidth assignment 
20 : 20 - but 40 is all what both children can get from LS (due to UL). 
Actually they will get nothing, as RT curve already covers that in 10:30 
ratio. Furthermore virtual time calculated from LS of both child classes 
will drift apart (more and more with passing time), which is precise 
thing HFSC is trying to avoid

2) UL curve is artificially limited - in this particular case in initial 
period - only realtime criterion is updating virtual time, and RT curve 
is half of UL one - thus ft calculated from received service using UL 
will drift away from current time (again - more and more with passing 
time). ITOW the class will become greedy :)  Actually there is a code 
fragment commented out that is probably meant to prevent that.

The effect is, that imemdiately after bumping up UL to 100 at 1:1, LS 
criterion will be only considering class 1:2 as long as virtual time has 
long way to catch with 1:3 (due to 1). At the same time 1:2's fittime is 
lower than it should be (due to 2), so the class will not be upper 
limited for some time period. RT of 1:3 will serve it 30, all available 
LS will go to 1:2.

After fittime catches up, 1:2 will get cut down by its UL again, while 
1:3 will not be limited by it for some time. Thus - 20:80. vt won't 
really matter at this time, as the arbitration is "choose class with 
lowest vt, while ft fits". vt will start drifting apart again.

Finally, once ft of both classes catch up, the final effect will be 20:40.

(I'll have to doublecheck it later, and look at the 2nd question)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html