Subject: RE: [NSIS] req to reqest QoS for more than one session at once (w as RE: [NSI S] Scenario for IP telephony)

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 22 Feb 2002 10:01:07 -0500

Ping,

I have the same doubts that multiple reservations per transaction have any
advantage I've just found the previous wording not precise and confusing.

Ilya

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: Friday, February 22, 2002 2:35 AM
To: Freytsis, Ilya
Cc: [email-masked]'
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was
RE: [NSI S] Scenario for IP telephony)

Freytsis, Ilya wrote:

> Marcus,
>
> I'd like to suggest different wording for your requirement:
> NSIS protocol should allow requesting QoS for more than one session with
the
> same originating and terminating points within the same transaction.
>

Hi,

Just curious, what's the gain of setting up one reservation session for
multiple application flows here? You may argue that one reservation is
cheap to process compare with multiple reservation sessions. However, it
looks to me that the application flows may be quite dynamic, then the
reservation needs to be modified constantly anyway. As a result, I argue
  that the processing overhead for supporting one-reservation-per-flow
vs. one-reservation-per-multiple-flows would be pretty close.

The aggregation argument in NSIS is quite different from what we have
seen in the backbone environment, where "static" reservations are
established based on how the network providers are arranging their
interval network resources. the "static" reservations that multiple
flows can aggregate into don't change a lot (if ever), and will last for
days and months. In the case of NSIS, the reservations are triggered by
the applications and can be rather dynamic.

In conclusion, IMHO, one reservation per flow may not be as complex and
expensive as people think.

>
> I share the point of view that NSIS should not be influenced too much by
any
> single application protocol however hot and promising it may look right
now
> but be rather application (signaling) neutral.
>

Excuse me. I had a conversation with a wise man the other day. He was
telling me how some people work toward a technical solution: It's like
making ice-cream cake in a very hot day. One approach is to argue how to
make a perfect cake that everyone will like. The only problem is by the
time it makes everybody happy, everything will melt. The other approach
is to look at the customer's order, and make a cake!

Back to your application neutral solution, are you recommending to
define a signaling protocol that is compatible for the past, the present
and the future applications? ;-) I suggest the following: look where a
signaling is needed (aka, who will use it and how it gets used), define
and develop a workable solution real fast, and get it done. Would the
solution be perfect? Well... the main thing is to make it working, not
to debate it!

2 cents,

- Ping

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis