Subject: RE: [NSIS] Two kinds of requirements (one-many applications)

From: [email-masked]
Date: Fri, 25 Jan 2002 14:46:59 -0000

See my comment below:

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: 24 January 2002 20:24
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

[email-masked] wrote:

> Nice one. I was waiting for this.
> 
> 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.

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

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

[Dick Knight]: Think of an extreme example. The president of the USA makes a
press release that he is going to make an important announcement concerning
[war; peace; world finances; aliens landing - something that almost
*everyone* in the world would like to hear about]. The announcement will
take place at 2pm EST, and of course will be multicast with to the NSIS
QoS-enabled internet. If the signalling sets up a QoS connection, in advance
of anyone connecting, where does it get set-up to? Suppose we wait for the
first client, use their QoS requirements (assuming they are above the White
House's minimum and below the whitehouse's maximum). Then the next client
was a bit better quality, and I am suggesting that is only achievable if the
White House sends the information in the appropriate format to the quality
requested. Now what happens if *every* client does that. Looks awfully
similar to a DOS attack?

If this example is too extreme (we handle only less clients) - then what is
the limit - 10 clients? 100? 1000? How do we decide how many?

> 
> 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: Tue, 29 Jan 2002 16:34:20 -0500

HI Dick

If I didn't misunderstood you, you also exemplified that a admission 
control of type "take it or leave it" is very limited. right?

About the number of clients.. Who knows.. Probably depends on the 
service quality :-)

Cheers,

Paulo