1 / 12

CONEX BoF

CONEX BoF. Welcome to CONEX!. Chairs: Leslie Daigle Philip Eardley Scribe Note well MORE INFO: http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN. Note Well.

rafal
Download Presentation

CONEX BoF

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. CONEX BoF

  2. Welcome to CONEX! • Chairs: • Leslie Daigle • Philip Eardley • Scribe • Note well • MORE INFO: http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN

  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. Questions • Is “congestion exposure” a problem for the IETF to solve? • a mechanism to allow senders to inform the network of the level of congestion they expect their packets to encounter. • Should a WG be formed with this charter (+ some word-smithing)

  5. Agenda • Administrivia [ 5 mins] • Introduction by chairs [ 5 mins] • Background • The problem [50 mins] • end-user perspective [Murari Sridharan] • ISP perspective [Rich Woundy] • technical problem [Mark Handley] • Towards a solution [20 mins] • Overview of re-ECN [Bob Briscoe] • Discussion of potential IETF work • Constraints [10 mins] [Philip Eardley] • Discussion of viability of congestion exposure [40 mins] [Leslie Daigle] • Draft charter discussion [20 mins] • Questions and hums [10 mins] • After close of BoF meeting -- Bar BoF of demonstrations [TBC]

  6. Some Background • This is proposing new work at the IETF – but it’s not new • Bar BoF in Stockholm • http://trac.tools.ietf.org/area/tsv/trac/wiki/0907re-ECNBarBoFMinutes • GIIC – high level industry workshop on fairness in capacity sharing • http://www.giic.org/ • http://www.giic.org/pdf/GIICFairInternetSharingWSAgenda-Final.pdf • http://www.giic.org/meetings/9-30-09.asp

  7. Draft Charter Discussion

  8. CONEX WG The purpose of the CONEX working group is to develop a mechanism to allow senders to inform the network of the level of congestion they expect their packets to encounter. This information is currently only visible at the transport layer. With the output of CONEX, it will be possible to provide sufficient information in each IP datagram so that any node in the network can see the expected rest-of-path congestion. Once any node can see the impact it causes (and suffers) by sending or forwarding packets, it will be possible to hold senders and whole networks accountable for the congestion they cause downstream. Tools that exploit the CONEX output could be used for mitigating distributed denial of service (DDoS); simplifying differentiation of quality of service (QoS); policing compliance to congestion control; and so on.

  9. Output of the CONEX WG will include… • An applicability statement -- the specific cases in which CONEX is useful, especially in different network conditions, incremental deployment considerations, etc • Specification of IP (v4 and v6) packet structure to encapsulate congestion exposure information (header bits, interpretation) • Use cases -- possible uses of the CONEX information to reduce congestion and/or increase accountability for it -- for illustration purposes only • Specification of necessary CONEX features in TCP, for example to carry congestion information from receiver to sender • Analysis of security threats from falsifying or suppressing CONEX information Future work may include specifications to implement one or more use cases, but that is out of scope initially.

  10. Milestones • Feb 2010 Draft applicability statement (-00) • Mar 2010 Evaluation of candidate protocol approaches • Apr 2010 Determination of protocol approach • May 2010 Draft use cases (-00) • Jun 2010 Revised applicability statement • Jun 2010 Draft CONEX IPv4 specification (-00) • Jun 2010 Draft CONEX IPv6 specification (-00) • Aug 2010 Draft security threats document (-00) • Dec 2010 Revised CONEX IPv4 specification • Dec 2010 Revised CONEX IPv6 specification • Jan 2011 Revised security threats document • Jan 2011 Revised use cases

  11. Issues from the list • Do we need an applicability statement document? • Handling other-than-TCP • Add specification of “how to” for other transports? • “Vision” document for potential long term architecture impact?

  12. Questions • Is “congestion exposure” a problem for the IETF to solve? • a mechanism to allow senders to inform the network of the level of congestion they expect their packets to encounter. • So that any node in the network can see the rest-of-path congestion (ie between the node and the destination) • [Note: this is a new capability] • Should a WG be formed with this charter (+ some word-smithing)

More Related