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

[Paulo Mendes <[e-mail]>]

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

[e-mail] wrote:

> See my comment below:
> 
> -----Original Message-----
> From: Paulo Mendes [mailto:[e-mail]]
> Sent: 24 January 2002 20:24
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [NSIS] Two kinds of requirements
> 
> 
> 
> 
> [e-mail] 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:[e-mail]]
>>Sent: 23 January 2002 01:21
>>To: Roy, Radhika R, ALASO
>>Cc: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>[e-mail]; Yaron Kahana; Geib, Ruediger;
>>[e-mail]; [e-mail]
>>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:[e-mail]]
>>>Sent: Friday, January 18, 2002 3:10 PM
>>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>>[e-mail]; Yaron Kahana; Geib, Ruediger;
>>>[e-mail]
>>>Cc: [e-mail]
>>>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:[e-mail]]
>>>Sent: Friday, January 18, 2002 9:18 AM
>>>To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>>[e-mail]; Yaron Kahana; Geib, Ruediger;
>>>[e-mail]
>>>Cc: [e-mail]
>>>Subject: RE: [NSIS] Two kinds of requirements
>>>
>>>
>>>Defined below [RRR]
>>>
>>>-----Original Message-----
>>>From: Schneider, Marco [mailto:[e-mail]]
>>>Sent: Thursday, January 17, 2002 8:47 PM
>>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>>[e-mail]; Yaron Kahana; Geib, Ruediger;
>>>[e-mail]
>>>Cc: [e-mail]
>>>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
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/nsis
>>>
>>>
>>>
>>
> 
> 


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


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