Subject: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03

From: Bob Briscoe <[email-masked]>
Date: Fri, 19 Oct 2012 18:29:36 +0100

Ken & Piers,

I finally got round to reviewing this draft.

1/ Where you refer to RFC6679 as more fine-grained information than 
TCP, you might want to refer to this one too, which the Vancouver 
TCPM meeting agreed to include in the TCPM charter:
<http://tools.ietf.org/html/draft-kuehlewind-tcpm-accecn-reqs-00.txt>

There are currently two possible proposals to satisfy these requirements:
<http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-01.txt>
<http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option-01.txt>

S.3.1
"  TFRC ... is seeing ... deployment in .... Empathy/Farsight, and 
GoogleTalk [googl].

    However it should be noted that TFRC is only recommended for real-time
    media use with ECN response. TFRC is not recommended for non-ECN paths
    due to its loss based operation which leads to full queues with
    maximised latencies.
"

Are you saying Empathy/Farsight and GoogleTalk only recommend TFRC if 
with ECN, or is this document doing the recommending?

"It is assumed that ECN markings will usually occur
    with lower queue occupancy and thus lower latency. "

That can't be right. RFC3168 insists that an AQM signals ECN where it 
would otherwise have signalled a drop for a non-ECN packet. There is 
only one queue for them both, so the occupancy has to be the same for 
both to satisfy RFC3168.

The whole point of the RFC3168 requirement is to ensure that non-ECN 
cannot starve ECN traffic. If an AQM were to mark ECN traffic at a 
shorter queue length, then non-ECN traffic would drive up the (same) 
queue length to the larger non-ECN operating point, and the algo 
would be marking ECN traffic with a lot higher probability than 
non-ECN. ECN would then starve itself given RFC3168 insists an ECN 
transport is meant to react to a mark as if it were a drop.

This assumption seems to be the justification for TFRC being 
appropriate for ECN, where it might not be for non-ECN. If the 
assumption isn't correct, where does that leave the main message of 
the document?

S.5.2 Fault Tolerance
I don't see why either redundant (duplicate) transmission or FEC are 
relevant to a document about using ECN, as opposed to loss, for 
congestion signalling.

S.5.3
I wholly agree that flows that consider themselves important could 
use a substantially less aggressive back-off. But I complete 
exemption is of great concern to me. Therein lies a congestion 
collapse. There is no need for complete exemption, if a flow can 
respond very little to congestion. At least then if congestion gets 
really bad, it will still respond a lot. But if congestion is not so 
bad, it will seem pretty much unresponsive.

I know you report experiments where ECN exemption has limited effect 
on normal flows, but the experiments assume low numbers of exempt 
flows relative to non-exempt. Each individual flow cannot know 
whether that assumption holds, so making this assumption is a recipe 
for boiling a network during an emergency - just when we need it most.

S.5.3
"  This applies to all
    flows that utilize some form of the rate control that is inversely
    proportional to the loss rate, which includes TCP-like algorithms or
    equation-based approaches.
"
s/inversely proportional to/inverse in some degree to/

"Inversely proportional to" means rate = k/p,
where p is loss probability and k is a constant
TCP New Reno    rate = k/p^0.5
TFRC            rate = k/p^0.5
TCP Cubic       rate = k/p^0.75
Compound TCP    rate = k/p^0.8
None have       rate = k/p

S.5.3. penultimate para:
I don't see how the normal flows can have a different latency from 
the exempt flows. If they all share the same queue, they all see the 
same latency at any one time. Certainly the average latency may be 
different for long-running flows that are present during times when 
shorter flows are there and when they are not. But the 
_instantaneous_ latency will be the same for any flows sharing a single queue.

Nits:
S.3. s/to quickly/too quickly/

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Piers O'Hanlon <[email-masked]>
Date: Tue, 23 Oct 2012 16:19:24 +0100

Hi Bob,

Thanks for the review. Comments inline.

On 19 Oct 2012, at 18:29, Bob Briscoe wrote:

> 1/ Where you refer to RFC6679 as more fine-grained information than TCP, you might want to refer to this one too, which the Vancouver TCPM meeting agreed to include in the TCPM charter:
Sure.

> S.3.1
> "  TFRC ... is seeing ... deployment in .... Empathy/Farsight, and GoogleTalk [googl].
> 
> Are you saying Empathy/Farsight and GoogleTalk only recommend TFRC if with ECN, or is this document doing the recommending?
> 
We're just saying that TFRC has seen some [partial] deployment in Empathy/Farsight and GoogleTalk. We suggested in the draft that if you're going use TFRC then one should use TFRC with ECN.

> That can't be right. RFC3168 insists that an AQM signals ECN where it would otherwise have signalled a drop for a non-ECN packet. There is only one queue for them both, so the occupancy has to be the same for both to satisfy RFC3168.
> 
> The whole point of the RFC3168 requirement is to ensure that non-ECN cannot starve ECN traffic. If an AQM were to mark ECN traffic at a shorter queue length, then non-ECN traffic would drive up the (same) queue length to the larger non-ECN operating point, and the algo would be marking ECN traffic with a lot higher probability than non-ECN. ECN would then starve itself given RFC3168 insists an ECN transport is meant to react to a mark as if it were a drop.
> 
> This assumption seems to be the justification for TFRC being appropriate for ECN, where it might not be for non-ECN. If the assumption isn't correct, where does that leave the main message of the document?
> 
Sure - when comparing an ECN enabled RFC3168 compliant queue with and without ECN. However it depends whether the queue complies with RFC3168 - there are a number of alternative approaches using ECN but not compliant to RFC3168 - such as DCTCP and others. Also there is quite a bit of leeway in the definition of the AQM behaviour in RFC3168. But if one is comparing an RFC3168 queue using ECN against against a drop-tail queue then the ECN/RFC3168 queue is generally more favourable to real-time flows due to the probabilistic nature of the marking/dropping.

But to be fair you have a point in the case of a direct comparison of RFC3168 ECN or drop.  I think that the more important aspect of using ECN is that it provide for back-off before loss occurs - allowing for flows to adapt earlier and minimise loss.

> S.5.2 Fault Tolerance
> I don't see why either redundant (duplicate) transmission or FEC are relevant to a document about using ECN, as opposed to loss, for congestion signalling.
> 
Well one could take a variety of actions on the reception of ECN (or loss) - the 3GPP specs suggest some interesting things... We've mentioned them as they're one of many possibilities.

> S.5.3
> I wholly agree that flows that consider themselves important could use a substantially less aggressive back-off. But I complete exemption is of great concern to me. Therein lies a congestion collapse. There is no need for complete exemption, if a flow can respond very little to congestion. At least then if congestion gets really bad, it will still respond a lot. But if congestion is not so bad, it will seem pretty much unresponsive.
> 
True complete exemption probably should not be generally used.

> I know you report experiments where ECN exemption has limited effect on normal flows, but the experiments assume low numbers of exempt flows relative to non-exempt. Each individual flow cannot know whether that assumption holds, so making this assumption is a recipe for boiling a network during an emergency - just when we need it most.
> 
The simulations are of flows that have finite rate limits - so the exempt can take all the bandwidth they need, leaving the rest to be shared amongst the non-exempt flows.

> s/inversely proportional to/inverse in some degree to/
Sure - we should add some 'approximate' qualification to that statement.

