Re: [tcpm] 793bis: IP ID
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 19 December 2019 17:32 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 ACB531202DD for <tcpm@ietfa.amsl.com>; Thu, 19 Dec 2019 09:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 QeQFmmGN_yuB for <tcpm@ietfa.amsl.com>; Thu, 19 Dec 2019 09:32:55 -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 7013C120072 for <tcpm@ietf.org>; Thu, 19 Dec 2019 09:32:55 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 457B31B000A6; Thu, 19 Dec 2019 17:32:51 +0000 (GMT)
Message-ID: <5DFBB442.60001@erg.abdn.ac.uk>
Date: Thu, 19 Dec 2019 17:32:50 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Borman <dab@weston.borman.com>
CC: "Wesley M. Eddy" <wes@mti-systems.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>
In-Reply-To: <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/URIex4ehGAFoioFX55ykwsgvp_0>
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, 19 Dec 2019 17:32:58 -0000
I get this - but if we keep this, I think it should expliclity say *all headers have not changed*. I still think this is a terrible hack to say the transport touches something in the network layer - because I have no idea how this sits with using TSOpt to disam=biguate retransmissions and extension headers, should they be used. Anyway, this is so very IPv4 centric, I think if we keep this, we should call IPv4 out explicitly. Gorry On 19/12/2019, 17:21, David Borman 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] 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 Joe Touch
- 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 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