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 scenarios with incentives 1.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 senderforwardingreceivernetwork anti-cheating integrity re-ECNECN re-ECNideal ECNok but misses some feedback 3. re-ECN some ECN (re-)ECN ok (ideal) 2.some droppartial? 1.re-ECNdrop partial; but detail design TBA

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