Subject: RE: [NSIS] Two kinds of requirements

From: [email-masked]
Date: Wed, 23 Jan 2002 09:27:56 -0000

Nice one. I was waiting for this.

So .. another new requirement. To support one-to-many applications.

There are two aspects to this:
1. The easy case. In internet TV, a provider (source of the TV) is
available. The first client uses NSIS to negotiate QoS with the network and
the source. Assuming the negotiation is successful a "connection" is
established. The second client then attepts to receive the TV. On initiating
the NSIS negotiation of QoS, they get a "take it or leave it" result of the
first client's negotiation. Anything else is not scalable.
2. A business conference will be established, with a known (limited) number
of clients. The provider can initiate the negotiation with the clients to
achieve the best possible QoS using the least resources.

The first case is no extra requirements above an IP telephony call. The
second requires multiparty negotiation at establishment.

Dick

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: 23 January 2002 01:21
To: Roy, Radhika R, ALASO
Cc: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
[email-masked]; Yaron Kahana; Geib, Ruediger;
[email-masked]; [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

If I understood correctly NSIS should be a QoS signalling protocol 
useful to all applications, right?

However it seems that this division between Application Layer QoS 
signalling (NSIS QoS) and posterior reservation request to the network 
for the necessary QoS agreed to at the session level only works for 
one-to-one applications, like IP telephony.

What happens with one-to-many applications like video-on-demand or 
InternetTV? In this case you can't establish a session level QoS 
agreement between provider and clients before the session starts (and so 
before the reservation of resources) because you would not know all your 
clients at that time.

Paulo Mendes

Roy, Radhika R, ALASO wrote:

> Hi, Marco:
> 
> Let me try to clarify from your point of view.
> 
> It seems to agree that there needs to be a session level QOS agreement.
Let us analyze what is this. To make an agreement, we need to send some
messages between the end points. This may be termed as "signaling."
> 
> A session expresses its QOS for its "application" that may consist of
media: audio, video, and/or data.
> 
> In general, the above two items can be expressed as "Application Layer QOS
signaling."
> 
> I think that we are agreeing on technical points.
> 
> Best regards,
> Radhika R. Roy
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:[email-masked]]
> Sent: Friday, January 18, 2002 3:10 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Below is the original text from your reponse to Gary Kenward. Hopefully
the
> context is clear.
> 
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network services, we would
say
> network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
> the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
> Now, there needs to have some kinds of standards how NSIS QOS will be
mapped
> over RSVP, DiffServ, MPLS, etc."
> 
> So by End-to-End you mean between directly between two "users". This is
> session level signaling and I don't believe the signaling part is within
the
> scope of this working group. An application level QOS specification may
be. 
> 
> After a session level agreement on QOS, the host/client/customer will need
> to signal an actual reservation request to the network for the necessary
QOS
> agreed to at the session level. This is the protocol that we need to work
> on. 
> 
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
> 
> Marco Schneider
> 
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:[email-masked]]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Defined below [RRR]
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Can you please define what you mean by "End-to-End Application Layer QOS
> Signaling". Thanks.
> 
> [RRR] Suppose an user is initiation a SIP call to another user with audio,
> video, and data. The use needs to express the needs of QOS for audio,
video,
> and data to another user. 
> 
> [RRR] The signaling mechanism that allows to express the QOS parameters of
> audio, video, and data is termed as the "End-to-End Application Layer QOS
> Signaling."
> 
> Marco Schneider
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes

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

---

From: Paulo Mendes <[email-masked]>
Date: Thu, 24 Jan 2002 15:24:13 -0500

> So .. another new requirement. To support one-to-many applications.

Yeap.. I say this is another requirement. I think that if we don't keep 
in mind one-to-many applications we'll specialize NSIS functionality to 
one-to-one cases, and then it would be hard to use NSIS with other type 
of applications...

Probably one-to-one requirements could be seen as a sub-group of one-to-many requirements.

> second requires multiparty negotiation at establishment.

I don't think this "take it of leave it" approach is the best one. For 
example, if the first client has a low quality requirement all the other 
clients can refuse join the session if they have a high quality expectation.
I think that a more flexible approach is needed. For example, the 
content provider should negotiate with the network provider a minimum 
quality level for the session, since he doesn't want to provide services 
with lower quality than that. After this, every client that joins the 
session can accept that level of quality or they can try to re-negotiate 
   with the network an increase of quality.

Cheers
Paulo

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 25 Jan 2002 17:16:29 +0100

And I was hoping to get rid of one-to-many on the transport layer.
Marcus

--On Wednesday, January 23, 2002 9:27 AM +0000 [email-masked] wrote:

> available. The first client uses NSIS to negotiate QoS with the network
> and the source. Assuming the negotiation is successful a "connection" is
> established. The second client then attepts to receive the TV. On
> initiating the NSIS negotiation of QoS, they get a "take it or leave it"
> result of the first client's negotiation. Anything else is not scalable.
> 2. A business conference will be established, with a known (limited)
> number of clients. The provider can initiate the negotiation with the
> clients to achieve the best possible QoS using the least resources.
>
>> the end-to-end (application layer) QOS signaling protocol (say, NSIS
>> QOS). Now, there needs to have some kinds of standards how NSIS QOS will
>> be
> mapped
>> After a session level agreement on QOS, the host/client/customer will
>> need to signal an actual reservation request to the network for the
>> necessary
> QOS
>> [RRR] Suppose an user is initiation a SIP call to another user with
>> audio, video, and data. The use needs to express the needs of QOS for
>> audio,
> video,
>> [RRR] The signaling mechanism that allows to express the QOS parameters
>> of audio, video, and data is termed as the "End-to-End Application Layer
>> QOS Signaling."
>>
>> Marco Schneider
>>

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus