Re: [tcpm] 793bis: IP ID

David Borman <dab@weston.borman.com> Thu, 19 December 2019 22:32 UTC

Return-Path: <dab@weston.borman.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 BFA951201DC for <tcpm@ietfa.amsl.com>; Thu, 19 Dec 2019 14:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 65WQjT1LBP8y for <tcpm@ietfa.amsl.com>; Thu, 19 Dec 2019 14:32:01 -0800 (PST)
Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (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 23B7F1200CC for <tcpm@ietf.org>; Thu, 19 Dec 2019 14:32:01 -0800 (PST)
Received: from davidbormansmbp.americas.cray.com (msp-nat.cray.com [136.162.2.1]) (authenticated bits=0) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id xBJMam2W031830 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2019 16:36:48 -0600
From: David Borman <dab@weston.borman.com>
Message-Id: <059F5B35-54F0-4019-A3C3-203A0D735766@weston.borman.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E26A449-B878-489E-8E3A-6555E3BEE2AF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 19 Dec 2019 16:31:28 -0600
In-Reply-To: <0A3E9FC0-27F2-4BB4-9F43-F3940E5CFC8E@lurchi.franken.de>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tcpm@ietf.org
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
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> <5DFBB442.60001@erg.abdn.ac.uk> <0A3E9FC0-27F2-4BB4-9F43-F3940E5CFC8E@lurchi.franken.de>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/8BW6lHoft_rPI0LEtpseDl3Ucv8>
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 22:32:04 -0000

Yes, the reality is that I don’t think any full featured TCP implementation today would want/be able to take advantage of this.  Some things were much simpler when RFC 1122 was published, a lot has changed since then.  But with IoT and very small and tiny TCP implementations, there may be some places where this makes sense.

I do agree with Gorry, rather than calling out a few example fields that also must not have changed, keep it simple:

If a retransmitted packet is identical to the original packet (which implies not only that the data boundaries have not changed, but also the headers have not changed),

		-David

> On Dec 19, 2019, at 11:47 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> 
>> On 19. Dec 2019, at 18:32, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>> 
>> I get this - but if we keep this, I think it should expliclity say *all headers have not changed*.
> The TCP timestamp option comes up to my mind. For TCP retransmission, the TSVal would be different.
> 
> Best regards
> Michael
>> 
>> 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 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
>