Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless

From: [email-masked]
Date: Fri, 18 Jan 2002 16:51:07 -0000

There are some important points in this email. Probably obvious for people
with wireless backgrounds, but a bit more of a surprise for wired
backgrounds.

I personally don't see NSIS as trying to solve the rate adaptation needs of
the wireless access network. I can see that it is very much needed, but it
is rather more specialised than a generic signalling protocol for QoS
requests. This looks like a charter debate.

The wireless access network definitely needs some QoS signalling support,
but as you have shown, it is specific to the technology and the mobility
service.

Dick

-----Original Message-----
From: Steve Gilbert [mailto:[email-masked]]
Sent: 18 January 2002 16:21
To: [email-masked]
Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless

I tend to agree with the need which Herman identifies (below) for throughput
adaptive capabilities in a wireless QoS system.

The cellular wireless QoS problem is very different than that of wired QoS
because of the need to handle the case of a user with a QoS "guarantee"
handing
off into a different cell.  In the worst case, the cell which it is entering
may
have its resources fully allocated to existing users. Dropping the session
of
the user being handed off is not a good idea. This points out the need for
some
rational way to accommodate such calls. The approach taken in some wireless
voice systems is to reserve resources for use only by sessions which are
handing
off into the cell. This may suffice if the resource needs of the hand off
session are predictable. However, in a system in which arbitrary
applications
can utilize a wide range of throughput values, reserving enough capacity to
handle the range of throughputs which could potentially be needed by a
single
flow may not be practical.

What is needed is the use of throughput adaptive applications and the
ability
for a traffic flow to express its QoS preferences with regard to the
throughput
values which it may be allocated. Upon handing off into the new cell, the
QoS
preferences of the handoff traffic flow and of the existing traffic flows in
that cell would be considered and resources reallocated to best meet their
preferences. Some of the existing traffic flows may have their throughput
allocations reduced in order to free up resources to be allocated to the
handoff
traffic flow.

The QoS signaling needs of this approach include the ability of the system
to
notify traffic flows of their new allocations, and the ability for a new
traffic
flow requesting "admission" to express its QoS preferences, possibly in
terms of
a list of throughput values and the benefit it receives from each. A
non-adaptive real-time application would indicate a single throughput value
which it desires rather than a list of throughput values.

One could argue that this provides no throughput "guarantee" and changes
what it
means to have a QoS request "admitted". This is true. But in wireless, it is
difficult and sometimes impractical to provide the same QoS guarantees that
could be provided in a wireline system which doesn't have to deal with
handoff. In a wireless system, there is the possibility that the user will
drive
into a tunnel or take the elevator to a sub-basement of a building where the
wireless signal is lost. Radio coverage and QoS can not be guaranteed under
all
possible situations.  Wireless channel resources are often more scarce or
expensive than those of a wired channel. This generally results in the
motivation to utilize them more efficiently. What is more realistic than
trying
to provide wireless QoS identical to that of wire-line is to come up with a
useful approach for "QoS management" and "resource allocation" which can be
applied in a wireless system.

If efficient utilization of the resources by QoS flows is not a major
concern,
the QoS of admitted users could be increased (or at least made less prone to
reductions) through over-provisioning or preventing admission of new calls
even
when the level of congestion is still low. The resources not guaranteed to
QoS
traffic flows could be used by best effort traffic. Systems with significant
best effort traffic would be able to increase the overall utilization of the
channel without negatively effecting QoS traffic flows.

Steve

