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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Aug 2001 11:38:10 -0400

I think we are getting pretty far ahead of ourselves, but it
could happen if we get a lot of, for example, video services.
Were that to happen, lots of the bits would be premium bits.
I'm not sure that we should spend a lot of time worrying 
about that now, but I also think we should be prepared to
deal with it some time in the not-too-distant future.
If that were to happen, we would have to lower the oversubscription
ratios we currently employ, and we would have to do much
better traffic engineering.

A part we need which we don't talk about much is policing.
Premium service only works if the network can limit the
amount of traffic marked premium.  The ability of routers
to police real time traffic is, aaah, limited.

I would point out that we could be embarrased by success --
if a large voice carrier decided to switch to a converged
network tomorrow, it would be the case that 50-90% of the
bits on its network would be voice bits.  The 10% number
that many toss around assumes the convergence happens over
time, at at the same time, the data traffic increases at
the rate it has been increasing.

The point Henry makes, which I agree with 100% is that WHAT
the traffic represents is not the descriminator on what
is done to the bits.  Premium data bits will be treated
as premium audio bits or premium video bits.

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).

Brian

> -----Original Message-----
> From: Kiarash Bodouhi [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2001 10:47 AM
> To: Henry Sinnreich; 'Rosen, Brian'; 'Jerry'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> 
> Hi,
> 
> What if the percentage of this premium services become 70% of 
> the actual
> bandwidth. In that case, what will be called premium? The 70% 
> part or that
> 30%?
> 
> Kiarash
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Henry Sinnreich
> > Sent: Tue, August 07, 2001 7:07 PM
> > To: 'Rosen, Brian'; 'Jerry'
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > Brian,
> > >I suspect
> > > that we will use things like different MPLS lsps for premium
> > > traffic in many cases.
> > 
> > Possibly agree, and the discriminator is not voice, but the word is
> > "premium" for whatever users want to pay more.
> > 
> > Henry
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Rosen, Brian
> > > Sent: Tuesday, August 07, 2001 1:38 PM
> > > To: 'Henry Sinnreich'; 'Jerry'
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > It may be that we do it with no special paths, but I 
> suspect that we 
> > > will use things like different MPLS lsps for premium 
> traffic in many 
> > > cases.
> > > 
> > > Whether we do or don't, understanding the traffic patterns is 
> > > important work.  I don't see much for the IETF to do with 
> it though.
> > > 
> > > Brian
> > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 07 Aug 2001 14:11:31 -0700

To amplify: Note that the policing behavior for premium traffic may well
depend on the traffic type. Dropping packets is fine for premium TCP,
but not for premium voice/video. (There, you'd want admission control.)

---

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

Couple of small comments/questions embedded:

> Sent: Tuesday, August 07, 2001 11:38 AM
> To: 'Kiarash Bodouhi'; Henry Sinnreich; 'Jerry'
> If that were to happen, we would have to lower the 
> oversubscription ratios we currently employ, and we would 
> have to do much better traffic engineering.
> 
> amount of traffic marked premium.  The ability of routers to 
> police real time traffic is, aaah, limited.
> 
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.

> I would point out that we could be embarrassed by success --
> bits on its network would be voice bits.  The 10% number that 
> many toss around assumes the convergence happens over time, 
> at the same time, the data traffic increases at the rate 
> it has been increasing.
> 
> the traffic represents is not the discriminator on what
> 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.

Dave.
> http://lists.bell-> labs.com/mailman/listinfo/iptel
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 08 Aug 2001 05:13:52 -0700

What's the granularity of policing? Can I police at the DSCP/IP
interface/IP src/dest level?

> doable on today's edge routers, and I would argue is not needed in the

It's needed at the interface level, i.e., I need to be able to say that
incoming interface 17 can't send more than X Mb/s of traffic to outgoing
interface 19.

---

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

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Wednesday, August 08, 2001 8:14 AM
> To: David R. Oran
> Cc: 'Rosen, Brian'; 'Kiarash Bodouhi'; 'Henry Sinnreich'; 
> 'Jerry'; [email-masked]; [email-masked]
> Subject: Re: [IPTEL] urgent: ip telphony traffic model
> 
> 
> What's the granularity of policing? Can I police at the 
> DSCP/IP interface/IP src/dest level?
>
Depends on the individual router platform. All the ones "I am intimately
familiar with" can do it at the DSCP/IP interface level. Some edge boxes
can do policing at the IP address level. Peoply who want to talk about
an particlar individual company's products should contact me privately,
as this isn't appropriate on an IETF list.

> > 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.
> 
> It's needed at the interface level, i.e., I need to be able 
> to say that incoming interface 17 can't send more than X Mb/s 
> of traffic to outgoing interface 19.
>
Hmmm, if you believe the Diffserv model I don't think the policing has
to be "pairwise". Each interface either goes "into" the cloud, or "out
of" the cloud. So, I would police on an ingress interface to the ingress
policy for the cloud, and separately on an egress interface which exits
the cloud to the policy for the egress link.

Dave.