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

From: Bill Courtney <[email-masked]>
Date: Wed, 14 Jun 2000 13:21:20 -0700

Bert,

I talked with our delegate to the ATM Forum. He said that the consensus
at the last meeting (late May in San Francisco) seemed to be along the
lines of your comment following your point 2, namely that the details of 
DiffServ had to be completed by the IETF before the ATM Forum could make 
a direct mapping to ATM QoS.

Bill Courtney
TRW, Network System Engineering

> -----Original Message-----
> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Wednesday, June 14, 2000 7:00 AM
> To: [email-masked]'
> Cc: [email-masked]
> Subject: [Diffserv] RE: Mapping IP QoS Info to ATM QoS
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > 
> > Hello,
> > I have a doubt regarding mapping QoS attributes..
> > 
> > Attributes like Token Bucket Rate etc.. are being used in 
> > RSVP and similar resource reservation techniques which are IP 
> > based. If the link is ATM, how are these mapped to ATM QoS? 
> > Is it implementation specific or are there any standards to 
> > dictate this?
> 
> There is work in progress at the ATM Forum that addresses 
> this issue, but it
> hasn't made it to the approved specs folder of their web 
> site, it seems.
> Maybe someone who is still a member can provide more updated info.
> 
> With respect to diffserv compatibility, the general idea is 
> to take two
> possible approaches:
> 
> 1. You use ATM like any other link layer, UBR, and literally 
> apply the same
> queueing solutions diffserv comes up with, at the ATM 
> switches. This is sort
> of the LANE philosophy, where ATM's own native capabilities 
> are not used to
> their fullest extent, but rather the IP solutions are layered 
> on top of ATM,
> and ATM emulates (to the extent possible) a connectionless 
> broadcast LAN.
> 
> 2. You rigorously map ATM CBR, VBR, etc. CoS to diffserv EF 
> and AFxy. This
> second strategy is presented only in an appendix, though.
> 
> Of course, #2 cannot at this stage be rigorously standardized, because
> diffserv itself has no specific implementations quantified yet.
> 
> 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: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jun 2000 17:01:04 -0500

Bill,

But which details are they missing? We've defined the PHBs and the issue
is how those PHBs map to ATM QoS parameters on an ATM hop. There is
nothing in the diffserv work plan that takes PHB definitions any further.

If the ATM Forum is waiting for something, they'd better tell us what it is.

> > second strategy is presented only in an appendix, though.

This is expressed backwards IMHO. The need is define an ATM VC
with appropriate QOS to act as an EF hop, an AF hop, or of course
a Best Effort or Class Selector hop. Personally, I'd use CBR for
everything, but that just my simplistic nature. 

  Brian Carpenter
  diffserv co-chair

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]

---

From: Scott W Brim <[email-masked]>
Date: Thu, 15 Jun 2000 20:38:58 -0400

The *mechanisms* for mapping from PCS/PHB to ATM VC signaling is 
well-defined.  The ATM Forum, just like the IETF, has declined to say 
(yet) how you build IP services or even PDBs using that mechanism.  Once 
the objectives of an IP service (or PDB) are clear, it should be easy to 
say how to do the mapping, and may not be a matter for standardization 
anyway.

There is one problem I think will continue to be Hard, which is that the 
ATM VC is often not going to originate at the edge of the diffserv 
region, so the node which is doing the ATM signaling is not going to have 
the information it needs to know what IP *service* the VC is supposed to 
support.

...Scott

---

From: Dan Grossman <[email-masked]>
Date: Fri, 16 Jun 2000 11:18:27 -0400

> say how to do the mapping, and may not be a matter for standardization 
I'll echo that.  The problem is that mapping local per-hop behaviors onto 
services is not very useful.  You want to map services (by whatever name) onto 
services.   I think that once we have the long-awaited PDB draft (hint, hint!) 
and an opportunity in the Diffserv working group to discuss it, the ATM Forum 
can begin to make progress toward useful mappings.   

This is also a problem in 3GPP, with some added complications.  Including the 
fact that 3GPP doesn't seem to share our understanding that PHBs are not 
end-to-end services.

Dan

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 16 Jun 2000 10:28:31 -0700

Dan Grossman wrote:
	[..]
> services.

See, now here I'm confused. Seems to me that the temporal
characteristics of an IP hop is the result of the PHB instantiated
by the router feeding the link concatenated with the e2e *service*
provided by the link itself. In other words, "actual IP PHB" is
really "DS PHB + link service".

Isn't it possible to come up with a set of ATM service classes for
VCs being fed by AF or EF queues such that the nett temporal behavior
from one IP/ATM router to the next is predictable and useful?

Or am I off in the weeds here and missing the point of the thread :)

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: John Schnizlein <[email-masked]>
Date: Fri, 16 Jun 2000 14:07:47 -0400

Answer below -
At 10:28 AM 06/16/2000 -0700, Grenville Armitage wrote:
>Dan Grossman wrote:
>	[..]
>> I'll echo that.  The problem is that mapping local per-hop behaviors 
>> services is not very useful.  You want to map services (by whatever 
>> name) onto services.
>

Yes, your confusion is missing Dan's point.
And Dan's point is a fundamental (if still overlooked) aspect of the 
DiffServ specification - justifying this ATM discussion on the list.

Since ATM services are end-to-end, and PHBs are not, it is necessary
to form an end-to-end (or at least edge-to-edge or cross-domain)
service level for comparison to the ATM service level. The service
level is determined by the PHBs along the path, but also by other 
things, as you note.

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

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.

John

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 16 Jun 2000 11:36:30 -0700

John Schnizlein wrote:
	[..]
> service level for comparison to the ATM service level.

But why? Perhaps I missed the question (which I thought was
triggerd by someone saying the ATM Forum is waiting for DS
services to be defined before it could figure out mappings
from PHBs to VC service classes).  If I've gotten the question
right, I dont see the above as a 'necessity'.

	[..]
> 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.

> through a virtual link. And the link behavior is part of the per-hop

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?

cheers,
gja

---

From: Scott W Brim <[email-masked]>
Date: Fri, 16 Jun 2000 17:17:16 -0400

>level services can usefully support particular DS PHBs.

For particular PHBs, sure, for example we have good clues what services 
EF might be used for (and we would want to lump them all in one or a few 
CBR or rtVBR VCs) ... but if all you see is a packet marked AF11, you 
have no clue what traffic parameters the stream that packet belongs to is 
conforming to, so you have no clue what kind of VC to set up.  This is 
true with or without the new Behavior Class Selectors.  What's the 
customer's goal?  Low loss?  How much burstiness etc.  Naturally I'm 
succumbing to my usual inclination and going right for the big problem 
with diffserv-ATM interworking, which is that there is no good mechanism 
for the node where the VC originates to get the knowledge it needs to set 
up that VC.  Note, also, that different IP services/PDBs can use the same 
PSC, and PSC->BCS *might* be one-to-many (sigh).

When you don't know what the actual desired service/PDB is, the BCS at 
least allows you to get a little bit closer to doing what the customer 
wants -- default to using a UBR pipe, and and set the BCS directly from 
the PSC.  It would be nice to do better.

...Scott

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 16 Jun 2000 14:56:32 -0700

Scott W Brim wrote:
	[..]
> but if all you see is a packet marked AF11, you
> conforming to, so you have no clue what kind of VC to set up.

Why even ask the question? As brian notes, the simplest initial
deployment would be to use CBR and let the packet level scheduler
mediate between different DS aggregates sharing the CBR VC. At
least someone might document that as a start.

Once you start utilizing non-CBR VCs whose temporal characteristics
can themselves fluctuate with time and load, what will it even
mean to configure a packet level scheduler with certain weights
and queue drop thresholds for AFxy? Wierdness will abound, no?

cheers,
gja

---

From: Siamack Ayandeh <[email-masked]>
Date: Mon, 19 Jun 2000 09:34:20 -0400

Scott W Brim wrote:

> up that VC.

Scott, if all you see is a packet marked AF11, you have the same information
whether you have ATM or IP.  In a hop by hop case the service provider still
has to provision resources for all the interfaces involved.  Fortunately a
network
also has information about which interface the AF11 packet came from.
Associated with the interface is a SLS etc etc.  So life is not as bleak as
it
seems.

Regards, Siamack

---

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

>Associated with the interface is a SLS etc etc.  So life is not as bleak as

Granted, it's not terrible.  The ATM edge can just use UBR[+MDCR] or CBR 
and the ATM cloud can act like a dumb IP forwarder.  The better we can 
do, the better we can do.  On the other hand the way things are going, 
ATM is getting to be more and more of a local matter, and by the time we 
could get this kind of signaling in place it might not be worth deploying.

...Scott