> Date: Thu, 17 Jan 2002 19:49:13 +0000
> To: "Georgios Karagiannis (ELN)" <[email-masked]>,
>    "'Loughney John (NRC/Helsinki)'" <[email-masked]>,
>    "'ext Kappler Cornelia'" <[email-masked]>
> From: Hermann De Meer <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: [NSIS] Two kinds of requirements
> 
> Hi Georgios and all
> 
> At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
> >Hi John and Cornelia
> >
> >I think that one of the requirements that should be included
> >in the NSIS WG requirements document is that the NSIS protocol
> >should be modular. Modular in the context of having
> >a toolkit from which one can choose the applicable tools
> >in order to manage QoS in a particular networking environment.
> 
> I believe you are raising a very important issue with the emphasis on 
> modularity
> of QoS architectures/signalling.
> 
> But one can generalize that: it's all about flexibility,
> namely flexibility of signalling/control/provisioning vs. flexibility of 
> applications/users.
> 
> Flexibility does not necessarily mean complexity, often on the contrary:
> one side being flexible makes the life for the other side easier (think of

> airline ticket pricing:
> the price for the *same seat* can vary in an order of magnitude simply
> depending on how flexible you are!)
> 
> QoS signalling is about indicating of how "inflexible" you are from that 
> perspective.
> But looking at IntServ (RSVP) or DiffServ,  an interpretation of these
signals
> have traditionally been seen rather statically:
> 
> - a "one-size-fits-all"  "end-to-end" implementation of the mechanisms
> - a "take-it-or-leave-it" approach: statically defined QoS classes.
> 
> this makes QoS provisioning cumbersome, complex, expensive (unnecessarily)
> (and it may be a good deal the reason for the "failure/insufficiency" of 
> current QoS solutions/
> signalling techniques).
> 
> Remember, the success of IP networking has to a larger extend been due to 
> the fact of
> relying on flexibility and cooperation, for example, for congestion
handling.
> (or "exception" handling, if you want, by TCP-similar schemes)
> 
> in <draft-demeer-nsis-analyis-00.txt> we therefore make a point to extend 
> QoS signalling for:
> 
> 1) explicitly dealing with such "QoS exceptions" (there is also an
economic 
> argument for this)
>      that is, not only signaling QoS preferences from applications to the 
> network, but also
>      QoS exceptions back from networks to applications or to between
networks,
>      and an expected cooperative adaptation.
> 
> 2) allowing for flexible interpretations in different domains (core, 
> access, mobile, wireless,
>       administrative conditions, ....)
> 
> 
> The "trick" may be to modify signalling (including RSVP) such that most 
> flexibility/cooperation
> can be re-gained by assuring a minimum support of inflexibility 
> (intentionally not using the
> the term QoS guarantee here).
> 
> 
> --Hermann
> 
...

_______________________________________________
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: "Gary Kenward"<[email-masked]>
Date: Fri, 18 Jan 2002 12:31:17 -0500

Steve:

  I don't believe that Dick is proposing that NSIS accomodate 
rate adaption, I believe that the issue is QoS re-negotiation 
to allow better handoff performance.
 
  The situation is simply that if the admission control used
during a handoff is "all or nothing" then the likelihood the
flows of the mobile user will be dropped when a handoff occurs is 
much higher. "Re-negotiation" of QoS allows the network to reduce
the resource demands to the point that the new access router 
can handle the flows, at least to some degree.

  Re-negotiation can mean many different solution scenarios.
At the extremes, the solution could be an NSIS negotiation 
protocol between mobile and access network; a "minimum" QoS 
that the network that is allowed as a fallback to allow the 
handoff to occur. Note that in either case, the result may
mean dropping of specific flows that cannot be support (e.g.
the video portion of a multimedia session).

The second scenario does not necessarly require interaction 
with the mobile or other networks and thus may
not impact NSIS.  However, it might be a good thing for the
network to tell the mobile that the QoS had been degraded,
thus allowing the mobile application to "adapt". NSIS does not
need to participate in the adaption, it would simply provide
the information on the new QoS.

I think the requirement here is for the NSIS wg to consider
all the options.

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: January 18, 2002 11:51
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in
> wireless
> 
> 
>

---

From: Yaron Kahana <[email-masked]>
Date: Sat, 19 Jan 2002 21:26:44 +0200

Hi all,
 
I think that the describe situation is:
1) NOT unique to the mobile case.
2) Should be handled by a "higher hierarchy".
 
I think that the described example is the derivative of unpredictable over
loading of resources, and is rather common (for example through Erlang
distribution?). The mobile case, with its relative high dynamic users, can
still perform the correct network planning work to handle such cases. The
NGN, whereas the users will have their services linked to their "entity" and
not to their landline, will have to deal with it as well.
 
