RE: issue 11 -- window size
"Stephane Beaulieu" <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
Thanks for the clarification. Given this, then I'm wondering how the connectivity check would work when we're trying to determine which pair of interfaces to switch to. Presumably it goes like this... Say PeerA, and PeerB, both with a window size = 2. PeerA (A1, A2) <--> PeerB (B1, B2, B3) A1 <--> B1 stops working (more precisely, some network devices near A1 stops working) 1 - PeerA sends a DPD (thus occupying 1 window slot) 2 - PeerA retransmits DPD a few times. 3 - PeerA sends a connectivity check A1->B2 (thus occupying a 2nd window slot) 4 - PeerA wants to send a connectivity check A1->B3, but has no window room left. Question: Would the connectivity check just be a replay of the DPD in 1? (thus re-using the window slot?) or would it occupy a new window slot? Stephane. > -----Original Message----- > From: Bill Sommerfeld [mailto:[email protected]] > Sent: Wednesday, March 30, 2005 4:45 PM > To: [email protected] > Cc: 'Geoffrey Huang'; 'Jari Arkko'; [email protected] > Subject: RE: [Mobike] issue 11 -- window size > > On Wed, 2005-03-30 at 16:37, Stephane Beaulieu wrote: > > This is only the case though if you assume that a mobility request > > should have a higher priority than a 'normal' request. That normal > > request, if deadlocked due to mobility change, I would think would > > eventually time out, thus clearing up the window for the > mobility request to get through. > > it appears that IKEv2 doesn't work that way. quoting from > draft-ietf-ipsec-ikev2-17.txt: > > 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. > > in other words, if you don't hear back from the peer at all, > you can tear down the IKE association but you can't abandon a > request in progress and keep going forward through the sequence space. > > - Bill >