Subject: [aqm] Question re draft-baker-aqm-recommendations recomendation #2

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 29 Apr 2013 14:00:04 +0000

Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.2? This is the question of signaling to an endpoint using both dropping and ECN.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 29 Apr 2013 14:46:44 +0000

Generally agree with signaling to an endpoint using both dropping and ECN, except ECN marking may not be possible in MPLS networks because MPLS ECN uses EXP bits that are used to mark Priority in many deployed networks. 

I think that it is important to emphasize that ECN marking for end points to notify source nodes don't work well in very large networks. 

Since today's network is tunnels over tunnels (multiple layers of tunnels, e.g. MPLS over PW),  the tunnel scoped ECN marking can work well if the outmost tunnel doesn't go over too many hops and subsequent tunnels control the ingress rate. 

Linda Dunbar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred Baker (fred)
> Sent: Monday, April 29, 2013 9:00 AM
> To: [email-masked]
> Subject: [aqm] Question re draft-baker-aqm-recommendations
> recomendation #2
> 
> Do we generally agree with the recommendation of
> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-
> 4.2? This is the question of signaling to an endpoint using both
> dropping and ECN.
> 
> 
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 29 Apr 2013 16:48:42 +0000

> Generally agree with signaling to an endpoint using both dropping and ECN, except ECN marking may not be possible in MPLS networks because MPLS ECN uses EXP bits that are used to mark Priority in m…

Well, "impossible" and "requires some effort" are two different things. I suspect that the LSP endpoint, and any MPLS endpoint that adds or drops labels in the stack, could copy MPLS-ECN from the outer header to the inner header as it does so, as is recommended for IP/IP tunneling. It does have a syntactic issue, in that MPLS has relatively few bits to work with. But I think the semantics are clear enough.

> Since today's network is tunnels over tunnels (multiple layers of tunnels, e.g. MPLS over PW),  the tunnel scoped ECN marking can work well if the outmost tunnel doesn't go over too many hops and s…

Thanks

---

From: John Leslie <[email-masked]>
Date: Mon, 29 Apr 2013 17:43:21 -0400

Fred Baker (fred) <[email-masked]> wrote:
> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.2?
> This is the question of signaling to an endpoint using both dropping and ECN.

   I agree this text captures the essence of the issue.

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Mon, 29 Apr 2013 17:50:02 -0400

Linda Dunbar <[email-masked]> wrote:
> 
> Generally agree with signaling to an endpoint using both dropping and
> ECN, except ECN marking may not be possible in MPLS networks because
> MPLS ECN uses EXP bits that are used to mark Priority in many deployed
> networks. 

   I believe that is covered by:
" 
" ...implement that effect by marking ECN-capable traffic "Congestion
" Experienced (CE)"

since the same traffic can indeed be ECN-capable at one point of the
path followed but not another. (Nonetheless, word-smithing may help...)

> I think that it is important to emphasize that ECN marking for end
> points to notify source nodes don't work well in very large networks. 

   I don't follow your point here. There are cases where ECN marking
may not work very well, but I don't see any correlation to the size
of the network. (ECN signals reach a receiving endpoint unless something
is broken.)

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 29 Apr 2013 22:28:59 +0000

> of the network. (ECN signals reach a receiving endpoint unless

[Linda] Congestion can be transient. For a network with many hops, the congestion might not exist anymore by the time the Source nodes receive the notification from the end points. 
When many source nodes throttle back traffic (or control ingress rate) for transient congestion, network oscillation can occur, which is not good. 

Network can perform much better if there are two different types of congestion marking, one for transient congestion, and another one for congestion caused by "hard degradation" (e.g. LAG link member failure, or microwave link bandwidth being reduced due to weather, etc). 

Linda

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 29 Apr 2013 23:36:18 +0000

On Apr 29, 2013, at 3:28 PM, Linda Dunbar <[email-masked]> wrote:

> [Linda] Congestion can be transient.

>From my perspective, network congestion is almost always transient; non-transient congestion is an outage or should be. Operators tend to measure on time scales of 300 ms, for reasons related to the tool (MRTG) commonly used to measure it. But congestion on the time scale of a TCP session is measured in RTTs, which are on the order of milliseconds to hundreds of milliseconds.

The direction you are arguing suggests that there is no value in TCP Congestion Control, for the simple reason that in the next RTT a given TCP may have nothing more to send. I hope that's not what you mean, because that doesn't square very well with measurable reality. It is true that sessions are predominantly short, and short sessions add a lot of noise to any measurement. However, the actual traffic is predominantly from longer sessions, and absent congestion control in one form or another would drive the network into congestive collapse.

If you believe that there is value in congestion control, the question on the table is whether there is value in explicit vs implicit signaling.

> For a network with many hops, the congestion might not exist anymore by the time the Source nodes receive the notification from the end points. 

Hops are irrelevant, in my view. What is relevant is the duration of sessions and of RTTs. I can show you the same behavior in many-hop and few-hop networks.

> Network can perform much better if there are two different types of congestion marking, one for transient congestion, and another one for congestion caused by "hard degradation" (e.g. LAG link memb…

That might be ECN and loss?

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 30 Apr 2013 12:29:37 -0400

> Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.2? This is the question of signaling to an endpoint using both dropping and E…

I think there are two recommendations embedded at the end of the
section:

"""
   Hence, network communication to the host regarding the moderation of
   its traffic flow SHOULD use an AQM algorithm to determine which
   packets it should affect, and then implement that effect by marking
   ECN-capable traffic "Congestion Experienced (CE)" or dropping non-
   ECN-capable traffic.

   Due to the possibility of abuse, the queue must also impose an upper
   bound, so that even ECN-capable traffic experiences tail-drop if
   necessary; this possibility, while equipment must design for the end
   case, should in theory be very uncommon.
"""

I'm basically good with both.

The second part (imposing an upper bound) might be worth expanding a
bit.  I don't know what a reasonable upper bound is, for failing into
a tail-drop mode, and it smells like another knob to be configured,
which we are hoping to avoid :).

So, there is a can of worms here.  Should the threshold be configurable?
Should it be based on some margin computed from the queue depth, link
rate, etc?  What should the defaults be?  What types of experiments
would we do in order to test sensitivity of this parameter and tune it?

I think all of these depend a bit on how the specific AQM works, and
it's tough to say much concrete about it.

-- 
Wes Eddy
MTI Systems

---

From: Dave Taht <[email-masked]>
Date: Tue, 30 Apr 2013 09:40:15 -0700

On Tue, Apr 30, 2013 at 9:29 AM, Wesley Eddy <[email-masked]> wrote:
>    bound, so that even ECN-capable traffic experiences tail-drop
"drop"

if
> I'm basically good with both.

As soon as ECN markings are widely deployed and AQMs are widely
deployed that use it, attacks will use ECN marked packets. A
reflection attack like the recent DNS attacks for example, would do
more damage with ECN based AQMs than AQMs with ECN off.

> a tail-drop mode,

No reason to specify "tail" drop here.

> and it smells like another knob to be configured,

It's not just a knob but another state to track in the AQM.

> would we do in order to test sensitivity of this parameter and tune it?

In the codel related experiments I found no operating point that made
sense for marking vs dropping other than equal. ECN marking at less
than the drop point resulted in ECN streams being outcompeted by drop
based tcp. ECN marking at more than resulted in the reverse.

I found some uses for ECN inside well protected networks on things
other than TCP, and for TCP at high rates, also inside well protected
networks.

Across the wild and wooly internet I do not have a lot of hope for
ECN. It has proved mildly useful on ingress into a network domain and
a hindrance on bandwidth limited egress, and in neither case copes
with the easy possibilities of abuse.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 30 Apr 2013 17:05:40 +0000

> it's tough to say much concrete about it.

Hmm. Maybe I should separate them into separate recommendations.

Yes, I think ECN has the built-in possibility of an end system using the flag to gain what it thinks is some variation on preference - it can get one more packet into a queue than it would if it didn't advertise an ECN capability, but it doesn't actually implement RFC 3168 etc. At some point, one has to drop even ECN-capable traffic. Not for AQM reasons; for defensive reasons.

I have, and dare I say "we have", observed several implementations that have tried the approach of bending the rules to gain preference. BitTorrent did so by having multiple parallel aggressive TCP-like connections; we all know the outcome of that - multiple connections is fine, but bulldozing networks is a good way to get yourself bulldozed. One TCP implementation I know of did away with slow start and congestion control altogether. Guess what happened; a repeat of the 56 KBPS NSFNET in a more confined environment. If such implementations become at all widespread, and that one did within the company that wrote it, it gets to compete with itself, and it's not a pretty sight. There are other ways to deal with that kind of thing than "we who are wise thumb our collective noses in your general direction". In the end, money talks, and customers prefer networks that work and transport implementations that work in those networks.

I personally don't have a problem with the *ability* to configure something; where I think we have issues is the *necessity*. On your other questions, I might refer you to the sixth recommendation; if we don't have papers that tell us that, let's write some.

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 30 Apr 2013 13:49:43 -0400

On 4/30/2013 1:05 PM, Fred Baker (fred) wrote:
> Yes, I think ECN has the built-in possibility of an end system using
> the flag to gain what it thinks is some variation on preference - it
> can get one more packet into a queue than it would if it didn't
> advertise an ECN capability, but it doesn't actually implement RFC
> 3168 etc. At some point, one has to drop even ECN-capable traffic.
> Not for AQM reasons; for defensive reasons.
> 
> I have, and dare I say "we have", observed several implementations
> that have tried the approach of bending the rules to gain preference.
> BitTorrent did so by having multiple parallel aggressive TCP-like
> connections; we all know the outcome of that - multiple connections
> is fine, but bulldozing networks is a good way to get yourself
> bulldozed. One TCP implementation I know of did away with slow start
> and congestion control altogether. Guess what happened; a repeat of
> the 56 KBPS NSFNET in a more confined environment. If such
> implementations become at all widespread, and that one did within the
> company that wrote it, it gets to compete with itself, and it's not a
> pretty sight. There are other ways to deal with that kind of thing
> than "we who are wise thumb our collective noses in your general
> direction". In the end, money talks, and customers prefer networks
> that work and transport implementations that work in those networks.
> 
> I personally don't have a problem with the *ability* to configure
> something; where I think we have issues is the *necessity*. On your
> other questions, I might refer you to the sixth recommendation; if we
> don't have papers that tell us that, let's write some.

This all makes sense to me.  I definitely think that splitting /
factoring-out the part about reverting to tail-drop is a good idea.

Note that if you have the ability to configure something, it should
be necessary for some sane default to be available, either so that
you don't have to touch it, or can easily revert back after you make
the mistake of touching it.

-- 
Wes Eddy
MTI Systems

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 30 Apr 2013 22:17:53 +0000

Wes, 

>    ECN-capable traffic "Congestion Experienced (CE)" or dropping non-

[Linda] Do you mean that downstream nodes treat packets with ECN bits marked differently than that packets whose ECN bits are not marked? 
In another words, is "congestion experienced (CE)" encoded in the packets? 

Thanks, Linda