Subject: [re-ECN] Charter Question

From: Ron Bonica <[email-masked]>
Date: Fri, 7 May 2010 10:58:25 -0400

Folks,

Please excuse a simple question from an AD who has not followed your
work very closely:

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.

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

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?

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

                                      Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 7 May 2010 11:02:18 -0400

Correction to my last message:

"What will those routers do with that information?"

                           Ron

On 5/7/2010 10:58 AM, Ron Bonica wrote:
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>

---

From: John Leslie <[email-masked]>
Date: Fri, 7 May 2010 12:59:38 -0400

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

> visible to all IP devices along the path."

   Yes.

> 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 <[email-masked]>

---

From: [email-masked]
Date: Fri, 7 May 2010 18:16:16 +0000

> inform better congestion-control mechanisms extending past the

	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?

--bill

---

From: John Leslie <[email-masked]>
Date: Fri, 7 May 2010 16:02:35 -0400

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

---

From: [email-masked]
Date: Fri, 7 May 2010 20:44:29 +0000

> don't claim to be talking for anyone else.

	sure... 

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

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

> 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!)

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

> congestion experienced, whether by ECN, dropping packets, or some

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

---

From: John Leslie <[email-masked]>
Date: Fri, 7 May 2010 17:56:24 -0400

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

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

   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.

> qos is a range,

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

> ecn is (for this thread) a range.

   Yes.

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

> i'm ok with this idea.  what would be useful here is some
> 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...

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 10 May 2010 12:41:20 -0400

>    I believe we consider that question out of scope; 

This is troubling. Before we invest in tool development, we really
should know something about the intended use of the tool.

I wouldn't mind letting the BoF spend some time bringing this question
into focus before chartering a WG.

                                        Ron

---

From: John Leslie <[email-masked]>
Date: Mon, 10 May 2010 13:43:53 -0400

> should know something about the intended use of the tool.

   We certainly have a lot of information on that developed by Bob
Briscoe, e.g.

http://bobbriscoe.net/projects/refb/

   I realize that not everyone agrees with Bob; so let me try to give
an independent viewpoint on use of a ConEx tool.

   Recall, the proposed charter says:
] 
] 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.

   Thus, at any point along the path -- most likely near the sender
or near the receiver -- it will be practical to aggregate the expected
congestion for some flows and see whether this is consistent with the
contractual arrangement.

   What to do if it isn't is clearly out-of-scope.

   How to ensure better service for flows that correctly mark the
expected congestion is mostly out-of-scope. Diffserv and source-
routing through special paths known to be less congested come to
mind; but any method whatsoever is fine, and even no method at all
may prove quite workable -- that is a business decision for the ISP
involved.

   This -- and only this -- is "the intended use of the tool".

   Being who we are, we inevitably speculate about other uses such
a tool will enable. Any good tool enables uses beyond the one it
was designed for.

> into focus before chartering a WG.

   What "better focus" would you like, Ron?

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 10 May 2010 14:25:16 -0400

I think I gave an example on this list last Friday.

See <http://www.ietf.org/mail-archive/web/re-ecn/current/msg00690.html>.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ron Bonica
Sent: Monday, May 10, 2010 12:41 PM
To: John Leslie
Cc: [email-masked]
Subject: Re: [re-ECN] Charter Question

                                        Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 10 May 2010 16:18:26 -0400

Richard,

I think that you gave a very fine example. Unfortunately, according to
John, it is out of scope.

Rather than putting it out of scope, I think that it should be the WGs
first order of business.

                                      Ron

On 5/10/2010 2:25 PM, Woundy, Richard wrote:
> .

---

From: [email-masked]
Date: Mon, 10 May 2010 20:31:29 +0000

>    What to do if it isn't is clearly out-of-scope.

	er... you have already proposed a use for the congestion information,
	i.e. aggregate flows... and then, its no longer the original sender/recevier,
	is the node that has chosen to mediate/aggregate and the source/target (or
	other middle-box that has chosen to aggregate/deaggregate based on local
	policy)

	Just saying.

>    This -- and only this -- is "the intended use of the tool".

	me thinks this vastly exceeds Bobs description - its moved past 
	a protocol change; "relay congesstion information back into the IP layer"
	to a specific implementation choice.

> a tool will enable. Any good tool enables uses beyond the one it

	amen - but lets get the tool working before we try and use it for
	a given purpose.

---

From: John Leslie <[email-masked]>
Date: Mon, 10 May 2010 16:51:49 -0400

Ron Bonica <[email-masked]> wrote:
>> [Ron Bonica wrote:]

   There may be some misunderstanding here...

] [Ron Bonica wrote:]
]] If I do have this right, who will those routers use this information?
]
] I believe we consider that question out of scope;

   I do consider the quetion of what any existing router does with the
information out of scope.

   But we have a pre-WG document which I believe _will_ see some work
after the WG is formed:

http://tools.ietf.org/html/draft-tschofenig-conex-ps-02

describing the problem we set out to address.

   I can understand that someone working for a router manufacturer may
be concerned how this will affect router design.

   But there appears to be a consensus (whatever that may mean in the
absence of a WG) that the answer is, "Not at all." We're thinking in
terms of middlebox operations, and asking no more of existing routers
than to perform ECN marking if it's convenient.

   (BTW, draft-tschofenig-conex-ps basically says that ISPs want to do
the right thing, but in the absence of congestion exposure they're
forced to use less appropriate metrics to "estimate" congestion.)

> Rather than putting it out of scope, I think that it should be the WGs

   I agree a Problem Statement deserves to be an early milestone.
What do you think is needed that's not in draft-tschofenig-conex-ps?

---

From: John Leslie <[email-masked]>
Date: Mon, 10 May 2010 17:05:25 -0400

> i.e. aggregate flows... and then, its no longer the original

   My bad... I meant "flow(s)". One can aggregate congestion-marking of
packets for a single flow.

> other middle-box that has chosen to aggregate/deaggregate based on local

   I don't understand that question.

   As far as "policy", I didn't envision anything like the "policies"
of BGP routing. I envisioned contractual arrangements between ISP and
customer about how much congestion the customer will "cause" -- where
I believe the average customer doesn't intend to cause much, but
other customers might be willing to pay for a higher grade of service.

> a protocol change; "relay congesstion information back into the IP
> layer" to a specific implementation choice.

   Neither Bob nor I speak for the WG that may form.

   (Bob can speak to how much violence I've done to his design; I
don't think I've done much at all...)

   And, of course, one _must_ move past the protocol definition to
reach an "intended use".

> amen - but lets get the tool working before we try and use it for

   Agreed!