Subject: Re: int-serv over e.g. ATM

From: [email-masked] (Mark W Garrett)
Date: Wed, 8 Nov 1995 10:43:33 -0500

Steve,

 > It's not especially uglier than any other VC-oriented, large-cloud
 > technology, like X.25 or ISDN.

 > What's your idea of "working right"?  Why should the Internet architecture
 > be changed to accommodate ATM, when we didn't feel compelled to change it
 > to accommodate X.25 or ISDN?  What's so special about ATM that should
 > cause us to treat it as anything *other* than just another subnet du jour?

The hope is that ATM will be much more successfully deployed
than X.25 and ISDN.  However, if you want to wait until that
success is more apparent, I'd have to say that's reasonable.
It's clear that there *is* adequate effort focused on the
routing issues, from rolc, ipatm and MPOA.

On the Traffic Management side, note that X.25 and ISDN do
not have differentiated QOS.  So ATM is a new animal.  The
ATM crowd will certainly come to this discussion thinking
that they just put all these great features into the ATM
technology, only to have them hidden from the applications
by a layer of abstraction that may or may not be powerful
enough to take advantage of them.  So the real issue might
be that ATM folks are saying, ``1) here's the first network
technology to have meaningfully differentiated QOS; 2) as
Internet develops QOS capability it should consider ATM to
be special''.  And the IP folks response is that no, ATM is
not special since it fits into the model just as any other
subnet.  Now, maybe the current IP model is general enough
that implementations which follow it will naturally take
full advantage of ATM's QOS capabilities.  The IP architecture
itself is a bit of a red herring in this, because obviously
both good and bad implementations can be made consistent with
the overall model.

I think the int-serv group's approach has been to get their
own house built before going to meet the neighbors, which is
fine for now.  From the recent responses it looks like a
number of significant efforts will occur in the next year to
evaluate the interoperation of ATM QOS and IP QOS.

 > I agree with your distinction.  In my previous message, I used the phrase
 > "the module that processes RSVP", as an attempt to avoid layer connotations.
 > Does that help?

Well, I'm not the one to choose a name for it, as long as
the distinction starts soaking into our common language.
We'll get better names for things as all this gets fleshed
out.

-Mark

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

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 08 Nov 1995 19:54:53 +0200

trying to summarize:

- application uses int-serv to express its traffic needs

- these needs are conveyed via rsvp to ip components (routers, if any on 
the path, plus the destination host)

how should the originating host decide whether to set up a direct 
connection to the destination over atm or whether to use the router path 
assuming that both are possible?  clearly making the decision based on 
whether the destination shares a common address prefix with the source 
doesn't make any sense.  one solution might be to include such a directive 
in the api and carry it in rsvp so that also routers on the path would 
know if it makes sense to try to shortcut the path.

if this makes sense, how can we get the shotcut bit into rsvp?

-- juha

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Nov 1995 22:54:50 -0500

> if this makes sense, how can we get the shotcut bit into rsvp?

This doesn't make sense.  The application should know what QoS it
needs and should not be trying to decide whether to shortcut an NBMA.
If it crosses two different NBMA clouds with different media types
ans/or different network equipment, it may make sense to shortcut one,
but not the other.  Similarly, depending on the route it takes, it may
make sense to shortcut or not to.  By specifying the QoS, the decision
can be made at network element at the border of each NBMA (which may
be the host in a special case).

Curtis

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 9 Nov 1995 17:28:19 +0200

curtis,

you say that a border box to an nbma (which can be the source itself)
can determine whether to shortcut by looking into the qos request only.

lets assume that you have a atm lan with 500 hosts and one single
router.  let also assume that the hosts don't all share a common address
prefix.  now if a wants to talk to b and a and b have different address
prefixes, how can the source figure out by looking into qos only if it
should send the the rsvp request to the router or create a direct vc?

if everybody would always go through the router, the router would be
very soon swamped and couldn't serve any more flows.  so my rule would
be "switch always when you can and route if you can't", i.e., that
shortcut would be the default.

