Re: "local/remote" decision

[Bob Tausworthe <[e-mail]>]

>Jeffrey,
>
>>I disagree that this is cleaner. In addition, it now places link management
>>functions within the application which is clearly not a good idea. I just
>>don't trust application programmers to do the right thing !
>
>If you don't trust application programmers to do the right thing, then
>I see little difference between exposing QoS management only, or
>QoS management and SVC management -- the programmers would do wrong
>things anyway :-)

I don't want to get too deep into this discussion, because by nature I
am a voyeur, not a voyager, but there is a real difference between
exposing one interface to a customer and exposing two interfaces which
the application programmer must use in concert with each other. We
have seen this before and it has the potential of causing more
problems (the problems of the whole are greater than the sum of the
problems of the parts :))

What we have found is that there is a tradeoff on whether to expose greater
functionality to an application programmer versus hiding complexity from
a programmer based upon the programming audience that the interfaces are
intended for. If the interfaces are to be used to primarily write "dedicated"
applications deep in basic subsystems (e.g. a transport, network or driver
level protocol in a kernel), then often we would rather expose functionality
to the programmer at the expense of reduced complexity. If, however, this
is an interface which will be used by a wide, diverse audience of 
ISVs, experimenters, et. al. we will  try to make the interface as simple
as possible even at the expense of reduced functionality.

I think for this discussion the same rules apply.

>
>>I also disagree with your concern about "overload of QoS semantics".
>>The decision of whether to use an existing VC should not be up to the
>>application. The QoS management function makes that decision based either
>>on specific QoS parameters defined at application setup ....
>
>Introducing additional level of indirection (via QoS management
>function) has its own tradeoffs. However, it is a bit hard to have
>a constructive discussion in absence of specific QoS management semantics.
>A better approach would be to define the semantics first, and then
>argue whether the semantics is sufficient, and if not whether
>the missing parts should be realized by expanding the QoS semantics or via
>a separate SVC management mechanism.
>

I agree.

                           Bob Tausworthe
                           Hewlett Packard
                           19420 Homestead rd.
                           Cupertino, Ca  95014
                           [e-mail]
                           [phone]