1 / 15

MPTCP – MULTIPATH TCP

MPTCP – MULTIPATH TCP. WG meeting #3 July 27 th & 29 th 2010 Maastricht, ietf-78 Philip Eardley Yoshifumi Nishida. Scribes Jabber Please include “-mptcp-” in your draft names Please say your name Slides at https://datatracker.ietf.org/meeting/78/materials.html. Note Well.

valin
Télécharger la présentation

MPTCP – MULTIPATH TCP

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 – MULTIPATH TCP WG meeting #3 July 27th & 29th 2010 Maastricht, ietf-78 Philip Eardley Yoshifumi Nishida

  2. Scribes • Jabber • Please include “-mptcp-” in your draft names • Please say your name • Slides at https://datatracker.ietf.org/meeting/78/materials.html

  3. Note Well • Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: • * The IETF plenary session • * The IESG, or any member thereof on behalf of the IESG • * Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices • * Any IETF working group or portion thereof • * The IAB or any member thereof on behalf of the IAB • * The RFC Editor or the Internet-Drafts function • All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). • Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. • Please consult RFC 5378 and RFC 3979 for details. • A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. • A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

  4. Agenda Tuesday 1710-1810 Auditorium 2 • Options vs payload discussion • Objective: To come to WG consensus on which approach MPTCP will use (options or payload). Thursday 1510-1610 Auditorium 1 • Objectives: • Placeholder to confirm /continue options vs payload decision (if further discussion time is needed • Brief Report back from Implementors workshop • Progress to fulfil our Milestone (Aug 2010) - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) • Progress on other WG drafts • Consensus to create WG draft(s) for Milestones on extended API and applications considerations. Interim audio meeting • If we run out of time

  5. Today’s agenda – • Agenda bash, Intro, note-takers (5mins) • Brief Report back from Implementors workshop (5mins) • Consensus call on Options vs Payload (10mins) • Progress to fulfil our Milestone (Aug 2010) • Security threats – Marcelo Bagnulo (5mins) • Architecture – Alan Ford (5mins) • Progress on other WG drafts • draft-ietf-mptcp-multiaddressed (10mins, Alan Ford) • draft-ietf-mptcp-congestion (5mins, Costin Raicu) • Consensus to create WG draft(s) for Milestones on extended API and application considerations. • API and application considerations (10mins, Michael Scharf) • Other documents • Alert about work on interface between multipathing and address selection (5mins, Aleksi Suhonen)

  6. Implementors workshop • Saturday 24th July, Maastricht http://tools.ietf.org/wg/mptcp/trac/wiki/Maastricht_workshop • Objective: to help make Multipath TCP real • to get it implemented in many operating systems and to get it used by key applications. • Bring together: people who’d use MPTCP, OS implementors & WG protocol designers • Discuss the use cases for Multipath TCP • Discuss Multipath TCP & OSes. • Organised under the auspices of the MPTCP working group, but is not a formal WG meeting • ~ 25 participants

  7. Implementors workshop • Use case #1: Mobiles • Energy saving by aggressively shifting to energy efficient radio • Impact on advanced API? • Resilience now seen as less important • Use case #2: Data centres • Everything under operator control • May simplify some MPTCP protocol aspects • MPTCP naturally puts traffic on path with capacity • Plenty of research issues

  8. Implementors workshop • OS discussions • Linux implementation on-going • http://inl.info.ucl.ac.be/mptcp • BSD effort would be great • On-going considerations • Eg more often out of order • Ability to use hardware accelerations • Think of NIC as a middlebox

  9. Implementors workshop • Worth doing again • Remote participation not easy • Bay area workshop suggested

  10. Consensus call • MPTCP needs to signal control data; how? • Extensive discussions in Anaheim, on Tuesday and on the list • We agreed to reach consensus whether to go for Options or Payload, by the end of Maastricht • To be confirmed on the list • #1: Use a TCP option (for all signalling) • #2: Use TLV encoding in payload (for at least some signalling)

  11. Today’s agenda – • Brief Report back from Implementors workshop • Consensus call on Options vs Payload • Progress to fulfil our Milestone (Aug 2010) • Security threats – Marcelo Bagnulo (5mins) • Architecture – Alan Ford (5mins) • Progress on other WG drafts • draft-ietf-mptcp-multiaddressed (10mins, Alan Ford) • draft-ietf-mptcp-congestion (5mins, Costin Raicu) • Consensus to create WG draft(s) for Milestones on extended API and application considerations. • API and application considerations (10mins, Michael Scharf) • Other documents • Alert about work on interface between multipathing and address selection (2mins, Aleksi Suhonen)

  12. Background • MPTCP needs to signal control data – how? • Use a TCP option • Traditional TCP method • Use TLV encoding in payload • No space issues • Note: if control data is lost, need to detect & fallback to regular TCP • If unknown Options get dropped by a typical middlebox, then signalling using Options is difficult • Measurement info about this (next presentations) • http://www.ietf.org/proceedings/77/slides/mptcp-4.pdf • We agreed to reach consensus whether to go for Options or Payload, by the end of Maastricht

  13. Corridor meeting Discussed Options vs Payload for signalling about: • MPTCP-capable • Adding new paths • Data sequence mapping • Data ACKs Context for later discussions

  14. Corridor meeting - conclusions Discussed Options vs Payload for signalling about: • MPTCP-capable • Agree best to use TCP Option on SYN • Adding new paths • Agree best to use Option • Data sequence mapping • Agree not much difference between Options and Payload. • Agree Payload may have slight performance benefit • Data ACKs • Agree Data ACKs are needed (>= SHOULD), otherwise (potentially substantial) inefficiency • Agree Payload can suffer from head-of-line-blocking -> performance penalty

More Related