Stephane Beaulieu's comments on draft-mobike-protocol-04.txt

Stephane Beaulieu (stephane) writes:
> 
> Section 3.
> "MOBIKE allows both parties to have several addresses, and there are
>    up to N*M pairs of IP addresses that could potentially be used."
> 
> - Do we not also allow a party to temporarily have 0 addresses?  While I
> walk from the office to Starbucks across the street, I may loose all
> wireless for a few minutes.

No we do not allow zero addresses. See issue 5 in the issue list. Also
the current protocol implictly always have the IP-address in headers
in the address set, so there is no way to express that in the
protocol. 

> Section 3.2 (2nd example)
> "(The initiator gives up on the current address pair, and tests the
>    other available address pair.)"
> 
> - Can the initiator test multiple address pairs simultaneously?
> (assuming he has the window space to do so).

As he is using the single message to test all addresse pairs he would
not need window to test multiple address pairs, but on the other hand
in the issue 14 we decided that we want to test them sequentially and
using exponential back-off procedure (to make sure we do not make the
congestion worse). 

> - If not, how many retries and how many seconds between each retry on a
> single address pair before we move on to the next?  Are there
> recommendations for this, or is this purely implementation detail?

Implementation datails. My guess is that as the most of those IKE
packets are very fast to respond to, we should mostly count only the
round trip time (unless the message we are trying to send has some
expensive calculations like Diffie-Helmman). I.e. the first
retransmission can happen after 2 * RTT, and next for example 1.4 *
from that, and after 2-3 tries with one IP pair you can move to the
next one, keeping the retries to use same exponential timer up to
certain max limit.

So if you have IPa1 and IPa2 in your end and IPb1 and IPb2 for the
other end, you end up following retransmissions:

Time		Cumulative Time	   Src-IP	Dst-IP
from prev	from start
---------	----------	   ------	------
0.000		0.000		   IPa1		IPb1
0.400   	0.400		   IPa1		IPb1
0.560   	0.960		   IPa1		IPb1
0.784   	1.744		   IPa1		IPb2
1.098   	2.842		   IPa1		IPb2
1.537   	4.378		   IPa1		IPb2
2.151   	6.530		   IPa2		IPb2
3.012   	9.541		   IPa2		IPb2
4.217   	13.758		   IPa2		IPb2
5.903   	19.661		   IPa2		IPb1
8.264   	27.925		   IPa2		IPb1
11.570  	39.496		   IPa2		IPb1

After that it has tried all addresses, and none of them work, so he
might want to start testing them rapidly, to see if one of them is
going to get fixed during the rest of time (and stop slowing the
retransmission after 30 seconds):

16.198          55.694		   IPa1		IPb1
22.678          78.371		   IPa1		IPb2
30.000          108.371		   IPa2		IPb2
30.000          138.371		   IPa2		IPb1
30.000          168.371		   IPa1		IPb1
30.000          198.371		   IPa1		IPb2
30.000          228.371		   IPa2		IPb2

And finally give up after 4 minutes of trying.

The exact value of exponent, the initial retransmission timer, number
of tries per IP and the max limit for the timer etc are all of course
implementation and scenario dependent.

For example in the GRPS network you might want to use initial timer of
2 seconds, use exponent of 2, try each IP-address only twice, and have
a max limit of 10 seconds.

> Section 4.2
> 
> I don't understand why we need to switch to port 4500 even if there is
> no NAT in the path.  Can someone explain this to me?  Or better yet,
> explain it in the draft?

I raised this question also earlier, and the answer was: In case we
later move to the path that has a NAT box between, and we need to
enable NAT-T, then we must be on the port 4500 before we enable NAT-T.
To avoid hassle to do the changing of the port at that time, we do it
in the beginning. It does not hurt at all to move to port 4500
immediately, if both ends support NAT-T, and it will make enabling
NAT-T very simple when we later in the UPDATE_SA_ADDRESSES notice
there is NAT between us.
-- 
[email protected]