Subject: Re: [Diffserv] Assured Rate PDB

From: "Nabil Seddigh" <[email-masked]>
Date: Fri, 5 Jan 2001 15:30:07 -0500 (EST)

In message "[Diffserv] Assured Rate PDB", demir writes:

>   "The traffic aggregate will also have the opportunity
>   to obtain excess bandwidth beyond the assured rate."

>This sentence is kind of confusing because excess bandwidth 
>and assured
>rate are related to each other. Result is "beyond the assured
>rate". "assured rate" is not a deterministic metric. It is CIR that is
>deterministic. I think "excess resources" would be a better choice.
>

"excess" bw has been used extensively in previous work on 
the AF PHB. The AF RFC (2597) uses the word "excess" quite
a bit. In addition, many of the studies on AF-based services use the 
term "excess".  If I recall, the early draft by Clark & Wroclawski
used the term excess. 

>3) "The  PDB is  applicable  for  a  one-to-one,  one-to-few as well as
>   one-to-any types of service."
>
>It is not clear what this sentence means. I assume these are services
can
>be based on from ingress to egress?
>

You're correct. One-to-one means single ingress to single 
egress within a domain. One-to-any means single ingress to 
any egress within a domain. Do these terms need to be explicitly
defined in the document?

>
>5) "Regardless  of  the  traffic mix, the CIR for the aggregate will be
>    assured."
>
>This sentence is kind of confusing. What is "traffic mix"? is it
aggregate
>load? I assume traffic aggregate will have a assured rate. CIR is a
>parameter.
>

"Traffic mix" refers to different types of traffic within the aggregate.
The intention was to assure the aggregate CIR independent
of whether the traffic was TCP or UDP, bulk or interactive etc etc.

>6) "better treatment of individual short microflows within  an
aggregate"
>
>What does that mean? is it TCP with short connection times?
>

TCP flows with few packets. e.g 10 packets. This was an
example in the applicability section. 

>7) "The grouping of microflows into the traffic  aggregate  can  be
done
>   either  at  the  customer site or by the provider's ingress router
on
>   behalf of the customer."
>
>What do you mean by grouping?
>

Classification.

>9) "In the case of one-to-any services, the PDB can be utilized to
assure
>   a  rate for a traffic aggregate that originates from one ingress
node
>   but whose individual five-tuple flows may exit the domain at  any
of
>   the egress nodes."
>
>   I am confused here. How do you define a "traffic aggregate"?
Actually,
>It is not clear what you mean by "one-to-any" services.
>

The above actually tries to provide an explanation of one-to-any. 

Regards,
Nabil

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: demir <[email-masked]>
Date: Fri, 5 Jan 2001 14:42:12 -0800 (PST)

Nabil,
> term "excess".  If I recall, the early draft by Clark & Wroclawski

I didn't mean the word "excess". It means what it is. It is
"resource" instead of "bandwidth". However, my main point wasn't that. It
was on the "excess bandwidth beyond the assured rate".
i) To me, "bandwidth" word should not be used when it is compared or
related to "assured rate". 
ii) It is not "excess bandwidth" only. I'll get that point. If "excess
bandwidth" is meant to be used than it is either "excess
bandwidth" (I assume that's what you meant) or "excess bandwidth beyond
configured service rate/configured bandwidth". 
iii) Here is a segment from AF PHB:
  "An AF class MAY also be configurable to receive more forwarding 
   resources than the minimum when excess resources are available either
   from other AF classes or from other PHB groups.  This memo does not
   specify how the excess resources should be allocated, but
   implementations MUST specify what algorithms are actually supported
   and how they can be parameterized."

Forwarding resources are defined as:
   "A DS node MUST allocate a configurable, minimum amount of forwarding
   resources (buffer space and bandwidth) to each implemented AF class. 
   Each class SHOULD be serviced in a manner to achieve the configured
   service rate (bandwidth) over both small and large time scales."

Please note that "excess resource" is used (even it is not "excess
forwarding resources". I am not sure if this is intentional or not. To me,
it makes sense).
-----------------------

An Example PDB in AF PHB:
   "In a typical application, a company uses the Internet
   to interconnect its geographically distributed sites and wants an
   assurance that IP packets within this intranet are forwarded with
   high probability as long as the aggregate traffic from each site does
   not exceed the subscribed information rate (profile).  It is
   desirable that a site may exceed the subscribed profile with the
   understanding that the excess traffic is not delivered with as high
   probability as the traffic that is within the profile."

I assume in AR PDB traffic aggregate is the total of the aggregate traffic
from each site and how to control aggregate traffic from each site is an
open issue?

> any egress within a domain. Do these terms need to be explicitly

To me, they do. Cause, when I read at first, I was shocked :)

> >   but whose individual five-tuple flows may exit the domain at  any

Traffic Aggregate: a collection of packets with a codepoint that 
maps to the same PHB, usually in a DS domain or some subset of  
a DS domain.

From my understanding, "traffic aggregate" does not specify anything about
origin and direction of flows/microflows. By default, each flow in a
"traffic aggregate" may exit the domain at any of the egress nodes. It
seems, by your definition, "traffic aggregate" is from one ingress to one
egress only. am I missing something?

Alper K. Demir

---

From: [email-masked]
Date: Sun, 7 Jan 2001 22:04:52 -0500 (EST)

>> assure a  rate for a traffic aggregate that originates from 
>> one ingress node but whose individual five-tuple flows may exit 
>> the domain at  any of the egress nodes."
>

The draft does not constrain the definition of "traffic aggregate"
as you interpret it above. The traffic aggregate for the AR PDB
can be used in one-to-one, one-to-any and one-to-few scenarios.
This is explicitly stated in the draft.

Your note above implies that all traffic aggregates treated
by a PDB will be for a one-to-any scenario. This is not the
case. The Virtual Wire is an example of a Diffserv PDB 
to be used solely in a one-to-one (one ingress to one egress)
scenario.

Best,
Nabil

---

From: [email-masked]
Date: Mon, 8 Jan 2001 14:33:17 -0500 (EST)

Just to confirm: the intention of  the Assumption section was
not to specify a particular method for achieving the requirements
of the PDB. Rather, it was to capture the assumption of low
loss for green packets.

The paragraph can be reworked along the lines of what Alper
suggested.

Best,
Nabil

>Alper,
>
>You are right, the mechanisms to achieve the low loss probability,
>should be left open.
>Traffic engineering with what ever means is one example, others could
be
>admission control,  network planning, or other management operations.
>
>Marcus
>
>demir wrote:
>> 
>>    "6.0 Assumptions
>> 
>>    The assumption is that the network operator  monitors  the  level
of
>>    green  packets  in  the  selected  AF  class  on  all  links  and,
if
>>    necessary, takes traffic engineering actions to keep  the  level
low
>>    enough  so that the likelyhood of green packets being dropped in
case
>>    of congestion is very low."
>> 
>> Can this be more generalized as: The network is well-provisioned
enough so
>> that the likelyhhod of green packets being dropped in case of
congestion
>> is very low. If necessary, network operator takes traffic engineering
>> actions. One way of achieveing this is that network operator monitors
the
>> level of green packets in the selected AF class on all links.
Provisioning
>> of the network is out of scope of this draft.
>> Just a suggestion.
>> 
>> Alper K. Demir
>>

---

From: Larry Ayres <[email-masked]>
Date: Mon, 08 Jan 2001 14:48:01 -0800

Nabil,
  I haven't been in this newsgroup from day one, so I am lacking some of
the history. Perhaps then, from reading the draft, when I seemed to see
assurances being given for service, without qualifications being made
regarding time intervals or relationships of time intervals, I couldn't see
how the assurances could be made.

  I guess what I am hearing from you and Brian is that the time
relationships are beyond the scope of this draft, but understood to exist.
I can live with this. It does however, make the draft harder to understand
as a stand-alone document, when the assumptions are not explicitly defined
at the start, at least in general or relative terms.

Thanks,
Larry Ayres