> I don't see how the normal flows can have a different latency from the exempt flows. If they all share the same queue, they all see the same latency at any one time. Certainly the average latency may be different for long-running flows that are present during times when shorter flows are there and when they are not. But the _instantaneous_ latency will be the same for any flows sharing a single queue.
> 
Yes the delay incurred on the shared bottleneck queue is the same for all flows, however relatively 'higher delay' seen by the exempt flows but it is actually mostly in the sender node transmit queue (which is the normal situation in this general scenario). That is where queuing should be occurring most of the time as the access link (1Mb/s) is lower than the backhaul link (100Mb/s) - it is in effect the bottleneck queue. So the situation of higher delays is actually the norm and only when ECN marking kicks in on the backhaul link does it actually lead to reduced delays for those flows responding to the marking - reducing their rate - and thus their delay. But the exempt flows that don't react to the marking continue with their normal higher delay. The queue in the backhaul link does build once the combined rates of the node exceeds the backhaul capacity but as the other nodes are ECN enabled they reduce their rate so that queue doesn't build beyond the [RED] queue marking thresholds.

> S.3. s/to quickly/too quickly/
Thanks,

Piers.

---

From: ken carlberg <[email-masked]>
Date: Tue, 23 Oct 2012 09:45:02 -0400

Bob,

thanks for the review.  I'll take a stab at some of the comments, and leave some fo the others for Piers to respond to (or correct me where he may have a different opinion :-)

> <http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option-01.txt>

Agreed.  Under the context you mention in terms of more granular information, it sounds good to add text and the references to the above.

> I don't see why either redundant (duplicate) transmission or FEC are relevant to a document about using ECN, as opposed to loss, for congestion signalling.

Its relevant in the sense that it is a *type* of reaction from the ECN signaling.  One vendor has told me in private that they have a preference for this approach, and I think its of value because it introduces the reaction on an ass needed basis instead of from the very begining and through the session.  But the gist of your concern is taken and we should probably add text that if this kind of reaction is taken, which would increase offered load, then an additional reaction (eg, employing CC algorithm, swapping to a lower load codec) should/must also be taken.

> I know you report experiments where ECN exemption has limited effect on normal flows, but the experiments assume low numbers of exempt flows relative to non-exempt. Each individual flow cannot know…

points well taken.  Within the context of the IETF, ETS is a generic term for preferential services that are deployed in some form in some of today's cellular networks.  And the numbers in terms of percentage of ETS users we used in our simulation are reflective at a very high and abstract level of what exists today in some cases.  (I'm sorry to be hand wavy, but I'm trying to be careful in my statements).

And we also agree that individual flows from the end-host/UE perspective will not know what percentage of exempt users co-exist in the same "area" where congestion has occured.  This is why we added the word "authorized" to help distinguish the two sets in that some added element needs to exist to help minimize the set of exempt users.

We also would agree that it would be preferable to have a less aggressive back-off algorithm for these otehrs users -- particularly in the case of typically higher bandwidth video users.  There is an ITU document that is also discussing this same topic.

One thing to keep in mind is that the Reactions draft isn't meant to be a recommendation of what should be done.  Its means to be information and point out what can be done.  However, I think the section can be improved a bit to make sure the concern you bring up above is well understood.

> Compound TCP    rate = k/p^0.8

okey dokey

and thanks again for the comments.

-ken

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 23 Oct 2012 19:22:11 +0100

Ken,

At 14:45 23/10/2012, ken carlberg wrote:
>Bob,
>
>thanks for the review.  I'll take a stab at some of the comments, 
>and leave some fo the others for Piers to respond to (or correct me 
>where he may have a different opinion :-)

> > S.5.2 Fault Tolerance
> > I don't see why either redundant (duplicate) transmission or FEC 
> are relevant to a document about using ECN, as opposed to loss, for 
> congestion signalling.
>
>Its relevant in the sense that it is a *type* of reaction from the 
>ECN signaling.  One vendor has told me in private that they have a 
>preference for this approach, and I think its of value because it 
>introduces the reaction on an ass needed basis instead of from the 
>very begining and through the session.  But the gist of your concern 
>is taken and we should probably add text that if this kind of 
>reaction is taken, which would increase offered load, then an 
>additional reaction (eg, employing CC algorithm, swapping to a lower 
>load codec) should/must also be taken.

