57 - question about initiator decides

It seems that discussion about this particular
design choice belongs to the design document.

So no text changes to protocol-04.

FWIW, I'm at least personally quite happy about
this decision. You have good questions, Marcelo,
and I hope this will improve our design document!
Some further discussion below:

>Now what i would like to understand is what parts of the mobike protocol 
>would not support the more general scenario, where both parties can 
>change the address pair used for the communication.
>  
>
We need to separate the ability to use different addresses
and the protocol's internal process at arriving a decision
from each other. Now, just because initiator decides in
MOBIKE, it doesn't mean that responder's addresses could
not change, or that the responder's input is not taken into
account.

In other words, its not a constraint that only X can do
something, but an arrangement where X gets information
and is the party responsible for final decisions and
coordination. An analogy may be a distributed system
where one of the nodes is elected to be a leader.

We found that the arrangement simplifies the operation
of the protocol.

>As i see it, this was a constraint to simplify the protocol to a case 
>like the VPN which was useful. My question at this point is how much of 
>the resulting protocol actually relies on this constraint?
>As i read it, this resulted in the following constraints:
>- Tunnel mode only is supported
>  
>
I don't think this is a result of the initiator-decides design.
Transport mode has fundamentally different issues,
including survivability of transport sessions.

>- Only the initiator can be behind a nat
>  
>
There are limited cases where the responder can also be
behind a nat. However, the question is whether limitations
in responder's location are due to design of if they are
fundamental limitations caused by NATs. I think the latter.

>- no simultaneous movement is supported
>  
>
Not sure how well initiator-decides affected this, but
at least there's another fundamental issue at the bottom:
without a home-agent or DNS or DHT like schemes we
can not implement simultaneous movements. (Same applies
to SHIM6 too, btw.)

>Now, i can see that supporting those may increase the complexity of the 
>protocol
>However, in addition, it seems that the protocol artificially imposes that
>- failure detection, path exploration and path selection can only be 
>performed by the initiator (client)
>  
>
Well, it only means that the final decision is done by one
party - not that the other party would be unable to be
a part of an exploration process. Having said that, the
exploration process in MOBIKE is very simple compared
to some other cases, because we assumed bidirectional
connectivity.

>- it includes a couple of corner cases where the responder can change 
>its address for dealing with specific cases.
>Wouldn't it be simpler to define a symmetric operation of the protocol 
>(without corner cases) and simply stating the three constraints above? 
>  
>
I think we tried, but it didn't appear to be simpler.

--jari