I also think that the solution of over loading should be managed by a local
"higher hierarchy" and not by the End-to-End reservation. This local service
controller should be aware of the sessions, users, resources and
commitments. Hence could decide a "re-negotiation" or a drop. Think about
the case that there is an emergency call in the cell (911) and it is being
dropped or degraded?
 
I'm not sure this is within NSIS scope, but this service controller
(softswitch?) should be aware of the resources reservation and should manage
the allocation of resources and admission control (see TIPHON
DTS02009v044.doc).
 
Best Regards,
 
Yaron Kahana
COGITO Project Manager
COMGATES
www.comgates.com <http://www.comgates.com> 

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:31 PM
To: [email-masked]'; [email-masked]; [email-masked]
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless

Steve: 

Gary 

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: Steve Gilbert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > the term QoS guarantee here). 
<https://www1.ietf.org/mailman/listinfo/nsis>  
<https://www1.ietf.org/mailman/listinfo/nsis>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 21 Jan 2002 11:58:30 +0100

Hi Steve

I would like to add some information on 
the need for severe congestion adaptation.
This is one of the QoS requirements (please look also to the rest 
of the QoS requirements)
that we have presented in the NSIS draft entitled:
"QoS Signalling Requirements for Wireless Networks"
located at:
http://www.ietf.org/internet-drafts/draft-karagiannis-nsis-wireless-requirements-00.txt

This additional information is:
"Ability to deal with severe congestion":

   In case of a route change or link failure a severe congestion
   situation may occur in the network. Typically, routing algorithms are
   able to adapt and change their routing decisions to reflect changes
   in the topology and traffic volume. In such situations the re-routed
   traffic will have to follow a new path.  Interior nodes located on
   this new path may become overloaded, since they suddenly might need
   to support more traffic than they have capacity for.  These severe
   congestion situations will severely affect the overall performance of
   the traffic passing through such nodes. Therefore, the QoS signalling
   solution should be able to efficiently solve this situation.

Best regards,
Georgios

-----Original Message-----
From: Steve Gilbert [mailto:[email-masked]]
Sent: vrijdag 18 januari 2002 17:21
To: [email-masked]
Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless

The cellular wireless QoS problem is very different than that of wired QoS
because of the need to handle the case of a user with a QoS "guarantee" handing
off into a different cell.  In the worst case, the cell which it is entering may
have its resources fully allocated to existing users. Dropping the session of
the user being handed off is not a good idea. This points out the need for some
rational way to accommodate such calls. The approach taken in some wireless
voice systems is to reserve resources for use only by sessions which are handing
off into the cell. This may suffice if the resource needs of the hand off
session are predictable. However, in a system in which arbitrary applications
can utilize a wide range of throughput values, reserving enough capacity to
handle the range of throughputs which could potentially be needed by a single
flow may not be practical.

What is needed is the use of throughput adaptive applications and the ability
for a traffic flow to express its QoS preferences with regard to the throughput
values which it may be allocated. Upon handing off into the new cell, the QoS
preferences of the handoff traffic flow and of the existing traffic flows in
that cell would be considered and resources reallocated to best meet their
preferences. Some of the existing traffic flows may have their throughput
allocations reduced in order to free up resources to be allocated to the handoff
traffic flow.

The QoS signaling needs of this approach include the ability of the system to
notify traffic flows of their new allocations, and the ability for a new traffic
flow requesting "admission" to express its QoS preferences, possibly in terms of
a list of throughput values and the benefit it receives from each. A
non-adaptive real-time application would indicate a single throughput value
which it desires rather than a list of throughput values.

One could argue that this provides no throughput "guarantee" and changes what it
means to have a QoS request "admitted". This is true. But in wireless, it is
difficult and sometimes impractical to provide the same QoS guarantees that
could be provided in a wireline system which doesn't have to deal with
handoff. In a wireless system, there is the possibility that the user will drive
into a tunnel or take the elevator to a sub-basement of a building where the
wireless signal is lost. Radio coverage and QoS can not be guaranteed under all
possible situations.  Wireless channel resources are often more scarce or
expensive than those of a wired channel. This generally results in the
motivation to utilize them more efficiently. What is more realistic than trying
to provide wireless QoS identical to that of wire-line is to come up with a
useful approach for "QoS management" and "resource allocation" which can be
applied in a wireless system.

