Re: [re-ECN] Charter Question

[[e-mail]]

On Fri, May 07, 2010 at 04:02:35PM -0400, John Leslie wrote:
> [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.

	sure... 


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

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

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

> 
>    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, ecn is (for this thread) a range.
	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.  CE marking sounds more like a warning to 
	the destination that the path taken by the source should 
	be avoided (congested) if possible. (this -could- be a single 
	bit!)

>    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 wiht this idea.  what would be useful here is some
	guidance from the IAB (the architecture people) about the 
	10'000m view.  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 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?  can intermediate nodes modify 
	CE marking?


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

	me too...
> 
> --
> John Leslie <[e-mail]>
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn