Re: [rrg] Issue #2 from Paul Jakma

RJ Atkinson <rja.lists@gmail.com> Thu, 17 June 2010 19:36 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6003A68B9 for <rrg@core3.amsl.com>; Thu, 17 Jun 2010 12:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.222
X-Spam-Level:
X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA86D8QJbBFI for <rrg@core3.amsl.com>; Thu, 17 Jun 2010 12:36:32 -0700 (PDT)
Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by core3.amsl.com (Postfix) with ESMTP id 3D8413A69D1 for <rrg@irtf.org>; Thu, 17 Jun 2010 12:36:31 -0700 (PDT)
Received: by vws20 with SMTP id 20so10371587vws.13 for <rrg@irtf.org>; Thu, 17 Jun 2010 12:36:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=54Ez2qYm2gnu6WoSNSErKPx+IdgnmpeTc2NWs1e++EI=; b=jfGy+hIg8RmGTrKfwNAll4CVWcYJkBPVl4oanSvvtPcbe1rq0rEMpD6xpJil4vQfdC RALJVYR2SWkLYMKCKGwRpED/WQSgD/U9/1YvEZF/UmjEOdpVl+RvldETzpvOuSEocjBS M1yZ3ns7MKTNyL8PYBL3y326HqqpXAU6fTkCE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=CU+iWN+iHLxMIP9vTsWmVAK8DmiHpLMEGBJpgTlJMC1OEP3ThRnsqLVKeRBY4uHoIP Fk0J3kyP5pQVCPBdcgNy47wAtyIbavY4hDQnya4z7bXeBrClUmWH8UAd0CpJnlrG73nb Ipca0oGvHDJGa7ZhXTKU7p6CmYcpfoQxuYvTk=
Received: by 10.220.127.87 with SMTP id f23mr5990704vcs.276.1276803393539; Thu, 17 Jun 2010 12:36:33 -0700 (PDT)
Received: from [10.30.20.3] (pool-70-104-194-43.nrflva.fios.verizon.net [70.104.194.43]) by mx.google.com with ESMTPS id e1sm9124933vch.41.2010.06.17.12.36.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jun 2010 12:36:33 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1081)
From: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <alpine.LFD.2.00.1006171733420.3324@localhost>
Date: Thu, 17 Jun 2010 15:36:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <03BF00C1-04E4-4A99-8407-88589E7129DD@gmail.com>
References: <4ae2.4cf4a9de.394b511b@aol.com> <alpine.LFD.2.00.1006171559550.3324@localhost> <3A8DE063-AD35-4354-89B8-7FB95A1E4E19@tony.li> <alpine.LFD.2.00.1006171733420.3324@localhost>
To: IRTF Routing RG <rrg@irtf.org>
X-Mailer: Apple Mail (2.1081)
Subject: Re: [rrg] Issue #2 from Paul Jakma
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2010 19:36:33 -0000

On 17  Jun 2010, at 15:03 , Paul Jakma wrote:
> On Thu, 17 Jun 2010, Tony Li wrote:
> 
>> In order for ILNP to be backward compatible and interoperable with legacy IPv6 hosts, it must use the exact same namespace.
> 
> The exact same, or a subset? Anyway..
> 
> I'm curious how backward compatibility is to work for applications accepting connections on ILNP-capable hosts. In particular, how to know whether to calculate the ULP checksum over the full L+I or just the ILNP style I?

This is described in detail in draft-rja-ilnp-intro.

> Looking further at the docs, it seems this relies on the Nonce Option having stateful semantics to indicate "this remote IP knows ILNP". How will this scale exactly? E.g. imagine servers communicating with large numbers of clients.

Scaling should be just fine.

Existing TCP/IPv4 implementations for web servers already keep 
a significant amount of session state for each TCP session.
This is known to scale adequately for very large numbers of
TCP sessions in several major operating systems (for example,
in Solaris and FreeBSD).

The additional ILNP session state required is relatively
small, and scales per-correspondent-node, rather than
per-TCP-session.

A typical web browser opens N parallel TCP sessions to the same 
server node.  So the ILNP session state should actually scale 
a bit better than TCP session state.

Yours,

Ran