1 / 8

GIST – The NSIS Transport Layer draft-ietf-nsis-ntlp-09.txt

GIST – The NSIS Transport Layer draft-ietf-nsis-ntlp-09.txt. Robert Hancock, Henning Schulzrinne (editors) IETF#66 – Montr é al July 2006. Status: Inputs. Version -09 released 9 th February Taking account of WGLC comments, and other comments that arose while processing WGLC comments, etc.

hwalsh
Télécharger la présentation

GIST – The NSIS Transport Layer draft-ietf-nsis-ntlp-09.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GIST – The NSIS Transport Layerdraft-ietf-nsis-ntlp-09.txt Robert Hancock, Henning Schulzrinne (editors) IETF#66 – 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-ntlp-issues/index

  3. Status: Current Snapshot • ‘Stepping stone’ to v10 can be seen at http://nsis.srmr.co.uk/nsis/draft-ietf-nsis-ntlp-10-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 T2=64*T1.” • Could allow T1 to be adaptive based on timing information for previous Queries for that MRI; however, it’s 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 B=10, N=10/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

More Related