[re-ECN] CONEX Principles & Constraints (version 2)

[<[e-mail]>]

Thanks for your very usefull comments about this. I've attempted a
revised version

 

[CONEX information = expected rest-of-path congestion]

 

1.	Application-agnostic - the CONEX protocol should be open about
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).
2.	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).   
3.	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
4.	CONEX information is in IP header - 2 & 3 imply that the CONEX
information is carried in the IP header. Signalling of 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 a packet structure (v4 & v6) to encapsulate
CONEX information (header bits, interpretation)
5.	Transport protocol - the receiver needs to inform the sender
what CONEX information to set (TBD: whether the capability of an ECN
receiver is sufficient). 
6.	Threats analysis - the proposed WG will study the threats,
especially from falsifying or suppressing the CONEX information
7.	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.

 

3 - John, does this now briefly summarise your granularity point? 

 

5 - some people have suggested we should restrict initial work to TCP
(to limit WG scope). John has argued that UDP needs to be in scope.
Views?

 

7 - bob, does 'opportunistic deployment' get your "subtle point 15"?

 

thanks

phil

 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: 29 October 2009 18:03
To: [e-mail]
Subject: [re-ECN] CONEX Principles & Constraints

 

We wanted to start some discussion on "principles" and "constraints" ie
what we want to do in the proposed WG and how would its scope would be
restricted (building especially on emails from John (about "principles")
and Rich (about "requirements"). Eventually this would feed into the
Charter. This is just a first guess, so please bash. Something on these
lines would be in the "Constraints" part of the Agenda.  

                                                                  

1.	the purpose is to standardise the conex protocol - this exposes
congestion information along the forwarding path of the Internet
("rest-of-path congestion"). (This is in addition to the current
capability that exposes the congestion on the "path-so-far".). Note, the
purpose doesn't include studying how the conex information could be
used. Reason: there are lots of potential uses for the information. In
order to reduce the scope of the proposed WG, we concentrate on the
underlying information protocol.
2.	The protocol should be open about the responses it allows to the
conex information. For example, it should not make assumptions about the
behaviour of a particular application, and it should allow a diversity
of potential traffic management practices (of networks and end-hosts).
3.	the conex information needs to be easily visible to all network
elements, and be application-independent (including encrypted apps).
Reason: this ensures 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).
4.	the conex information needs to be sufficiently up-to-date, for
example so that it can usefully assist congestion control by end
systems. Reason: stale information is little use. [Question: instead of
"sufficiently up-to-date", would "real-time" or "near real-time" be
better?]
5.	the conex information needs to be sufficiently granular, to
allow identification of those sending traffic to the bottleneck
[Comment: this is trying to get a point that John made about 'granular
enough for cost allocation' but in a more generic way. "Identification"
is a bad word as, for some readers, it might be imply more than intended
- but I can't think of a better one at the moment. I hope that the
following bullet about conex information in the IP header solves how to
do it.]
6.	the conex information is carried in the IP header. Note: it is
in scope to work out which IP header bits to use (and the implications
for other stuff that may already be using those bits). 
7.	a protocol will be developed for both IPv4 and IPv6. Reason:
both are needed for full applicability. (There was push-back on an
earlier suggestion of narrowing the scope to IPv4.)
8.	TCP options will be used to inform the sender about congestion
received at the receiver. (Note, current proposals require this
information transfer.) Reason: narrow the scope by looking only at TCP,
which is used by the vast majority of the traffic (~85-90%). 
9.	a baseline assumption is that routers are unmodified. Reason:
deployment viability
10.	a baseline assumption is that conex information is signalled
explicitly (through the IP header) and not implicitly signalled through
packet loss, delay or jitter. Reason: explicit signalling allows a
"better" reaction, for example faster, without impairment
11.	but we will also develop a solution where the conex information
is signalled through packet loss. Reason: ECN is not enabled in most
routers today; incremental deployment is critical
12.	(possibly) we will study an incremental deployment step where
only the sender is conex-enabled [Step suggested by Matt]
13.	(possibly) another incremental deployment step?
14.	we will describe threats, especially from falsifying or
suppressing the conex information - whether by ISPs or end-hosts. The
protocol needs to allow such threats to be dealt with (in as simple a
manner as possible), but the actual mechanisms to tackle those threats
(using policer boxes, for instance) are out of scope. Reason: such
mechanisms are about uses of conex, rather than exposing the
information.
15.	anything else?

 

Thanks

phil