Subject: RE: [NSIS] RE: qos-nslp-00

From: "McDonald, Andrew" <[email-masked]>
Date: Wed, 24 Sep 2003 13:35:20 +0100

Hi Cornelia, Ruediger,

I'm sure the phrase "monotonically increasing sequence number" was used to describe the RSN at some point, but it appears to have got lost in one of the rewrites.

Andrew

Kappler Cornelia wrote:
> Hi Ruediger,
> 
> We deliberately refer to the state to be refreshed by the RSN
> (minimally) rather than by the session ID. 
> 
> Summary refreshes should be handled with caution, we should be sure
> it is the correct state that is being refreshed. If we just use
> session ID, we dont know what possibly obsolete state might be
> refreshed. By matching the RSN in the summary refresh with the
> locally stored RSN, a nodes knows whether it is refreshing the
> correct state.     
> 
> Vice versa, when the RSN in the summary refresh does not match the
> local RSN, the refresh will be disregared - which makes sense,
> because a problem must have occurred (i.e. a node does not have the
> most up-to-date state information).   
> 
> Originally the idea was to make RSNs monotonically increasing
> (remember they have only local significance), so the newest RESERVE
> can always be identified. For some reason this idea didnt make it
> into the current version of the ID (I just noticed) I am not sure
> this was on purpose.    
> 
> Of course all this should become clear from reading the ID. We should
> check where it can be clarified. 
> 
> Does this address your concerns?
> 
> Cornelia
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Geib, Ruediger [mailto:[email-masked]]
>> Gesendet: Mittwoch, 24. September 2003 13:59
>> An: [email-masked]
>> Cc: [email-masked]
>> Betreff: RE: [NSIS] RE: qos-nslp-00
>> 
>> 
>> Hi Cornelia,
>> 
>> if it is important to identify a reserve message by a
>> refresh instead of a session, then I'd appreciate text
>> on the protocol reaction if the refresh's RSN can't
>> be matched with local state. The following occasions
>> may occur:
>> - no similar RSN
>> - local RSN bigger then refresh RSN
>> - local RSN smaller then refresh RSN
>> 
>> I'd suggest at least a placeholder for the issue in the next version.
>> 
>> Regards, Rüdiger
>> 
>>> the RSN identifies a specific RESERVE message, whereas the
>>> session ID identifies a session, during which many RESERVE messages
>>> may be issued. 
>>> 
>>> Cornelia
>>> 
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Geib, Ruediger [mailto:[email-masked]]
>>>> Gesendet: Mittwoch, 24. September 2003 13:26
>>>> An: [email-masked]
>>>> Cc: [email-masked]
>>>> Betreff: [NSIS] RE: qos-nslp-00
>>>> 
>>>> 
>>>> Hi Sven,
>>>> 
>>>> maybe we have different concepts of what a session ID identifies.
>>>> To me it identifies the flow of packets for which you request a
>>>> service by NSIS signaling. I think that is exactly what you use
>>>> the RSN for in the case of refreshes.
>>>> What is your definition of session ID?
>>>> 
>>>> Regards, Rüdiger
>>>> 
>>>>>> - Retransmitted "Reservation Sequence Numbers"
>>>>>>  serve as a Session ID. Why aren't
>>>>>>  the tradeoffs and benefits of combining both
>>>>>>  functions discussed?
>>>>>> 
>>>>>> Sven>> We took special care not to use the RSN for anything else
>>>>>> but ensuring that QoS NSLP message reordering could be detected.
>>>>>> They have nothing to do with any session ID at the NTLP. Afaik,
>>>>>> it is an open issue how NTLP sessions will relate to NSLP
>>>>>> message exchanges. 
>>>>> 
>>>>> [Rudi]: Section 4.2 introduces a summary refresh using the RSN to
>>>>> identify a reservation. This isn't related to reordering.
>>>>> 
>>>>> Sven>> It is used in the summary refresh, but this is purely a
>>>>> QoS NSLP matter that is unrelated to the session ID. Note that we
>>>>> see 
>>>>> the summary refresh with RSN as a minimal case but that other
>>>>> objects or parameters may be part of it.
>>>> 
>>>> _______________________________________________
>>>> nsis mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/nsis
>>>> 
>>> 
>> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

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