Subject: RE: Refresh Reduction = RE: [Tsvwg] WGLCfordraft-ietf-tsvwg-rsvp-ipsec-00.txt NOW

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Fri, 19 May 2006 09:56:47 +0200

Alex and all, 

>> -----Original Message-----
>> From: Francois Le Faucheur (flefauch) 
>> Sent: jeudi 18 mai 2006 15:56
>> To: Alexander Sayenko
>> Cc: tsvwg
>> Subject: Refresh Reduction = RE: [Tsvwg] 
>> WGLCfordraft-ietf-tsvwg-rsvp-ipsec-00.txt NOW
>> 
>> Hello again Alexander,
>> 
>> >> Another proposition concerns the extended vDstPort. It is 
>> >> mentioned that it
>> >> is "normally set to all zeroes". 
>> 
>> Actually, that text probably needs some tweaking. 
>> It is normally set to zero IF the session needs to be shared across
>> multiple Aggregators (eg if the reservation is to be shared across
>> multiple aggregators). However, I believe each aggregator 
>> would normally
>> want a separate reservation and thus should write its IP address in
>> there.
>> I will think/discuss more about that and propose some edits 
>> to reflect
>> that.
>> 

Here is the replacement text I'd like to propose:

"
 Extended vDstPort (Extended Virtual Destination Port) 
 
 A 32-bit identifier used in the SESSION that remains constant over
 the life of the generic aggregate reservation. 
 A sender (or Aggregator) that wishes to narrow the scope of a
 SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair)
 SHOULD place its IPv4 address here as a globally unique identifier. A
 sender (or Aggregator) that wishes to use a common session with other
 sender (or Aggregators) in order to use a shared reservation across
 senders (or Aggregators) MUST set this field to all zeros.
"

Let me know if you have comments/issues.

Tx

Francois

>> >>Is it logical to send zeros 
>> >> (16 bytes in
>> >> the case of IPv6)? Furthermore, while sending the refresh 
>> >> PATH messages we
>> >> can reduce the overhead. I realize that one can use the 
>> RSVP refresh
>> >> reduction, but it is just recommendation, not obligation. 
>> >> So, the solution
>> >> is to introduce another C-Type that will correspond to the
>> >> GENERIC-AGGREGATE-IPv6/v4 SESSION without the extended 
>> >> vDstPort field.
>> 
>> Considering that, [In light of what I said above] the common 
>> case will
>> be that the field actually contains a meaningful information (ie
>> non-zero) and that there is a refresh reduction mechanism available
>> which would reduce the overhead orders of magnitude more, it doesn't
>> seem worth defining/handling yet another session type. This 
>> would just
>> save one field in a minority of cases. Would you agree?
>> 
>> >> Also, I have implemented the aggregated RSVP reservations 
>> >> for the NS-2
>> >> simulator. 
>> 
>> Nice!
>> 
>> Cheers
>> 
>> Francois
>> 
>> PS: Thanks for your review/comments and giving this spec the 
>> benefits of
>> your RFC3175 implementation experience.
>>