by the way, if there are several routers on the path, how can the source
be sure that the routers all support rsvp?  does rsvp routing protocol
provide information about the whole path to the source?

-- juha

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 10 Nov 1995 20:43:27 -0500

> should send the the rsvp request to the router or create a direct vc?

This is the blind leading the blind, so ... please excuse me if the
details aren't quite right.  Here is how I would envision this being
accomplished.

Regardless of the mechanisms that come into play in setting up a path,
there needs to be a way to determine if a given path can support the
additional capacity.

In your example the router with 500 hosts would no longer be able to
support additional VCs or provide the QoS or media capacity to the
router may saturate.  If the host did not have apriori knowledge that
the QoS could not be granted, it would try to use RSVP.  In RSVP the
repient initiates reservation.  When RESV is sent, either a PATH or
PERR is returned.  If PERR is returned, a direct connection can be set
up.  If the host (or a router acting on the behelf of a host not
directly connected to the NBMA) did know apriori that a shared VC or a
hop by hop path cannot accomodate a certain QoS, the step of probing
the lower cost path with RESV can be skipped and a VC set up
immediately, and then a RESV sent to confirm (in case the other end is
off NBMA and still cannot be reached with the requested QoS).

Once set up, the VC would continue to be used.

> shortcut would be the default.

This is one heuristic that could be used as the "a priori information"
used to set up a direct connection without even trying an indirect
connection.  The heuristic might be "never trust this particular
router if you want a certain level of QoS".

On the other hand, SVCs may cost money.  If the router is set up well
it will require that some capacity is reserved for non-QoS traffic for
things like DNS and it will be set up to admit QoS VCs only until
their is risk of not being able to sustain the load.  If you are
sitting at the host and don't think the router is well set up and does
this, you can simply configure the layer sitting bnetween RSVP and ATM
to always go for the VC first, and always return PERR if you get a
RESV on a shared VC from the router.

If you can often use either a shared VC to the router (shared with
other traffic from the same router) or use a VC to that router rather
than a direct VC all the way, you might still get the QoS you want and
reduce your costs when the router is lightly loaded, and get the QoS
you want when rejected using a direct VC.

> provide information about the whole path to the source?

I think that just came up on the RSVP list.  RSVP can be forwarded to
non-RSVP portions of the topology that are believed (by the local
administrators) to be mostly uncongested and capable of supporting a
given QoS.  The argument was made that end systems need to know that
this decision was made.  IMO this should never occur (forwarding RSVP
through a non-RSVP portion of topology) if the Rspec was for any form
of guarenteed service (unless it was certain that the reservation
could be met, due to something like gross overprovisioning).  If the
Rspec was for a predictive service, then it is really a judgement
call, prefereably made based on very reliable basis.  But I'm speaking
here about something that shouldn't be since I'm only a lurker on RSVP.

Curtis

---

From: [email-masked] (John Krawczyk)
Date: Sat, 11 Nov 95 14:39:00 EST

On Fri, 10 November, Curtis Villamizar ([email-masked]) wrote:

Hi Curtis,

Just a slight correction on the protocol activity.  The session
senders will send out PATH messages first.  When the receiver sends
out a RESV, it may get a RESV ERR, indicating that the reservation was
not granted at some node in the network.  On Friday, we discussed an
additional "soft ACK" that would be returned when a RESV hit the
sender or a reservation merge point, whichever comes first (monitor
the rsvp list for more details).

This was also discussed on Friday.  This would be contained in the
ADSPEC object of the PATH message (probably).  It might just be a bit
that says "this PATH went through some best-effort hops" or one may
actually be able to tell how many best-effort hops there were (it's
not clear that this is a measure of goodness/badness, since you only
need one congested best-effort link to make things unbearable).  This
way, the receiving application/user can decide if they want to gamble.
As you say, if the receiver really needs guaranteed service, it should
not try to establish a reservation in this case.

-jj