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

From: Jon Bennett <[email-masked]>
Date: Tue, 25 Jul 2000 15:26:09 -0400

There appear to be a number of serious problems with the latest
version of the Virtual Wire PDB. A number of these stem from section
2.3 of the draft which says

"2.3 Attributes
Colloquially, "the same as a wire." That is, as long as packets are
sourced at a rate <= the virtual wire's configured rate, they will be
delivered with a high degree of assurance and with almost no
distortion of the interpacket timing imposed by the source. However,
any packets sourced at a rate greater than the VW configured rate,
measured over any time scale longer than a packet time at that rate,
will be unconditionally discarded. "

This requirement has a number of implications.

1 Requires non-workconserving link schedulers and/or potentially
massive over allocation of WV traffic at the source and at domain
boundaries. 

The only possible interpretation of section 2.3 is that if the time
between the start of one VW packet and the next is smaller than the
(size of the first packet)/(VW rate) then the second packet is
discarded. It is also a requirement that the over a similar time scale
that the VW aggregate must receive its configured rate. These two
requirements combine to require not only a non-workconserving
scheduler for the VW traffic, but for all other traffic as well. To
see why consider a VW aggregate with a rate of 1/8 of the line rate
sending packets of size '2' as follows

VV..............VV..............VV..............VV.. etc

if there is best effort traffic sending packets of size '4' at line
rate over the same link then the following pattern is the obvious
output in the absence of the requirement in 2.3

VVaaaabbbbccccddddVVaaaabbbbccccVVddddaaaabbbbccccVVdddd.. etc

however this results in the 2nd and 3rd VW packets being too close
together which should cause the 3rd VW packet to be discarded. The
only way to avoid this is to either transmit the following stream of
packets.

VVaaaabbbbcccc..VVddddaaaabbbb..VVccccddddaaaa..VVbbbbd.. etc

that is, to not begin transmission of a packet if it will still be in 
transmission when it would become possible to transmit the next VW
packet. This allows the VW packet to depart at the correct time but
means that the link will be idle even when there is best effort traffic
to send.

For small packets and/or any reasonable fraction of the link rate
worth of VW traffic the amount of overallocation and the amount of the
link bandwidth lost due to stalling non-VW traffic would both appear
to be very large. 

Either of these solutions, neither of which is very attractive still
leaves the following more onerous problem.

2 Can produce a denial of service 'attack' given the right rates
and/or packet sizes. 

Consider the case of a VW aggregate with a configured rate of only
1/10 of the line rate. If the VW aggregate is composed of very small
packets, say 64 byte packets, then every 64 byte times a VW packet
must begin transmission. As a result it is impossible for any non VW
packet of length >640 bytes to ever be sent over that link. 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. 

The only way to avoid this would be for the VW to be given a
configured rate which would let it catch up. Without the ability to
send a burst of packets it will be necessary to massively allocate
bandwidth to the VW traffic as well as running the other traffic in a
non-workconserving mode. 

There are a number of places in the text were it suggests the use of a
number of EF-like queues to support varying rates of VW traffic. It
should be clear that this then leads to the case of the various VW
aggregates interfering with each other as in the above examples. It is
not clear what solutions could be used in this case.

The correctness of the whole document appears questionable, for in
Section 2.7 it says that;

"The analysis in Section 2.4 would hold in a world where traffic
policers and link schedulers are perfect and mathematically
exact. When computing parameters for our world, 5-10% fudge factors
should be used."

Having just gotten done prescribing a service in which all manner of
requirements are stated in absolute terms and in which the
explanation of the correct functioning of the PDB is based on various
properties which are unconditionally true, to then suggest that a
'fudge factor' should be used raises yet more questions;

1 Where is the fudge factor to be applied? To what portions of the
  draft should this 'fudge factor' be added? Are there any places
  where it should not be added? 

2 Does the service still operate when this 'fudge factor' is added?
  If so then why are all the requirements stated as absolutes if they
  are not?

3 If the service still operates with a 'fudge factor' of 5-10%, does
  it still work with a 'fudge factor' or 10-20%? how about 20-40%?  At
  what point does it stop working?  

4 Do the authors know what the effect of loosening the requirements by
  allowing a 'fudge factor' are? If so, what are they? If the effects
  of loosening the requirements are known then the draft should state
  them so that equipment and networks could be designed to these
  looser requirements. If the effects are not known then how can the
  authors advise the use of any 'fudge factor'.

As a general comment about the style of the draft, in the introduction
the authors state that

"This document introduces and describes VW informally via pictures and
examples rather than by derivation and formal proof. The intended
audience is ISPs and router builders and the authors feel this
community is best served by aids to developing a strong intuition for
how and why VW works. However, VW has a simple, formal description and
its properties can and have been derived quite rigorously."

Speaking as a router builder, I do not find that an intuitive
description which is devoid of any formal description, or formal
descriptions which are impossible to meet to be of much use. And to go
and impose very strict requirements only to then say that a 'fudge
factor' should be added does nothing but leave me wondering which
requirements in the draft are actually necessary and which are
arbitrarily imposed without being actually needed.

Jon C. R. Bennett
Chief Engineer
RiverDelta Networks 
3 Highwood Drive
Tewksbury, MA  01876
978.858.2300/2361 (direct)
978.858.2399 (Fax)

   -export-a-crypto-system-sig -RSA-3-lines-PERL

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jul 2000 15:55:03 -0500

Jon,

Not speaking as WG co-chair:
...
> massive over allocation of WV traffic at the source and at domain

It's hardly a surprise that a bounded-jitter behaviour requires
underbooked links. I don't think we have pixie dust powerful enough
to change this. Yes, the VW behaviour will be non-work-conserving;
is this a problem? (It absolutely doesn't require "massive
over-allocation" - see below.)

...

> must begin transmission. As a result it is impossible for any non VW
^^may

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

> If any

Right. So the link is misconfigured: it has an MTU that is larger
than 640, otherwise no such packet could be queued for transmission.
Obviously, the inter-packet gap in the VW aggregate must be long enough
to carry MTU size packets.

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

> Without the ability to

No, it argues for a *lower* configured rate for VW to prevent the
problem you describe and to minimise the impact on other aggregates.

> not clear what solutions could be used in this case.

Again, this shows that the total configured rates for all VW
aggregates needs to be limited to a relatively small fraction of
the total capacity.

>   where it should not be added?

Well, let me see. I remember a conversation ten years or so ago with
a highly respected ATM pioneer who, having helped design initial
ATM products for his company, asked me if I could tell him anything
about the bursty traffic he'd been hearing about recently. And you're
asking for precision in fudge factors? We're trying to avoid 
repeating the mistakes of ATM here, and we have plenty of
experience of the need for fudge factors anywhere and everywhere
in traffic management.

>   If so then why are all the requirements stated as absolutes if they

Fudge factors are intended to add a safety margin, so they are
over and above the strict requirements by their nature. I think there
is already experimental evidence that EF-Jacobson configurations should be
about 10% conservative. I'm not aware of any experimental evidence
for EF-Charny.
>   what point does it stop working?

Wrong way round. More fudge = more margin (and less work-conserving).

>   authors advise the use of any 'fudge factor'.

Again, wrong way round. More fudge = more capacity, i.e. tighter requirements.

> how and why VW works... 

This is how the IETF does business. 

> ...However, VW has a simple, formal description and

In general that's not how the IETF does business. Maybe we'd be better
off by getting rid of all the mathematics; that's what seems to be
getting us into trouble. I'm serious.
  
   Brian (not speaking as WG co-chair)

---

From: "Bill Courtney" <[email-masked]>
Date: Tue, 25 Jul 2000 18:30:59 -0700

Brian,

> getting us into trouble. I'm serious.

This sounds like a suggestion that we shoot the messenger. I figured that
your message must have a smiley-face emoticon in it somewhere, but that my
software was treating it as an unprintable character.

Let's take a (semi-serious) look into a possible future:

A draft is put forward just before the deadline. At the following meeting
a commentor makes the observation that the draft is inconsistent or
unrealizable. Or perhaps, that a simple change will improve some feature
or another. The WG chair inquires whether this observation is based on
a *mathematical analysis*. A collective gasp followed by bated breath seizes
the group. The commentor stiffens his back and says, "Yes. I used ...
MATH!!"
He is cast into the outer darkness; he is anathema. He tries to find work
with
the WAP Forum, but his reputation precedes him.

:-)  ;-)
Bill Courtney
TRW, Network System Engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jul 2000 09:17:49 -0500

Bill,

I am totally serious. Let me quote what Van said elsewhere on this thread:

> To the best of my
> knowledge, the state of the art in queuing theory is very, very far from
> the point where one could hope to get a useful analytic model of a real
> router so we made no attempt to *specify* the behavior.

We can't correctly model routers, so maybe we should give up the
pretence that describing a single scheduling algorithm mathematically
tells us anything much about the total performance of a node. I've seen
people use the word "conformance" and the word "guarantee" in this
discussion; this is thinking from the ATM/Telco world and it isn't
going to get us very far in the Internet.

Again, not speaking as WG Chair at this instant.

   Brian