Re: [tcpm] RFC 5925 SNE algorithm concern

Joseph Touch <touch@strayalpha.com> Wed, 06 May 2020 19:07 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 40AC23A0AA4 for <tcpm@ietfa.amsl.com>; Wed, 6 May 2020 12:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 4xnXjFM8OWXg for <tcpm@ietfa.amsl.com>; Wed, 6 May 2020 12:07:34 -0700 (PDT)
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 862193A0AA3 for <tcpm@ietf.org>; Wed, 6 May 2020 12:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=References:To:In-Reply-To:Subject:Date: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To:Cc: 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=cY4qeg2TF15SGpmK4rn/MvTuJkXTwT/AEHcEaFZjPpM=; b=ns84a+DKuNOPVw7gD9pAGJubv 7cHh5SLVFXfYHhRKqav9smJdQpIr7cMJGi1xfXMpYjMX4NeQXfhCytz+xOz35fuWh59yqqQ0jedtn lHvCoJceu9AZWhkQ9WKIYGMVwOjIWbZMkvN3XOp16QDNRZAyeQWPowgZXKrtu4tisShaylfxgcU6h ZShuQEZblSpYazrsdDOSUpqcTSqJoJ+ZyTITxSX4KX+kI5AghaSkRDz46yN7NLzUVZXY18T+EEEZ2 BKSxlqfrQcqhlC++2yz0uckhNB1oKGksn5xG77IqGwe8dwgQVA9XRlA/ICSaa0p3y5P7PWOZXoeDg WQpanTBuw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61267 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1jWPOA-000xcQ-BS; Wed, 06 May 2020 15:07:30 -0400
From: Joseph Touch <touch@strayalpha.com>
Message-Id: <26C2355F-AAF8-405B-BA38-8E7F50013D27@strayalpha.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F8BAE5A5-1401-4BC7-9935-3D86928C0329"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Wed, 06 May 2020 12:07:25 -0700
In-Reply-To: <CACS3ZpC3z-D8C=g90vuz-1n-w4oX8y2vOzJWrhouNqnKeuZ42w@mail.gmail.com>
To: tcpm IETF list <tcpm@ietf.org>
References: <CACS3ZpBLAO2=O6Vf2Vx766qAGqmY2yD_yiLag-K7C3sYFjH9hw@mail.gmail.com> <EAE578C4-4C60-429A-9826-821B3075DA08@strayalpha.com> <CACS3ZpCjWb2+-v8MCjRJvMCARZ1YDLAr5HyRUTSTteMefu76qQ@mail.gmail.com> <CACS3ZpC3z-D8C=g90vuz-1n-w4oX8y2vOzJWrhouNqnKeuZ42w@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
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/1mjqymNcvMoqMnmOqwEmhpzkO-k>
Subject: Re: [tcpm] RFC 5925 SNE algorithm concern
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: Wed, 06 May 2020 19:07:37 -0000

Hi, all,

Juhamatti pointed out a flaw in the pseudocode for receive-side SNE computation in RFC 5925.

The good news (in a sense) is that the code was not normative; 

   The implementation of SNEs is not specified in this document, but one
   possible way is described here that can be used for either RCV.SNE,
   SND.SNE, or both.

The corrections that Juhamatti posted don’t address the key issue, which is that there are several possible interpretations of any received SEQ. There is no simple way to fix this except to handle all the cases (which the code below does - I believe minimally):

	- it is in-order
		- moving the receive window forward
		- incrementing the SNE if it wraps the number space
	- it is out-of-order
		- which might use either the current SNE or SNE-1, depending on whether it is pre-wrap of the number space

Because the number space wraps, all received SEQ could be interpreted as in-order or out-of-order; the only way to know the difference is the distance between the two — which cannot be larger than 0x7FFF FFFF (half the number space minus 1).

The following is code that covers the cases and passes all current tests. Given this is not as obvious as it might seem and might be more useful than for just RFC 5925 and the SNE alg in 5925 is “not specified” anyway, I propose to submit this as a stand-alone doc.

So here are the ways forward:

	1) have that doc “UPDATE” RFC 5925
		this is the cleanest because it would more definitely be caught by implementers
		but it requires the new alg be standards-track, which seems odd (though we could say what SNE is as a standard
		and still leave its implementation as informative rather than normative)

	2) publish that doc as informational
		then we could issue an errata on 5925 to point to the new RFC

	3) issue the new alg as an errata to 5925 only

Any thoughts?

Joe

——

PS - here’s the alg:


#DEFINE HALF (0x80000000)

SNE = RCV_SNE;                               // use current SNE (as default)
if (distance(SEG_SEQ,RCV_PREV_SEQ) < HALF) { // both in same SNE range?
  if ((SEG_SEQ >= HALF) 
      && (RCV_PREV_SEQ < HALF)) {            // jumps fwd over N/2?
    RCV_SNE_FLAG = 0;                        // reset wrap increment flag
  }
  RCV_PREV_SEQ = MAX(SEG_SEQ,RCV_PREV_SEQ);  // move prev forward if needed
} else {                                     // both in diff SNE ranges
  if (SEG_SEQ < HALF) {                      // jumps forward over zero?
    RCV_PREV_SEQ = SEG_SEQ;                  // update prev
    if (RCV_SNE_FLAG == 0) {.                // first jump over zero? (wrap)
      RCV_SNE_FLAG = 1;                      // set flag so we increment once
      RCV_SNE = RCV_SNE + 1;                 // increment window
      SNE = RCV_SNE;                         // use updated SNE value
    }
  } else {                                   // jump backward over zero
    SNE = RCV_SNE - 1;                       // use pre-rollover SNE value
  }
}