Re: [tcpm] RFC 5925 SNE algorithm concern

[Joseph Touch <[e-mail]>]

PS - 

#define distance(x,y)   (((x)<(y))?((y)-(x)):((x)-(y)))

The idea is that if we treat the two values as if they’re in the same SNE, would they be valid (i.e., jump less than half). If so, they’re in the same SNE. If not, then they must be in different SNEs (and then their distance would be less than half).

Joe

> On May 6, 2020, at 12:07 PM, Joseph Touch <[e-mail]> wrote:
> 
> 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
>   }
> }
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm