1 / 14

Multipath TCP Signaling Options or Payload?

Multipath TCP Signaling Options or Payload?. Costin Raiciu c.raiciu@cs.ucl.ac.uk. Motivation . MPTCP needs to signal control data to function correctly Data sequence mapping Data ACK Add/remove IP Security Information What’s the best way to signal this information?. Considerations.

jerickson
Télécharger la présentation

Multipath TCP Signaling Options or Payload?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multipath TCP SignalingOptions or Payload? Costin Raiciu c.raiciu@cs.ucl.ac.uk

  2. Motivation • MPTCP needs to signal control data to function correctly • Data sequence mapping • Data ACK • Add/remove IP • Security Information • What’s the best way to signal this information?

  3. Considerations • Control Message • Size • Requirements • Middlebox behavior • Remove/duplicate options • Normalize payload

  4. Options Encoding • 40B in TCP header, some already used • Traditional way to signal control information in TCP • Not reliably delivered • Limited size • Messed with by middleboxes

  5. Payload Encoding • Use Type-Length-Value encoding to add control messages in the payload • No more reliability issues • No more space issues

  6. Connection/Subflow Setup • Options encoding: • Add MPTCP capable/token on initial connection • Add JOIN option on subsequent connections • Payload encoding • Initial connection: must use options encoding! • Additional subflows: must use options encoding!

  7. Data Sequence Mapping • 10-14B with options, 6-10B with payload • Options encoding: • Reliability issue: may be stripped by middleboxes • If data ACK: can infer it was lost => drop path and use others • No data ACK: receiving subflow must drop data without options (hack) to force the sender to retransmit. • Or explicitly ack the mapping – quite a few of them • Payload Encoding • If segment is acked, mapping is acked too. • Still need data ACK for other corner cases.

  8. Data ACK • 4-8B • Options • just piggyback on ACKs, cuts 1 SACK segment • Payload • Data ACKs are sent reliably, in order, and are congestion controlled! • Implications • Cannot piggyback them on all ACKs • Can trigger timeouts at the sender on connection level data

  9. Add/Remove IP • 6-18B • Need in order, reliable delivery • Options • Must echo options explicitly and send one/RTT or • Add sequence numbers & acks • Payload • Send one/RTT or • Add sequence numbers & acks.

  10. Security Information • Typically bootstrapped when connection begins • Options • Public keys (if used) will not fit in options, must encode in payload • Add option describing where in the payload the security data is • Payload: no issues

  11. Middleboxes • That strip options on data packets • Options • Will not use the subflow • Payload • Will use the subflow

  12. Future Middleboxes • Middleboxes will be deployed to optimize various aspects of multipath TCP • Options • Allows all (stateless/stateful) middleboxes to see the state of the connection and the fact its multipath • Payload • Stateless middleboxes cannot differentiate between TCP and MPTCP • Stateful middleboxes will have to parse the data stream; when they get desynchronized the can’t tell if it’s TCP or multipath anymore.

  13. Comparison Summary

  14. And the winner is …?

More Related