Subject: RE: [Diffserv] clarifications on new terms (draft-ietf-diffser v-new-terms-04)

From: "Chen, Cheng" <[email-masked]>
Date: Thu, 3 May 2001 15:06:16 -0500

Brian,

May be I misunderstood something. let me try again.

Suppose we have 400 voice calls each requires 64 K bps,which are classified
as EF traffic. How many bandwidth do we need to allocated to EF service
class? 400* 64 k or just 100*64K? Please comment on this.

Best Regards,
Cheng C. Chen

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 2:49 PM
To: Chen, Cheng
Cc: [email-masked]
Subject: Re: [Diffserv] clarifications on new terms
(draft-ietf-diffserv-new-terms-04)

Not the way I understand EF. The rate is guaranteed.

   Brian

"Chen, Cheng" wrote:
> 
> Brian,
> 
> It seems to me that EF might be able to do overbooking also since not all
EF
> traffic will be in active state
> even in the "busy (peak) hour". Just think of the voice traffic, during
busy
> hour a 4-to-one or 8-to-one concentration ratio (overbooking) is
frequently
> used". Would you comment on this?
> 
> Cheng C. Chen
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 12:10 PM
> To: Sergio Andreozzi
> Cc: [email-masked]
> Subject: Re: [Diffserv] clarifications on new terms
> (draft-ietf-diffserv-new-terms-04)
> 
> Sergio,
> 
> Some PHBs explicitly allow for over-booking of capacity and for the
> dropping of packets due to instantaneous overload. AF is an example.
> If you are over-booking the total capacity, it is clearly not
mathematically
> possible for the behavior aggregates to be independent, since excess
traffic
> in one aggregate will compete with the excess in another.
> 
> Even in the case of EF, where no over-booking is allowed, if two EF
> aggregates
> are sharing a link, they will influence each other's jitter.
> 
>   Brian
> 
> Sergio Andreozzi wrote:
> >
> > Hi everybody,
> >
> > could you tell me if the following sentences are correct? (If no, please
> > comment why):
> >
> > 1. PHB groups (a single PHB is a special case of a PHB group) MUST
operate
> > entirely independently between each other
> >
> > 1. _instances_ of a _type_ PHB group MUST operate entirely independently
> > between each other
> >
> > 2. to operate entirely independently means each _istance_ of PHB
receives
> > individual buffer space and bandwith, and mechanisms that implement it
> don't
> > use any information coming from mechanisms that implement a different
> > _istance_ of PHB
> >
> > 3. Class selector PHB requirements specify how PHB associated to
> codepoints
> > xxx000 should behave for backwards compatibility;
> >    we can assert these PHBs operate indipendently, being single PHBs
> >
> > Thanks
> >
> > Sergio Andreozzi

_______________________________________________
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: Kathleen Nichols <[email-masked]>
Date: Thu, 03 May 2001 14:17:38 -0700

> class? 400* 64 k or just 100*64K? Please comment on this.

...

The answer is clearly "it depends". Primarily because you seem to be
mixing a "customer-visible service" with the configuration and
provisioning choices that might be made on a network. Note, there is
no such thing as an "EF service class". If a provider wants to handle
400 simultaneous calls that can hit 64K peak rates, then there'd
better be 400*64K bandwidth available (and some other requirements,
too).
If a provider has 400 total subscribers but knows from old style
telco work or some other observations that the likelihood of more than
100 subscriber making active calls at once is almost zero AND has some
mechanism for giving a "busy signal" if this should happen, then it's
probably just find to be able to deliver EF (as I understand it) up
to a rate of 100 * 64 kbps. But understand that the issues of how
the service to the customer looks and so on are really a level above
the diffserv tool box.

	Kathie