At 10:35 PM 1/7/01 -0500, [email-masked] wrote:
>
>>
>>Given fairly long time intervals
>>for rate measurement, it may be possible to assure a rate on a packet
>>stream with delay and jitter, as long as the delay and jitter times are
>>less than the measuring interval and the link speed is sufficient to accept
>>the traffic.
>>
>>It would seem to be necessary to state some basic time relationships. I see
>>that these are touched upon in section 7.0 Example Uses, but I am concerned
>>that they should be stated up front and the scope or limitations of what is
>>being proposed are explicit and well known.
>>
>
>Larry:
>
>Are you saying that you would like jitter and delay values 
>to be associated with the parameters that describe the PDB behaviour?
>If so, we should acknowledge that aggregate behaviours based on 
>the AF PHB have long been discussed soley in the context of 
>assuring a rate. Your note is the first time I've seen any 
>interest expressed in associating some sort of
>delay and jitter with the rate for AF-based PDBs. 
>The whole motivation behind the AR PDB is to provide
>a service with statistical assurance - without worrying about
>guarantees for time-scales on the order of a packet or two.
>
>Of course, as you note, the rate would need to be 
>associated with either a measurement time interval or bucket sizes.
>The draft requires such a parameter to be specified along with the cir.
>However, the draft does not constrain the particular parameter 
>to be used as it will depend to some extent on the policer 
>algorithm used in the edge routers for the domain.
>
>Your note mentioned section 7 of the draft. Are you suggesting
>that we flesh out that section in greater detail?
>
>Regards,
>Nabil Seddigh
>
>
>
>
>
Larry Ayres

---------------------------------------------------------
Lawrence Ayres
Principle Software Engineer

Ericsson Datacom, Inc
IP Network Edge & Access Product Unit
Data Backbone and Optical Networks
70 Castilian Drive
Santa Barbara, CA 93117
[email-masked]
Phone: 805-562-6656
---------------------------------------------------------

---

From: demir <[email-masked]>
Date: Tue, 9 Jan 2001 02:08:35 -0800 (PST)

Nabil,
> to be used solely in a one-to-one (one ingress to one egress)

I am not sure if we are on an aggrement on this. Here is a section taken
from VW PDB:

"For scalability, a diffserv domain supplying this service must be
completely unaware of the individual endpoints using it and sees instead
only the aggregate EF marked traffic entering and transiting the
domain."
"Despite the lack of per-flow state, if the aggregate input rates are
appropriately policed and the EF service rates on interior links are
appropriately configured, the edge-to-edge service supplied by the domain
will be indistinguishable from that supplied by dedicated wires between
the endpoints."

To me, VW PDB (also AR PDB because AR PDB "assumtion" leads that
way) makes the PDB from any edge to any edge that is any-to-any. As a
result, on-to-one, one-to-few, and one-to-any is supported by
default. There is no need to talk about them at all unless you have a
special case definition for a behavior aggregate such as classification
actions are taken so that each individual behavior aggregate is from one
ingress to one egress. Please, let me know if I am misinterpreting
something.

Alper K. Demir

---

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Jan 2001 07:09:36 -0800

Hi,

I think the AR PDB, is assuring that all the packets with an "INPUT" rate of less than CIR will be delivered (with high probability). So the committed rate is measured at the "input" during a specified measuring period, and therefore is independent of the delay/jitter that the aggregate experiences in the Diffserv domain. By using a jitter buffer with appropriate depth at the egress point of the network, any jitter can be absorbed.

Yours,
-Shahram

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Monday, January 08, 2001 9:17 AM
> To: [email-masked]
> Cc: Larry Ayres; Seddigh, Nabil [CAR:0C24:EXCH]; [email-masked];
> Nandy, Biswajit [CAR:0C40:EXCH]; [email-masked]
> Subject: Re: [Diffserv] Assured Rate PDB
> 
> 
> Nabil,
> 
> I agree with Larry, that some kind of time relationship is needed. In
> your draft, you basically left it to the traffic parameters. Isn't it
> possible to have a time parameter, which is general enough to be used
> with different mechanisms?
> 
> Marcus
> 
> [email-masked] wrote:
> > 
> > >
> > Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

---

From: "Nabil Seddigh" <[email-masked]>
Date: Tue, 9 Jan 2001 12:29:59 -0500 (EST)

