Subject: RE: [IPTEL] urgent: ip telphony traffic model

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 8 Aug 2001 05:36:52 -0400

> I certainly agree that policing is critical. What do you see as
> "limited" in the policing capability of current routers? The routers I
> know intimately can police class-based aggregates at wire rates for
> pretty high values of "wire rate", and at the edge where the 
> wire rates
> are lower this isn't too challenging at all. In fact it's turned on by
> default on the routers I know intimately. Is your "limited" comment
> referring to the granularity of policing? Policing individual flows
> (class based) at the edge (or at least at IP address granularity) is
> doable on today's edge routers, and I would argue is not needed in the
> core.
The policing has to be done at the ingress into a carrier network.
So each individual customer flow must be policed.
If the outgoing flow of the egress router at the customer site could
be trusted, I agree it would be easier.
 
> > I do think that one big difference between audio/video and
> > the general purpose data bits is that there is the very 
> > real possibility of admission control.  That means only that 
> > you can fail more appropriately (return busy rather than 
> > poor quality audio/video).  This is admission control on
> > a Diffserv network (admission control with Intserv is
> > already there).
> > 
> Ah...you can do admission control on Diffserv by using RSVP with the
> DCLASS object. It's important to not mix flow-based
> classification/queuing versus class-based classification/queuing with
> having admission control versus not having admission control. 
> As long as
> your network conforms to the architectural assumptions of diffserv
> (bandwidth-rich clouds connected by bandwidth-controlled 
> links) you can
> do a fairly decent job of admission control if you ignore the focused
> overload problem. You just look at RSVP passing through the 
> inter-cloud
> links and do class-based aggregate admission on those links.
Not only do I believe that you can't ignore focused overload,
but I also doubt the viability of ISPs deploying DCLASS RSVP at the
level of a 64K audio stream.  We will see.

Brian 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 8 Aug 2001 05:58:19 -0400

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: Wednesday, August 08, 2001 5:37 AM
> To: 'David R. Oran'; 'Kiarash Bodouhi'; 'Henry Sinnreich'; 'Jerry'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> > pretty high values of "wire rate", and at the edge where the wire 
> > rates are lower this isn't too challenging at all. In fact 
> it's turned 
> > on by default on the routers I know intimately. Is your "limited" 
> > comment referring to the granularity of policing? Policing 
> individual 
> > flows (class based) at the edge (or at least at IP address 
> > granularity) is doable on today's edge routers, and I would 
> argue is 
> > not needed in the core.
Sure. This has to be done anyway to constrain customer bandwidth to the
contract as opposed to the speed of the physical interface between the
CE and PE. Everybody already does this today. The extra complexiy is
doing the policing on class-based aggregates rather than treating all
the customer's traffic identically. I'll reiterate that today's carrier
edge routers do this as part of their basic feature set.

> So each individual customer flow must be policed. 
I find your use of the term "customer flow" confusing. A given
customer's traffic consists of many simulataneous flows (unless you've
hidden the flows intentionally by stuffing them inside an IPSEC tunnel
at the CE, in which case you get what you asked for :-) ).

> If 
> the outgoing flow of the egress router at the customer site 
> could be trusted, I agree it would be easier.
> 
Well, for scalability yes, but I'm not making that assumption.

> > > I do think that one big difference between audio/video and the 
> > > general purpose data bits is that there is the very real 
> possibility 
> > > of admission control.  That means only that you can fail more 
> > > appropriately (return busy rather than poor quality 
> audio/video).  
> > > This is admission control on a Diffserv network 
> (admission control 
> > > with Intserv is already there).
> > > 
> > having admission control versus not having admission 
> control. As long 
> > as your network conforms to the architectural assumptions 
> of diffserv
Then by definition you don't believe in Diffserv. That's OK, (and I tend
to agree for many carrier cases) but people have to understand that
TANSTAAFL.

> but I also doubt the viability of ISPs deploying DCLASS RSVP 
> at the level of a 64K audio stream.  We will see.
>
Remember that you need RSVP protocol state at the edge boxes but *not*
flow state for this to work. You don't need RSVP protool state in the
core. In my depressed mode, I often dispair of the ISPs deploying
ANYTHING in the QoS domain. What I would argue is that once you write
and enforce QoS-sensitive SLAs, doing RSVP admission control at the
CE/PE boundary does not introduce significant extra complexity and in
fact might be simpler than other forms of SLA monitoring/enforcement.

Dave.