Subject: [NSIS] backoff, rate limiting and other parameters

From: "Robert Hancock" <[email-masked]>
Date: Fri, 14 Jul 2006 14:18:49 -0400

hi all,

at the session on Wednesday, there was some discussion about the various
parameters for rate limiting, backoff during the handshake process, and
other timers. i'm summarising the proposed v10 text here in case people want
to comment:

in section 4.4.3 for routing state refresh time (also probe frequency in
7.1.2):

  "Each item of routing state expires after a lifetime which is
   negotiated during the Query/Response/Confirm handshake.  The Network
   Layer Info (NLI) object in the Query contains a proposal for the
   lifetime value, and the NLI in the Response contains the value the
   Responding node requires.  A default timer value of 30 seconds is
   RECOMMENDED.  Nodes which can exploit alternative, more powerful,
   route change detection methods such as those described in
   Section 7.1.2 MAY choose to use much longer times.  Nodes MAY use
   shorter times to provide more rapid change detection, but MUST take
   into account the fact that the Query messages generated may stress
   the rate limits applied to D-mode traffic (Section 5.3.3)."

in section 4.4.3 for the default time to hold an unused MA open:

   "During
      messaging association setup, each node indicates its own MA-Hold-
      Time as part of the Stack-Configuration-Data.  A node MUST NOT
      tear down the association if it has received traffic from its peer
      over that period.  A peer which has generated no traffic but still
      wants the association retained may use a special null message
      (GIST-MA-Hello) to indicate the fact.  A default value for MA-
      Hold-Time of 30 seconds is RECOMMENDED.  Nodes MAY use shorter
      times to achieve more rapid peer failure detection, but need to
      take into account the load on the network created by the Hello
      messages.  Nodes MAY use longer times, but need to take into
      account the cost of retaining idle connections for extended
      periods."

in section 5.3.3 for the backoff during Query handshakes:

  "Query messages which do not receive Responses MAY be retransmitted;
   retransmissions MUST use a binary exponential backoff.  The initial
   timer value is T1, which the backoff process can increase up to a
   maximum value of T2 seconds.  The default value for T1 is 500 ms.  T1
   is an estimate of the RTT between the querying and responding nodes.
   Elements MAY use smaller values of T1 if it is known that the Query
   should be answered within the local network.  T1 MAY be chosen
   larger, and this is RECOMMENDED if it is known in advance (such as on
   high latency access links) that the RTT is larger.  A default value
   of T2 is 64*T1.

   Note that Queries may go unanswered either because of message loss
   (in either direction), or because there is no reachable GIST peer.
   Therefore, implementations MAY trade off reliability (large T2)
   against promptness of error feedback to applications (small T2).  If
   the NSLP has indicated a timeout on the validity of this payload (see
   Appendix B.1), T2 MUST be chosen to be less than this value."

in section 5.3.3 for rate limiting:

  "The basic rate-control requirements for D-mode traffic are
   deliberately minimal.  A single rate limiter applies to all traffic,
   for all interfaces and message types.  It applies to retransmissions
   as well as new messages, although an implementation MAY choose to
   prioritise one over the other.  Rate-control applies only to locally
   generated D-mode messages, not to messages which are being forwarded.
   When the rate limiter is in effect, D-mode messages MUST be queued
   until transmission is re-enabled, or an error condition MAY be
   indicated back to local signaling applications.  The rate limiting
   mechanism is implementation-defined, but it is RECOMMENDED that a
   token bucket limiter as described in [31] be used.  The token bucket
   should be sized to ensure that a node cannot saturate the network
   with D-mode traffic, for example when re-probing the network for
   multiple flows after a route change.  A suitable approach is to
   restrict the token bucket parameters so that the mean output rate is
   a small fraction of the nodes lowest-speed interface, such as 5%."

cheers,

robert h.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Jul 2006 13:21:06 +0200

Hi,

I think the new text is acceptable. I would have preferred clearer 
rate-limiting rules. However I will accept this as one area where 
further work and deployement hopefully will clarify the impact.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]