Subject: RE: [NSIS] Two kinds of requirements

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Mon, 21 Jan 2002 11:04:41 -0500

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

---

From: Paulo Mendes <[email-masked]>
Date: Tue, 22 Jan 2002 20:20:55 -0500

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

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