Re: [tcpm] 793bis: IP ID
Joe Touch <touch@strayalpha.com> Fri, 20 December 2019 22:23 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 9CBF21200EF for <tcpm@ietfa.amsl.com>; Fri, 20 Dec 2019 14:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 EBUamUsifw75 for <tcpm@ietfa.amsl.com>; Fri, 20 Dec 2019 14:23:08 -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 413741200C1 for <tcpm@ietf.org>; Fri, 20 Dec 2019 14:23:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding: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=TgwlEigsoKQ2qQQmWSP2iDSknK7xvc+Mt3eVJPrSYu0=; b=PkGAavWe9ind9NW4PEG1hcUUY TcPdtV0Xcp9pEDUtfDFzuTvI41BcejvT62Dlg9GD9es37F60T70fwBVT5T4cHmGU1kRwXivlLOMIw g0USYDnMDXmFBz5H2TLsHC5Wu+k2ZIIMaMUL0SweGrGqfxU46L0+JmXq3bKv87vhxmt+dhSr/FZOg Gm4470yF3cJoJ0LyQc/R7qMoP9ljZrLGCas4Fo7H7Hi2bKhhUARbMN4oTJGr90NAvnaphbMRzXwG+ 0r59Svyqzn91PEzrAr0a/FNmAy87IsM1QXP+nxJY9/m0I+y8RhTICDU3TBID5Ca85t7bpLhDCClHx GKQ6rkMWA==;
Received: from [::1] (port=47778 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1iiQfm-002vSK-TE; Fri, 20 Dec 2019 17:23:07 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_07286caa3f85c9bfc977882ef632da44"
Date: Fri, 20 Dec 2019 14:23:02 -0800
From: Joe Touch <touch@strayalpha.com>
To: David Borman <dab@weston.borman.com>
Cc: tcpm@ietf.org
In-Reply-To: <F9E41A50-83FA-477C-8E19-5CE6A58931D3@weston.borman.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> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <F9E41A50-83FA-477C-8E19-5CE6A58931D3@weston.borman.com>
Message-ID: <eba35b7842c9b020287293e20cab042f@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
X-OutGoing-Spam-Status: No, score=-1.0
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/jfiubTIDRwx2xbPv9GBd99NB8mc>
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 22:23:10 -0000
Hi, David, On 2019-12-20 12: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. Right - it doesn't matter. But that also means it can be reused *even if the packet contents change*. It should have no impact unless fragmentation occurs; if it's "atomic" (not source fragmented and DF=0), then it can be reused *at will* (and already widely is). > So just stating that the IPID must not be reused on retransmission unless the packet is identical to the original should be sufficient. That's overkill. The ID can be (and already is) reused if the packets are atomic (per above). > We want to avoid having an implementation reuse IPIDs and cause problems, and then say "but the RFC didn't say we couldn't do that". Implementations of TCP need to know that they should not be using IP IDs for uniqueness, as already indicated in RFC 6864. We should be clear in supporting that advice here. Joe > -David > > On Dec 19, 2019, at 8:44 PM, Joe Touch <touch@strayalpha.com> wrote: > > 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] review of rev 14 of RFC 793 bis part 1 of … Gorry Fairhurst
- [tcpm] review of rev 14 of RFC 793 bis part 2 of … Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Joe Touch
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Joe Touch
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 2… Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Wesley Eddy
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Gorry Fairhurst
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Rodney W. Grimes
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Wesley Eddy
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Jonathan Morton
- Re: [tcpm] review of rev 14 of RFC 793 bis part 1… Rodney W. Grimes
- [tcpm] 793bis: TCP Quiet Time Wesley Eddy
- Re: [tcpm] 793bis: TCP Quiet Time Yuchung Cheng
- Re: [tcpm] 793bis: TCP Quiet Time Neal Cardwell
- Re: [tcpm] 793bis: TCP Quiet Time Matt Mathis
- Re: [tcpm] 793bis: TCP Quiet Time Joe Touch
- [tcpm] 793bis: variable MTU Wesley Eddy
- [tcpm] 793bis: reset generation section Wesley Eddy
- [tcpm] 793bis: IPv6 jumbograms Wesley Eddy
- [tcpm] 793bis: IP ID Wesley Eddy
- Re: [tcpm] 793bis: IP ID David Borman
- Re: [tcpm] 793bis: variable MTU Gorry Fairhurst
- Re: [tcpm] 793bis: IP ID Gorry Fairhurst
- Re: [tcpm] 793bis: IP ID Michael Tuexen
- Re: [tcpm] 793bis: TCP Quiet Time Matt Mathis
- [tcpm] 793bis: dead gateway detection Wesley Eddy
- [tcpm] 793bis: delayed ACKs Wesley Eddy
- Re: [tcpm] 793bis: IP ID David Borman
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID David Borman
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: delayed ACKs Yuchung Cheng
- Re: [tcpm] 793bis: TCP Quiet Time Fernando Gont
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: TCP Quiet Time Joe Touch
- Re: [tcpm] 793bis: TCP Quiet Time Matt Mathis
- Re: [tcpm] 793bis: TCP Quiet Time Fernando Gont
- Re: [tcpm] 793bis: TCP Quiet Time Fernando Gont
- Re: [tcpm] 793bis: IP ID Gorry Fairhurst
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch
- Re: [tcpm] 793bis: IP ID Fernando Gont
- Re: [tcpm] 793bis: IP ID Joe Touch