Re: Stephane Beaulieu's comments ondraft-mobike-protocol-04.txt

Inline [SB]

> -----Original Message-----
> From: Tero Kivinen [mailto:[email protected]] 
> Sent: Tuesday, October 18, 2005 4:20 AM
> To: Stephane Beaulieu (stephane)
> Cc: [email protected]
> Subject: [Mobike] Stephane Beaulieu's comments 
> ondraft-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. 

[SB] Thanks.  Went back and re-read the notes on issue #5, and I see the
reasoning behind it.


> 
> > 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). 

[SB] OK.  Some text to that effect would be helpful.


> 
> > - 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.

[SB] OK.  This is fine with me.

> 
> 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.

[SB] Ah.  That makes sense.  Perhaps the reasoning here should be
documented as well.

> --
> [email protected]
>