Window size limits the amount of responses that the responder has to remember.
After receiving requests 17, 18 and 19, the responder needs to remember those
three responses, because if it gets a retransmission, it should reply with the
old response.
When request #20 arrives, it is safe to disca
Hi Yoav,
Any benefits of this behaviour over allowing 'window-size' outstanding
requests at any given time.
Thanks,
-Amjad
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Yoav Nir
Sent: Wednesday, July 22, 2009 2:34 PM
To: 'Raj Singh'
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 wrote:
> Hi Raj.
>
>
>
> Too many variables, let’s assume values wit
No. All the draft says, is that to send 20, you need to have received answers
to everything up to and including 17. You don't get to always have three
outstanding requests.
From: Raj Singh [mailto:rsjen...@gmail.com]
Sent: Wednesday, July 22, 2009 11:57 AM
To: Yo
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, unti
Hi,
Could someone please clarify if the below interpretation of IKEv2 window
size is correct.
IKEv2 window size of N implies that there can be N un-acknowledged
requests at any given time - without any relation to the message-ids of
the requests in transit.
For example, consider an IKEv2 pee
