[c-nsp] Hierarchical QoS Policies

[Andre Beck]

Hi,

On Thu, Apr 07, 2005 at 10:11:19PM +0200, mejllistor at carlson.homeunix.net wrote:
> On Thu, Apr 07, 2005 at 05:50:21PM +0200, Andre Beck wrote:
> 
> > Looking closer at them, I realized
> > that at 100kbps, a full size packet of 1500 bytes aka 12000 bits will
> > have a serialization delay of 120ms, so if the shaper emulates the
> > queueing behavior of a real interface up to and including the blocking
> > of packets due to serialization delay of other packets that have just
> > seized the interface, well, it would explain the RTT values I see.
> 
> that very much highlights the issues with qos and low bandwidths. if for
> example 10 ms delay of priority traffic due to head of line blocking is
> acceptable, the bandwidth must be at least
> 1500 * 8 (bits) / 10e-3 (s) = 1.2 Mbps!

Yep, with a real hardware interface I understand this perfectly. It's
just the question whether a MQC shaper implements this behavior. In a
way it would have to, but then again, as the serialization delay of the
final transmit interface is way slower than that imposed by the shaper,
the packet doesn't really seize the interface up to the point in time
when it is completely "serialized" by the shaper. So if another packet
with LLQ specs travels in just before the packet goes to the real
interface, the shaper *could* rearrange things and give the LLQ one
precedence, probably by cleverly swapping some statistics and queue
entries. It could swap the already "serialized" amount of bytes from
the old best effort packet with the same amount of bytes from the new
prioritized packet, continuing to serialize that one. As a result, the
shaper would not impose a delay larger than the real interfaces
serialization delay to LLQ packets (which of course must not exceed their
class limits, so the overall bandwidth limits of the shaper are kept).

>From what I measure, though, it doesn't seem that way. With only my
test pings, RTTs are surprisingly small (they are smaller than one
would expect of pings on a 100kbps real-world interface), but as soon
as congestion of the shaper occurs, they go up by two orders of magnitude.

> a way to circumvent this on lines with low bandwidth is lfi
> (link fragmentation and interleaving), which is available on fr and
> ppp-lines.

Yeah, but what I'm required to traverse here is a PIX-based VPN. I'm
using GRE Tunnels with OSPF routing for this purpose (to get around
the No-I-don't-wanna-route paradigm of the PIXen as well as to have
a single point of QoS application). As neither PIXen nor the CPE
equipment used to connect this VPN to the carrier are QoS capable
but, on the other hand, a minimum available bandwidth within the
carrier/ISP network is guaranteed (simply by the fact that all the
lines terminate on the same router, and it's my router), going the
shaped tunnel way seemed the only rational approach.
 
> with ethernet, it is not much you can do except trying to reduce the
> max packet length. for tcp traffic, 'ip tcp adjust-mss' will do that.
> for udp, there is no buttons...

If the shaper is really implemented this way, yes. But I'm not convinced,
mostly because I'm getting the same RTT average values and jitter inde-
pendend of whether I run the shaper alone or plug a child policy under
it that does LLQ. I would at least expect a difference.
 
> > I have not found detailed documentation about the shaper and how it
> > interacts with LLQ so far, any pointers are welcome.
> 
> there were a similar thread last december on this mailing list. rodney dunn
> posted some explanations how shaping works.

Yeah, thanks, found that back in my mailbox (I've even read it then)
and reread it. Rodney essentially explains that LLQ under a shaper would
give better latency than just the shaper or a shaper with just "bandwidth"
child policies. I'd just like to be able to proof that in my lab...

Thanks,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-