Subject: Re: [NSIS] QoS NSLP: summary object

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 10 Nov 2006 08:40:07 +0100

Dear Jukka, dear Roland

as expressed by my mail

http://www1.ietf.org/mail-archive/web/nsis/current/msg04320.html

(see "3.2.5 Change to: Refresh options"),

I support proposal number 1 on refreshing several sessions 
by a single Reserve. 

The above mail also proposed changes to the RSN mechanism aiming to 
simplify summary refresh, but these aren't applicable any more 
(what I proposed back then on RSN handling would require 
significant changes in NSLP - too late for that now).

Regards,

Rudiger

-----Original Message-----
From: Jukka MJ Manner [mailto:[email-masked]]
Sent: Thursday, November 09, 2006 10:48 PM
To: Roland Bless
Cc: [email-masked]
Subject: Re: [NSIS] QoS NSLP: summary object

Hi,
two comments back. :)

Jukka

On Thu, 9 Nov 2006, Roland Bless wrote:

> Hi Jukka and all,
> 
> Jukka MJ Manner wrote:
> > Based on John's request, here is recap of the summary object
mentioned 
> > today. After Roland's comment on the mic, there are actually two use

> > cases:
> > 
> > 1. Allow a QNE to refresh several sessions in one NSLP refreshing
RESERVE 
> > message. 
> > 
> > 2. Allow a ANE to tear down several sessions in one NSLP tearing 
> > RESERVE message.
> > 
> > Both of these save bytes and processing compared to doing it
independently 
> > for each session. They can be implemented outside GIST by keeping
track of 
> > the SII_HANDLE provided by GIST (however, you can only know the
handle 
> > after you have received a message from the per, e.g., a RESPONSE).
If a 
> 
> Not quite. After you received a GIST response. GIST will report it
> upwards to the NSLP. However, you care about refresh or tear only
> after the initial setup worked. So I don't see any problems here.
> Furthermore, it is an optimization, so basically no problem if it
> is not applicable in some rare cases.

[1] This note comes from looking at the GIST API. In order to send a 
summary refresh, you need to have compared the GIST SII_HANDLE before.
And 
you will only get to know the SII_HANDLE for a session if you receive
the 
RESPONSE. It is not a problem in the general case, just a note.

> 
> > QNE has sessions whose next peer has the same SII_HANDLE, it can use
a new 
> > SESSION_LIST where it indicates SID+RSN pairs of sessions it wants
to 
> > refresh or tear down. The receiving QNE, in case of unknown SID,
will 
> 
> Yes, and as we just discussed in private, it would be good to have
> an SID-List only object (SIDs w/o RSN), too.

[2] Actualy... may be not. You need the SID AND the RSN for both tear
and 
refresh. Thus, you need to send both anyway. RSN is a mandatory object
for 
all RESERVE messages. You need to have the RSN in synch if you are
tearing 
otherwise you will tear a different state than the previous QNE.

> 
> > reply with a RESPONSE carrying the same object to indicate which
session 
> > references where not understood. If a confirmation was requested
from the 
> > QNR for a tear, and it must send an individual RESPONSE for each 
> > terminated session, as usual - the summary refresh could hit a QNR
with 
> > multiple sessions being terminated.
> 
> In this case we would get a summary error back.
> 
> > We would like to add this to the NSLP spec. Any comments, arguments,

> > feedback? I'll wait for a week, then add this unless I hear
arguments 
> > against.
> 
> Obviously I'm in favor of having that. However, we must be careful
> about covering the new error cases and handle them properly.
> 
> Regards,
>  Roland
> 
> 

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

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