Re: [re-ECN] Charter Question

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> wrote:
> On Fri, May 07, 2010 at 04:02:35PM -0400, John Leslie wrote:
>> 
>> I don't believe any of us are talking a "congested/notcongested"
>> binary switch, and I'm certainly not.
> 
> well, we -could- be, if this is truely hop/hop - then the
> only link you care about is the link betwn the two hops.

   IMHO, even if this ends up in an IPv6 "hop-by-hop" option, it won't
concern the link between two hops. This is about _exposing_ information
now at the transport layer _to_ the forwarding layer.

>> 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.
> 
> perhaps I am jaded, but for many years there were real problems
> with forwarders being able to operate at "line-rates".

   I remember that too...

> If the forwarder spends too much time "inspecting, detecting,
> neglecting, infecting" the datagrams - it could be considered a point
> of congestion.. 
> Or I am misunderstanding (again)

   It is, of course, always possible to create yet-another-point-of-
congestion. :^(

   I would, however, view it as an abuse for any forwarder to spend
much time evaluating ConEx marking.

   There is an unstated presumption that "true backbone" links will
have sufficient aggregation to have negligible congestion except
during extraordinary DoS conditions. Thus, there would be no point
in putting congestion-policing at these. If their design allows, we'd
like them to ECN mark (in the rare case); but dropping packets during
congestion is perfectly fine.

>> 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.
> 
> qos is a range,

   Not, IMHO, to any forwarder that actually acts on it...

> ecn is (for this thread) a range.

   Yes.

> based on other parts in this thread, ecn markers could be
> used to tag/flag which flows needed priority - which sounded
> like QOS to me.

   I don't believe any of us intend ConEx marking to indicate a
"need" for priority; nor do I believe there is any current proposal
calling for giving such packets priority (though I personally don't
want to rule out such things in some future charter -- if it might
lead to better congestion management).

> CE marking sounds more like a warning to the destination that the
> path taken by the source should be avoided (congested) if possible.

   The reECN proposal calls for CE marks in just a few packets of a
flow. Treating those packets any differently than non-CE-marked
packets seems counter-productive.

   (There is, of course, ongoing work in MPTCP; and I don't mean to
try to forbid a case where MPTCP pays attention to CE markings.
But IMHO there doesn't seem to be any _reason_ for them to do so.)

>> 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'm ok with this idea.  what would be useful here is some
> guidance from the IAB (the architecture people) about the 
> 10'000m view.

   Hmm... I'm willing to push for that, but the IAB appears to have
a pretty full plate of liaison issues, and I doubt we'd get anything
from them in less than 3-6 months.

> granted we may be working on a small piece, but it would be nice to
> know that when we start mass hallucination that we are either
> ontrack or way out of scope. e.g. I'd like to see a larger context
> in which this work would be a contributing part.

   I think we'd have to start that discussion here, and hand IAB
members much more specific questions to see whether they bite...

>> 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.
> 
> ok.  hop/hop or end/end?

   End-to-end, IMHO. We're talking about making transport-layer
information visible at a lower layer -- the transport-layer info
is strictly end-to-end.

> can intermediate nodes modify CE marking?

   I suppose they "can", but it doesn't seem helpful to do so.

--
John Leslie <[e-mail]>