I clearly don't understand what S5.2 is about (which may be taken as 
a hint that the doc probably needs to explain better). I still don't 
get it... redundancy & FEC fix loss. ECN isn't a loss, so why would 
anyone trigger a redundant transmission or FEC after an ECN mark?

> > S.5.3
> > I wholly agree that flows that consider themselves important 
> could use a substantially less aggressive back-off. But I complete 
> really bad, it will still respond a lot. But if congestion is not 
> so bad, it will seem pretty much unresponsive.
> >
> > I know you report experiments where ECN exemption has limited 
> effect on normal flows, but the experiments assume low numbers of 
> exempt flows relative to non-exempt. Each individual flow cannot 
> know whether that assumption holds, so making this assumption is a 
> recipe for boiling a network during an emergency - just when we need it most.
>
>points well taken.  Within the context of the IETF, ETS is a generic 
>term for preferential services that are deployed in some form in 
>some of today's cellular networks.  And the numbers in terms of 
>percentage of ETS users we used in our simulation are reflective at 
>a very high and abstract level of what exists today in some 
>cases.  (I'm sorry to be hand wavy, but I'm trying to be careful in 
>my statements).
>
>And we also agree that individual flows from the end-host/UE 
>perspective will not know what percentage of exempt users co-exist 
>in the same "area" where congestion has occured.  This is why we 
>added the word "authorized" to help distinguish the two sets in that 
>some added element needs to exist to help minimize the set of exempt users.

Even if you're talking about authorized users, if you get an 
emergency, you might get an influx of authorized users into an area 
to deal with the emergency. I don't need to teach granny that the 
main characteristic of emergencies is unpredictability.

>We also would agree that it would be preferable to have a less 
>aggressive back-off algorithm for these otehrs users -- particularly 
>in the case of typically higher bandwidth video users.  There is an 
>ITU document that is also discussing this same topic.
>
>One thing to keep in mind is that the Reactions draft isn't meant to 
>be a recommendation of what should be done.  Its means to be 
>information and point out what can be done.  However, I think the 
>section can be improved a bit to make sure the concern you bring up 
>above is well understood.

Yup, certainly.

>and thanks again for the comments.

No problem. Now on to Piers's

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 23 Oct 2012 19:49:46 +0100

Piers,

> > Are you saying Empathy/Farsight and GoogleTalk only recommend 
> TFRC if with ECN, or is this document doing the recommending?
> >
>We're just saying that TFRC has seen some [partial] deployment in 
>Empathy/Farsight and GoogleTalk. We suggested in the draft that if 
>you're going use TFRC then one should use TFRC with ECN.

[BB]: My point was merely to suggest you clarify the text - putting 
'recommended' in the passive voice makes it unclear whether you or 
Google are doing the recommending.

> > That can't be right. RFC3168 insists that an AQM signals ECN 
> where it would otherwise have signalled a drop for a non-ECN 
> packet. There is only one queue for them both, so the occupancy has 
> to be the same for both to satisfy RFC3168.
> >
> > The whole point of the RFC3168 requirement is to ensure that 
> non-ECN cannot starve ECN traffic. If an AQM were to mark ECN 
> traffic at a shorter queue length, then non-ECN traffic would drive 
> up the (same) queue length to the larger non-ECN operating point, 
> and the algo would be marking ECN traffic with a lot higher 
> probability than non-ECN. ECN would then starve itself given 
> RFC3168 insists an ECN transport is meant to react to a mark as if 
> it were a drop.
> >
>Sure - when comparing an ECN enabled RFC3168 compliant queue with 
>and without ECN. However it depends whether the queue complies with 
>RFC3168 - there are a number of alternative approaches using ECN but 
>not compliant to RFC3168 - such as DCTCP and others. Also there is 
>quite a bit of leeway in the definition of the AQM behaviour in RFC3168.

[BB]: I should have been clearer. The requirement of RFC3168 for the 
queue to behave equivalently for drop and ECN packets isn't just a 
quirk of RFC3168, it's very hard (impossible?) to avoid starvation of 
one or the other (ECN or non-ECN) unless the queue uses the same 
algorithm and parameters for both.

>  But if one is comparing an RFC3168 queue using ECN against against 
> a drop-tail queue then the ECN/RFC3168 queue is generally more 
> favourable to real-time flows due to the probabilistic nature of 
> the marking/dropping.

[BB]: Eh? There aren't two queues. There's only one. If there were 
two queues, it would be hard (impossible?) to know which one to serve 
by how much given packets sometimes arriving as  ECN and sometimes 
not - I suspect even an adaptive approach would just end up looking 
like a single FIFO.

I gave a presentation at the last IETF (Transport Area Plenary) about 
a possible way to get DCTCP/ECN to interwork with classic non-ECN 
traffic (well I would have, but I was cut short due to severe overrun 
of the previous speaker). Here's what I would have said:
<http://www.ietf.org/proceedings/84/slides/slides-84-tsvarea-3.pdf>

>But to be fair you have a point in the case of a direct comparison 
>of RFC3168 ECN or drop.  I think that the more important aspect of 
>using ECN is that it provide for back-off before loss occurs - 
>allowing for flows to adapt earlier and minimise loss.

[BB]: There is a more subtle sense in which ECN reduces latency. I 
just wrote it into the opening para of this draft I just posted:
<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines-01>

"  as ECN is
    used more widely by end-systems, it will gradually remove the need to
    configure a degree of delay into buffers before they start to notify
    congestion (the cause of bufferbloat).  The latter delay is because
    drop involves a trade-off between sending a timely signal and trying
    to avoid impairment, whereas ECN is solely a signal so there is no
    harm triggering it earlier.
"
This is an emergent property that would only happen if ECN became 
predominant, so that the optimum point to set AQM parameters was 
determined mostly by ECN users, not legacy (drop) users.

>Well one could take a variety of actions on the reception of ECN (or 
>loss) - the 3GPP specs suggest some interesting things... We've 
>mentioned them as they're one of many possibilities.

[BB]: I suggest there's no need to repeat things other people say 
unless they make sense. I still don't understand why these things make sense.

>True complete exemption probably should not be generally used.

[BB]: I agree, if you delete 'generally' :)

>The simulations are of flows that have finite rate limits - so the 
>exempt can take all the bandwidth they need, leaving the rest to be 
>shared amongst the non-exempt flows.

[BB]: As I said, this depends on an assumption about proportions.

> > S.5.3. penultimate para:
> > I don't see how the normal flows can have a different latency 
> from the exempt flows. If they all share the same queue, they all 
> see the same latency at any one time. Certainly the average latency 
> may be different for long-running flows that are present during 
> times when shorter flows are there and when they are not. But the 
>Yes the delay incurred on the shared bottleneck queue is the same 
>for all flows, however relatively 'higher delay' seen by the exempt 
>flows but it is actually mostly in the sender node transmit queue 
>(which is the normal situation in this general scenario). That is 
>where queuing should be occurring most of the time as the access 
>link (1Mb/s) is lower than the backhaul link (100Mb/s) - it is in 
>effect the bottleneck queue. So the situation of higher delays is 
>actually the norm and only when ECN marking kicks in on the backhaul 
>link does it actually lead to reduced delays for those flows 
>responding to the marking - reducing their rate - and thus their 
>delay. But the exempt flows that don't react to the marking continue 
>with their normal higher delay. The queue in the backhaul link does 
>build once the combined rates of the node exceeds the backhaul 
>capacity but as the other nodes are ECN enabled they reduce their 
>rate so that queue doesn't build beyond the [RED] queue marking thresholds.

[BB]: OK, I can see the point. I assume you are interpreting the 
results of a test or simulation here. I guess what you've actually 
got is a bottleneck shuttling between two points, so the explanation 
is a bit more complicated, but I get the idea.

>Piers.

Cheers

Bob

---

From: ken carlberg <[email-masked]>
Date: Tue, 23 Oct 2012 15:08:37 -0400

Bob,

> I clearly don't understand what S5.2 is about (which may be taken as a hint that the doc probably needs to explain better). I still don't get it... redundancy & FEC fix loss. ECN isn't a loss, so why would anyone trigger a redundant transmission or FEC after an ECN mark?

because its generally a fine line between the ECN marking and the point where one needs to acually drop the packet because of queue overflow (keeping in mind that we don't want huge queues for RTP flows).  We've done one simulation effort and a couple of implementations.  And in the latter case, it was a bit of a challenge to get that sweet spot of generating traffic (in our case, from an actual video feed) that triggered the ECN markings without overflowing the queue.  And even then, unless the feedback came back soon enough and there wasn't a continually added influx of flows from additional users (eg, a flash crowd), then the chances were quite good that some packets would be dropped after the initial CE feedback occured. If my application or session is considered mission critical, then using FEC in anticipation of lost packets and only done as needed versus the lifetime of the entire flowis a good thing.

We'll definitely have to add some text to clarify our thought process on this particular topic.

> Even if you're talking about authorized users, if you get an emergency, you might get an influx of authorized users into an area to deal with the emergency. I don't need to teach granny that the main characteristic of emergencies is unpredictability.

the numbers I've come across with today's deployed services in some cellular networks has shown that less than 1% within a cellular footprint are these "authorized" users.  In our simulations, we aimed at a worse case scenario of 10%.  And yes, unpredicability is still a cause for heartburn.  

cheers,

-ken

---

From: Piers O'Hanlon <[email-masked]>
Date: Tue, 23 Oct 2012 22:08:24 +0100

Bob,

On 23 Oct 2012, at 19:49, Bob Briscoe wrote:

> [BB]: My point was merely to suggest you clarify the text - putting 'recommended' in the passive voice makes it unclear whether you or Google are doing the recommending.
> 
Sure.

>> Sure - when comparing an ECN enabled RFC3168 compliant queue with and without ECN. However it depends whether the queue complies with RFC3168 - there are a number of alternative approaches using ECN but not compliant to RFC3168 - such as DCTCP and others. Also there is quite a bit of leeway in the definition of the AQM behaviour in RFC3168.
> 
> [BB]: I should have been clearer. The requirement of RFC3168 for the queue to behave equivalently for drop and ECN packets isn't just a quirk of RFC3168, it's very hard (impossible?) to avoid starvation of one or the other (ECN or non-ECN) unless the queue uses the same algorithm and parameters for both.
> 
Agreed.

>> But if one is comparing an RFC3168 queue using ECN against against a drop-tail queue then the ECN/RFC3168 queue is generally more favourable to real-time flows due to the probabilistic nature of the marking/dropping.
> 
> [BB]: Eh? There aren't two queues. There's only one. If there were two queues, it would be hard (impossible?) to know which one to serve by how much given packets sometimes arriving as  ECN and sometimes not - I suspect even an adaptive approach would just end up looking like a single FIFO.
> 
I was talking of a more of general comparison where one might consider running TFRC on a droptail based network vs another one than runs ECN enabled queues.

> I gave a presentation at the last IETF (Transport Area Plenary) about a possible way to get DCTCP/ECN to interwork with classic non-ECN traffic (well I would have, but I was cut short due to severe overrun of the previous speaker). Here's what I would have said:
> [BB]: There is a more subtle sense in which ECN reduces latency. I just wrote it into the opening para of this draft I just posted:
> This is an emergent property that would only happen if ECN became predominant, so that the optimum point to set AQM parameters was determined mostly by ECN users, not legacy (drop) users.
> 
Ok sounds good - though isn't one still limited by the BDP queue size needed to accommodate TCP flows?

> [BB]: I suggest there's no need to repeat things other people say unless they make sense. I still don't understand why these things make sense.
> 
You don't see why FEC makes sense as congestion reaction (or you're not keen on FEC in general)?

