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

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

Circo Systems provides a good note on ATM and IP network
QoS vs CoS effect on one of the documents in their web site:

"Note If the ATM network could not offer lossless transport despite the ATM
shaping on the router, the operation of the IP to ATM CoS feature would be
compromised for two reasons. First, because the ATM layer is unaware of the
IP Precedence and therefore of the "priority" of the transported packets,
ATM cell loss would be indiscriminate and thus would compromise the desired
service differentiation. Second, the desired sophisticated dynamic
interaction of WRED and TCP for proper congestion avoidance would be
affected, which could prevent WRED benefits such as avoiding TCP
synchronization and global oscillation."

Information source:
IP to ATM Class of Service Phase 1 Design Guide
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/ipatmd
g.htm

This is very Circo equipment centric document,
but can provide atleas one viewpoint to the situation.
Not derectly applicable to all DiffServ situations,
but the problematics on the QoS thing mappings are
in many ways similar.

> -----Original Message-----
> From: EXT Mohammed Atiquzzaman [mailto:[email-masked]]
> Sent: 16. June 2000 23:47
> To: [email-masked]
> Cc: 'Grenville Armitage'; Manfredi, Albert E
> Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS
> 
> 
> An issue related to DiffServ-ATM mapping (in addition to
> the mapping of the services) is the mapping of the drop 
> precedences from
> DiffServ to ATM.  The question is, even if can map AF to VBR 
> or ABR, how do
> we map multiple drop precedences from the Assured Service to 
> only two drop
> precedence of ATM (ATM has only one CLP bit to indicate the drop
> precedence).
> 
> Anyone has any thoughts or pointers to literature?
> 
> Regards
> 
> Mohammed Atiquzzaman       | Email: [email-masked]
> Department of Electrical & |        [email-masked]
>   Computer Engineering     | Voice: (937) 229 3183,
> University of Dayton,      |  (937) 229 3191 (sec), (937) 229 
> 4974 (lab)
> Dayton, Ohio 45469-0226.   | Fax:   (520) 962 8422 or (937) 229 4529
>                            | 
> http://www.engr.udayton.edu/faculty/matiquzz/
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> > Of Manfredi, Albert E
> > Sent: Friday, June 16, 2000 4:20 PM
> > To: 'Grenville Armitage'
> > Cc: [email-masked]
> > Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS
> >
> >
> > > -----Original Message-----
> > > From: Grenville Armitage [mailto:[email-masked]]
> > >
> > > John Schnizlein wrote:
> > >
> > >  [ ... ]
> > >
> > > > Dan's "by whatever name" refers to the linguistic debate spawned
> > > > by the attempt to move a litte closer to service specification
> > > > named "behavior aggregate" and renamed "per domain 
> behavior" (PDB).
> > >
> > > That part I understand, but I still dont see why DiffServ needs
> > > to define services before anyone can figure out what ATM
> > > level services can usefully support particular DS PHBs.
> > >
> > > > While we are out here in the weeds, note that the tidy 
> lawn view of
> > > > this is as Brian said - ATM virtual circuits connect router hops
> > > > through a virtual link. And the link behavior is part 
> of the per-hop
> > > > behavior.
> > >
> > > Well, that's pretty much what I said in different words. IP PHB
> > > is DS PHB + link service class. So what's the question that cannot
> > > be answered by this approach?
> >
> > I'm going to assume that ATM is used in part or all of the 
> diffserv domain
> > and that the approach used is to map diffserv PHBs to ATM 
> CoSs, or vice
> > versa.
> >
> > 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? I think
> > there is a lot more quantifying of services that needs to 
> be done before
> > anything meaningful can be said about mapping. It's 
> possible that the
> > diffserv wg will never go to that level of definition.
> >
> > In my view, once (or if) diffserv determines what EF means 
> in terms of
> > packet drop probabilities, latency, and jitter, and what 
> the different AF
> > classes mean in terms of peak, avergage, and min bit rates, drop
> > probabilties, and latency, then once can start working out real
> > equivalencies in terms of the kind of QoS an ATM setup 
> message must demand
> > when serving a diffserv domain.
> >
> > Or vice versa.
> >
> > Or am I missing something?
> >
> > Bert
> > [email-masked]
> >
> > _______________________________________________
> > 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: Juha Heinanen <[email-masked]>
Date: Mon, 19 Jun 2000 17:58:42 +0300 (EEST)

> synchronization and global oscillation."

the above is bullsh*t.  don't believe everything you read.  atm layer
can be made aware of the traffic class of each vc and and drop
precedence of each cell and (together with epd) can implement wred like
any packet switch.

-- juha