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

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

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.

I think this requirement should be review from the perspective how easy it
can be supported by various existing QoS mechanisms and base our judgment at
least on this analysis.

The statement about different applications can be understood in two ways:
1. There should be some sort of cross awareness between applications and
they will coordinate requests themselves. I think it is far beyond the
protocol requirement and probably unrealistic anyway
2. The protocol implementation can be smart enough to make this kind of
aggregation. This is a requirement for the implementation rather than
protocol and probably should not be discussed here.

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.

Ilya

To: [email-masked]
Subject: req to reqest QoS for more than one session at once (was RE: [NSIS]
Scenario for IP telephony)
Date: Thu, 21 Feb 2002 13:09:16 +0100 (CET)
From: Marcus Brunner <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

I prefer the term session.

So the requirement:
The NSIS protocol should be able to request QoS for more than one
session at once. The sessions might originate at different applications or 
different instances of the same application, or the same appication.
However, 
the data path MUST be the same, and the whole request MUST be granted at
once 
or denyed at once.

Opinions?

Marcus

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

---

From: Ping Pan <[email-masked]>
Date: Thu, 21 Feb 2002 23:34:52 -0800

> 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.

> 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

---

From: "Ki Young Jung" <[email-masked]>
Date: Fri, 22 Feb 2002 17:58:18 +0900

Hi, Ping.
First, please forgive my poor English.

I have different opinion with with you.

> vs. one-reservation-per-multiple-flows would be pretty close.

I think that making dynamic management with aggregated flow path whenever
a flow in that path is changed is somewhat overkilled work.
In backbone situation, if a flow need 500KB bandwidth in a path,
then we can make (or add)  2MB bandwidth in that path.
We can use residual 2MB with other 4 flow without additional signaling.
The amout of residual BW and signaling cose have a trade-off relation.

My opinion is that  we can use the benefit of aggregate flow management
in backbone network in the signaling view point and it should be considered
in this WG.

I expect the comment from anyone.

----------------------------------------------------
Ki Young Jung ([email-masked])
Information and Communications University(ICU)
Broadband Network Laboratory (http://bnlab.icu.ac.kr)
58-4 Hwaam-dong, Yusong-gu, Taejon, 305-732, KOREA
Tel)+82-42-866-6182, 016-370-1751 Fax)+82-42-866-6110

---

From: [email-masked]
Date: Fri, 22 Feb 2002 13:57:53 +0100

Hello Ping

I respect Marcus's decision, but would like to answer your question

> vs. one-reservation-per-multiple-flows would be pretty close.

Application dynamicity depends on the time scale considered of course.
We could say a interractive multimedia call lasts something like 5
minutes, and could reach hours. For you, is is dynamic, or not? 
But anyway, a reservation for a session does not change previous
reservations, so they won't be modified constantly. 

If I send 3 reservations (audio, video and data), the third one being
rejected and then I cancel the two firsts, and then redo 3 other
reservations, this is a mess, and increases the signalling burden. There
would be in this case 2 simple use cases for the draft: simple
reservation, simple cancellation. But you see the scenario for SIP calls
would be complex, and requires multiple processings inside the network.
On the other hand, one reservation per multiple flow would give two
requests. 

I mean, this type of thinking was adopted in SIP/SDP: in a SIP
invitation, the whole multimedia session context is guathered in one
packet, instead of the verbose H.323 way of doing. But maybe thing that
applies for SIP are not so well suited for signalling...
And maybe my proposition was not a requirement, but an implementation
choice.

> expensive as people think.

Best regards

-- 
Alban Couturier
---------------------------------------------------------------------
Alcatel Research and Innovation
Ets de Marcoussis R&I/ULC
Route de Nozay                      mailto:[email-masked]
F-91461 Marcoussis CEDEX                       tel: +33 1 69 63 11 97
---------------------------------------------------------------------

---

From: "Andreas Kassler" <[email-masked]>
Date: Fri, 22 Feb 2002 14:27:38 +0100

Hello Alban,

> reservations, so they won't be modified constantly.

