Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 15 June 2012 12:03 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07E21F85DD for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 05:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.655
X-Spam-Level:
X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gci-GEh9vbMX for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 05:03:26 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id C9F3421F85D8 for <ietf@ietf.org>; Fri, 15 Jun 2012 05:03:21 -0700 (PDT)
Received: (qmail 81772 invoked from network); 15 Jun 2012 12:07:34 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 15 Jun 2012 12:07:34 -0000
Message-ID: <4FDB2436.2060805@necom830.hpcl.titech.ac.jp>
Date: Fri, 15 Jun 2012 21:01:58 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
References: <20120531143816.30508.66250.idtracker@ietfa.amsl.com> <Pine.LNX.4.64.1205311957420.31608@shell4.bayarea.net> <4FC9585E.6010205@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.64.1206022127550.17026@shell4.bayarea.net> <4FCBB71E.9080209@necom830.hpcl.titech.ac.jp> <4FCEAA6B.20204@isi.edu>
In-Reply-To: <4FCEAA6B.20204@isi.edu>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2012 12:03:27 -0000

Joe Touch wrote:

> Hi,

Hi,

>> But, then,
>>
>>      >>   Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
>>      values within one MSL for a given source address/destination
>>      address/protocol triple.
>>
>> makes most, if not all, IPv4 hosts non compliant if MSL=2min.
> 
> This is already noted throughout this document, however there is little
> impact to such non-compliance if datagrams don't persist that long.

So, the question to be asked is how long datagrams persist.

As you now say MSL may be smaller than 2min, the draft is
useless to promote implementers implement rate limiting.

If you can't define hard value of MSL, implementors can
assume anything.

>> Worse, without hard value of MSL, it is a meaningless
>> requirement. Note that MSL=2min derived from RFC793 breaks
>> 150Mbps TCP.
> 
> It breaks at 6.4 Mbps for 1500 byte packets, as is already noted in the doc.

With practically very low probability.

>> The proper solution, IMHO, to the ID uniqueness is to request
>> a destination host drop fragments from a source host after
>> it receives tens (or hundreds) of packets with different IDs
>> from the same source host.
> 
> That doesn't help ID uniqueness; it helps avoid fragmentation
> overload.

It does help ID uniqueness, because fragments with accidental
matches are quickly discarded.

> FWIW, such issues were discussed at length in the INTAREA WG when this
> doc was developed.

I appreciate that the draft is terse not including so lengthy
discussions in the WG.

However, at the same time, don't expect me to read all the log
of the discussions in the WG, especially because you and
the discussions misunderstand the problem as:

> That doesn't help ID uniqueness; it helps avoid fragmentation
> overload.

That does help ID uniqueness.

						Masataka Ohta