Subject: RE: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb

From: Jon Bennett <[email-masked]>
Date: Wed, 26 Jul 2000 14:31:26 -0400

> It's hardly a surprise that a bounded-jitter behavior requires
> underbooked links. 

Given that I have built high speed hardware schedulers that provide tightly
bounded jitter without requiring that the *entire link* be run in an
underbooked manner, I would in fact be very surprised by this.

> Yes, the VW behavior will be non-work-conserving is this a problem? 

My complaint was not with the need for VW to be non-work-conserving, but
with the fact that given the statements in 2.3 that it will require that ALL
OTHER behaviors on the link be non-work-conserving as well. And as a result
I have a number of problems with it;

1) It is yet another serious restriction that has never been mentioned in
the document or in discussion of it.

2) Given that the policing requirements of 2.3 will be applied at the source
link and when crossing between different domains (most likely at an ISP
peering point), both of which are links with high operations costs and
almost always with too little bandwidth, having to waste any of it will not
be acceptable to a great many people. 

> (It absolutely doesn't require "massive over-allocation" - see below.)

If you are unwilling to needlessly waste link capacity to accommodate the
unneeded requirements of the VW PDB then I do not see how it can not require
over allocation.

> > 2 Can produce a denial of service 'attack' given the right rates
> > and/or packet sizes.
 .
.
> > packet of length >640 bytes to ever be sent over that link. 
> 
> Actually not, if there is no VW traffic. But let's assume there is
> continuous VW traffic for the sake of argument...

There would not be much to discuss if there were no VW traffic would there?

> > If any such packet is received than it will have to be dropped 
> (regardless of what type of traffic it is) otherwise it will cause all 
> traffic queued behind it to stop when this packet comes to the head of 
> the queue.
> 
> Right. So the link is misconfigured: 

> Obviously, the inter-packet gap in the VW aggregate must be 
> long enough to carry MTU size packets.
..
> > The only way to avoid this would be for the VW to be given a
> > configured rate which would let it catch up. 
> 
> I'd say it the other way round: VW must not be given a configured
> rate that fails to leave gaps big enough for MTU-sized packets.

I don't see any place in the draft where it says that it may be necessary to
limit the MTU over the link, or that the way the MTU effects the maximum
rate of VW traffic is as you describe as opposed to being limited to its
effects of single packet jitter accumulations. The draft only discusses the
effect of MTU size on the forwarding behavior it does not discuss this
effect on the policing behavior.

In section 2.6 there is an example where a link is shown being almost 50%
full of G.729 calls with 60 byte packets. There is no mention of the fact,
that if we take the restriction you just gave, the MTU for all other types
of traffic would have to be limited to 120 bytes!!!

Put another way on a GE or POS link where the MTU might be ~8KB this new
requirement of VW would mean that the maximum rate of VW traffic would be no
more than 60B/8KB = 0.7% of the link rate

I will get to the discussion of 'fudge factors' in a separate message, this
one is long enough already

jon

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/