Re: [re-ECN] Two questions about CONEX

[John Leslie <[e-mail]>]

Stewart Bryant <[e-mail]> wrote:
> 
> I would like to clarify what my concern is here.
> 
> If the marking is in every packet then the forwarder needs to take 
> action on every packet.

   There might be forwarders expected to act on every packet, but I
don't believe any current design calls for that (beyond what forwarders
might already do in Explicit Congestion marking). In particular, it
seems thoroughly unlikely that backbone routers will be expected to
do anything.

> The thing that makes IP (and MPLS) cheap and fast is that we only do the 
> minimum amount of processing in forwarding and do as much as we can by 
> other means. In particular everything other than forwarding happens at a 
> much slower rate, is often asynchronous WRT forwarding, and usually 
> happens in a process that can schedule the processing at some convenient 
> time.

   Agreed.

   But "middleboxes" that do various translations and such on every
packet are common and becoming even more common.

> I used the term OAM rather loosely earlier to indicate a packet that 
> traversed the path, fate sharing with the data, containing information 
> of note intended for the intermediate systems.  I make no comment on how 
> such packets might be carried or fate shared.

   Thanks for the clarification; I was quite confused by that term.

> My question here is that whilst I can see that we need to do better
> than the 15mins that systems seem to do at the moment, do we need to
> go all the way to making the reporting the congestion state on every
> packet.

   I'm not sure...

   The reECN proposal marks very few packets as Congestion Expected;
and in the ideal case it hopes that they will pick up Explicit
Congestion markings as they go through forwarders experiencing
congestion.

   I'm not aware of any expectiations of processing beyond that for
reECN.

   But it's early to say whether we might encode differently in IPv6
ConEx. We do expect middleboxes (for example, policers) to examine
ConEx markings, and it's conceivable they might forward ConEx flows
differently. This issue may or may not be discussed, but actual design
of such middleboxes is clearly out-of-scope in the initial charter.

   Thus, there _might_ be a reason to mark every packet of a ConEx
flow as "ConEx-aware" -- strictly for the convenience of middleboxes.

   More specifically, to what I think is your question: "is there a
need to report congestion on every packet?"...

   There is a clear benefit attached to a transport protocol learning
of congestion without waiting to declare a packet has been dropped.
This has been clearly recognized in all the Explicit Congestion
Notification work. ConEx adds nothing to that issue, but does stand
to benefit from it.

   There is also, IMHO, a potential benefit from estimating potential
congestion _before_ waiting for a full Round-Trip-Time. Such work is
clearly research-level, and is no way "included in" ConEx; but could
be enabled by finer gradations of "pre-congestion-vs-time" information.
As our work proceeds, we will see whether a finer gradation of
Congestion-Expected marking turns out to be practical; I suspect it
may be.

   Do note, there's a real issue _today_ of TCP not filling pipes
whose bandwidth-delay is too large. IMHO, this will _need_ to be
solved by transport protocols that back-off more gently upon
"signals" of congestion or impending congestion. This work goes
beyond any foreseen ConEx charter; but I'd like to believe that
ConEx work could enable better precision of congestion signals.

   Signaling "expected congestion" is necessarily a technology
which will enable all kinds of optimizations which we can't yet
imagine. We really need to standardize _something_ in this realm,
without worrying how the things it will enable will impact the
job of current router boxes.

   Do we need to go all the way to reporting congestion state on
every packet? No, but it might be good to have an option which
allows for that. And the farther from that we settle, the greater
the danger that the packets we _do_ mark will turn out to not be
typical of the whole flow. This is an issue that needs a WG to
find the reasonable consensus: I don't believe we can solve it
in a charter.

--
John Leslie <[e-mail]>