Re: Last Call for draft-ietf-rolc-apr-00.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>OM>, Joel Halpern writes:
> I think that there is one other aspect of the situation here.
> One of the thinks which is not necessarly agreed, but which I assume, is
> that it is better for the system if long-lived communications use direct
> VCs.  This is not a matter of meeting the users QoS requirements, but of
> using the system resources effectively.

I don't know if that is true.  The bandwidth sharing that can occur if
long connections *don't* use direct VCs may be more important than a
more predictable delay, for example.

> Thus, I tend to think of QoS as only one part of the reason for doing
> direct VCs. 

If there is some characteristic of the application that affects the
decision to go with a direct VC and that is not expressible in the
reservation protocol, then this is an issue to be taken up in the
int-serv WG.  I suggest you be very specific and that you bring this
up on int-serv.  The traffic characterization and requirements
characterizations that RSVP will carry are to be decided in the
int-serv WG.  If you feel there is an ommission, bring it up there.

> This leads, to my thinking, to a document (the APR document under
> discussion) whcih discusses when one wants direct VCs.  The important
> observations (I think) are:
> 1) That the desire for direct VCs is not coupled to whether the source
>     and destination are in the same "address aggregate".  In particular, 
>     it is independent of whether they are in the same lowest level
>     "address aggregate" (traditionally known as "subnet").
> 2) That the communicating host, informated by the policy of the system
>     and the QoS requested by the user/application is in the best position
>     to decide when to establish direct VCs.

Your conclusion 2) is predicated on their being an ommission in the
int-serv work.  If so, fix the ommission for the general case, rather
than stating that the only way to do this is to essentially ignore the
work of RSVP and int-serv and limit yourself to directly connecting
the end system to the NBMA.

> There are a number of implications here.  Among them are a chnage in the
> meaning of the notion of "subnet" towards a notion oriented towards address
> management rather than communications management.
> Another aspect is that some lower level system in the host will need
> information about the user/applications desires and expectations for
> communications.  Initial implementations may get this from some combination
> of port numbers, RSVP, and magic.  Later? ...

We're engineers.  We don't beleive in magic.  If you want magic
implement MPOA.  ;-)

If there is a major ommission in the int-serv work, then fix it.  If
you can't define what it is that would be useful in making a
local/remote decision, and therefore should be communicated by a
reservation protocol, then you won't do any better making a decision
at the host.

It is perfectly valid to write this architecture document under the
assumption that the int-serv work is highly incomplete and may take
considerable time before converging.

> I think getting these points documented is very useful for us.
> And they are certainly not duplicative with current RSVP or Int-Serv work.

I would strongly favor documenting the case where the host is at an
advantage in making a local/remote decision as an interim case that
is likely to arise as the understanding of how to best make such a
decision evolves faster than agreement on how to codify the relevant
parameters into a reservation request.

> Yours,
> Joel M. Halpern				[e-mail]
> Newbridge Networks Inc.

Curtis