>relationships are beyond the scope of this draft, but understood to
exist.

Yes and no. There is no jitter/delay association with respect to the
AR PDB parameters. However, the draft does require additional
parameters to indicate a time relationship over which the rate
is policed at the ingress. The following is taken from the 
"Rules" section:

**  The filter  MUST  be  associated  with  a  traffic
** profile  that  specifies  committed  information  rate  (CIR)  AND  a
** description on how it is to be measured. For example, the measurement
** may  be  based  on  a committed burst size (CBS) or an averaging time
** interval (T1).

>at the start, at least in general or relative terms.

If you have specific suggestions for stating such assumptions and
the sections which you feel these assumptions could be placed,
please feel free to put them on the list or email the authors.

Thanks,
Nabil

---

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Jan 2001 12:16:50 -0800

Demir,

> > > 2)
> > > rate are related to each other. 
> > 
> > I don't see any relationship at all between excess BW and 
> assured rate. You can have zero excess BW or very very large 
> excess BW regardless of the assured rate. Why do you think 
> they are related?
> 
> That's what I mean. I don't see any relationship. That's why "excess
> bandwidth beyond assured rate" phrase doesn't make any sense to me.
> 

I have answered this by an example in my previous email.

> > Result is "beyond the assured
> > > deterministic. 
> > I don't see any difference between these two.  Assured rate = CIR
> 
> I am not sure if: assured rate = CIR. If it is, then I guess 
> I'm wrong.
>

I am sure it is.

-Shahram
 
ent/maillist.html

---

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Jan 2001 13:55:38 -0800

Hi,

I had a minor mistake in my previous email. The 50Mbits/s excess traffic that I mentioned is the difference between the CIR and the actual delivered traffic. So the excess BW in that example is 150-100 = 50Mbits/s

-Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Tuesday, January 09, 2001 3:14 PM
To: 'demir'
Cc: Nabil Seddigh; [email-masked]; Biswajit Nandy; [email-masked]
Subject: RE: [Diffserv] Assured Rate PDB

Demir,

> "I think the AR PDB, is assuring that all the packets with an 
> "INPUT" rate
> of less than CIR will be delivered (with high probability)."
> Q.1. What is "assurance"?
> Q.2. What is "assured rate"?
> Q.3. What is "excess bandwidth"?
> Q.4. What is "excess bandwidth beyond assured rate"?

1) "Assurance" means guaranteeing something with a very high probability. In the AR PDB context it means guaranteeing delivery of green packets with very high probability.
2) "Assured rate" means the maximum rate that a customer can send AR PDB packets to the network and be sure that they will be delivered.
3, 4) "Excess bandwidth" and "excess bandwidth beyond assured rate" both mean the input traffic that is in excess of the assured rate (CIR) that is not guaranteed but can still make it to the egress of the network.

As an example assume an AR PDB that guarantees 99.99% delivery of packets, when the input rate is below 100Mbits/s (CIR). Now if a customer sends 200Mbits/s AR PDB traffic and the network delivers 150Mbits/sec of his/her traffic, then the extra 50Mbits/s (200-150) is called the excess bandwidth.

Yours,
-Shahram

---

From: "Nabil Seddigh" <[email-masked]>
Date: Tue, 9 Jan 2001 17:46:25 -0500 (EST)

>I am not sure if: assured rate = CIR. If it is, then I guess I'm wrong.
>
>Alper K. Demir
>

Yes: the draft equates assured rate to cir.

Nabil

---

From: demir <[email-masked]>
Date: Wed, 10 Jan 2001 10:44:01 -0800 (PST)

Below was my whole point besides some misleading terminology. That's why I
used "approximates".

Alper K. Demir

On Wed, 10 Jan 2001, Nabil Seddigh wrote:

> The term "guaranteed" has certain historical connotations from
> Intserv. It implies providing more rigorous guarantees for 
> the traffic than AR provides. 
> 
> I don't think we will be changing the name from assured rate
> to guaranteed rate.
> 
> Nabil
> 
> >
> >If it equates assured rate to cir, then it is "guaranteed rate". I
> would
> >say the draft aproximates assured rate to cir.
> >
> 
>