Subject: [re-ECN] RE-ECN without ECN.

From: Matt Mathis <[email-masked]>
Date: Thu, 1 Oct 2009 12:36:34 -0400

Here is a fun little tidbit for people to think about, while others
resolve some of the non-technical issues surrounding launching the
conex.

For all modern reliable protocols over non-ECN networks (where loss is
the primary congestion indicator), the amount of duplicate data is a
direct measure of the down stream congestion.    (e.g. If I observe
both a data packet and its retransmission, then the first transmission
was lost someplace downstream).    This is because for all modern
protocols, the sender almost never sends data that the receiver
already holds.

If you add the assumption that the network itself does not reorder
packets, then the number of out-of-order packets is a direct measure
of the upstream congestion.  (e.g. the first transmission was lost,
and I see the retransmission).

This is sufficient information to implement many of the proposed uses
for RE-ECN marking.

For example, the bottleneck for problematic flows can be moved
upstream so that they are less disruptive to other users, by
throttling the amount of duplicate data permitted through an ingress
router.  In the extreme case, when a particular flow exceeds its quota
for duplicate data, you drop the retransmissions which will
(eventually) cause it to run out of receive window and take a timeout.
 More polite would be to pass the retransmission, but then discard the
next in-order packet on the same flow, normally causing it to slow
down.  There are some details to be worked out...

The point being that for non-encrypted standard transports, many
RE-ECN like things can be implemented unilaterally, without global
deployment of complicated, subtitle and hard to verify new protocol
features.

 Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://staff.psc.edu/mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

---

From: João Taveira Araújo <[email-masked]>
Date: Thu, 01 Oct 2009 22:37:12 +0100

Inline

> protocols, the sender almost never sends data that the receiver

Except it's not transport oblivious, so you'd have to a) redesign the 
solution for every new transport protocol or b) expect a single 
transport protocol to be all-encompassing. Won't nitpick since this is a 
thought experiment though...

> deployment of complicated, subtitle and hard to verify new protocol

You'd be missing one of the most important features however - that 
information is verifiable across borders by both parties. An ISP can 
throttle the duped packets, but why would it voluntarily hinder its 
customers when the downstream transit domain is unable to verify whether 
such enforcement is taking place?

Congestion may come from within the ISP itself, but I'm not certain the 
ISP can reliably infer the location of such congestion at the ingress. 
Something like multipath TCP would also make it very hard to figure out 
whether or not a packet is retransmitted ... which would make a great 
incentive for deploying  mtcp.

Joao.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 02 Oct 2009 16:43:05 +0100

Matt,

At 22:37 01/10/2009, João Taveira Araújo wrote:
>Except it's not transport oblivious, so you'd 
>have to a) redesign the solution for every new 
>transport protocol or b) expect a single 
>transport protocol to be all-encompassing. Won't 
>nitpick since this is a thought experiment though...
>

I think you mean a measure of e2e congestion, not upstream.

>>This is sufficient information to implement many of the proposed uses

It took me a while to unpick the subject line, 
but I understand now. You mean the network 
viewing e2e congestion with neither ECN nor re-ECN protocols.

A related reference (viewing e2e congestion with only ECN):
[Purple] Pletka, R., Waldvogel, M., and S. 
Mannal, “PURPLE: Predictive Active Queue 
Management Utilizing Congestion Information,” 
Proc. Local Computer Networks (LCN 2003) , October 2003.

>>(eventually) cause it to run out of receive window and take a timeout.

We ought to try to get consensus on whether 
network-based policing of the amount of 
congestion per flow is desirable. It's not a goal 
I think we should aim for - it enforces a 
transport monoculture completely unnecessarily, 
as it's surely neither needed nor effective for 
any 'reasonable' form of fairness.

Flow policing was indeed a use proposed for 
re-ECN (in our original SIGCOMM'05 paper). But we 
were conflicted over whether to include it. We 
ended up highliting it to pander to the SIGCOMM 
committee - I now wish we hadn't. Since then, 
we've written "The Case Against Bottleneck 
Policing" (S.3.1.2 of 
draft-briscoe-tsvwg-re-ecn-tcp-motivation-01) and 
I now find the whole idea of flow policing unneeded and actually harmful.

But let's not throw out the baby with the 
bathwater. There may be something in what you're 
saying, even if we disagree how it might be used.

>>down.  There are some details to be worked out...

I'm concerned that using a feature that a 
protocol exhibits when it is behaving (TCP 
retransmissions) in order to police misbehaviour 
of another aspect of the protocol (too much 
congestion) requires us to suspend too much 
disbelief. If I'm going to modify the protocol to 
misbehave in one way, I can modify the retransmission semantics too.

Rather than per flow policing, a better framing 
might be bulk policing over time. Targeting 
misbehaviour of single flows presumes someone has 
modified the code. Whereas targeting excessive 
congestion caused by excessive use of unmodified 
TCP(s) is lower hanging fruit. Whether for 
excessive amounts of data over time, or excessive numbers of flows all at once.

Certainly apps or users can work round a 
re-transmission-based bulk policer by not using 
TCP, but they then have to hack an alternative 
that still does all the reliable delivery (or use IPsec).

>>deployment of complicated, subtitle and hard to verify new protocol

I know what you're trying to achieve in terms of 
unlilateral deployment. However, I think this 
characterisation of re-ECN is a little uncharitable.
i) The point of the re-ECN design was that one 
network can deploy unilaterally without waiting 
for others, and one stack can deploy unilaterally 
without waiting for others. But you're right that 
not much can be achieved until a significant number of both have moved.
ii) re-ECN is designed for very simple verification (balance of two counters).
iii) I don't see complicated. I see simplicity 
relative to the complexity of any of the things 
it could replace, and the things that can't even be done at all any other way.

True, there might be simpler schemes that don't 
work, or can be bypassed. But network operators 
don't want the complexity of deploying many 
schemes one after the other as each one fails 
(they are driven to behave like this for lack of 
good solutions, but they don't want to).

Bob

>You'd be missing one of the most important 
>features however - that information is 
>verifiable across borders by both parties. An 
>ISP can throttle the duped packets, but why 
>would it voluntarily hinder its customers when 
>the downstream transit domain is unable to 
>verify whether such enforcement is taking place?
>
>Congestion may come from within the ISP itself, 
>but I'm not certain the ISP can reliably infer 
>the location of such congestion at the ingress. 
>Something like multipath TCP would also make it 
>very hard to figure out whether or not a packet 
>is retransmitted ... which would make a great incentive for deploying  mtcp.
>
>Joao.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Matt Mathis <[email-masked]>
Date: Fri, 2 Oct 2009 18:42:02 -0400

2009/10/2 Bob Briscoe <[email-masked]>:
>> solution for every new transport protocol or b) expect a single transport
>> protocol to be all-encompassing. Won't nitpick since this is a thought
>> experiment though...

Joao,
Which do you think is harder: adding duplicate data detection for a
new transport protocol to the ingress router or to get a (potentially
hostile) new transport to carry the ECN information on its ACKs?  (See
the ECI field for TCP Section 6.1.1 in -re-ecn-tcp- )   My bet that it
is a lot easier to add the duplicate detection to the ingress router,
since the owner is motivated to do so.

> I think you mean a measure of e2e congestion, not upstream.

Ok, It depends on how you define out-of-order when the packet is
duplicate.   Yea, perhaps your definition is better.

> It took me a while to unpick the subject line, but I understand now. You
> mean the network viewing e2e congestion with neither ECN nor re-ECN
> protocols.

Correct.

> [Purple] Pletka, R., Waldvogel, M., and S. Mannal, “PURPLE: Predictive
> Active Queue Management Utilizing Congestion Information,” Proc. Local
> Computer Networks (LCN 2003) , October 2003.

