Subject: [Diffserv] DiffServ Model - slides from yesterday

From: Andrew Smith <[email-masked]>
Date: Mon, 27 Mar 2000 15:13:20 -0800

Here is a transcript of my slides from yesterday's DiffServ meeting. Please
send comments to the DiffServ list ASAP.

Andrew Smith

====================================================

General tidying-up

Closer alignment with DiffServ MIB and PIB
terminology (which is correct? - other drafts need to change)
"counter" or "monitor"? "discarder" or "algorithmic dropper"?

Structure

- shapers: still some residual text that treates these as Actions, not part
of Queuing -> clean this up
- move most of the discussion stuff from MIB to Model
- Fred's n x 2-port = n-port router discussion from 3.1 to Hierarchical
Model 3.2
- Meter discussion from 3.3 to Meters 5.1
- Kwok's RED discussion from 3.4 to Discarders 7.1.3
- Kwok's Queuing example from 3.5 to Schedulers 7.1.2

Model: open issues

1. There is a difference in interpretation of token bucket behavior between
this document (Appendix A) and [DSMIB].  Specifically, [DSMIB] allows a
packet to conform if any smaller packet would conform. (discuss)

2. Should a classifier be part of a TCB?  We argue yes.  This allows a TCB
to be a one input/one output black box element.
- MIB assumes not.
- why can't we feed discarders from existing classifier blocks? 
- What if I want to discard based on something other than DSCP?
- 3rd discarder example in 7.1.3 does not make sense and is inconsistent
with previous examples (uses DSCP, not PHB) (no)

3. Should we discuss MPLS (a) more or (b) less? (b)

4. Include support for non-DSCP markers? (allow but no explicit discussion)

5. The meter in [SRTCM] cannot be precisely modeled using two two-parameter
token buckets because its two buckets do not accumulate credits
independently.  
- Do we need to show how the [TRTCM] meter could be implemented? If so,
someone please supply text.
- Should the Model include examples of each or just describe a general
n-rate meter? (discuss)

6. Are the current examples for queues, scheduling and buffer management
sufficient? (yes)
- FIFO with thresholds
- Schedulers (work-conserving and non-work-conserving) with min/max/priority
- Discarder with triggers (e.g. queue-threshold feedback) and classifiers
- Should we add a "Precedence PHB" example? (no)

7. Is the description of a shaper sufficient (section 7.2)?  Is it
overbroad? (please send comments)

8. Does the Queue/Queue-Set concept belong in the model (and the MIB and
PIB?), or should the model stick to the abstract PHB representation and
leave the implementation details to the MIB and PIB (and other work in this
area)? (discuss)

===========end===============

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

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 27 Mar 2000 16:57:57 -0800

Model comments I didn't make in the WG meeting yesterday:

Section 3.1.1 Optional RSVP Module ..."if present might be
active only in the control plane not the data plane..."
I would suggest that the "might" would better be a "should".

"monitors" update an "octet": why the restriction to an octet?
Why not a 32 bit word?

Reiterate neeed to clean up "dropper"/"discarder"/buffer management
algorithm terminology. 

In Definitions, fix the words for Non work conserving.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Mar 2000 22:52:26 -0500

I have re-read this document several times.
The first piece is just to make sure I understand the assumptions of the 
jitter analysis.  In particular, I am trying to understand the simulations 
of the effect of non EF traffic on the EF traffic.
1) You assume that the links are "congested" with BE traffic.  This is what 
I would think one would want to assume.  Do you assume that at all times, 
on all links, there is BE traffic queued?  That may be a mite extreme, but 
seems the must reasonable assumption to understand the confidence with 
which one can make the VW guarantees.

2) After that, you do an analysis of the maximal effect of the BE traffic, 
and conclude that it is one max-MTU packet per hop.  Again, this makes 
sense.  You then argue that both from simulation and analysis that the 
probability of this worst case occurring is very small.

My question is what the expected value of the impact is.  Reading your 
graphs, the 50% probability line is significantly sub-linear.  However, an 
intuitive examination of the problem suggests that if the links are indeed 
congested with BE traffic (suppose no other EF traffic), then one would 
expect, on average, that the EF packet would see 1/2 an MTU of "jitter" per 
hop.

So, the obvious question is why this does not match your graphs.  The 
explanation that comes to mind is that since the simulation was done with 
congestion at all times, all the packets were affected by this 1/2 MTU 
"jitter".  Is this consistent with the way you did the simulation?  Or is 
this a case where intuition misleads and there is some good reason to 
expect a smaller variation between between best case and congested case 
behavior?

Yours,
Joel M. Halpern

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 27 Mar 2000 21:50:04 -0800

"Joel M. Halpern" wrote:
....
> expect a smaller variation between between best case and congested case

SO one thing is to not confuse jitter and delay. I think you
are getting at this when you say, on average, a packet sees
1/2 MTU wait at each hop. So, on average, two consecutive
packets would see that same wait and no jitter. The worst
case jitter only happens if packet j sees no queue and
packet j+1 (or j-1) waits behind every entire MTU packet.

The square root shape comes from the convolving of the
uniform distributions at each hop to get a gaussian
with this nice behavior in its variance. Sanjay
Agrawal of Cisco has worked this out and it will go into the
next version of the draft.

Oh, yes, we kept the DE queues hammered on with 1500 byte
packets. If the utilization is smaller then tgere is a
higher likelihood of seeing an empty queue.

	Kathie

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Mar 2000 01:20:09 -0500

Thank you for clarifying.  If I understand then the implication is that if 
congestion arrives between two packets, the jitter between them may be on 
the order of hops*mtu/2?  Admittedly, it takes a pretty odd network 
behavior to get this kind of variation repeatedly, but that is statement 
about BE traffic distributions, rather than a statement about the 
confidence with which one may make EF promises.  An ISP may well be 
prepared to make committments on this basis, but it seems dangerous given 
the variations in congestion.

Yours,
Joel M. Halpern

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 27 Mar 2000 22:54:52 -0800

"Joel M. Halpern" wrote:
> the order of hops*mtu/2? 

Well, that's one way to think of it. It could be an uncongested
network or a congested network. All that has to happen to
reach that worst case is that one packet of a "stream"
arrives at every router when there is no DE packet being
serviced (could be that one just finished) and the next
packet of the stream arrives at every router just as a DE
packet starts (might be the only packet to go through in
a half hour, but the second packet was just unlucky). Yes,
that would be a very unlikely scenario. In fact, we can't
make it happen in a simulation with a congested DE queue
at each hop. But that doesn't mean it won't happen. 

 Admittedly, it takes a pretty odd network
> the variations in congestion.

I won't presume to tell an ISP what committment to make, but it
appears that an ISP can make a jitter committment like 95%
of the time the subscribed stream will see a jitter less than
_something_ where _something_ might be a virtual packet time
at the subscribed rate or perhaps something else that ISP
feels comfortable with doing. But, sure, if the same ISP
wanted to make an absolute committment that a customer will
NEVER see more than some jitter value, it's necessary to
tread carefully. 

I'm not sure why you say it is a "statement about BE traffic
distributions". Maybe you can grab me and draw me a picture
in case I'm being dense. Yes, the DE utilization levels can
affect this, but this is why we went for a worst case NOT
what happens under lighter load.

	Kathie