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

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 21 Jan 2002 10:15:00 +0100

>  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  

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

---

From: Hermann De Meer <[email-masked]>
Date: Mon, 21 Jan 2002 20:16:35 +0000

Ruediger,
Georgios,

At 10:15 21/01/2002 +0100, Geib, Ruediger wrote:
>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.

I tend to agree ...

>   occured  between DCME units.

this is a good observation!
what it needs, however, from the signalling side is congestion 
indication/notification.
Now this is something that has traditionally been ignored within QoS 
architectures
and would be very useful  to be incorporated within NSIS, therefore.

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.

Regards,
Hermann

---

From: Paulo Mendes <[email-masked]>
Date: Tue, 22 Jan 2002 21:39:54 -0500

Comments below [PM]

>> apps are adaptive. This requires no extra procedures.

[PM] It makes two of us ...

> and would be very useful  to be incorporated within NSIS, therefore.

[PM] It should be interesting to complement this congestion notification 
with some information to help applications to converge quickly to the 
optimal rate. Let say for example inform applications about the 
bandwidth the network allocs to their session. NSIS could get this 
information from network level protocols.

> more generally, as pointed out by Georgios, this can be referred to as 
> QoS violation signalling:

[PM] I seems a good idea...

> - does not only apply to individual flows but also to whole aggregates 
> in the DiffServ sense,

[PM] I also agree with this.. However in the presence of aggregation the 
kind of notification NSIS provide adaptive application with, should have 
a higher fine-granularity. This is, notifications about the amount of 
resources reserved for the aggregate traffic isn't useful to applications.

Paulo Mendes

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