> [BB]: I agree, if you delete 'generally' :)
I thought you might say that!

Sure.

> [BB]: OK, I can see the point. I assume you are interpreting the results of a test or simulation here. I guess what you've actually got is a bottleneck shuttling between two points, so the explanation is a bit more complicated, but I get the idea.
> 
Right.

Cheers,

Piers

---

From: <[email-masked]>
Date: Wed, 24 Oct 2012 09:11:41 +0200

BB > S.5.2 Fault Tolerance
>> > I don't see why either redundant (duplicate) transmission or
     FEC are relevant to a document about using ECN, as opposed
     to loss, for congestion signalling.

P> Well one could take a variety of actions on the reception of ECN (
   or loss) - the 3GPP specs suggest some interesting things... We've
   mentioned them as they're one of many possibilities.

> [BB]: I suggest there's no need to repeat things other people say
  unless they make sense. I still don't understand why these things
   make sense.

[PO'H]You don't see why FEC makes sense as congestion reaction (or
      you're not keen on FEC in general)?

[RG] Not talking for Bob, just for me: ECN is used to inform senders,
that they cause congestion and should reduce rate. What you seemingly
propose to do by FEC or duplication is the opposite, increase the
load. I think to have read that Skype behaves like that. I also
recall that there was an early WLAN "QoS" implementation which
simply ignored the resource sharing mechanism and thus looked
for unfair advantage. If you are not aware of Bobs Conex efforts,
please read into that. To me, Conex seems to be a reasonable
approach to deal with senders reacting with FEC or duplication
on ECN signals.

[RG] To be constructive: if an application requires QoS with a
minimum bandwidth requirement scheme (would mean admission control
in the network), then go for a propper QoS class. I'd recommend
that for UDP flows without TFRC or any other possibility to
reduce rate.

[RG] ECN should be used to trigger a reduction of load. Sure
enough, also some RTP based applications benefit from ECN in that
sense. So there's a point in your draft.

Regards,

Ruediger

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 24 Oct 2012 18:59:24 +0100

Ken,

inline

At 20:08 23/10/2012, ken carlberg wrote:
>Bob,
>
> >> Its relevant in the sense that it is a *type* of reaction from 
> the ECN signaling.  One vendor has told me in private that they 
> have a preference for this approach, and I think its of value 
> because it introduces the reaction on an ass needed basis instead 
> of from the very begining and through the session.  But the gist of 
> your concern is taken and we should probably add text that if this 
> kind of reaction is taken, which would increase offered load, then 
> an additional reaction (eg, employing CC algorithm, swapping to a 
> lower load codec) should/must also be taken.
> >
> > I clearly don't understand what S5.2 is about (which may be taken 
> as a hint that the doc probably needs to explain better). I still 
> don't get it... redundancy & FEC fix loss. ECN isn't a loss, so why 
> would anyone trigger a redundant transmission or FEC after an ECN mark?
>
>because its generally a fine line between the ECN marking and the 
>point where one needs to acually drop the packet because of queue 
>overflow (keeping in mind that we don't want huge queues for RTP 
>flows).  We've done one simulation effort and a couple of 
>implementations.  And in the latter case, it was a bit of a 
>challenge to get that sweet spot of generating traffic (in our case, 
>from an actual video feed) that triggered the ECN markings without 
>overflowing the queue.  And even then, unless the feedback came back 
>soon enough and there wasn't a continually added influx of flows 
>from additional users (eg, a flash crowd), then the chances were 
>quite good that some packets would be dropped after the initial CE 
>feedback occured. If my application or session is considered mission 
>critical, then using FEC in anticipation of lost packets and only 
>done as needed versus the lifetime of the entire flowis a good thing.

The chances of much loss following ECN CE are, I assume, fairly low, 
so it seems very tenuous to be thinking of adding the complexity of 
FEC when a small amount of loss can probably be handled just fine.

> >> points well taken.  Within the context of the IETF, ETS is a 
> generic term for preferential services that are deployed in some 
> form in some of today's cellular networks.  And the numbers in 
> terms of percentage of ETS users we used in our simulation are 
> reflective at a very high and abstract level of what exists today 
> in some cases.  (I'm sorry to be hand wavy, but I'm trying to be 
> careful in my statements).
> >>
> added the word "authorized" to help distinguish the two sets in 
> that some added element needs to exist to help minimize the set of 
> exempt users.
> >
>the numbers I've come across with today's deployed services in some 
>cellular networks has shown that less than 1% within a cellular 
>footprint are these "authorized" users.  In our simulations, we 
>aimed at a worse case scenario of 10%.  And yes, unpredicability is 
>still a cause for heartburn.

I still think a nearly unresponsive algo would give you nearly 
exactly the same behaviour as exemption if 1% or 10% authorized users 
did happen, but it would still avoid boiling the network if you did 
get 90%. Whereas completely unresponsive would not.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 24 Oct 2012 19:09:50 +0100

Piers,

One response, plus two redirects to Ken's thread, inline...

> >> But to be fair you have a point in the case of a direct 
> comparison of RFC3168 ECN or drop.  I think that the more important 
> aspect of using ECN is that it provide for back-off before loss 
> occurs - allowing for flows to adapt earlier and minimise loss.
> >
> > [BB]: There is a more subtle sense in which ECN reduces latency. 
> I just wrote it into the opening para of this draft I just posted:

No. If ever ECN users become the large majority, you still have a BDP 
/buffer/ that can accomodate TCP, but it becomes an optimal 
compromise to set a much tighter threshold on the AQM. The few legacy 
TCP users would see loss earlier, but the majority (ECN) users who 
see ECN earlier don't care, because it's not an impairment, it's only 
a signal. So their short flows etc still finish quickly without timeouts etc.

> FEC are relevant to a document about using ECN, as opposed to loss, 
> for congestion signalling.
> >> >
> >> Well one could take a variety of actions on the reception of ECN 
> (or loss) - the 3GPP specs suggest some interesting things... We've 

Ken has answered this one, and I've responded in the other part of this thread.

>I thought you might say that!

Again, this discussion is progressing in the Ken thread.

---

From: ken carlberg <[email-masked]>
Date: Thu, 25 Oct 2012 07:06:12 -0400

On Oct 24, 2012, at 1:59 PM, Bob Briscoe wrote:

> 
> The chances of much loss following ECN CE are, I assume, fairly low, so it seems very tenuous to be thinking of adding the complexity of FEC when a small amount of loss can probably be handled just fine.

depends on the event causing the congestion.  my assumption is that the vast majority of these events are brief transitive events, and as you say, can be handled fine.  however, the events I get exposed to (eg, disasters, sudden weather events, sustained flash crowds) last from tens of minutes, hours, and even days, which is much too long for certain folks.  

> I still think a nearly unresponsive algo would give you nearly exactly the same behaviour as exemption if 1% or 10% authorized users did happen, but it would still avoid boiling the network if you did get 90%. Whereas completely unresponsive would not.

yes, a fair point, which we need to make clear in the document.

-ken

---

From: ken carlberg <[email-masked]>
Date: Thu, 25 Oct 2012 07:30:13 -0400

Understood.  I'll need to give some thought as to how to exactly convey these points about QoS into the draft.

As for Conex, I was one of the early ones arguing for its formation, though in truth, I hadn't thought about entwining it in some form to the Reactions draft.  Again, some more stuff I'll need to think about.

cheers,

-ken