Re: [tcpm] 793bis: IP ID

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 23 January 2020 13:24 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EF21200CE for <tcpm@ietfa.amsl.com>; Thu, 23 Jan 2020 05:24:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO6GG__iH6NQ for <tcpm@ietfa.amsl.com>; Thu, 23 Jan 2020 05:24:56 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A436120096 for <tcpm@ietf.org>; Thu, 23 Jan 2020 05:24:56 -0800 (PST)
Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:b938:ce19:7b9a:f008]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 741191B0007F; Thu, 23 Jan 2020 13:24:48 +0000 (GMT)
To: Fernando Gont <fgont@si6networks.com>, tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <f4d75224-d7d0-002b-2bca-f93505d6c9d3@mti-systems.com> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <F9E41A50-83FA-477C-8E19-5CE6A58931D3@weston.borman.com> <a7080caa-18ce-94ec-3bbf-ae5c8d1bc17c@si6networks.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk>
Date: Thu, 23 Jan 2020 13:24:47 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <a7080caa-18ce-94ec-3bbf-ae5c8d1bc17c@si6networks.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Pw1ukRerqYpfAYX6eFpiTb1p06k>
Subject: Re: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 13:24:58 -0000

I think this is the wrong ID to discuss anything related to IPv4 ID.

I suspect some deployed boxes do exist that do shortest-packet first 
link scheduling; re-use various codepoints; and boxes that in this case 
clear DF. That's sad, but real. In days gone by, people may have built 
implementations that relied on any of these. It doesn't mean a modern 
TCP Spec needs to discuss the IPv4 ID field.

I'd encourage the TCP Spec to say nothing about how IPv4 uses the ID field.

Gorry

On 22/01/2020 19:05, Fernando Gont wrote:
> Hi, Dave,
>
> On 20/12/19 17:37, David Borman wrote:
>> Yes, the IPID is only used for doing IP fragment reassembly, so the 
>> IPID really doesn’t matter on retransmission when IP fragmentation is 
>> not possible.
>
> Some boxes are know to clear DF and fragment packets. That's why some 
> implementations have resorted to ensure IP ID uniqueness (or try to), 
> even when they send packets with DF=1.
>
> Thanks,