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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 12 Oct 2006 10:23:07 +0100

Hi all,

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.

cheers,

robert h.

========================================================================
[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

---

From: Roland Bless <[email-masked]>
Date: Mon, 16 Oct 2006 17:42:34 +0200

Hi Robert and all,

> up and say so. It would be very good to see change/no change 

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.

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)?
* 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)
* 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.
  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. Thus, also the MAY on top of p. 30
  (sec 4.4.1) should be a MUST.

Regards,
 Roland

-- 
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

---

From: Roland Bless <[email-masked]>
Date: Tue, 17 Oct 2006 16:14:09 +0200

Hi Robert and all,

an important addition that I missed:
repeating the MA-Hold-Time
is only required when C-Mode is used.
Sorry for that.

Regards,
 Roland