|
|
Motivations for a big change in the communication paradigm... :)
The communication between two nodes in infrastructure-based networks is often based on
point-to-point communication to implement communication models such as client-server.
This approach relies on the availability of both nodes at time of the communication and
on a stable connection between the two nodes during the duration of the communication.
The typical motivation of existing level-3 protocol is to provide a reliable or unreliable
way to send data between two endpoints across a network. This concept assumes that both
nodes are connected at the same time, directly via a single link or as part of a bigger network.
In mobile networks all these assumption do not hold. This is especially true in
mobile ad-hoc networks.
The client-server model is more difficult because of:
- the mobility of either node,
- unavailability of one node during migration,
- unavailability of a route between the two nodes,
- low or extremely variable bandwidth,
- etc.
Our idea is to split the communication in two segments
by inserting a Meeting Place node. The assumption is that mobile nodes will always
be able to connect to a stable node somewhere in the network.
The key advantages of this model on a highly variable network is that a few known and
relatively stable network nodes can be used to achieve point to point like communication
without the otherwise necessarily persistent quality of network.
The approach is scaleable through the introduction of more message points.
Four motivations motivate the design of the MPTCP as it is now:
- Absence of contemporaneity between the Client and the Server:
the two endpoints are rarely connected simultaneously.
- Resilience to disconnections. The "connectivity assumption" can become false at any time.
The two endpoints should be able to work without being affected by disconnections.
- Minimize the processing power and transmission time of the client. Server or network throughput
can be lower than the capacity of the Client. Efficiency suggests to cache the data in the network and collect it late.
- Reduce the load of the client, in case of periodical repeated requests. Delegate the network itself
to manage periodical repeating requests.
In MPTCP four different types of requests are defined, as described in this table:
The first letter in the acronyms specifies the number of requests to be carried out. A single request
consists in only one request from the Client to the Server and its relative answer. Instead, with a
multiple request a Client could ask to a Meeting Place to collect data from a Server many times at
specified intervals.
The second letter defines the type of connection ongoing between the Client (C), the Meeting Place
(MP) and the Server (S), as follows.
Direct Requests: The client delegates the MP to get the data (one time or more) from a remote
server and store it. The dialogue between the 3 actors assumes the following form:
step 1.
C to MP: "Please send my payload to S"
MP to C: "Ok"
step 2.
MP to S: "This is my payload"
S to MP: "This is my data"
Later...
step 3.
C to MP: "Please send me the data waiting for me"
MP to C: "This is your data"
Reverse Requests: The client directly connects to the Server and ask to send the answer
to its request to a Meeting Place. Later on, the client will get the data from the MP.
step 1.
C to S: "Please send the answer to this request to MP"
S to C: "Ok"
step 2.
S to MP: "This is data for C"
MP to C: "Ok"
Later...
step 3.
C to MP: "Please send me the data waiting for me"
MP to C: "This is your data"
In our design the size and number of fields in the header of the MPTCP protocol is not constant but can
vary to adapt the protocol to each situation while keeping the overhead low.
To discover more about
the protocol, you can read about its main features at this page, consider some
sample scenarios, read the protocol "draft"
or use our sample implementation.
|
