Download PowerPoint Presentation - 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
•
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.
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)
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]
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/0907reECNBarBoFMinutes
• GIIC – high level industry workshop on
fairness in capacity sharing
• http://www.giic.org/
• http://www.giic.org/pdf/GIICFairInternetSharingWS
Agenda-Final.pdf
• http://www.giic.org/meetings/9-30-09.asp
Draft Charter
Discussion
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.
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.
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
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?
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)