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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 21 Feb 2002 13:26:02 +0100

Hi Marcus

Do you mean that the same QoS request message
will signal QoS information to the network related to
more than one flow IDs?

I really do not know if this will make the NSIS protocol 
more efficient, but probably it will make it more complex!

Alban could you please motivate this requirement in more detail?

Best regards,
Georgios

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: donderdag 21 februari 2002 13:09
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: req to reqest QoS for more than one session at once (was RE:
[NSIS] Scenario for IP telephony)

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

Zitiere [email-masked]:

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

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

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

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

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 21 Feb 2002 13:58:51 +0100

Hi Alban

Regarding the motivation you just gave!
I think you could achieve the same results by
just sending two (or more) independent QoS requests.
In this way each QoS signaling procedure 
it will be much more simple and will be processed much more 
faster. I also think that the completion of the 
session (that should relate two or more flow IDs) will
also be completed much faster in the way that I described above
than in the way you described.

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 21 februari 2002 13:42
To: Marcus Brunner; Georgios Karagiannis (ELN)
Cc: [email-masked]; [email-masked]
Subject: Re: req to reqest QoS for more than one session at once (was
RE: [NSIS] Scenario for IP telephony)

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