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

• These are a work in progress – intentionally

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)

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?

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).

Illustration: feasible unilateral re-ECN deployment scenarios

with incentives1. 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

2. receivers deploy re-ECN (mostly because they are also senders)3. 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

sender forwarding receiver network anti-cheating integrity

re-ECN ECNre-ECN idealECN ok but misses some feedback

3.re-ECN

some ECN(re-)ECN

ok (ideal)2. some drop partial?1. re-ECN drop drop partial; but detail design TBA

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...?