1 / 11

ConEx Concepts and Abstract Mechanism

This draft proposes a new abstract design for ConEx (Congestion Exposure), including the design of algorithms and protocols, and the encoding of signals in different protocol headers. It aims to provide loss-based congestion control for all transports, using TCP as the first concrete step.

webbc
Download Presentation

ConEx Concepts and Abstract Mechanism

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 Concepts and Abstract Mechanismdraft-mathis-conex-abstract-mech-00.txt Matt Mathis, Google Bob Briscoe, BT (two duffers) presented instead by Andrea Soppera, BT IETF-79 ConEx Nov 2010 This work is partly funded by Trilogy, a research project supported by the European Community www.trilogy-project.org

  2. ConEx Concepts and Abstract Mechanism • new individual draft: draft-mathis-conex-abstract-mech-00.txt • intended status: informational • immediate intent: request adoption as ConEx w-g item • milestone target: Jul 2011 recall • defer encoding to avoid obscuring underlying design • abstract design of algorithms & protocol • encoding in different protocol headers can follow (IPv6, v4) • scope • loss-based (for incremental deployment), not just ECN • any transport, ConEx just using TCP as first concrete step

  3. basic signals and functional units transportsender transportreceiver ACKS SACK ECE congestednetworkelement policy audit DATA ECN loss Re-Echo-ECN Re-Echo-Loss

  4. ConEx signal requirements • visible to internetwork layer • useful under partial deployment • minimal deployment: transport sender-only • accurate (auditable) • timely all SHOULDs not MUSTs in case compromises needed for encoding in headers

  5. terminology for signalling states max 5 states needed (white backgrounds) as well as 3 markings, 2 types of non-marking • Not-ConEx = ConEx not supported • ConEx-Capable = ConEx supported • ConEx-Not-Marked ConEx support but not marked (yet) • ConEx-Marked one of: • Re-Echo-Loss • Re-Echo-ECN • Credit … (see later talk) also sets of states (blue backgrounds) given names • all names can be bashed on list

  6. combinations five signals do not require five flags • Not-ConEx mutually exclusive • ConEx-Capable mutually exclusive • ConEx-Not-Marked mutually exclusive • ConEx-Marked mutually exclusive • Re-Echo-Loss • Re-Echo-ECN combinations feasible but avoidable • Credit … • ideally completely orthogonal to ECN • Re-Echo-ECN with Not-ECN-capable could be redundant • but may need further compromises to encode within header space

  7. relation to re-ECN • re-ECN: original concrete candidate ConEx proposal <draft-briscoe-tsvwg-re-ecn-tcp-09> up-rev’d for reference only implemented, security analysed • re-ECN required ECN-capable receiver • could severely constrain deployment • re-ECN did not need any ECN in queues • re-echoed loss as proposed in ConEx • but had no distinction between Re-Echo-ECN and Re-Echo-Loss

  8. congestion exposure components modifiedtransportsender optionallymodifiedtransportreceiver policypolicereroutedown-gradereport etc audit

  9. audit audit function • ECN-based audit • counting ECN markings • best near receiver • loss-based audit • Not a generic solution but possibly good enough in two common cases: • reconstruct losses by sniffing TCP seq numbers • Broken by IPsec, deviant TCPs • single primary access bottleneck • Bottleneck device can also perform audit

  10. status & plans • 5 reviews on list so far – 1 more detailed [Bagnulo] • all agree Credit needs to be explained (see later presentation) • other places where too much reader knowledge assumed • fairly easy to fix • plans • consensus on terminology (list) • text to explain Credit & reach consensus if disagreement • add normative design criteria for audit function • otherwise, looking in fairly good shape • adopt as WG draft?

  11. ConEx Concepts and Abstract Mechanismdraft-mathis-conex-abstract-mech-00.txt Q&A

More Related