Subject: RE: [NSIS] GIST issue on MA-Hold-Time

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 31 Oct 2006 17:35:12 -0000

Hi Roland,

there have been questions about exactly when and how to send
the confirm, and when and how to include the hold time value.
The details and proposals for how to fix them are in the 
tracker at 
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue156

you might like to take a look. Some more detailed comments in
line below.

r.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 16 October 2006 16:43
> To: Hancock, Robert
> Cc: nsis
> Subject: Re: [NSIS] GIST issue on MA-Hold-Time
> 
> 
> Hi Robert and all,
> 
> Hancock, Robert wrote:
> > An issue has been raised on MA-Hold-Time negotiation. It is in
> > the tracker as issue #131
> > 
> (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131)
> > and the summary text is included below.
> >  
> > This is a solicitation for input, especially from the 
> implementors, on 
> > this matter. In the absence of input, my preference would 
> be to leave 
> > to spec unchanged, but if people feel that this level of 
> flexibility 
> > is necessary please speak up and say so. It would be very 
> good to see 
> > change/no change comments either way.
> 
> I'm not really sure whether it's indeed required to have an 
> own MA-Hold-Time per protocol. On the one hand the 
> negotiation is already complex enough, on the other hand it 
> would be more consistent to provide it per proposal. 
> Currently, I would vote for no change.

At the moment I have done nothing.

> 
> However, I have more issues that came up with the 
> MA-Hold-Time during the interop test:
> * What does an MA-Hold-Time of 0 mean (keep open forever)?

Reserved. Added text to say this.
(This and the next point are actually covered under a different
issue, http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131)

> * Should very small values, e.g., below one or several seconds
>   be always ignored and forced to be set to a predefined lower bound?
>   (In order to avoid a flooding with MA-Hellos)

I am not sure how to do this in an interoperable way without 
quite a bit of extra complexity (some more message rounds). I'd
prefer just to emphasise that it's silly to use small values.
Any text suggestions?

> * The MA-Hold-Time must be repeated in the first Confirm message
>   due to the need for having this value available even if late
>   state installation is used.
>   => What should be done if the MA-Hold-Time is missing?
>   Sending back an Object-Type error with mandatory object missing is
>   probably the right thing to do.

Done.

>   Furthermore, the specification in 5.1 of the Confirm message
>   is confusing in this respect and should be clarified.
>        Confirm = Common-Header
>                  Message-Routing-Information
>                  Session-Identification
>                  Network-Layer-Information
>                  [ Responder-Cookie
>                   [ Stack-Proposal
>                      [ Stack-Configuration-Data ] ] ]
>                  [ NSLP-Data ]
>   While the example in fig.4 sheds more lighty on how it is
>   intended, one would think that Stack-Proposal _and_ SCD
>   of the Responder are repeated in the Confirm (so I guess
>   nesting with brackets must be fixed). Therefore,
>   clarification is needed that only the R-Node SP is repeated
>   (w/o R-Node SCD)
>   and the Q-Node SCD with MA-Hold-Time is mandatory in the
>   very first Confirm. 

I think that the ABNF is correct here; the real problem is that
ABNF is not a good syntax for handling 'conditionally mandatory'
information elements. More discussion is in the issue tracker.
Also, I don't really want to qualify which SP is included 
(since this makes the ABNF harder to validate). Hopefully the
new text before the ABNF in 5.1 makes this clearer.

> Thus, also the MAY on top of p. 30
>   (sec 4.4.1) should be a MUST.

Done.

Cheers,

robert h.
> 
> Regards,
>  Roland
> 
> > [Following Routing Area Directorate comments from Adrian Farrel]
> > 
> > At the moment, the MA-Hold-Time in a proposal applies to 
> all possible 
> > configurations of the messaging association. There is no way to 
> > indicate that (for example) one would prefer 30 seconds for 
> TCP, but 
> > 120 seconds for TLS/SCTP.
> > 
> > In principle, different hold time possibilities could be 
> indicated in 
> > the Query, but this would require some changes in the 
> Stack-Proposal 
> > or Stack-Configuration-Data objects. The SCD syntax does 
> not allow one 
> > to specify a
> > value which applies to a whole proposal, only to a MA-protocol in a
> > proposal;
> > the SP syntax does not allow one to specify MA-Hold-Time at all. One
> > option
> > would be to tag the MA-Hold-Time value in the SCD so that 
> there was a
> > single
> > value (tagged 0) possibly overridden by alternative values for
> > particular
> > proposals (rather like we do for the other protocol 
> options). The SCD
> > would get
> > another count field in the header, and we could steal a 
> byte from the
> > MA-Hold-Time field for the tag.
> > 
> > However, it is not clear whether the value of this sophistication 
> > outweighs the cost. The policy for choosing an MA-Hold-Time 
> presumably 
> > is a tradeoff between 3
> > variables:
> > a) the extent to which an MA is being used or is going to be used
> > b) the cost of keeping the MA open (in stored protocol 
> state inside the
> > protocols that make up the MA itself)
> > c) the cost of re-setting up the MA if it is needed again
> > Of these, (a) is totally independent of the protocol 
> configuration, (b)
> > is
> > weakly dependent on it, and (c) is definitely dependent on 
> it. But the
> > strength
> > of the dependence is not that great. If you just chose the largest
> > hold-time
> > value for all possible MA configurations and used that as the single
> > value in
> > the negotiation, the net affect would not be much different 
> from what
> > could be
> > achieved with a more granular mechanism.
> > 
> ==============================================================
> ==========
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> 
> -- 
> Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless
> Institut für Telematik, Universität Karlsruhe (TH), Germany 
> Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358
> Tel.: +49 721 608-6413 Fax: +49 721 608-6789
> 

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