Re: [tcpm] Francesca Palombini's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

David Borman <dab@weston.borman.com> Fri, 07 January 2022 16:44 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 9D7653A0BFE; Fri, 7 Jan 2022 08:44: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 KfhhpiK7T__2; Fri, 7 Jan 2022 08:44:53 -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 209AE3A0BFB; Fri, 7 Jan 2022 08:44:52 -0800 (PST)
Received: from local-25.weston.borman.com (local-25.weston.borman.com [192.168.1.25]) (authenticated bits=0) by frantic.weston.BORMAN.COM (8.14.7/8.14.7) with ESMTP id 207Gtw5W027786 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Jan 2022 10:55:59 -0600
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: David Borman <dab@weston.borman.com>
In-Reply-To: <5a6dbb3f-22ba-2953-430b-3b4fac567181@mti-systems.com>
Date: Fri, 07 Jan 2022 10:44:45 -0600
Cc: Francesca Palombini <francesca.palombini@ericsson.com>, The IESG <iesg@ietf.org>, draft-ietf-tcpm-rfc793bis@ietf.org, tcpm@ietf.org, tcpm-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <637C526C-D418-4652-A2A3-5DEE59096BF8@weston.borman.com>
References: <163234555786.20689.7200051930871118197@ietfa.amsl.com> <5a6dbb3f-22ba-2953-430b-3b4fac567181@mti-systems.com>
To: "Wesley M. Eddy" <wes@mti-systems.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/JR7A5RIpX4_hrlRUhxheEYn2yjw>
Subject: Re: [tcpm] Francesca Palombini's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)
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, 07 Jan 2022 16:44:58 -0000


> On Jan 6, 2022, at 10:26 PM, Wesley Eddy <wes@mti-systems.com> wrote:
> 
> Sorry for the very slow response, but I think all questions are answered below.  Thanks for your comments and patience.
> 
> 
> On 9/22/2021 5:19 PM, Francesca Palombini via Datatracker wrote:
>> Francesca Palombini has entered the following ballot position for
>> draft-ietf-tcpm-rfc793bis-25: No Objection
...
> 
>> 
>> 4. -----
>> 
>> FP: This is surely me missing something but, in section 3.5 I see:
>> 
>>    4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED
>> 
>>    5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
>> 
>> which is followed by:
>> 
>>    Note that the sequence number of the segment in line 5 is the same as
>>    in line 4 because the ACK does not occupy sequence number space (if
>>    it did, we would wind up ACKing ACKs!).
>> 
>> However, later on, in Figure 13:
>> 
>>    2.  (Close)                                              (Close)
>>        FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  ... FIN-WAIT-1
>>                    <-- <SEQ=300><ACK=100><CTL=FIN,ACK>  <--
>>                    ... <SEQ=100><ACK=300><CTL=FIN,ACK>  -->
>> 
>>    3.  CLOSING     --> <SEQ=101><ACK=301><CTL=ACK>      ... CLOSING
>>                    <-- <SEQ=301><ACK=101><CTL=ACK>      <--
>>                    ... <SEQ=101><ACK=301><CTL=ACK>      -->
>> 
>> I am confused why in this case, in line 3, ACK does in fact occupy sequence
>> number space. What am I missing?
> 
> In line 3 if the sequence number was 100, that would be a retransmission of the FIN, rather than just an ACK that covers the other side's FIN (300).  There's no data in the segment, so the sequence number is just meaningful for validation.

To be clear, it is the FIN that occupies one byte in the sequence space, not the ACK.  In line 3, each side is ACKing the other side's FIN; they do not include the FIN bit so the sequence number is advanced beyond the FIN.

			-David Borman