Re: [re-ECN] Charter Question

[John Leslie <[e-mail]>]

Ron Bonica <[e-mail]> wrote:
> 
> About ten years ago, the IETF sponsored work regarding the Explicit
> Congestion Notification (ECN). In this strategy, a router determines
> that it is about to forward a packet over a link that is running hot,
> but not so hot that it is obliged to discard the packet. So, the router
> marks the packet's ECN bits and forwards the packet over the hot link.
> The endpoints respond appropriately.

   Yes. The end-receiver of the ECN-marked packet, by whatever magic,
presumably causes the sender to reduce its sending rate.

> As far as I understand, the difference between the proposed work CONEX
> and ECN is that "The mechanism to be developed by the CONEX WG
> will enable the sender to also relay the congestion information
> back into the IP layer, such that the total level of congestion is
> visible to all IP devices along the path."

   Yes.

> When you say "the IP layer", I assume that you mean "other routers on
> the path between the two endpoints". Do I have this right?

   My understanding is that by "IP layer" we mean that the information
is carried in IP packets; thus information received by the sender at
transport layer is carried in future packets at network layer.

   The intent, of course, does include that this information will be
visible to IP-layer forwarders along the path (whether or not we call
them "routers") as well as any "policing" devices that might be in
the path.

> If I do have this right, who will those routers use this information?

   I believe we consider that question out of scope; but I will answer
that some of us envision "policing" devices (which may or may not also
have "routing" functions) to note imbalance, whether at the flow level
or AS level or some other level entirely, gather data on such imbalance,
and in extreme cases actually drop packets based on the imbalance.

   None of us believe that this function would be needed at every
router. So, most routers would not be expected to do anything whatsoever
with this information (though marking explicit congestion instead of
dropping packets _will_ be appreciated).

   Our principal intent is to have a forwarding-layer mechanism to
distinguish flows that intend to operate despite congestion from those
that intend to avoid congestion. Clearly routers forwarding onto
uncongested links do not need to distinguish these, while routers
that know they're forwarding onto a congested path might have reason
to treat them differently (though we don't yet know how), and
customer-facing routers might wish to enforce limits on the amount
of congestion-expected traffic.

   Generally, I don't believe we're at the point where it makes sense
to describe how routers would use the information -- so I have no
intent to speak for the list-members on this: but I do believe Ron
is entitled to some indication where we're coming from.

   We're talking about a mechanism to have a uniform view of path
congestion along a forwarding path, not about any particular method
of dealing with the congestion. We believe such information can
inform better congestion-control mechanisms extending past the
foreseeable future.

--
John Leslie <[e-mail]>