I will look it up.

> We ought to try to get consensus on whether network-based policing of the
> amount of congestion per flow is desirable. It's not a goal I think we
> should aim for - it enforces a transport monoculture completely
> unnecessarily, as it's surely neither needed nor effective for any
> 'reasonable' form of fairness.
>
> Flow policing was indeed a use proposed for re-ECN (in our original
> SIGCOMM'05 paper). But we were conflicted over whether to include it. We
> ended up highliting it to pander to the SIGCOMM committee - I now wish we
> hadn't. Since then, we've written "The Case Against Bottleneck Policing"
> (S.3.1.2 of draft-briscoe-tsvwg-re-ecn-tcp-motivation-01) and I now find the
> whole idea of flow policing unneeded and actually harmful.
>
> But let's not throw out the baby with the bathwater. There may be something
> in what you're saying, even if we disagree how it might be used.

I misspoke - although the duplicate detection has to be done per flow
(since it requires per-flow state) the enforcement can be done on any
aggregate.   These two functions could even be done in different
places, if for example the duplicate data detection was used to apply
a pseudo-re-feedback mark (DSCP codepoint?) that was enforced further
downstream.   This also permits the duplicate detection to be
parallelized across multiple processors (so flow state becomes less of
a problem) and the aggregate congestion to be limited after the
streams from the different duplicate detectors are merged.

>>> down.  There are some details to be worked out...

 BTW Discarding excessive retransmissions clearly can enforce a hard
policy on an aggregate: e.g. no more than x% duplicate data.  However,
from the users point of view, this is a bad thing because losing the
same segment twice most often causes timeouts, and has the effect of
greatly increasing the variance of the application performance, as
seen by the user.    One would expect that discarding a future segment
to be better behaved from the users perspective, but it requires flow
state (or at least flow matching) at the point where the dropping is
happening.  My sense is that this also has a RED-like tuning problem
(the dropper has to guess what loss rate is required to attain a
particular data rate or congestion rate).  If the duplicate data
detection and enforcement are separated, then there is the additional
problem that you would like to exclude the enforcement drops and
subsequent retransmissions from the down stream statistics being
monitored by the enforcement.

I still don't understand the RE-ECN analogue of this latter problem.
If some aggregate is causing too much congestion, how can the network
throttle it, without causing it to exhibit even more congestion?

> I'm concerned that using a feature that a protocol exhibits when it is
> behaving (TCP retransmissions) in order to police misbehaviour of another
> aspect of the protocol (too much congestion) requires us to suspend too much
> disbelief. If I'm going to modify the protocol to misbehave in one way, I
> can modify the retransmission semantics too.

Actually it is extracting information from TCP's mechanism to
implement reliable data delivery.  It is a tautology that downstream
losses cause reliable protocols send duplicate data.   My proposed
mechanism would even work if the transport protocol was not responding
to losses as congestion signals, as long as it continued to implement
reliable delivery.

> Rather than per flow policing, a better framing might be bulk policing over
> time. Targeting misbehaviour of single flows presumes someone has modified
> the code. Whereas targeting excessive congestion caused by excessive use of
> unmodified TCP(s) is lower hanging fruit. Whether for excessive amounts of
> data over time, or excessive numbers of flows all at once.

Yea, I'd like to understand what "bulk policing over time" might mean.
  One of the big pieces missing from "per flow fairness" schemes is a
reasonable way to make them average over long time periods.

> Certainly apps or users can work round a re-transmission-based bulk policer
> by not using TCP, but they then have to hack an alternative that still does
> all the reliable delivery (or use IPsec).
>
> I know what you're trying to achieve in terms of unlilateral deployment.
> However, I think its characterisation of re-ECN is a little uncharitable.

Sorry, I was a little harsh.

> i) The point of the re-ECN design was that one network can deploy
> unilaterally without waiting for others, and one stack can deploy
> unilaterally without waiting for others. But you're right that not much can
> be achieved until a significant number of both have moved.
> iii) I don't see complicated. I see simplicity relative to the complexity of
> any of the things it could replace, and the things that can't even be done
> at all any other way.

Consider pseudo-re-feedback as a possible deployment strategy for
RE-ECN.   One ISP can implement it unilaterally, and as real RE-ECN
gets deployed, the instrumentation and controls become more accurate.

> True, there might be simpler schemes that don't work, or can be bypassed.
> But network operators don't want the complexity of deploying many schemes
> one after the other as each one fails (they are driven to behave like this
> for lack of good solutions, but they don't want to).

Precisely the question I wanted to read for - what are the cases that
RE-ECN covers that pseudo-re-feedback can't address.

>> such enforcement is taking place?

I was actually thinking of the last ISP, peering with many "wholesale
ISPs" and having congested access networks feeding millions of  home
customers.   It would greatly help such an ISP to be able to discard
just enough traffic at it's ingresses from other ISP's to limit
congestion on its access links to its customers.   The whole problem
and my solution fall within a single ISP.

>> incentive for deploying  mtcp.

I'm sort of missing the point here, but I think some of the problems
that you are concerned about are the same for RE-ECN and others are
solved by separating  duplicate detection from enforcement.

Thanks,
--MM--

---

From: João Taveira Araújo <[email-masked]>
Date: Mon, 05 Oct 2009 18:49:34 +0100

> since the owner is motivated to do so.

I thought you were referring to the first, rather than last ISP, so I 
had construed your solution backwards, but even so doesn't this depend 
on the fate of non-re-ECN traffic? If non compliant traffic is treated 
in bulk as if it were misbehaving, the incentive would be for all 
transport protocols to adhere to re-ECN, in which case it wouldn't 
matter how hostile a transport protocol is, so long as it complies with 
the ISP's definition of acceptable behaviour [see Bob's ReArch paper].

Joao

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Oct 2009 11:51:31 -0700

On Oct 2, 2009, at 3:42 PM, Matt Mathis wrote:

>  My bet that it

is the presence of encrypted or tunneled data streams important here?

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Oct 2009 12:03:23 -0700

> and I see the retransmission).

The assumption concerns me. There are probably places in the Internet  
where loss is unusual and reordering is unusual, but making it a  
baseline assumption... The Internet is still a best effort service,  
which is to say that datagrams may be lost, duplicated, or reordered.

I personally am very much in favor of congestion signaling that  
doesn't involve loss, and supported the development of RFC 3168 as a  
result. I scratch my head on re-ecn - not opposed per se, but noting  
that there are issues with any traffic in which the flags may not be  
visible - tunnels especially come to mind - and in asking the first  
hop router to do something. What is a "first hop router"? Is it the  
CPE router, such as Linksys-etc, or the first ISP hop, or something  
else?

---

From: Matt Mathis <[email-masked]>
Date: Mon, 5 Oct 2009 17:26:34 -0400

> is the presence of encrypted or tunneled data streams important here?

Clearly, any encryption prevents peeking at sequence numbers and
generating pseudo re-feedback.  However, for RE-ECN, any non-ECN
receiver or non-re-ECN sender prevents re-feedback....   On day 1 loss
based re-feedback would be way ahead, even if it doesn't work
everywhere.

My hope that these two schemes might be unified.  One then becomes a
migration (bootstrapping?) strategy for the other.  I am also finding
that imagining a dual implementation (both loss based and ECN based
re-feedback) leads to a whole lot of clarity on many side issues.
Its got a much better chance of being deployable, because the
partially deployed states provide at least some of the function of
full deployment.

Thanks,
--MM--

---

From: Matt Mathis <[email-masked]>
Date: Mon, 5 Oct 2009 17:45:03 -0400

On Mon, Oct 5, 2009 at 3:03 PM, Fred Baker <[email-masked]> wrote:
> The assumption concerns me. There are probably places in the Internet where
> loss is unusual and reordering is unusual, but making it a baseline
> assumption... The Internet is still a best effort service, which is to say
> that datagrams may be lost, duplicated, or reordered.

Reordering is not insurmountable.   Network reordering is most often
bound by some fairly small maximum offset related to the number of
parallel paths or processing stripes.  Retransmissions are always
out-of-order by slightly more than one full window of data.   At small
window/low rates these are indistinguishable, but it probably isn't as
important  to get it right.   At higher rates, these are likely to be
different by an order of magnitude or more.  My hunch would be that a
pretty simple adaptive controller might do well enough.   Yes, more
research is needed.

> I personally am very much in favor of congestion signaling that doesn't
> involve loss, and supported the development of RFC 3168 as a result. I
> scratch my head on re-ecn - not opposed per se, but noting that there are
> issues with any traffic in which the flags may not be visible - tunnels
> especially come to mind - and in asking the first hop router to do
> something. What is a "first hop router"? Is it the CPE router, such as
> Linksys-etc, or the first ISP hop, or something else?

I agree all around.   Bob has been putting a lot of effort into making
sure that the specifications for tunnels say the right things.   What
I don't know is if there have been any measurements of the population
of devices that do busted things, such not updating the inner ECN bits
from the outer header on decapsulation.   (But note that this is
busted for all variants of ECN).

Thanks,
--MM--

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Oct 2009 15:05:58 -0700

On Oct 5, 2009, at 2:45 PM, Matt Mathis wrote:

> pretty simple adaptive controller might do well enough.

Well, yes, they are bounded, but that doesn't make them without effect.

Take for example one case that some of my customers report to be  
fairly common - the use of multiple parallel DSL, Frame Relay, or ect  
circuits at some point in their network. We have several ways of  
dealing with such, including both PPP Multilink (which tries to  
distribute load approximately evenly) and IP equal cost multipath  
routing. The latter can be used in a round-robin fashion or by hashing  
addresses as described in some RFC. the issue there is that in cases  
where reordering happens, it can be sustained for a while.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 06 Oct 2009 00:26:23 +0100

Matt,

> > At 22:37 01/10/2009, João Taveira Araújo wrote:
[snip]

>[MM]>>>  More polite would be to pass the retransmission, but then discard the
>[MM] BTW Discarding excessive retransmissions clearly can enforce a hard
>happening.

[BB] Like Joao said, first off we're just 
treating all the user's traffic together, so if 
the user as a whole is causing too much 
congestion, the policer shoots their packets 
randomly, not per flow. Then it can hit later 
packets without flow state. In the reArch paper 
Joao referred to, we show this gives the user an 
incentive to run a shadow policer to keep out of trouble.
<http://www.bobbriscoe.net/projects/refb/#polfree>

We just wanted to show that a really simple bulk 
congestion policer was sufficient (perhaps to 
deploy in a street cabinet in front of the 
upstream of a PoN or cable network at L2). The 
idea is if you done bad enough to get locked up 
in the cells overnight, you don't expect a 
gift-wrapped mint on your pillow. But we have a 
less harsh design with flow state too.

>[MM] My sense is that this also has a RED-like tuning problem
>particular data rate or congestion rate).

[BB] We've added a ramp (increasing) drop 
probability at the bottom of the bucket, rather 
than a hard threshold, and it seems to find a 
stable level. Obviously more tests will be needed.

There were papers in the past describing how rate 
policing tended to make TCP oscillate. So far 
we're finding that congestion policing seems to 
be a lot nicer to TCP. I think it's because 
policing is done on markings which are introduced 
randomly by congestion elsewhere, whereas a rate 
policer is locally deterministic.

Rather than describe it all here tho, it's 
probably best to wait for us to finish the 
experiments & write up the results, which should be in the next months.

>[MM] If the duplicate data

[BB] Our latest policer design includes a way for 
the transport to re-echo congestion drops but not 
policer drops. We've added a subtle way for the 
policer to signal in-band that any drops are 
probably due to policing, not congestion. Also 
the policer doesn't drop the packet carrying the 
marking that first empties the bucket, so there's 
no bias against the packets that happen to carry the markings.

We haven't added this to the protocol draft 
(re-ecn-tcp) yet, or to the implementation. 
Before putting this in the draft, I'm currently 
working out whether this signalling can be used 
generically for any policy drop, not just by congestion policers.

Here's an outline: If a re-echo (aka black or 
positive marking) empties the policer bucket, the 
policer removes the re-echo marking and forwards 
the packet, *then* it increases the drop 
probability ready for the next packet.

Re-echo markings are meant to be immutable e2e, 
so the transport can check the integrity of them 
(this requires additional transport feedback that 
we would have to add to re-ECN's TCP mechanism). 
When the transport notices re-echo marks are 
being removed, it stops re-echoing on drop, and only re-echoes on ECN feedback.

We haven't worked out the details of this yet tho.

>[BB] > I'm concerned that using a feature that a protocol exhibits when it is
>[MM] Actually it is extracting information from TCP's mechanism to

[BB] I didn't mean that. I'm saying TCP can do 
reliabile delivery without doing it exactly like 
now. Imagine I plan to re-code my TCP not to 
respond to congestion. If the network is 
accounting for congestion by detecting 
retransmissions, while re-coding I will just 
change both{*} ends to obfuscate sequence 
numbers. I just have to apply some reversible 
transformation keyed on a shared secret to the 
sequence numbers and I'm done. Or actually 
easier, I will be driven to use IPsec.

{*} A strength of your idea is that both ends 
have to be changed to alter TCP's reliability 
mechanism, while the sender alone can alter the congestion response.

>[BB] > Rather than per flow policing, a better 
>framing might be bulk policing over
>[MM] Yea, I'd like to understand what "bulk policing over time" might mean.

[BB] That's why I was happy with the big token 
bucket in the reArch paper mentioned earlier. It 
can allow a lot of leeway in the short term, but 
the user has the incentive to be friendly to 
others on average. How tight or loose all depends on the choice of parameters:
<http://www.bobbriscoe.net/projects/refb/#polfree>

>[MM] Consider pseudo-re-feedback as a possible deployment strategy for

[BB] Certainly.

I still worry it's TCP-only, so could cause a 
backlash against TCP as a whole. In trying to 
sort out fairness, we mustn't risk losing the 
dynamics of TCP that protect against congestion collapse.

Recently (prompted by Mark Handley) I've been 
thinking of re-ECN being deployed voluntarily by 
the end-points first (particularly those like 
LEDBAT that want to prove they are causing *less* 
congestion than others). Then networks deploy ECN 
to prove to their neighbours that congestion had 
already occurred before passing the traffic across a border.

Given re-ECN is trying to encourage everyone to 
co-operate more, there's merit in thinking of 
deployment strategies that start with the 
endpoints yielding, rather than networks constraining first.

>[BB] > True, there might be simpler schemes that 
>don't work, or can be bypassed.
>[MM] Precisely the question I wanted to read for - what are the cases that

[BB] like Joao said:
- non-reliable transports
- the ability to see how much congestion is each side of a border

And I've added:
- reliable transports that morph in response to being detected

> > Bob
> >
> >
>[JTA] >> You'd be missing one of the most important features however - that
>[MM] I was actually thinking of the last ISP, peering with many "wholesale

[BB] Oooh. This is getting close to sending TCP 
resets to off-net connections isn't it?! The 
congestion is caused as much by the whole set of 
traffic in the access network's queues - not just 
off-net traffic but on-net too.

This hilites the Internet's problem - we have an 
internetwork where off-net traffic is somehow 
perceived as less worthy. One of the aims of 
re-ECN is to ensure that this access net can 
treat incoming traffic as if it is as valuable as 
on-net traffic. Visible congestion information at 
borders can be used in contracts & settlements 
between networks so they can recompense each 
other if costs don't balance, rather than 
dropping traffic - dropping is an admission of failure to my mind.

It's not good business to throw away traffic 
without knowing whether it would be willing to pay to be spared!

>[JTA] >> Congestion may come from within the ISP 
>itself, but I'm not certain the ISP can reliably 
>infer the location of such congestion at the ingress.

[BB] I think Joao's saying:
a) that on-net traffic as well as off-net causes congestion in the access
b) that dup detection reveals e2e congestion, so 
it doesn't say whether the congestion the 
arriving packet reveals is in the access net, or off-net elsewhere.

On the other hand, re-ECN doesn't just expose e2e 
congestion, it also exposes how much congestion is downstream of the border.

>[JTA] >> Something like multipath TCP would also 
>make it very hard to figure out whether or not a 
>packet is retransmitted ... which would make a great
>[MM] I'm sort of missing the point here, but I think some of the problems

[BB] I think Joao is conjecturing that you could 
design an MTPCP where retransmissions were sent 
on different paths to the original loss - in such 
a way they couldn't be identified as 
retransmissions. This could thwart your idea.

With re-ECN the deal the net gives is "Tell me 
how much congestion you are causing (on each 
sub-path), otherwise I'll drop your traffic (from 
each sub-path) before it gets to the destination. 
Having made you truthful, if you say you are 
causing excessive congestion (across all 
traffic), I'll drop your traffic to limit how much congestion you can cause."

With dup detection, the deal is "If I can work 
out how much congestion you're causing from the 
dups (in each sub-flow), and if it's excessive 
(across all traffic), I'll drop traffic to limit 
how much congestion you can cause."

Sorry about the long response.

HTH

Cheers

Bob

---

From: "Don Bowman" <[email-masked]>
Date: Mon, 5 Oct 2009 22:22:06 -0400

On Mon, Oct 5, 2009 at 5.45 PM, Matt Mathis wrote:
> where

One thing to watch out for is hand-off conditions. E.g. in a mobile
network, handing from one cell to another, or one carrier to another,
can cause some re-ordering w/o loss. Also, periodically you run into
a network which balances by packet rather than flow, or balances
by flow on something which isn't stable and flops back and forth.
Typically OSPF ECMP does a L3(or L4) hash to select a link, but sometimes
that hash is of an 'outer' ip which is not relevant to the inner content,
and thus reordering occurs.

... snip ...

> busted for all variants of ECN).

Again to the mobile network. One of the most (variably) congested networks
out there is the mobile backhaul network. In 3GPP, this is carried in a
tunnel type called GTP-U. I've not found GTP-U implementations to be
much for moving markings from outer to inner (e.g. DSCP). I've done
a quick check on a couple of networks, and did not observe ECN marked
on the inner, so i can't say if they support ECN 'moving the mark'.

One of the things i am hopeful to use re-ECN for in our products is
as an indication of backhaul health (and i dream someday of RF health)
so that we can break reporting information down by 'this is what
congested/near-congested/non-congested links are doing'. So i'm
hopeful it can be made to work in GTP-U (which implies getting
ECN basis working).

--don

---

From: <[email-masked]>
Date: Thu, 8 Oct 2009 11:59:58 +0100

[phil] one follow-up on the comment below about GTP-U tunnels. Getting
congestion marking correct for tunnels other than IP/IPsec is certainly
important - I guess in general that has to be taken up with other
standards bodies. There is some guidance in an earlier version of Bob's
tunnel draft about guidelines for what needs to be done for a generic
tunnel type; it disappeared in more recent versions (in order to focus
on ietf specifics). I think it might be worth resurrecting this content
at some point - maybe once the tunnel draft has progressed in ietf
(currently, it's nearly done in tsvwg [I think!])
phil

> busted for all variants of ECN).

Again to the mobile network. One of the most (variably) congested
networks

--don

_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn