Subject: RE: [NSIS] New NSIS-related drafts - bandwidth negotiation

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 17 Oct 2002 12:31:04 +0200

Xiaoming,

[RG] Would negotiation then be an option or a requirement? 
Option would be ok to me. The mechanism suggested leaves the 
granularity of bandwidth reduction to CASP signaling 
elements within the network. It may not be aware of the 
way an application reduces bandwidth. A voice or MPEG 
Codec may reduce bandwidth by changing its analog/digital 
coding scheme. The bandwidth is by granular steps. 
The NSIS unit within the network probably isn't application 
aware. The sender may then have the options of reducing it's 
rate to the next possible one below the bandwidth resulting 
from negotiation or restart the reservation with that value 
(if no more then the required bandwidth should be reserved).

[RG] Wouldn't it be simpler if an application indicates that 
it is able to reduce transmission bandwidth during reservation? 
If the network notices upcoming shortage of resources, further 
reservations may be accepted while some active (and new) 
reservations are asked to reduce their sending rate. 

[RG] Again my suggestion to ask application experts on their 
expectations or preferences. 

Regards, Rüdiger

> [RG] The maximum/minimum bandwidth procedure seems to be the only
> feasible way of realising a simple negotiation mechanism. I still
> feel it to be too complex and would favor a single bandwidth as
> only requirement for the protocol. I'd be curious in learning 
> more about application developers views on that.
> 
> [XF] We thought this is helpful particullarly in wireless mobile
> environments; people may use only one bandwidth if a single bandwidth
> information is available. Meanwhile we would also like to see how this
> could or could not well-fit the QoS provisioning techniques and
> applications.
 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis