RE: issue 11 -- window size

Hi Tero,

> 
> There is also one other option, i.e. the way my original 
> protocol proposal did it, i.e. every IKE packet can be used 
> to test the paths.
> If you add also so that every IKE packet also includes the 
> information needed to do mobility that solves the problem 
> with window size 1.
> 
> I.e. if mobike needs n payload for its processing, you add 
> those n payloads to all IKE packets, and then when you are 
> retransmitting the IKE packet you simply also use that packet 
> to do path finding, i.e.
> change the source and destination addresses but keep the packet same.
> The responder will reply to reversed addresses, and after 
> that IKE exchange both ends know that the path has changed, 
> and can take appropriate actions (either automatically or 
> manually by sending another exchange).

So, if you have two peers

PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the initial
connection.

Given the following sequence of events
- Window Size = 1

A1 --> B1 (CREATE_CHILD_SA request)
Interface A1 goes down
A1 x-- B1 (CREATE_CHILD_SA response)

How would PeerA inform PeerB to start using A2?  It is unable to send any
IKE pkts at all without exceeding the window size.  Or are you relying on
PeerB to retransmit the response to A1 a few times, and then automatically
switch to A2?

Stephane.

> 
> That protocol will work with window size of 1, and it does 
> not need any packets that are outside of the normal window 
> processing. If we still do manual actions, then we actually 
> do not need any special payloads in the IKE packets.
> --
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>