Subject: [Diffserv] Re: I-D ACTION:draft-mercankosk-diffserv-pdb-vw-00.txt

From: Guven Mercankosk <[email-masked]>
Date: Sat, 15 Jul 2000 13:37:26 +0800

Joel,

> I could not tell reading through your paper what the total limit on
> saleable "arbitrary destination VW" is.  It looks like you still have the limit
>
> min(i)(f_i*C_i)
>
> where f_i*C_i is the portion of link i devoted to EF.  Is this the limit on
> total saleable service?

Not at all.

That constraint comes into play when you allow for full IP re-routing flexibility.
Appendix F, provides numerical results to support the view that all you need to
consider is the min(i)(f_i*C_i). On the other hand, with IP re-routing flexibility
you can no longer assume a fixed propagation delay. Probably this point requires a
discussion on its impact.

If we allow for route pinning then the constraint is removed. I have just left both
options open for discussion.

Cheers,
Guven.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 16 Jul 2000 16:19:29 -0400

It is certainly true that with route pinning alternative limits are 
achievable (with the original definition or yours).
Part of what I look for to understand any of these definitions is what the 
traffic limit is.  The existing VW draft is quite clear and specific.  I 
could not tell whether you changed that.

Thank you for the reply,
Joel M. Halpern

>options open for discussion.

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

---

From: Guven Mercankosk <[email-masked]>
Date: Mon, 17 Jul 2000 14:26:21 +0800

Joel,

> could not tell whether you changed that.

Let me seek a clarification first. Are you refering to the EF bandwidth being
limited to half the link bandwidth, i.e. f<0.5?

Guven.

---

From: Guven Mercankosk <[email-masked]>
Date: Thu, 20 Jul 2000 18:41:15 +0800

Joel,

> Yes, I know that route pinning removes the restriction.  I believe I can
> now conclude that except for a small change in the constant, your proposal
> does not significantly change the limits from those already on the
> table.  That is what I was trying to determine.

The 0.5 limit is a superficial limit due the current EF-definition. It is being
addressed elsewhere. Hopefully when that issue is resolved than we will not have a
such limitation. Now when it comes to limiting the EF aggregate to a fraction 'f'
of capacity C is a totally different thing. It is a design parameter. It is a
target operating point. The actual aggregate input rate could be less but cannot
exceed 'f*C'. When it is less, the unused bandwidth is available to non-EF
traffic. So, there is nothing new there.

> Given that it does not change the limits significantly, can you tell me
> what is particularly new in your draft?

In the original document (March 2000), I believe that there were a couple points
overlooked. I used mathematical rigor to formalize a model so that those points
are clarified. Here are a few bullet points that highlight my contributions and
points of clarification.

 i) Extensions

    - the delay equalization of micro flows at the egress border router

    - the route pinning option

ii) Points of clarification

    - the delay equalization is necessary and not automatic.

    - the jitter window (the queueing delay bound) does not depend on virtual wire
rate R.

    - the delay due to non-EF flows does not necessitate additional bandwidth.

    - the possible impact of larger non-EF packet sizes on delay (could be
significant)

    - the relationship between the parameter alpha to the expected time to the
first failure

> The playback buffer was either implicit or unnecessary depending upon what
> service you were trying to give out the other side:
> o if you had a line matched to the ingress line, and VW at that speed, then
> one ended up definitionally with a playback buffer effect.

It is not automatic. Unless you introduce an equalization delay before the
transmission of the first packet onto the egress link. The concept of delay
equalization is well known for people dealing with the physical layer. It is an
application of the concept here. Intuitively, it can be seen as introducing a
slack time for the subsequent packets. However, in the original document there was
no mention of it. Also, the queueing delay bound is effectively the jitter window
of interest and it does not necessarily depend on the the virtual wire rate R.

> o if one was not concerned with the precision of the recreated signal, but
> only with the effective delivery of the traffic, then no playout buffer was
> necessary

If at the egress edge, you are connecting to another DS-domain for VW PHB, the
traffic will be strictly policed any way and it may result in a loss if the signal
is not recreated. However, by recreating the signal, the next DS-domain does not
need to know about the delay characteristics of the previous DS-domain.

> o alternatively, if one was not using matched channels, but was concerned
> with the playout shape then egress shaping, and the concomitant buffering
> was obviously necessary.

Again, the key point here is the delay equalization. Without it, the inter packet
timing imposed by the source could be lost. It, in effect, means the delay
characteristics of the DS-domain would be required at the final destination to
compensate for it. I think it is not the idea behind the VW PHB. Although my
model, as the original document, considers CBR flows only, the concept can be
easily extended to non-CBR case.

> Yours,
> Joel M. Halpern
>
> PS: I apologize if I sound somewhat argumentative.   I am just trying to
> understand what is new here so that I can look at it appropriately.

I appreciate the questions.

Thanks,
Guven.

> At 06:08 PM 7/18/00 +0800, you wrote:
>
> >Joel,
> >
> > > I am referring to the ef bandwidth being limitted to some proportion (0.5
> > > versus 0.9 is mathematically interesting  but not practically interesting)
> > > of the smallest single link in the core.
> >
> >Thanks for the clarification. Route pinning removes the restriction of
> >considering
> >the smallest single link. I believe that the updated VW document also
> >points out
> >this. As to the 50% of limitation, it has got to do with the definition of
> >EF PHB
> >rather than being a technical restriction. Anna Charny's group is
> >addressing that
> >issue. As to the 90%, it was only an example. Otherwise, 'f' is a design
> >parameter
> >and there is no restriction on it apart from the obvious limit of 1.
> >
> >Cheers,
> >Guven.
> >