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

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

My view for thing which should at least work (might not be optimal):

 1. For EF, use CBR.
 
 2. For AFxy, use CBR.
 
 3. For so-called best effort, use UBR.

> -----Original Message-----
> From: EXT Manfredi, Albert E [mailto:[email-masked]]
> Sent: 16. June 2000 23:20
> 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/

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 19 Jun 2000 17:10:37 +0300 (EEST)

tomi,

cbr/guaranteed reserves end-to-end bandwidth for each vc/lsp.  the idea
behind diffserv over atm or mpls is to reserve aggregate bandwidth for
each af class in each node/interface, not for each individual vc/lsp.
in order for this to work, there must be a means to tell, which af class
a vc/lsp belongs to so that its packets can be assigned in each node to
the correct queue.

-- juha

---

From: Scott W Brim <[email-masked]>
Date: Mon, 19 Jun 2000 10:57:27 -0400

>a vc/lsp belongs to so that its packets can be assigned in each node to

The theory with the ATM behavior class selector is that you use 
end-to-end signaling to install per-hop behavior.  Looks a bit like 
diffserv over MPLS except for those pesky VCs sometimes getting in the way.