[re-ECN] CONEX Principles & Constraints

[<[e-mail]>]

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