Re: [tcpm] 793bis: IP ID

Joe Touch <touch@strayalpha.com> Fri, 20 December 2019 02:44 UTC

Return-Path: <touch@strayalpha.com>
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 161251207FD for <tcpm@ietfa.amsl.com>; Thu, 19 Dec 2019 18:44:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level:
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 f1OteCFPdF1T for <tcpm@ietfa.amsl.com>; Thu, 19 Dec 2019 18:44:40 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E40A1200EC for <tcpm@ietf.org>; Thu, 19 Dec 2019 18:44:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TSe3x/DQXSu0A+wJFW8na1MKYPfqN7PVASHvaFwTT8Q=; b=3h3ni3PhYVSxtFdJ+F2XJGbul DZRJQGKKo6n3S+f2YO5YuHmRSuiujBDost46kJLWHEp4bC3xMjSHKq6eFD7K0wH+1Lw3LWUlQ00uH 5D3dwZNEwgvCtFbFUY9R+PQs/wEkX9FWAREcB07H2z7WqaYpsQQjM+x7PxEU5AzeSK9a/KtFn2h69 pifZxzN+b4vE9hMrqGwWs3DRioPpy5DvVk8pFfxM7qFuCt3x4qqbQGZeN7LYFlx5IoBuIoVfNmjco XXoFfZFZnfmT5cssjd48r5Y5WqOxv+GkRXKQKwDua8y0Y96ctMLPz5Z6ncgj645nSLfbwp0nBPyef Pf9tPgMxA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61497 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1ii8HI-00050F-Kz; Thu, 19 Dec 2019 21:44:39 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com>
Date: Thu, 19 Dec 2019 18:44:33 -0800
Cc: Wes Eddy <wes@mti-systems.com>, tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com>
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>
To: David Borman <dab@weston.borman.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/5R8cYUQmRCh5BExM57Bj0U1qaZs>
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: Fri, 20 Dec 2019 02:44:42 -0000

FWIW, the ID is now supposed to be ignored if fragmentation isn’t possible (not source fragmented and not fragmentable).

Perhaps this advice needs revision accordingly, esp. since TCP generally tries to run in that mode.

I.e., retransmission should have no bearing on the IPv4 ID unless fragmentation occurs or is possible.

Joe

> On Dec 19, 2019, at 9:21 AM, David Borman <dab@weston.borman.com> wrote:
> 
> This has to do with the fact that the IPID field is used to do fragmentation reassembly.  It is ok to reuse the same IPID when retransmitting, as long as the retransmitted packet is identical to the original packet, not just the TCP data, but also all the TCP headers.  If the two packets aren’t identical and they are fragmented, then using the same IPID could cause the receiver to not properly reassemble the packet.
> 
> What this also says is that, if a TCP implementation is such that it buffers up previously sent packets for possible retransmission and retransmits them verbatim, it doesn’t have to change the IPID just because it is a retransmission.  But if there are any differences between the original and the retransmitted packet, then the IPID must be updated.
> 
> 			-David Borman
> 
>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>> 
>> While I think Gorry's comment below is pretty much correct, this is direct from RFC 1122's material on TCP.  I'm proposing not to change anything about this at the moment, since I don't think any harm is done by saying this.
>> 
>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>>> Section 3.8.1
>>> OLD:
>>>   If a retransmitted packet is identical to the original packet (which
>>>   implies not only that the data boundaries have not changed, but also
>>>   that the window and acknowledgment fields of the header have not
>>>   changed), then the same IP Identification field MAY be used (see
>>>   Section 3.2.1.5 of RFC 1122) (MAY-4).
>>> - What is this MAY about? Is it about the IPv4 IPID field and is that really
>>> important for a TCP spec? 
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm