RE: issue 11 -- window size

That's a good point.

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.  Of
course, that would cause loss of connectivity for the length of the time
out, but then again, maybe that's the price you pay for having a small
window.

Perhaps the answer is that you don't timeout.  Retransmit forever.  But then
the question becomes what do you do when a peer doesn't respond to a
request.  What do you do if the window is full.  Can't send a DEL, or a DPD.
Are you supposed to just retransmit forever, or silently drop the
connection?

Stephane.

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email protected]] 
> Sent: Wednesday, March 30, 2005 4:08 PM
> To: Geoffrey Huang
> Cc: [email protected]; 'Jari Arkko'; [email protected]
> Subject: RE: [Mobike] issue 11 -- window size
> 
> On Wed, 2005-03-30 at 15:46, Geoffrey Huang wrote:
> > I agree.  I think it's reasonable to expect a window size > 1.
> 
> the issue is a bit more subtle than that: if mobike mobility 
> requests (of whatever form) occupy ike request sequence 
> space, then in order to avoid deadlocking during a move while 
> there are other outstanding requests, mobike implementations 
> will need to reserve at least the "last" request window slot 
> for those requests at all times, effectively reducing the 
> window at all other times by at least one request.
> 
> 
>