I'm sure you had good time to think about the discussion captured last blog (/ blogs / 2013/08 / 16 / tcp-network beyond /).
so we know the problem well and we understand that trying to change the basic networking will not be acceptable in any way. Several researchers have worked together on this issue and finally came up with the proposal of MPTCP -. Multipath TCP
Returning to TCP bases, the connection establishment process is called three -way handshake. Host A sends a packet with SYN flag to the host B responds back with a packet with SYN and ACK flags. Finally Host A sends a packet with ACK flag that marks the connection is established and ready for data transfer. Thus, the basics remain the same and MPTCP uses the unused portion of TCP packets called the options field. In a session MPTCP A host will add the MP_CAPABLE to the SYN packet. If the host supports MPTCP reception B then add the same option MP_CAPABLE for the SYN-ACK response packet. The final ACK Host A will thus contain the MP_CAPABLE establishing the TCP session multichannel between hosts A and B. There are many other TCP extensions using the option field and so it is nothing new in the world of TCP.
So far, nothing different that the host A and B knowing that they have formed MPTCP session. Host A now recognizes a different interface to connect to the host B and launches a new TCP connection to different source address and a different port. It is a normal TCP connection but MPTCP world, it is called a sub-stream between the host A and B. For MPTCP stack to recognize that this is a sub-stream of an existing MPTCP session, Host A will start SYN packet with MP_JOIN option. This option also includes information on which MPTCP session, he should join. So the session MPTCP recognize this new connection as an existing session sub-stream and add. But if this is so simple then an attacker could easily be able to forge a TCP connection to join other session MPTCP. Research has supported this issue by exchanging cryptographic key between the two armies so that they exchange MPTCP options. Thus, with the help of the cryptographic validation it is ensured that the new connection belongs to the same host and may be allowed to join the existing MPTCP session.
multiple sub-streams even can be created and assembled in the MPTCP session and once the session has several sub-streams, it totally depends on the host A and B decide which stream should be used for transfer of data at the given point in time. Each TCP connection maintains its own sequence space and recognition and ensures that it transfers data reliably. At the session layer MPTCP will have its own reception window that spreads across all sub-flows. It also has its own space sequence to keep track of how the data received from multiple sub-flows within the overall session stream. Here is a quick illustration of how the overall stack resembles MPTCP:
Interestingly MPTCP offers much more flexibility than the sub-streams are not dependent on the each other. The sub-streams can join and leave the session MPTCP at any time without affecting the entire session. This is where it perfectly into mobile use where the equipment disconnects and reconnects based on network availability because it is on the move. The application layer will not even notice that the sub-streams join and leave at their own will. MPTCP session will ensure that the application has connectivity and smooth data transfer rate between the two hosts.
Great stuff and that's what we have built in battery NetScaler to ensure that we can work with mobile customers effectively and ensure a better end user experience. Stay tuned for the next blog with details about our implementation ...
0 Komentar