I slightly disagree. We have scenarios, for example video transmission, that
have very dynamic bandwidth
variation. There are several proposals how to implement this using for
example renegotiated CBR like
reservations, where you approximate the dynamic variation in bandwidth by
piecewise constant amount of
bandwidth. Clearly there is a tradeoff between re-negotiation interval and
accuracy. However what I want to
point out is that there might be situation where the reservations from the
endsystem point of view may be updated
frequently, say every 10 seconds. Consider a scene break with significant
amount of motion afterwards.
At least from the application point of view there should not be a
restriction on how frequently the app
wants to re-negotiate QoS for an already existing reservation.

> reservations, this is a mess, and increases the signalling burden. There

This is application strategy, right? If the applications wants to react in
this way, fine.
However, the application can react in any other way and say, ok, I'm
satisfied with audio alone.

> And maybe my proposition was not a requirement, but an implementation

Just my two cents, Andreas.

---

From: [email-masked]
Date: Fri, 22 Feb 2002 15:36:53 +0100

Hello Andreas,

Thank for your feedback.
First, I apologize for talking about something which is now obsoleted in
the discussion. 

> wants to re-negotiate QoS for an already existing reservation.

I don't see really the relationship with grouping of microflows, which
is an option, and doesn't prevent a user to modify only a part of the
group. It does not prevent people to use groups of one session, either. 
And again, if you want to update QoS for an RTP session, I don't see the
impact on the reservations for other RTP (or other) sessions, even if
they have been initiated in the same group. So you can send as many
requests as you want, update them etc, grouping of micro flows would
have been just an nice option that can help you, it would be never an
overhead (OK, the improbable split of request, which is not so complex,
compared to RSVP or even SIP forking).

Concerning the video transmission, I understand your point Ilya. The
video traffic is indeed very difficult to model. 
I don't really think there is an impact on NSIS, wrt the video rate
fluctuations.  What I assume for interractive multi media services, is
that nobody -even the video codec in the terminal- can predict that the
max bit rate of the codec will be reached one second later. Simply
because a bird in the sky or a unexpected move can generate (there are a
lot of reasons) a big change in the codec throughput.
So, what a interractive multimedia user needs, is the guarantee that the
pictures he sends will arrive at destination, being simple compressed
picture or a complex one. (he has of course an idea of the max bit rate,
and the mean bit rate, knowing the codec, the screen size, the
performance of his machine, the persons he talks with, etc... ). For SIP
terminal with video (SIP, H.323, anything which is interractive) , my
view is that a user wants a quantity of service's availability. He can
not follow precisely the rate of its codec(s) and requests in real time
the exact quantity of bandwidth. So the user should pay also for
bandwidth he does not use, but may use the very micro second after). 

> satisfied with audio alone.

True. This was an example. Mine was that stereo, or high sound quality
is not needed anymore without video. Question was ("was" since it is
over): do we think that NSIS users would use often the "transaction"
capabilities (I answer SIP users will), or not (because NSIS users would
be in majority non interractive video on demand services).

> Just my two cents, Andreas.

Here are my two euro cents,

Kind regards

---

From: Ping Pan <[email-masked]>
Date: Fri, 22 Feb 2002 09:09:29 -0800 (PST)

> reservations, so they won't be modified constantly.

That's exactly my point. One reservation per session does not seem to be a
bad idea in the first place. So why bother with managing multiple flows
per session. One-to-many reservation looks good on paper, but in
implementation it can be quite complex...

> And maybe my proposition was not a requirement, but an implementation

IMHO, SIP is e2e signaling protocol that may trigger another signaling
protocol to setup reservations inside the network. The reservation
signaling should be independent from whoever is calling it, however it
must provide enough functionality to make the users (e.g. SIP) happy.

2 more cents,

- Ping

---

From: Ping Pan <[email-masked]>
Date: Fri, 22 Feb 2002 09:16:18 -0800 (PST)

> wants to re-negotiate QoS for an already existing reservation.

Andreas,

It looks like what you have described above can be solved via Steve
McCanne's multi-layer approach. Except you set up reservations from the
sender's direction for each of the layers that you want to protect... At
worst it is a many-reservations to one user-session....

- Ping