1 / 6

MPTCP Protocol draft-ietf-mptcp-multiaddressed-07

MPTCP Protocol draft-ietf-mptcp-multiaddressed-07. Alan Ford alanford@cisco.com. WGLC Complete. Thanks to Christoph Paasch for detailed comments and discussion. Recent Technical Changes. -03 to -04: added path ID to MP_PRIO -05 to -06: added Fast Close (MP_FASTCLOSE) mechanism.

joseh
Download Presentation

MPTCP Protocol draft-ietf-mptcp-multiaddressed-07

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. MPTCP Protocoldraft-ietf-mptcp-multiaddressed-07 Alan Ford alanford@cisco.com

  2. WGLC Complete • Thanks to Christoph Paasch for detailed comments and discussion

  3. Recent Technical Changes • -03 to -04: added path ID to MP_PRIO • -05 to -06: added Fast Close (MP_FASTCLOSE) mechanism

  4. Fast Close Mechanism • Derived from long-running discussion with Georg Hampel, started in Quebec • Analogous to (ab)use of TCP RST as ‘Fast Close’ • i.e. allow instant drop of state for all subflows • Says “no more data will be accepted for this subflow” • Mechanism: • Host A sends ACK+MP_FASTCLOSE on one subflow, and RST on remainder • Host B responds with RST on subflow • Upon receipt of RST in this situation, or of another MP_FASTCLOSE, Host A tears down state • Host A SHOULD retransmit MP_FASTCLOSE if not RST is received in one RTO

  5. Various Clarifications • Notably: • Clarified retransmissions and ACK mechanism for MP_CAPABLE and MP_JOIN exchanges • Revert to TCP three-way-handshake • Reverted changes of presence of keys • Clarified when to send data on new subflows • Clarified negotiation of checksums • Clarified rationale for DATA_ACK • Clarified fallback mechanisms: rationale and scenarios

  6. Next steps…

More Related