Message-ID: <1323467512.3159.93.camel@denise.theartistscloset.com>
Date:	Fri, 09 Dec 2011 16:51:52 -0500
From:	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>
To:	netdev@...r.kernel.org
Subject: Latency guarantees in HFSC rt service curves

Hello, all.  Sorry to be SPAMming the list but I think I must have a
fundamental conceptual misunderstanding of HFSC's decoupling of latency
and bandwidth guarantees.  I understand how it is done.  I understand in
theory why it is critically important.  Where I'm failing is seeing how
the current implementation makes any real world difference.  I'm sure it
does, I just don't see it.

Here's how I've explained it at the end of the 14 pages of documentation
I've created to try to explain IFB and HFSC from a system
administrator's perspective.  As you can see, I'm relying upon the
excellent illustration of this part of HFSC in the SIGCOM97 paper on
page 4:

"To illustrate the advantage of decoupling delay and bandwidth
allocation with non-linear service curves, consider the example in
Figure 2, where a video and a FTP session share a 10 Mbps link . . . .
Let the video source sends 30 8KB frames per second, which corresponds
to a required bandwidth of 2 Mbps. The remaining 8 Mbps is reserved by a
continuously backlogged FTP session. For simplicity, let all packets be
of size 8 KB. Thus, it takes roughly 6.5 ms to transmit a packet."

"As can be seen, the deadlines of the video packets occur every 33 ms,
while the deadlines of the FTP packets occur every 8.2 ms. This results
in a delay of approximately 26 ms for a video packet."

Let's work through the math to make that more understandable.  HFSC is
committed to deliver 2 Mbps to video and each packet is 8KB long.  Thus,
HFSC's commitment to deliver that packet is within (8000 * 8)bits /
2,000,000(b/s) = 32ms.  I'm not quite sure why I come up with 32 and
they say 33 but we'll use 33.  In other words, to meet the deadline
based solely upon the rate, the bandwidth part of the rt service curve,
the packet needs to be finished dequeueing at 33ms.  Since it only takes
6.5ms to send the packet, HFSC can sit on the packet it received for 33
- 6.5 = 26.5ms.  This adds unnecessary latency to the video stream.

In the second scenario, we introduce an initial, elevated bandwidth
guarantee for the first 10ms.  The bandwidth for the first 10ms is now
6.6 Mbps instead of 2 Mbps.  We do the math again and HFSC's commitment
to video to maintain 6.6 Mbps is to finish dequeueing the packet within
(8000 * 8)bits / 6,600,000(b/s) = 10ms.  Since it takes 6.5 ms to send
the packet, HFSC can sit on the packet for no more than 10 - 6.5 = 3.5
ms.  Quite a difference!

That's our documentation so I think I get it but here's my problem.
Practically speaking, as long as it's not extreme, latency at the
beginning of a video stream (I'm using video because that is the example
given) is not an issue.  The problem is if I introduce latency in the
video stream once it has started.  So what is the advantage of starting
the stream in 3.5ms versus 26.5ms? The subsequent packets where latency
really matters are all governed by the m2 curve at 2 Mbps in this
example.

Moreover, let's say I have three video streams which start
simultaneously.  Only the first packet of the first stream receives the
6.6Mbps bandwidth guarantee of the first 10ms so the other videos
receive no practical benefit whatsoever from this m1 curve.

I'm sure that's not the case but what am I missing? Thanks - John

--
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

Powered by blists - more mailing lists