Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jan 2008 20:40:04 GMT
From:      "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" <ermal.luci@gmail.com>
To:        freebsd-pf@FreeBSD.org
Subject:   Re: kern/120057: [patch] Allow proper settings of ALTQ_HFSC. The check i wrong since even with the values forbidden from this check you get a concave curve.
Message-ID:  <200801282040.m0SKe4EA068359@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/120057; it has been noted by GNATS.

From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" <ermal.luci@gmail.com>
To: "Max Laier" <max@love2party.net>
Cc: bug-followup@freebsd.org, eri@freebsd.org
Subject: Re: kern/120057: [patch] Allow proper settings of ALTQ_HFSC. The check i wrong since even with the values forbidden from this check you get a concave curve.
Date: Mon, 28 Jan 2008 21:03:39 +0100

 http://www.sigcomm.org/sigcomm97/papers/p011.pdf
 If you look at the paper on the link i gave here and i copied a
 snippet from page 11:
 <snippet>
 To demonstrate H-FSC's ability to ensure low delay for
 real-time connections, we target for a 5 ms delay for the
 audio session, and a 10 ms delay for the video session. To
 achieve these objectives, we assign to the audio session the
 service curve Sa = (umax
 a = 160 bytes; dmax
 a = 5 ms; ra =
 64 Kbps), and to the video session the service curve Sv =
 (umax
 v = 8 KB; dmax
 v = 10 ms; rv = 2 Mbps). Also, in order
 to pass the admission control test, we assign to the FTP
 session the service curve SFTP = (umax
 FTP = 4 KB; dmax
 FTP =
 16.25 ms; rFTP = 5 Mbps). The service curves of all the
 other sessions and classes are linear
 </snippet>
 
 And the paper specifically states that ALTQ_HFSC implementation
 doesn't allow for convex curve with a m1 parameter of 0.
 Furthermore, the check is wrong since the second curve starting point
 is not (0, 0) but the point where the first curve ends, with x = d and
 y = conversion of m1. So the resultant curve is concave.
 
 Sorry the bug follow up was not complete first time, but was tired
 when reported.
 
 P.S. There is another check actually, but that can be part of another
 PR, which does not allow setting only the realtime parameter and so
 forbids making altq non work conserving and being used in admission
 mode. always if you cipole it with a daemon that makes the propper
 changes in time.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801282040.m0SKe4EA068359>