RE: issue 11 -- window size

Right, but we write the code for the implementation don't we? :)

So, a mobike capable IKEv2 implementation *could* exceed the peer's window
ONLY for mobike msgs, and choose NOT to view a lack of response as a failure
on these messages.  

The way I see it, mobike is kind of a special case, since when an interface
change happens, we'll never know for sure if the peer did respond to a
previous message, but we didn't get it, or if the previous request is still
sitting on the peer's queue.  We do know that we can't retransmit our
request (since we haven't picked a new interface yet).

Stephane. 

> -----Original Message-----
> From: Geoffrey Huang [mailto:[email protected]] 
> Sent: Thursday, March 31, 2005 1:25 PM
> To: [email protected]; 'Paul Hoffman'; 'Bill Sommerfeld'; 
> 'Jari Arkko'
> Cc: [email protected]
> Subject: RE: [Mobike] issue 11 -- window size
> 
> Yes, I suppose you could just keep retransmitting your 
> messages.  However, I would assume that most implementations 
> would view a failure to respond as a sign that the peer might 
> be dead.  Either the implementation would just delete the SA 
> or (window permitting), kick off DPD.  Since the window size 
> is already reached (and breached), you won't be getting any 
> response from the peer for the DPD messages.  Essentially, 
> this would still result in the deletion of the IKE SA.
> 
> -g
> 
> > -----Original Message-----
> > From: Stephane Beaulieu [mailto:[email protected]]
> > Sent: Thursday, March 31, 2005 9:49 AM
> > To: 'Paul Hoffman'; 'Geoffrey Huang'; 'Bill Sommerfeld'; 
> 'Jari Arkko'
> > Cc: [email protected]
> > Subject: RE: [Mobike] issue 11 -- window size
> > 
> > Is there really a point of reserving.  I mean, what's the 
> peer going 
> > to do if you exceed the window? (other than complain you're 
> violating 
> > the RFC :).
> > The peer will silently drop it until it's finished with 
> another one, 
> > right.
> > So what !  I can just keep transmitting my mobike 
> message(s) until the 
> > peer has a chance to process it and respond, right?
> > 
> > Stephane.
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]] On Behalf Of Paul Hoffman
> > > Sent: Thursday, March 31, 2005 10:44 AM
> > > To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko'
> > > Cc: [email protected]
> > > Subject: RE: [Mobike] issue 11 -- window size
> > > 
> > > At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote:
> > > >So it needs to
> > > >split this between "regular" IKE messages and MOBIKE messages?
> > > 
> > > Not "split", but "allow enough extra for MOBIKE".
> > > 
> > > >I prefer your earlier suggestion of reserving one or two
> > message IDs
> > > >from the window for mobility purposes.  Consider a roaming
> > > client that
> > > >gets a notify from a security gateway (SGW) saying the
> > SGW's window
> > > >size is 5.  The client should know that it's capable of
> > mobility and
> > > >consequently reserve a message ID for MOBIKE messages.  Just
> > > because a
> > > >peer sends a notification about a window size doesn't 
> mean that an 
> > > >implementation needs to fill up the window.
> > > 
> > > That sounds good. The question is: how many should we suggest to 
> > > reserve?
> > > 
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > > _______________________________________________
> > > Mobike mailing list
> > > [email protected]
> > > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > > 
> > 
>