RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope

["Francois Le Faucheur \(flefauch\)" <[e-mail]>]

Hello Janet, 

>> -----Original Message-----
>> From: Janet P Gunn [mailto:[e-mail]] 
>> Sent: mardi 6 juin 2006 17:42
>> To: Janet P Gunn
>> Cc: [e-mail]; [e-mail]; Francois Le 
>> Faucheur (flefauch); [e-mail]; [e-mail]
>> Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : 
>> Preemption scope
>> 
>> 
>> 
>> 
>> 
>> I said
>> 
>>  If I remember correctly, one of Joseph  Babiarz IDs hinted at this
>> behavior, with a variant on RSVP as the mechanism.
>> 
>> I take it back.
>> I was thinking of draft-ietf-tsvwg-rsvp-bw-reduction-00.txt,
>> A Resource Reservation Extension for the Reduction of
>>                   Bandwidth of a Reservation Flow
>> 
>>                         February 10th, 2005
>> 
>>  James Polk
>>  Subha Dhesikan
>>   Cisco Systems
>> 
>>  but it doesn't seem to have survived on line.

It is alive and kicking: It is now RFC4495. 

Yes, I believe the mechanisms defined in RFC4495 could be used in
conjunction with those of <emergency-rsvp> to achieve the preemption
flavor you described in your other message ie where some "non-emergency"
sessions could have their reservation reduced to make room (if needed)
for emergency sessions. As mentioned in RFC4495, RSVP will ensure that
the end systems get notified of the reservation reduction. This allows
end-systems to react appropriately (for example fall back to a lower
bandwidth codec). This is to make sure that the bandwidth reduction does
not simply translate in huge QoS degradation on the corresponding calls.

The current version of <emergency-rsvp> allows (along with RFC4495) to
implement such a flavor of emergency, should one decide to want that.

We could add this "flavor" of emergency to the list of flavor examples
(and associated mechanisms) in the new Appendix.

Cheers

Francois

>> Janet
>> 
>> 
>> -------------------------------------------------------------
------------------------------------------------------------------------
-------------------------------------------
>> 
>> This is a PRIVATE message. If you are not the intended 
>> recipient, please
>> delete without copying and kindly advise us by e-mail of the 
>> mistake in
>> delivery. NOTE: Regardless of content, this e-mail shall not 
>> operate to
>> bind CSC to any order or other contract unless pursuant to 
>> explicit written
>> agreement or government initiative expressly permitting the 
>> use of e-mail
>> for such purpose.
>> -------------------------------------------------------------
------------------------------------------------------------------------
-------------------------------------------
>>