Hi Yoav, Do you think this behavior contradicts with definition of windowing mentioned in draft that if responder window is 3, initiator can have 3 outstanding request ?
Regards, Raj On Wed, Jul 22, 2009 at 1:09 PM, Yoav Nir <y...@checkpoint.com> wrote: > Hi Raj. > > > > Too many variables, let’s assume values without loss of generality. > > > > Suppose N=3, and you have send requests 17, 18 and 19. Because of the > network problems, you got responses for 18 and 19, but not **yet** for > 17. > > > > What the draft (and RFC 4306) says, is that you keep retransmitting 17, > until you get a response. Before that, you can’t begin transmitting #20. If > your retransmissions of #17 time out (after “at least a dozen > retransmissions over at least 2 minutes”) then you assume that the peer has > died, and silently discard the IKE SA. This will usually not happen in the > above scenario, because once the network is back, the responder will also > reply to #17. > > > > Hope this helps > > > ------------------------------ > > *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf > Of *Raj Singh > *Sent:* Wednesday, July 22, 2009 8:52 AM > *To:* ipsec@ietf.org > *Subject:* [IPsec] [IKEv2] Questions on windowing in IKEv2 > > > > Hi Group, > > According to IKEv2bis-04, section 2.3 > > ----------------------------------------- > > An IKE endpoint MUST NOT exceed the peer's stated window size for > > transmitted IKE requests. In other words, if the responder stated > > its window size is N, then when the initiator needs to make a request > > X, it MUST wait until it has received responses to all requests up > > through request X-N. An IKE endpoint MUST keep a copy of (or be able > > to regenerate exactly) each request it has sent until it receives the > > corresponding response. An IKE endpoint MUST keep a copy of (or be > > able to regenerate exactly) the number of previous responses equal to > > its declared window size in case its response was lost and the > > initiator requests its retransmission by retransmitting the request. > > > ---------------------------- > > Now, suppose responder window size is N. > > Initiator send a request (X-N) but Initiator does get > > response for request no (X-N) say due to n/w flapping. > > So initiator schedules this request for re-transmissions > > but between the time intervals of re-transmission n/w comes UP > > and request no. (X-N+1) to (X) goes fine i.e. these request get response. > > Now, initiator wants to make another request i.e. request no. > > (X+1). But according to draft it can't make that request as it has > > not received the response for request no (X-N) even though there is > > only one outstanding request in transit. > > > Also draft says: > > --------------------------- > The SET_WINDOW_SIZE notification asserts that the sending endpoint is > > capable of keeping state for multiple outstanding exchanges, > > permitting the recipient to send multiple requests before getting a > > response to the first. > ------------------------ > > > That means windowing is for outstanding request. > > So in above mentioned scenario even though there is only 1 > > outstanding request and window size is N but we are not able to send > > next request because of windowing definition. > > > Maybe i am missing something here. > > Please elaborate the on the behavior in above scenario. > > > > Regards, > > Raj > > > > Scanned by Check Point Total Security Gateway. > > > Email secured by Check Point > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
