Re: [re-ECN] CONEX Principles & Constraints

[<[e-mail]>]

In general I think these are a good starting point. Some comments
inline...

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

I might even go so far as saying "Potential uses for such information
are explicitly beyond the scope of this initial
{WG/BoF/protocol/whatever}"

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

I would either merge this with the later points about IP or at least
re-order the list so they occur in a row.

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

How about "Sufficiently up-to-date to enable near-real-time traffic
management". 

Incidentally this is nothing to do with congestion control at
end-systems - the end-system already sees congestion! So the only link
to congestion control is if this in turn allows the network to be more
lenient towards end-systems.


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

The information needs to granular enough to hold the originator of the
traffic accountable?


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

Better: "This may require defining new codepoints in the IP header or
possibly even the re-definition of existing codepoints. We will be
careful to consider the impact of our choices both on existing protocols
and on deployability.

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

I might consider phrasing this "although on the face of it an IPv6
protocol may be easier, we will also develop solutions for IPv4 as it is
still the dominant network-layer protocol.."

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

Do we want to specify using TCP options at the moment? Option space is
limited and already used for lots of other things + MPTCP will be using
even more (and there is a very high chance of eventual overlap between
conex and MPTCP). I would prefer to leave this as "we will concentrate
on TCP as this provides a feedback path..."

> 9. a baseline assumption is that routers are unmodified. Reason:
> deployment viability

"This MUST work with unmodified routers, even if they don't do ECN...
although modifying routers may allow additional refinements...

> 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

In theory implicit signalling already exists - if you observe a TCP
source halving its rate you can assume it was (probably) in response to
a loss event...

> 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

No! - we may develop a solution that informs the network of congestion
the sender has learnt about both as a result of explicit notification
(ECN) and implicit notification (loss). However we DON'T use loss to
signal ConEx information (which is surely impossible anyway?)! 

> 12. (possibly) we will study an incremental deployment step where only
> the sender is conex-enabled [Step suggested by Matt]

We certainly need to leave this open as a possible step

> 13. (possibly) another incremental deployment step?

Proxy?

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

Probably :)

> 
> Thanks
> phil