GIST

1
GIST The NSIS Transport Layerdraft-ietf-nsis-nt
lp-09.txt

• Robert Hancock, Henning Schulzrinne (editors)
• IETF66 Montréal
• July 2006

2
Status Inputs

• Version -09 released 9th February
• Taking account of WGLC comments, and other
  comments that arose while processing WGLC
  comments, etc.
• Very thorough review by Magnus
• Thread starts at http//www1.ietf.org/mail-archive
  /web/nsis/current/msg06306.html
• Some additional points turned up in the issue
  tracker in the meantime
• http//nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-nt
  lp-issues/index

3
Status Current Snapshot

• Stepping stone to v10 can be seen at
  http//nsis.srmr.co.uk/nsis/draft-ietf-nsis-ntlp-1
  0-v1.txt
• Takes account of Magnus L1, L3, L5, L7, L8, L9,
  L11, L12, L14, part L15, L16, L20, L21, L22, L23,
  L25, N2, N4, N5, N6, part N7, N8, N9 (and issue
  111, which is new)
• No mods for L4, L13, L17, L18, N3
• See D.1 for the details of what has changed where
• Still updating for the other points (following ML
  discussion), a couple of issues worth
  highlighting here

4
I Transport-related parameter values (M1, L10,
L15)

• General concern that there is too much
  implementation freedom in setting the tunable
  parameters of the protocol
• Applies to
• Backoff parameters during handshake
• Rate limits for D mode
• Handshake lifetime
• Hello frequency
• Probe frequency

5
Parameter Proposals

• For backoff, used SIP (rfc3261 17.1.1.2) as a
  starting point
• The default value for T1 is 500 ms. T1 is an
  estimate of the RTT between the client and server
  transactions. 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. Whatever the value
  of T1, the exponential backoffs on
  retransmissions described in this section MUST be
  used. The value of T264T1.
• Could allow T1 to be adaptive based on timing
  information for previous Queries for that MRI
  however, its not clear how much value this
  provides
• You only really care about fine-tuning T1 for new
  flows/after route changes, when no valid feedback
  is available
• For handshake lifetime, probe and hello
  frequency recommend a default value of 30
  seconds (with SHOULD force).

6
Rate Limiting (1/2)

• Trickier situation is D-mode rate limiting.
  Current spec (see section 5.3.3) only requires
  the use of a token bucket without giving bucket
  parameters
• Why a token bucket? From following the ICMPv6
  specification discussions (about 65 messages from
  January 2004)
• Basic problem the bucket parameters depend on
  the size of the router, which is a nebulous
  concept to pin down

7
Rate Limiting (2/2)

• 4 options
• Leave this part of 5.3.3 as it is
• Use some example non-normative numbers
• Cf. RFC4443 The rate-limiting parameters SHOULD
  be configurable. In the case of a token-bucket
  implementation, the best defaults depend on where
  the implementation is expected to be deployed
  (e.g., a high-end router vs. an embedded host).
  For example, in a small/mid-size device, the
  possible defaults could be B10, N10/s.
• Relate it to some other more intuitive sizing
  parameters, such as sessions and session
  lifetime
• Define an adaptive scheme (not clear if this is
  even possible)

8
II IANA Considerations

• Need a number of technical and procedural
  clarifications
• Depend normatively on extensibility document
• Clarify applicability of experimental/private
  space (issue 106)
• Explain rationale for reserved spaces
• Less restrictive policy for NSLPID allocations?
• Currently experimental or IESG approval only