-------------------- Stephane Beaulieu (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001127.html 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. ++++++++++++++++++++++++++ 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). - 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? Section 3.3 IMO, there should be text in this section that explains that Mobike tries to detect sporadic NAT mapping changes by adding NATD payloads in the DPD msgs. I know this is explained later, but I would expect to hear something about this in this section, since this is the "NAT" section. ++++++++++++++++++++++++++++++ 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? -------------------- Tero Kivinen (2005-10-18): https://www.machshav.com/pipermail/mobike/2005-October/001129.html > 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. -------------------- Stephane Beaulieu (2005-10-18): https://www.machshav.com/pipermail/mobike/2005-October/001130.html > 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. > 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. > 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. > 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. -------------------- Pasi Eronen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001273.html The text currently says: To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later). But perhaps the last part could be slightly rephrased. How about this? "(this way, there is no need to change the ports later if a a NAT is detected on some other path)" -------------------- Stephane Beaulieu (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001272.html Sounds good. --------------------