Subject: RE: [NSIS] Scenario for IP telephony

From: [email-masked]
Date: Thu, 21 Feb 2002 13:51:33 +0200

Hi Alban,

> This lead me to two new requirements for NSIS: it should be 
> possible for
> a user to request at the same time two (or more) QoS for two (or more)
> microflows (especially if they have the same destination/origination
> adresses), or even the same QoS that will be shared by two microflows.

Question to the working group on terminology.  Should we discuss
microflows or should we discuss sessions?  I'm a bit split on which
term is better.  

However, I think the requirement could be reworded to be:

 The NSIS protocol should be able to request QoS for different
 applications or different instances of the same application.

John

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 21 Feb 2002 13:09:16 +0100 (CET)

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

>  applications or different instances of the same application.

-------
Marcus Brunner
Network Labs
NEC Europe Ltd
Heidelberg, Germany

E-Mail: [email-masked]
WWW: www.brubers.org/marcus

---

From: [email-masked]
Date: Thu, 21 Feb 2002 13:42:09 +0100

Hello Marcus , John, and Georgios

If this is only a question of wording, agreement should come fast.

> I prefer the term session.

Agreed, by anyhow, I think definition session could be usefull (Anyway,
what I would like is that an NSIS session can be an RTP session)

> the data path MUST be the same, and the whole request MUST be granted at once

Yes, the last sentence sounds good to me. This is a good motivation for
grouping requests. 
Marcus, don't you think we could have a parameter saying that the
request is "transactional" as you propose, or not? But I agree inserting
this option complexify again a little bit the requirements (and maybe
the protocol)

Why not? Because I see advantages just in grouping requests, and here is
my answer to Georgios. The main task of a QoS controller is to check if
there is bandwith for sessions. It must see where there are possible
bandwidth shortages, and to forward the request to another QoS
Controller if needed.
If the two flows goes in the same directions, there are chances that
checking the possible QoS shortages will be in the same ressources, and
the request will be forward to the same QoS controller. I see here a lot
of common tasks in the handling of the grouped request. So this
requirement is good for the QoS initiator (if it is SIP aware, it is
simpler), and also enhance the efficiency of the request processing. The
SIP QoS initiator will get its answer back quickly.

-- 
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: Roland Bless <[email-masked]>
Date: Thu, 21 Feb 2002 13:53:13 +0100

Hi Marcus,

> the data path MUST be the same, and the whole request MUST be granted at once 

I think it would be better to keep the protocol simple and let the end
systems decide what a failed reservation request means in relation to
other respective requests. Your suggested AND operation on successful
reservation is just one possible scenario. In others you might request
resources for an audio flow and a video flow, but if the latter
fails you'll be happy get the audio stream at least. Moreover, doesn't
it require to have a centralized instance for signaling (disallowing
an application level library implementation for the signaling protocol) 
when requests for different applications should be aggregated into one 
single request (this is also a very application-specific case)?

I'm also not sure about the requirement that the data path should be the
same. The paths could be different as long as your flows' QoS
requirements are met (thinking of applying QoS routing methods etc.).

IMHO it is a good point to apply the end-to-end arguments in system
design here and keep complexity out of the network control plane.
Let's concentrate on making signaling fast and scalable.

Just my 2 cents.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097

---

From: [email-masked]
Date: Thu, 21 Feb 2002 15:10:57 +0100

Hello Roland,

> single request (this is also a very application-specific case)?

The only requirement I see is the SIp terminal to know the two sessions
can be requested at once. But I don't see a consequence forcing a
centralized instance for signalling in the network.

 
> Let's concentrate on making signaling fast and scalable.

If the two streams come from the same IP adress and go the same IP
adress, and in case the network is making diffserv in a usual way, I see
the burden of the signalling divided by two, and the processing of the
request factorized.
If there is QoS based routing, and if the two streams does not follow
the same path, yes the signalling should be splitted. Does this implies
to bring a lot of complexity? My guess is that it is not so much.

Regards

---

From: Roland Bless <[email-masked]>
Date: Thu, 21 Feb 2002 16:08:08 +0100

Hello Alban,

> centralized instance for signalling in the network.

Sorry, maybe I wasn't clear enough. I meant the _implementation_ within
a terminal or end-system. If the signaling protocol instance in the
terminal/system should group reservation requests of different
applications into a single request, no application can use an own nsis
protocol instance (e.g. as library implementation) independently of 
others.

> to bring a lot of complexity? My guess is that it is not so much.

Yes, IMO it does mean a lot of complexity, because the split point has
to keep track of the splitted (now) "independent" signaling transactions
and it must somehow combine the different answers back into the third
original transaction. The complexity lies in the possibility of
combining the answers in case of unsuccessful or failed requests. Marcus
suggested an AND operator. But others such as OR might also be useful.
So if you want the signaling to be flexible, we have to support an
arbitrary number of grouped sessions/flows and also several logical
operators expressing the logical relationship between the sessions
(which have to be specified in the signaling message, too!). 

I understand that it would be nice for a user/terminal to send only one
request. But in case of a negative response the application may have to
try a new request with a subset of the previous flows anyway. So let
the terminal send "independent" requests instead and let the
application decide about the further actions according to its own logic
in case of failure of any request.

Regards,
 Roland

---

From: [email-masked]
Date: Thu, 21 Feb 2002 16:54:57 +0100

Roland,

> protocol instance (e.g. as library implementation) independently of

A SIP application knowing the SDP knows the 2 or three microflows it
generates, and COULD signal it in  a grouped request. I don't claim it
is a SHOULD.
Other applications, especially sending flows in other directions don't
need share the signaling with the SIP application.  

> (which have to be specified in the signaling message, too!).

Well, Marcus suggested an AND inconditionnaly. This limits the problem.
We could also have a parameter in the signalling in order to choose if
this is an AND or an OR. May be this is too complex. But for me, this
was not as the fixed shared filters of RSVP  ;)
My proposition comes from SIP world: we have two, three, very seldomly
more, microflows coming from the same terminal, going to the same
destination. The fact there is one OR or AND (or always one AND) for
them gives a very simple formula.

But do you think that flows having the same origination and destination
IP adresses will be often separated in different routes? My guess is
that this will happen not so often. That is why I don't think my
proposition is not so complex.

> in case of failure of any request.

It is a possibility. But for me, in 98% of the cases, it doubles
signaling and its processing, in the terminal and in the network.

Best regards,