Subject: Re: [Capwap] Issue 215: Sequence number questions

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 10 Oct 2008 08:01:01 -0700

The following exchange occurred after the text below was agreed upon:

> It is also possible to become out of sync with this if the sender of 
> requests do what is not recommend and aborts transmission
> 16 times. Then the sender and receiver will have there sequence number

> windows out of sync. I don't think there is a significant issue here. 
> But a warning about this might with the SHOULD NOT abort sentence may 
> provide good motivation.

OK, I would propose adding the last sentence at the end of the paragraph
below, which I believe is sufficient with the SHOULD NOT statement:

<new sentence>
4.5.3.  Retransmissions
[...]
   If the sender stops retransmitting a Request message before reaching
   MaxRetransmit retransmissions (which leads to transition to DTLS
   Teardown, as described in Section 2.3.1), it cannot know whether the
   recipient received and processed the Request or not.  In most
   situations, the sender SHOULD NOT do this, and instead continue
   retransmitting until a Response message is received, or transition to
   DTLS Teardown occurs.  However, if the sender does decide to continue
   the connection with a new or modified Request message, the new
   message MUST have a new Sequence Number, and be treated as a new
   Request message by the receiver.  Note that there is a high chance
   that both the WTP and the AC's sequence numbers will become out of
   sync.
</new sentence>
 
PatC
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Thursday, September 25, 2008 9:29 AM
To: [email-masked]
Subject: [Capwap] Issue 215: Sequence number questions

All,

The following comment was raised during the IESG Review:

> > Section 4.5.3:
> > 
> >    If an older Request message (with smaller
> >    Sequence Number modulo 32) is received, it MUST be ignored.
> >   
> >    Smaller is not super obvious here. I would interpret it as
> > (Last_nr-15)%32 to (Last_nr-1)%32. Saying something like that might 
> > be clearer on which sequence numbers that are okay.
> 

Got it. How about the following:

<modified text>
   Implementations MUST keep track of the Sequence Number of the last
   received Request message, and MUST cache the corresponding Response
   message.  If a retransmission with the same Sequence Number is
   received, the cached Response message MUST be retransmitted without
   re-processing the Request.  If an older Request message is received,
   meaning one where the sequence number is smaller, it MUST be ignored.
   A newer Request message, meaning one whose sequence number is larger,
   is processed as usual.

   Note: A sequence number is considered "smaller" when s1 is smaller
   than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or (s1>s2
   and (s1-s2)>128)
</modified text>

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap