Subject: Re: deploying reservations....

From: [email-masked] (Mark W Garrett)
Date: Thu, 22 Jun 1995 15:59:12 -0400

This got a little long, but it's basically about why we're forced
to map between the IP flowspec to the ATM QOS/Traffic descriptors.

 > Jon,
 > Your proposal clearly does not relate to large clouds.  It should be
 > noted, however, that your suggestion about doing 'QoS cut-through' with
 > ATM does appear to be closely related to the "cell-switch router"
 > architecture proposed at the colip-atm BOF.  Your X would play the role
 > of their router component, I think.
 > Cheers,
 > Bob

Actually, I think Jon's model is exactly opposite the COLIP model,
in some senses:  Jon interconnects IP links with an ATM node, while
COLIP interconnects ATM links with an IP node.

Crowcroft model                                    .---.
(= conventional IP over           <----->IP-Router-|ATM|-IP-Router<----->
 ATM-cloud QOS-mapping problem):                   .---.

Colip model                                     .---------.
(= QOS scheduling in router,       <------->ATM-|IP-Router|-ATM<-------->
 but transport interfaces are ATM):             .---------.

The Colip argument (or one of them) is that QOS should be handled on
a global basis, by the *inter*network, because each subnet has
different properties, and you need something to unify the overall
quality of the connection.  (Perhaps analogous to routing and
addressing.)  Therefore, the ATM cloud only should provide
limited-capability pipes, and to effect any QOS-related function, e.g.
scheduling, we have to pop back up to the IP layer, and do it in a
router.  So the links might look like ATM, or go across an ATM cloud,
but the "true" nodes in the network are always IP routers.
(I disagree with the efficacy of this model myself, see below---but
that's my understanding of their expressed view.  If I've
just put ill-flavored words in someone's mouth, I trust that
I'll be corrected.)

Crowcroft's model is that you have an Internet path which crosses a
single ATM switch, which functions e.g. as a NAP.  Then the question
is what QOS to request from the ATM connection, given that you know
something about the flowspec of the internet connections (flows).

While Jon's case certainly has no large cloud in it, the same question
does arise when the ATM part is a cloud instead of the single switch.
Here we can map the QOS requirements of the flow to the QOS
requirements of the VC across the ATM cloud.  If ATM provides
completely isolated connections, like "guaranteed pipes", then
the problem is rather uninteresting.  If, however, the ATM QOS
menu is rich, then the ATM connection can be set up to correctly allow
the traffic from a flow to share resources with other similarly
QOS-ed flows.  If the behavior in the ATM scheduler (essentially
the policy of isolation and sharing) is very close to what would
happen in the IP w/ QOS router scheduling, then all of the
efficiency and QOS benefits of proper traffic management
can be obtained in the ATM cloud.  So the end to end route can
be chosen to run through ATM-based networks and/or IP-based networks
(in the sense of network providers) as is convenient.

If the ATM cloud *cannot* effectively combine streams, and has
to provide plain-old isolated pipes to effect any QOS at all,
then we're in trouble, and the Colip assumption becomes correct.
Two specific examples come to mind where the large cloud has
to combine flows.  One is statistical multiplexing for efficiency:
N flows come into a switch, and each requires a 1 Mb/s pipe
to provide good QOS if it's isolated (e.g. in the access from
the customer site to the first switch or router).  However,
when combined, proper QOS can be achieved if the set of flows
shares 0.1 * N Mb/s.  The second example is point-to-multipoint.
If the ATM cloud doesn't know how to do it, then we have to
buy a lot of redundant pipes across the cloud.

So, when the ATM technology cannot provide this QOS and multipoint
functionality, the efficiency decreases rapidly with the size
of the cloud, and one "solution" would be to force the flow
to pop up into the IP-router layer for appropriate flow sharing,
combining, splitting, etc.  This implies very small ATM clouds
between routers, which is the Colip point of view.

My opinion, of course, is that it's much easier and more effective to
make the ATM technology work right in the first place.  This does
mean that QOS for a flow becomes the concatenation of the QOS primitives
available over the path, which isn't as pure and pretty as having
a globally consistent QOS paradigm. But heterogeneity has been
thrust upon us by the market, not to mention the convergence of
telecom and datacom, like it or not.  As long as the QOS machinery
is rich enough at all the queueing points, it should be possible
to make effective and efficient translations between technologies.

-Mark

-------------------------------------------------------------------------------
			Bellcore				+1 201 829-4439
Mark W. Garrett		445 South St.  Rm. 2L-237	[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
			WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: [email-masked] (Hiroshi Esaki)
Date: Thu, 22 Jun 1995 19:51:53 -0400

Hi Mark, 

I am afraid that this discussion may not be associated with int-serv ML.
But, please let me try to respond to Mark's comments. 

 mwg> This got a little long, but it's basically about why we're forced
 mwg> to map between the IP flowspec to the ATM QOS/Traffic descriptors.
How to map IP flowspec and ATM QOS/Traffic descriptors is very 
interesting work. 
But, I think, one to one mapping between IP flowspec and ATM QOS/Traffic 
descriptor is just one case, even when the ATM networks provide 
variety types of VCCs. 
I mean some IP flows will be aggregated into ATM-VCC, in some cases. 
One to one mapping is ideal case, but this is not the only case. 
Of course, one to one mapping will be the ideal case, but we can not 
assume all IP flows are identically mapped with the corresponding 
ATM-VCCs.    I think, though ATM will have a potential to provide 
variaty of QOS-ed pipe for IP packet flows, ATM pipe is still datalink 
pipe. 
I may be wrong..... 

And, one point Mark seems to missing, regarding large cloud ATM, may be 
how to provide a large scale soft-state (RSVP-type) multicast. 
In order to provide a large scale soft-state multicast, we can not 
use a large scale datalink multicast connection as discussed in the 
colip-BoF.  We need routers on the large cloud networks to provide 
scalable soft-state IP multicast. 

 bob> Jon,
 bob> noted, however, that your suggestion about doing 'QoS cut-through' with
 bob> ATM does appear to be closely related to the "cell-switch router"
 bob> architecture proposed at the colip-atm BOF.  Your X would play the role
 bob> of their router component, I think.
 bob> Bob

 mwg> Actually, I think Jon's model is exactly opposite the COLIP model,
 mwg> in some senses:  Jon interconnects IP links with an ATM node, while
 mwg> COLIP interconnects ATM links with an IP node.
 mwg> 
 mwg> Crowcroft model                                 .---.
 mwg> (= conventional IP over        <----->IP-Router-|ATM|-IP-Router<----->
 mwg> ATM-cloud QOS-mapping problem):                 .---.
 mwg>
 mwg> Colip model                                  .---------.
 mwg> (= QOS scheduling in router,    <------->ATM-|IP-Router|-ATM<-------->
 mwg> but transport interfaces are ATM):           .---------.

If we see the [ATM] part in Jon's model as a ATM switch, the Jon's 
model could see as a large scale router. 
Then, [ATM] part can be equivalent to the a back plane bus or switch 
in the router, i.e. the interconnecting module among the distributed IP 
processing modules. 
  Now, my concern on Jon's model is the performance of IP router 
modules, "IF" the input and output links is not low speed.
Here, Jon's intention and assumption is that input/output links of 
IP router module is not high speed, compared to [ATM] part's 
performance, I guess.  
  "IF" the input/output links are high speed, we may want to 
cut-thru the conventional IP processing at IP-Router module, if 
possible (if the input and output datalinks are connection oriented 
datalinks), in order to obtain a high performance.  

 mwg> While Jon's case certainly has no large cloud in it, the same question
 mwg> does arise when the ATM part is a cloud instead of the single switch.
Yes, we proposed who large ATM based large scale IP network. 
So that, basically, we discuss the case where [ATM] part is 
large scale cloud. 
   Also, CSR (cell switch router) model can be applied to LIS's routers, 
as well as the conventional model's router. 

 mwg> If the ATM cloud *cannot* effectively combine streams, and has
 mwg> to provide plain-old isolated pipes to effect any QOS at all,
 mwg> then we're in trouble, and the Colip assumption becomes correct.
I think that how to use ATM pipe from the view point of IP packet 
flow has many alternatives, i.e. not only one to one mapping. 

Finally, now, I think the datalink seems to go to connection oriented 
(or could say switch base) platform. 
Then, we can cut-thru the IP packet forwarding based on datalink's 
connection identifier.  This is the target of FANP that we have recently 
proposed. 

Regards, 

Hiroshi Esaki 
c/o CTR, Columbia University

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Jul 95 0:11:18 JST

Sorry for the delayed response.

Mark;

> between routers, which is the Colip point of view.

From the colip point of view, flow control packets do pop up into
the IP-router. But, on the router, flow itself is relayed cell-by-cell.

With such relaying, just as the case of legacy ATM switches, no
sharing, combining, splitting possible while copying (point to multipoint
VC) is possible.

> make the ATM technology work right in the first place.

ATM, as is, is OK.

> But heterogeneity has been
> telecom and datacom, like it or not.

The problem is that global IP and global E.164 world can't
co-exist scalably.

So, the only known way to scalably have IP over ATM is to have ATM
locally and to have IP globally. Telcom must follow IPv6addressing
architecture.

That is, ATM segments should be small subnets connected by (cell
relaying) IP routers.

							Masataka Ohta