Re: [re-ECN] Charter Question

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> wrote:
> On Fri, May 07, 2010 at 12:59:38PM -0400, John Leslie wrote:
> 
>> 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.
> 
>  ok, then I am confused by your POV.  are we talking about a
>  binary switch (congested/notcongested) or are we talking about
>  preference/priority - with a range of values?  if the former,
>  then its not really applicable to the flow, end/end, since the
>  "inspecting forwarder" may in fact be the cause of the congestion.
>  if its a range, then how is this different than QOS?

   First and foremost, I'm talking of _my_ point-of-view here -- I
don't claim to be talking for anyone else.

   I don't believe any of us are talking a "congested/notcongested"
binary switch, and I'm certainly not.

   The reECN proposal encodes a scalar of arbitrary precision by the
proportion of "congestion-expected" marks in the IP packets of a flow.
I expect other possible encodings would be investigated when/if the
WG forms.

   I agree with Bill that the binary switch he mentions isn't really
applicable to the problem, though I don't agree the "inspecting
forwarder" is a likely cause of congestion.

   I'm a bit confused by Bill's "how is it different" question: to
me "a range" is totally different from QoS...

   Nevertheless, congestion-expected marking is a fundamentally
different thing than QoS marking, and rather orthogonal IMHO. QoS
deals with what _kind_ of special treatment you request; CE marking
deals with passing information about an estimate of future
congestion the packet might encounter.

   Thus, IMHO, it's quite reasonable to imagine QoS marking in
addition to CE marking, to designate what you want a forwarder to
do in the event of lengthening queues, for example (though I don't
mean to say the two markings _should_ overlap in the slightest!).
Or it might be the case that a forwarder could benefit from CE
markings to estimate whether a particular QoS path is becoming
congested... Any such work goes _far_ beyond our initial charter.

   I believe it is our intent to specify the meaning of CE marks,
expecting nothing of intermediate forwarders than that they signal
congestion experienced, whether by ECN, dropping packets, or some
other method entirely.

   (I hope this at least begins to answer Bill's question...)

--
John Leslie <[e-mail]>