Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS

From: [email-masked]
Date: Mon, 19 Jun 2000 16:06:16 +0300

If we use one CBR VC for everything and make sure that
the ATM switch system can deliver the CBR as promised,
we know that it works as designed because we have 
schedulers for each PHB at the IP level. 

If the ATM system can't deliver the promised CBR, then
we are in throuble. But if the ATM system can't do that
then it is eithet broken, wrongly configured or the network
improperly engineered for the services it needs to give.

When we are soing scheduling at the IP level, I don't
see much point in doing that again at cell level.
Doing strictly cell based scheduling at ATM cell level
can give quite strange results on the QoS. For example
if we are carrying 1.5 kilobyte IP packets through ATM
link (one IP packet takes 32 ATM cells or more). If we
would loose cell packet for every 10 000 cells sent
out randomly, we are effectively loosing one IP packet
for around every 300-400 packets because of lots cell 
in those packets (assumtation: the cell losses are
widely distributed and do not come in bursts). 

Strictly cell based handling of IP taffic in ATM world
is not a good idea. If we would try to do things on 
packet by packet basis on ATM switches, then we are effectively
trying to do things which are easy to do on IP level in
a very hard way on place where it is not convient.

For the effects of ATM traffic controlling the majority
of IP traffic I have run though ATM networks have been 
run on using CBR or UBR type of ATM connections, because
those are the most practical ways in real world to run
IP traffic on ATM networks. If you try ot use somethign else,
you generally run to much higher complexity, compatibility
problems within equipments and hassle without any
noticable benefits. I don't see any worth of the trouble
technical or pratcial reason to trying to use VBR for 
carrying diffserv IP traffic.

UBR is quite good on providing IP links which do not need any 
specific service classification or performance quarantees 
without much hassle. CBR connections are for those where 
service guarantees are needed. CBR is also the way to get a 
reliable deterministic transparent transmission media to
carry IP packets scheduled on IP level to give the
differentiated QoS for different IP flows. Based
on the original mail message I would use the following
combination:

1. For EF, use CBR.

2. For AFxy, use CBR.

3. For so-called best effort, use UBR.

That's my personal view from my personal experience.
To me it is no wonder why CBR and UBR seems to be 
the ways the tranfer IP packets on ATM based IP networks.

Tomi Engdahl

> -----Original Message-----
> From: EXT Mudassir Tufail [mailto:[email-masked]]
> Sent: 17. June 2000 1:16
> To: 'Brian E Carpenter'; [email-masked]
> Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS
> 
> 
> What about if packets have to traverse many ATM swicthes 
> before reaching the
> next IP router. I think in that you may want to have some 
> work at cell level
> as well in order to maintain service differentiation.
> 
> Mudassir
> 
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:[email-masked]]
> > Sent: Friday, June 16, 2000 2:03 PM
> > To: [email-masked]
> > Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS
> > 
> > 
> > "Manfredi, Albert E" wrote:
> > ...
> > > What can be said, at this stage? As far as I can tell, not 
> > much more than:
> > > 
> > > 1. For EF, use CBR.
> > > 
> > > 2. For AFxy, use VBR or ABR, or GFR.
> > > 
> > > 3. For so-called best effort, use UBR.
> > > 
> > > Does that tell you anything. For that matter, is it even correct?
> > 
> > As I said earlier, I would just use either one CBR VC for 
> everything,
> > or a separate CBR VC for each diffserv PDB. We know that works. What
> > is the advantage in complicating things with VBR etc.? We 
> will already
> > have schedulers for each PHB at the IP level, why do the work
> > again at cell level?
> > 
> >   Brian
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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

---

From: Scott W Brim <[email-masked]>
Date: Mon, 19 Jun 2000 09:44:33 -0400

>see much point in doing that again at cell level.

At intermediate ATM switches you are not doing anything at the IP 
level.  Some people expressed the desire to give packets the same 
queueing differentiation at the intermediate switches as they do at the 
edge IP routers.

>widely distributed and do not come in bursts).

Bad assumption.  See {early,partial} packet discard.

>without much hassle.

True.

>CBR is also the way to get a
>differentiated QoS for different IP flows.

If that's all you want.

...Scott