1 / 6

Principles & Constraints

Principles & Constraints. Philip Eardley. Application-agnostic. The CONEX protocol should be open about (independent of) the responses it allows to the CONEX information, supporting a diversity of traffic management practices by networks and end-hosts.

naiara
Download Presentation

Principles & Constraints

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. Principles & Constraints Philip Eardley

  2. Application-agnostic • The CONEX protocol should be open about (independent of) the responses it allows to the CONEX information, supporting a diversity of traffic management practices by networks and end-hosts. • The proposed WG will encourage experiments on traffic management, but not standardise them (in order to reduce its scope).

  3. CONEX information is in IP header • Visibility of CONEX information – it should be easily visible to all network elements (even if the data traffic is encrypted) • in order to ensure the widest possible applicability – • it is visible to both end-systems (to help them control their sending rate) and to network managers (to help them manage a bottleneck, whether traffic originates from their own users or from other networks).    • Granularity of CONEX information – it should be sufficiently granular to allow near real-time, per packet traffic management. • So that any node can see the impact of the packets it is asked to forward. • The CONEX information is inevitably a minimum of 1 RTT out-of-date • The above 2 bullets suggest that the CONEX information is carried in the IP header. • Signalling of whole path congestion information is thus explicit, rather than implicitly through packet loss, delay or jitter, which allows a faster and more accurate reaction. • The proposed WG will specify how to encapsulate CONEX information (header bits, interpretation) (v4 & v6)

  4. Feedback path congestion info • The receiver needs to inform the sender what the total path congestion is • Simplest case, this is what the sender sets as the initial CONEX information • (TBD: do this using TCP mod; RTP/UDP;) • (TBD: whether the capability of an ECN receiver is sufficient).

  5. Threats analysis • The proposed WG will study the threats, especially from falsifying or suppressing the CONEX information

  6. Deployability analysis • The proposed WG will study technology to support incremental deployment steps: • ECN routers vs non-ECN routers vs CONEX routers; • Receivers with CONEX-capability, ECN-capability, or neither; • Opportunistic deployment.

More Related