If efficient utilization of the resources by QoS flows is not a major concern,
the QoS of admitted users could be increased (or at least made less prone to
reductions) through over-provisioning or preventing admission of new calls even
when the level of congestion is still low. The resources not guaranteed to QoS
traffic flows could be used by best effort traffic. Systems with significant
best effort traffic would be able to increase the overall utilization of the
channel without negatively effecting QoS traffic flows.

Steve

> But looking at IntServ (RSVP) or DiffServ,  an interpretation of these signals
> relying on flexibility and cooperation, for example, for congestion handling.
> 1) explicitly dealing with such "QoS exceptions" (there is also an economic 
> argument for this)
>      QoS exceptions back from networks to applications or to between networks,
...

---

From: Yaron Kahana <[email-masked]>
Date: Mon, 21 Jan 2002 15:09:46 +0200

Hi Duediger,

We agree on the problems, and I'm not sure we are in dispute on the
solution. In my opinion, the old PSTN world DCME signaling should be
correlated to network resource management entity of the NGN.
The same applies for the 2nd example - I'm not sure, but I think the simple
solution of "First Come first Served" should not apply in a service oriented
world. If I am a tycoon that paid a lot to the telephone company, or if I'm
a doctor conducting en emergency phonecall, I would like the service
provider to differentiate my sessions from the others (doctors :-)). This
must be done by an entity that understand who is the user behind the
application.

Regards,

Yaron Kahana
COGITO Project Manager
ComGates Ltd.
Email: [email-masked]
Visit Us: www.comgates.com

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: Monday, January 21, 2002 11:15 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in
wireless

>  I also think that the solution of over loading 
>  should be managed by a local "higher hierarchy" 
>  and not by the End-to-End reservation. This 
>  local service controller should be aware of the 
>  sessions, users, resources and commitments. 
>  Hence could decide a "re-negotiation" or a drop.   

I'd favour adaptive applications also in the QoS case. Network to user
re-negotiation means more complexity and it requires extra signalling. Leave
it to the apps. A network may overbook, if it is aware that most apps are
adaptive. This requires no extra procedures.

Two further arguments:
- Plain old telephony used a compression scheme
  to save transatlantic capacity during high 
  congestion (called DCME). No user was
  aware of that. The only extra signalling
  occured  between DCME units. 

- Say you support re-negotiation. Your cell 
  supports 10 QoS reservations and the ten
  of them are used. Number 11 wants to enter
  and triggers a re-negotiation. Do you 
  re-negotiate all of the ten existing
  reservations? Only one? If so, how do you
  decide on the candidate in a fair way?

Regards, Rüdiger

---

From: [email-masked]
Date: Mon, 21 Jan 2002 15:25:08 +0200

Hi all,

> I'd favour adaptive applications also in the QoS case. 
> Network to user re-negotiation means more complexity and it 
> requires extra signalling. Leave it to the apps. A network 
> may overbook, if it is aware that most apps are adaptive. 
> This requires no extra procedures.

NSIS cannot insist on adaptive applications, that is out of
scope.  Perhaps we could think that an NSIS protocol
could support re-negotiation (and allow a user to insist
on no re-negotiaion - but this starts to get into policy).

John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 21 Jan 2002 14:57:18 +0100

Dear Yaron,

Solutions may be different service definitions for the doctor and the standard customer, preemption or a very high service availability. I'm not sure whether a "911" call preempts busy lines in Germany. But to the best of my knowledge, services and networks which are used to support emergency calls must be very reliabile, even if preemption is added as a secondary measure to ensure success. 
I however don't favour preemption as a general tool to differentiate services. It requires additional signalling, network planning and network monitoring. Service descriptions get more complex: a preemption event means a reduced service availability. But to what degree can you control availability decrease caused by preemption?

Regards, Rüdiger 

Y> The same applies for the 2nd example - I'm not 
Y> sure, but I think the simple solution of "First
Y> Come first Served" should not apply in a service
Y> oriented world. If I am a tycoon that paid a lot
Y> to the telephone company, or if I'm a doctor 
Y> conducting en emergency phonecall, I would like
Y> the service provider to differentiate my sessions
Y> from the others (doctors :-)). This must be done
Y> by an entity that understand who is the user 
Y> behind the application.

R> Say you support re-negotiation. Your cell 
R> supports 10 QoS reservations and the ten 
R> of them are used. Number 11 wants to enter 
R> and triggers a re-negotiation. Do you 
R> re-negotiate all of the ten existing 
R> reservations? Only one? If so, how do you 
R> decide on the candidate in a fair way?

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 21 Jan 2002 10:01:01 -0500

Yaron:
 
  The difference with handover in mobile networks is a matter of time
constraints. Handovers
can happen very frequently, and often happen during an active session. For
some applications,
such as best effort applications, re-negotiation of QoS using a high layer
protocol may be viable,
however, for many other services, most notably voice and video, there simply
is not enough time 
before the service is disrupted.
 
   The "re-negotiation" during handoff being referred to is not, I believe,
the same as the negotiation
during session set-up. If it were, then yes, it should happen at a higher
layer, and as I have alluded to
above, not likely to help the situation much. I would go so far as to say
that the situation during a
handover is not so much "re-negotiation" as "notification" of a change in
QoS. However, this gets
deep into the solution space, and unless there is a need for use to explore
it in order to understand
the requirement, we should defer the discussion.
 
Gary

-----Original Message-----
From: Yaron Kahana [mailto:[email-masked]]
Sent: January 19, 2002 14:27
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]';
[email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless

Hi all,

 

Best Regards,
 
Yaron Kahana
COGITO Project Manager
COMGATES

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:31 PM
To: [email-masked]'; [email-masked]; [email-masked]
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless

Steve: 

Gary

---

From: "Chen, Weijing" <[email-masked]>
Date: Mon, 21 Jan 2002 09:36:57 -0600

[wj] I agreed with Rüdiger's comment. It is up to NP&E (Network Planning and
Engineering) to proper engineering the network for most frequent situations.
If network can not handle the request, it ought to return back a busy
signal. That is the job of NP&E engineers, it is their butter and bread. The
preemption service is difficult and involving a lot of regulatory and legal
issues. Don't go there.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----
From: 	Geib, Ruediger [mailto:[email-masked]] 
Sent:	Monday, January 21, 2002 7:57 AM
To:	[email-masked]; Geib, Ruediger
Cc:	[email-masked]
Subject:	RE: [NSIS] Support needed for Throughput Adaptive QoS in
wireless

Dear Yaron,

Solutions may be different service definitions for the doctor and the
standard customer, preemption or a very high service availability. I'm not
sure whether a "911" call preempts busy lines in Germany. But to the best of
my knowledge, services and networks which are used to support emergency
calls must be very reliabile, even if preemption is added as a secondary
measure to ensure success. 

I however don't favour preemption as a general tool to differentiate
services. It requires additional signalling, network planning and network
monitoring. Service descriptions get more complex: a preemption event means
a reduced service availability. But to what degree can you control
availability decrease caused by preemption?

Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 22 Jan 2002 09:57:27 +0100

Hermann

> more generally, as pointed out by Georgios, this can be 
> referred to as QoS violation signalling:
> network to network or network to edge/host etc.
> 
> extending Georgios' view:
> - it may as well be required in wired network segments (not only in 
>   wireless segments)
> - does not only apply to individual flows but also to whole 
>   aggregates in the DiffServ sense, for example.
> 
> Please note, this does not necessarily mean re-negotiation.

Sounds like some kind of "congestion notification". An adaptive application would provide it on application level. Alternatively, a network service may provide it. I guess it is not a general requirement but may be useful for some services. Did we find a useful feature which doesn't have to be part of a generic NSIS protocol? I would agree, it should (or even must) be possible to add service specific congestion notification to an NSIS protocol.

Regards, Rüdiger

---

From: [email-masked] (Gabor Fodor)
Date: Wed, 23 Jan 2002 11:51:06 +0100 (MET)

Paulo,

Paulo Mendes wrote :

> Considering all the references to RSVP in this thread, the amount of 
> resources reserved in the network can be the information to supply 
> applications with. However this information is only useful if the 
> network has per-flow reservation end-to-end, which isn't always true. If 
> some kind of data aggregation in used in (part of) the network, e.g. 
> DiffServ, the information that applications require from NSIS if not the 
> amount of resources reserved to the DiffServ class/service they are 
> using, but the amount of those resources that are allocated to their 
> session.
> 

[GF]
In my view it can also be useful if the NSIS protocol allows a certain
network segment to notify the host about the available resources either
at call setup time or during the call even there is aggregation in
some part(s) of the network. 

That is, the support of re-negotiation and adaptivity can be a 
useful feature even if there is no per-flow resource reservation end-to-end. 
An example of such a situation is a wireless access link that has
its own wireless reosurce manager that can notify the application 
about the wireless link status. Since the application runs over IP,
the wireless link manager needs to communicate with the IP level 
signaling entity in order to do this notification. 
[GF]

/Gabor

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Thu, 24 Jan 2002 16:26:44 -0500

Agreed. More inputs inline [RRR].

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: Thursday, January 24, 2002 4:06 PM
To: Roy, Radhika R, ALASO
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
wireless

Roy, Radhika R, ALASO wrote:

> Inline [RRR]
> From: Paulo Mendes [mailto:[email-masked]]
> Sent: Tuesday, January 22, 2002 9:17 PM
> To: Roy, Radhika R, ALASO
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
> wireless
> 
> 
> There are references in this thread to adaptive applications and 
> applications that require re-negotiation of QoS parameters. However 
> these are two different type of applications.
> I agree with you that re-negotiation require extra signalling from NSIS. 
> However this extra burden don't exist with adaptive applications, which 
> I think only require to be notified by NSIS about the available network 
> quality... So the requirements imposed to NSIS by these two types of 
> applications are different.
> 
> [RRR] Not really. We do not know what is the definition of adaptive application (can you cite an example that is being used?). If we assume that an adaptive application is able to adapt the QOS in accordance to the needs of the lower layer QOS, even then NSIS QOS will be able to satisfy its needs. Because the adaptive application, as I understand from your term with limited knowledge, will not use all capabilities of the NSIS QOS. It will rather will use a sub-set of the NSIS QOS capability.

[PM] By adaptive applications I mean applications that have the 
capability to adjust the rate they are using depending upon the 
available network resources. For this they need to be notified by the 
network about the quality level they are entitle to during the session.
As an example of an adaptive mechanism I can mention RLM from Steve 
McCanne as receiver-driven and MLDA from Dorgham Sisalem as 
source-driven. I can also mention an application that allows 
receiver-driven adaptation since receivers can adjust the video quality 
adjusting the number of video layers they receive: Rendez-Vous 
(http://www.gaia-interactive.com/rv/)
Therefore, I think adaptive applications support should be considered in 
  the NSIS Framework, as was proposed by David Partain.

[RRR] Yes, it is quite possible even in the simple codecs in multimedia conferencing even without layer coding. For example, codecs can send signals among themselves to measure delay for synchronization or flow control signal (e.g., buffer overflow etc.). This kind of signaling among the codecs will also allow to predict what rate/bandwidth is available in the lower layer (or even in the presentation [codec] layer) and codec's rate/flow needs to be adjusted accordingly (as if a kind of flow control mechanism used similar to the TCP layer).

> [RRR] It is also not clear how an adaptive application will behave when QOS needs to be agreed upon between the two parties. Can you please provide some examples to know their behavior?

[PM] During setup I think they might behave exactly as the other 
applications, i.e., they will try to negotiate a quality level with the 
network. I only meant that during the session, adaptive applications 
differ from applications that require re-negotiation since the latter 
will require extra signalling.

[RRR] So, it is a simplistic case because there is an implicit agreement between the users that if the network signals to them whatever rate/bandwidth available after the session setup will be OK for them and they do not need to re-negotiate. Consequently, NSIS doe not need to send any extra signaling for negotiations. Users applications will have to a hook to do so and no new works are needed in NSIS QOS.

Cheers
Paulo

> Roy, Radhika R, ALASO wrote:
> 
> 
>>Hi, John:
>>
>>I agree with you and like to add a little more [RRR].
>>
>>Best regards,
>>Radhika
>>
>>

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