1 / 8

Viability of Congestion Exposure

Viability of Congestion Exposure. Framing the Discussion. This discussion is about congestion exposure not any specific solution Viability and tractability capturing the answers to some of the larger questions en route to nailing up a chartered activity

lester
Download Presentation

Viability of Congestion Exposure

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. Viability of Congestion Exposure

  2. Framing the Discussion • This discussion is about congestion exposure • not any specific solution • Viability and tractability • capturing the answers to some of the larger questions en route to nailing up a chartered activity • These are a work in progress – intentionally

  3. Viability Issue #1 • What are the points in favour of/against congestion exposure as an architecturally sound technique to specify for the Internet? (NB -- this is about congestion exposure, as constrained in the agreed principles, not any particular proposal)? • Suggested: • This is about network flows or packets, not applications or services, • so future applications and services are served, as well • it makes networks work better for real-time applications, now • Congestion exposure provides mechanisms to declare awareness of congestion elsewhere on the path WITHOUT prescribing behaviours. • many different behaviours are possible • This is also network agnostic in the sense that no pre-existing agreements or interpretations need be in place to make the congestion exposure work. (*Accounting* for it is a separate matter, but that's okay)

  4. Viability Issue #2 • The expectation is that congestion exposure information will be carried in IP packet headers. Is there really enough room to do that effectively? • For discussion: • In IPv4? Bits • In IPv6? extension header has space, but practical limits • This assumes tight timing -- that feedback is received and acted upon such that subsequent packets will experience the same or similar network state. What are the implications (or likelihood) of different paths? Or, are there other network state changes that will (could) change in that timeframe (now or in future developments). • But, would anything else be better?

  5. Viability Issue #3 • Does this scale -- to the whole Internet? is it deployable? • Suggested • Discussions of working with ECN-enabled and non-ECN enabled routers begins to address this. • There should not be issues with scale (processing, state) in core routers • In general it is only border devices that are expected to change in response to this (aside from any issues of ECN-capability).

  6. Illustration: feasible unilateral re-ECN deployment scenarioswith incentives • senders saying “It’s not me” unilaterally deploy re-ECN • no need for ECN in Net • e.g. LEDBAT, or Windows/Linux for majority of users • receivers deploy re-ECN (mostly because they are also senders) • nets deploy ECN to reduce queues and check metrics • another: mobile operators mandate for network & handsets via 3GPP • there will be broken middleboxes • will require re-ECN black hole detection & fall-back

  7. Viability Issue #4 • What *does* this close off? I.e., apart from the "last bit" issue, with IPv4, does this cause networks to react badly to new types of flows? Stifle innovation? Or...?

More Related