subject:"\[Cerowrt\-devel\] \[Bloat\] DOCSIS 3\+ recommendation\?"

Folks,

I think I have just seen this statement a little too often:

> That’s right, Jim. The “some packet loss is good” part is from what I have 
> seen the hardest thing for people to understand. People have been trained to 
> believe that any packet loss is terrible (..)

I understand the "wrong mindset" thing and the idea of AQM doing something 
better. Still, I'd like people to understand that packet loss often also comes 
with delay - for having to retransmit. This delay is not visible in the queue, 
but it's visible in the end system. It also comes with head-of-line blocking 
delay on the receiver side: at least with TCP, whatever has been received after 
a dropped packet needs to wait in the OS for the hole to be filled before it 
can be handed over to the application.

Here we're not talking a few ms more or less in the queue, we're talking an 
RTT, when enough DupACKs are produced to make the sender clock out the missing 
packet again. Else, we're talking an RTO, which can be much, much more than an 
RTT, and which is what TLP tries to fix (but TLP's timer is also 2 RTTs - so 
this is all about delay at RTT-and-higher magnitudes).

Again, significant delay can come from dropped packets - you just don't see it 
when all you measure is the queue. ECN can help.

Cheers,
Michael

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

2015-03-20 Thread Jim Gettys

On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl  wrote:

> Folks,
>
> I think I have just seen this statement a little too often:
>
> > That’s right, Jim. The “some packet loss is good” part is from what I
> have seen the hardest thing for people to understand. People have been
> trained to believe that any packet loss is terrible (..)
>
> I understand the "wrong mindset" thing and the idea of AQM doing something
> better. Still, I'd like people to understand that packet loss often also
> comes with delay - for having to retransmit. This delay is not visible in
> the queue, but it's visible in the end system. It also comes with
> head-of-line blocking delay on the receiver side: at least with TCP,
> whatever has been received after a dropped packet needs to wait in the OS
> for the hole to be filled before it can be handed over to the application.
>
> Here we're not talking a few ms more or less in the queue, we're talking
> an RTT, when enough DupACKs are produced to make the sender clock out the
> missing packet again. Else, we're talking an RTO, which can be much, much
> more than an RTT, and which is what TLP tries to fix (but TLP's timer is
> also 2 RTTs - so this is all about delay at RTT-and-higher magnitudes).
>
> Again, significant delay can come from dropped packets - you just don't
> see it when all you measure is the queue. ECN can help.
>

And without AQM, the RTT's are often many times the actual speed of light
RTT's, sometimes measured in seconds.  And you eventually get the losses
anyway, as the bloated queues overflow.

So without AQM, you are often/usually in much, much, much worse shape;
better to suffer the loss, and do the retransmit than wait forever.
 -  Jim


> Cheers,
> Michael
>
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?



Sent from my iPhone

> On 20. mars 2015, at 16:31, Jim Gettys  wrote:
> 
> 
> 
>> On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl  wrote:
>> Folks,
>> 
>> I think I have just seen this statement a little too often:
>> 
>> > That’s right, Jim. The “some packet loss is good” part is from what I have 
>> > seen the hardest thing for people to understand. People have been trained 
>> > to believe that any packet loss is terrible (..)
>> 
>> I understand the "wrong mindset" thing and the idea of AQM doing something 
>> better. Still, I'd like people to understand that packet loss often also 
>> comes with delay - for having to retransmit. This delay is not visible in 
>> the queue, but it's visible in the end system. It also comes with 
>> head-of-line blocking delay on the receiver side: at least with TCP, 
>> whatever has been received after a dropped packet needs to wait in the OS 
>> for the hole to be filled before it can be handed over to the application.
>> 
>> Here we're not talking a few ms more or less in the queue, we're talking an 
>> RTT, when enough DupACKs are produced to make the sender clock out the 
>> missing packet again. Else, we're talking an RTO, which can be much, much 
>> more than an RTT, and which is what TLP tries to fix (but TLP's timer is 
>> also 2 RTTs - so this is all about delay at RTT-and-higher magnitudes).
>> 
>> Again, significant delay can come from dropped packets - you just don't see 
>> it when all you measure is the queue. ECN can help.
> 
> And without AQM, the RTT's are often many times the actual speed of light 
> RTT's, sometimes measured in seconds.  And you eventually get the losses 
> anyway, as the bloated queues overflow.
> 

not necessarily with ecn. and where in a burst loss occurs also matters


> So without AQM, you are often/usually in much, much, much worse shape; 
> better to suffer the loss, and do the retransmit than wait forever.

sure!!


>  -  Jim
> 
>> 
>> Cheers,
>> Michael
> 
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

> On 20 Mar, 2015, at 16:54, Michael Welzl  wrote:
> 
> I'd like people to understand that packet loss often also comes with delay - 
> for having to retransmit.

Or, turning it upside down, it’s always a win to drop packets (in the service 
of signalling congestion) if the induced delay exceeds the inherent RTT.

With ECN, of course, you don’t even have that caveat.

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

2015-03-20 Thread Valdis . Kletnieks

On Fri, 20 Mar 2015 07:08:27 -0700, "David P. Reed" said:

> M-Lab is better by far. But control by Google automatically discredits it's 
> data.

> Criticizing M-LAB is just fodder fir the operators' lobby in DC.

I'm trying to get those two statements to play nice together, but keep having
to beat down the cognitive dissonance with a stick.

And why, exactly, are they automatically discredited?  Unless you live in one
of the very few places that has Google Fiber, you're someplace where Google
has a vested interest in improving the eyeball-to-content connection, because
they want to get content to you.



pgpUA23WLwoPj.pgp
Description: PGP signature
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

> On 20 Mar, 2015, at 16:11, Livingood, Jason 
>  wrote:
> 
>> Even when you get to engineers in the organizations who build the equipment, 
>> it's hard.  First you have to explain that "more is not better", and "some 
>> packet loss is good for you".
> 
> That’s right, Jim. The “some packet loss is good” part is from what I have 
> seen the hardest thing for people to understand. People have been trained to 
> believe that any packet loss is terrible, not to mention that you should 
> never fill a link to capacity (meaning either there should never be a 
> bottleneck link anywhere on the Internet and/or that congestion should never 
> occur anywhere). 

That’s a rather interesting combination of viewpoints to have - and very 
revealing, too, of a fundamental disconnect between their mental theory of how 
the Internet works and how the Internet is actually used.

So here are some talking points that might be useful in an elevator pitch.  The 
wording will need to be adjusted to circumstances.

In short, they’re thinking only about the *core* Internet.  There, not being 
the bottleneck is a reasonably good idea, and packet loss is a reasonable 
metric of performance.  Buffers are used to absorb momentary bursts exceeding 
the normal rate, and since the link is supposed to never be congested, it 
doesn’t matter for latency how big those buffers are.  Adding capacity to 
satisfy that assumption is relatively easy, too - just plug in another 10G 
Ethernet module for peering, or another optical transceiver on a spare 
light-frequency for transit.  Or so I hear.

But nobody sees the core Internet except a few technician types in shadowy 
datacentres.  At least 99.999% of Internet users have to deal with the last 
mile on a daily basis - and it’s usually the last mile that is the bottleneck, 
unless someone *really* screwed up on a peering arrangement.  The key 
technologies in the last mile are the head-end, the CPE modem, and the CPE 
router; the last two might be in the same physical box as each other.  Those 
three are where we’re focusing our attention.

There, the basic assumption that the link should never be loaded to capacity is 
utter bunk.  The only common benchmarks of Internet performance that most 
people have access to (and which CPE vendors perform) are to do precisely that, 
and see just how big they can make the resulting bandwidth number.  And as soon 
as anyone starts a big TCP/IP-based upload or download, such as a software 
update or a video, the TCP stack in any modern OS will do its level best to 
load the link to capacity - and beyond.  This is more than a simple buffer - of 
*any* size - can deal with.

As an aside, it’s occasionally difficult to convince last-mile ISPs that packet 
loss (of several percent, due to line quality, not congestion) *is* a problem.  
But in that case, it’s probably because it would cost money (and thus profit 
margin) to send someone out to fix the underlying physical cause.  It really is 
a different world.

Once upon a time, the receive window of TCP was limited to 64KB, and the 
momentary bursts that could be expected from a single flow were limited 
accordingly.  Those days are long gone.  Given the chance, a modern TCP stack 
will increase the receive and congestion window to multi-megabyte proportions.  
Even on a premium, 100Mbps cable or FTTC downlink (which most consumers can’t 
afford and often can’t even obtain), that corresponds to roughly a whole second 
of buffering; an order of magnitude above the usual rule of thumb for buffer 
sizing.  On slower links, the proportions are even more outrageous.  Something 
to think about next time you’re negotiating microseconds with a high-frequency 
trading outfit.

I count myself among the camp of “packet loss is bad”.  However, I have the 
sense to realise that if more packets are persistently coming into a box than 
can be sent out the other side, some of those packets *will* be lost, sooner or 
later.  What AQM does is to signal (either through early loss or ECN marking) 
to the TCP endpoints that the link capacity has been reached, and it can stop 
pushing now - please - thank you.  This allows the buffer to do its designed 
job of absorbing momentary bursts.

Given that last-mile links are often congested, it becomes important to 
distinguish between latency-sensitive and throughput-sensitive traffic flows.  
VoIP and online gaming are the most obvious examples of latency-sensitive 
traffic, but Web browsing is *also* more latency-sensitive than 
throughput-sensitive, for typical modern Web pages.  Video streaming, software 
updates and uploading photos are good examples of throughput-sensitive 
applications; latency doesn’t matter much to them, since all they want to do is 
use the full link capacity.

The trouble is that often, in the same household, there are several different 
people using the same last-mile link, and they will tend to get home and spend 
their leisure time on the Internet at rou

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

> On 20. mar. 2015, at 17.31, Jonathan Morton  wrote:
> 
> 
>> On 20 Mar, 2015, at 16:54, Michael Welzl  wrote:
>> 
>> I'd like people to understand that packet loss often also comes with delay - 
>> for having to retransmit.
> 
> Or, turning it upside down, it’s always a win to drop packets (in the service 
> of signalling congestion) if the induced delay exceeds the inherent RTT.

Actually, no: as I said, the delay caused by a dropped packet can be more than 
1 RTT - even much more under some circumstances. Consider this quote from the 
intro of https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01  :

***
To get a sense of just how long the RTOs are in relation to
   connection RTTs, following is the distribution of RTO/RTT values on
   Google Web servers. [percentile, RTO/RTT]: [50th percentile, 4.3];
   [75th percentile, 11.3]; [90th percentile, 28.9]; [95th percentile,
   53.9]; [99th percentile, 214].
***

That would be for the unfortunate case where you drop a packet at the end of a 
burst and you don't have TLP or anything, and only an RTO helps...

Cheers,
Michael

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

2015-03-20 Thread David P. Reed

I think this is because there are a lot of packets in flight from end to end 
meaning that the window is wide open and has way overshot the mark. This can 
happen if the receiving end keeps opening it's window and has not encountered a 
lost frame.  That is: the dropped or marked packets are not happening early 
eniugh.

Evaluating an RTO measure from an out of whack system that is  not sending 
congestion signals is not a good source of data, unless you show the internal 
state of the endpoints that was going on at the same time.

Do the control theory.

On Mar 20, 2015, Michael Welzl  wrote:
>
>> On 20. mar. 2015, at 17.31, Jonathan Morton 
>wrote:
>>
>>
>>> On 20 Mar, 2015, at 16:54, Michael Welzl  wrote:
>>>
>>> I'd like people to understand that packet loss often also comes with
>delay - for having to retransmit.
>>
>> Or, turning it upside down, it’s always a win to drop packets (in the
>service of signalling congestion) if the induced delay exceeds the
>inherent RTT.
>
>Actually, no: as I said, the delay caused by a dropped packet can be
>more than 1 RTT - even much more under some circumstances. Consider
>this quote from the intro of
>https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01  :
>
>***
>To get a sense of just how long the RTOs are in relation to
>   connection RTTs, following is the distribution of RTO/RTT values on
>   Google Web servers. [percentile, RTO/RTT]: [50th percentile, 4.3];
>   [75th percentile, 11.3]; [90th percentile, 28.9]; [95th percentile,
>   53.9]; [99th percentile, 214].
>***
>
>That would be for the unfortunate case where you drop a packet at the
>end of a burst and you don't have TLP or anything, and only an RTO
>helps...
>
>Cheers,
>Michael

-- Sent with K-@ Mail - the evolution of emailing.___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?


On Fri, 20 Mar 2015, Michael Welzl wrote:


On 20. mar. 2015, at 17.31, Jonathan Morton  wrote:



On 20 Mar, 2015, at 16:54, Michael Welzl  wrote:

I'd like people to understand that packet loss often also comes with delay - 
for having to retransmit.


Or, turning it upside down, it’s always a win to drop packets (in the service 
of signalling congestion) if the induced delay exceeds the inherent RTT.


Actually, no: as I said, the delay caused by a dropped packet can be more than 
1 RTT - even much more under some circumstances. Consider this quote from the 
intro of https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01  :


You are viewing this as a question to drop a packet or not drop a packet.

The problem is that isn't the actual question.

The question is to drop a packet early and have the sender slow down, or wait 
until the sender has filled the buffer to the point that all traffic (including 
acks) is experiencing multi-second latency and then drop a bunch of packets.


In theory ECN would allow for feedback to the sender to have it slow down 
without any packet being dropped, but in the real world it doesn't work that 
well.


1. If you mark packets as congested if they have ECN and drop them if they 
don't, programmers will mark everything ECN (and not slow transmission) because 
doing so gives them an advantage over applications that don't mark their packets 
with ECN


  marking packets with ECN gives an advantage to them in mixed environments

2. If you mark packets as congested at a lower level than where you drop them, 
no programmer is going to enable ECN because flows with ECN will be prioritized 
below flows without ECN


If everyone use ECN you don't have a problem, but if only some 
users/applications do, there's no way to make it equal, so one or the other is 
going to have an advantage, programmers will game the system to do whatever 
gives them the advantage


David Lang___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?


> On 21. mar. 2015, at 00.47, David P. Reed  wrote:
> 
> I think this is because there are a lot of packets in flight from end to end 
> meaning that the window is wide open and has way overshot the mark. This can 
> happen if the receiving end keeps opening it's window and has not encountered 
> a lost frame.  That is: the dropped or marked packets are not happening early 
> eniugh.

... or they're so early that there are not enough RTT samples for a meaningful 
RTT measure.


> Evaluating an RTO measure from an out of whack system that is  not sending 
> congestion signals is not a good source of data, unless you show the internal 
> state of the endpoints that was going on at the same time.
> 
> Do the control theory.

Well - the RTO calculation can easily go out of whack when there is some 
variation, due to the + 4*RTTVAR bit. I don't need control theory to show that, 
a simple Excel sheet with a few realistic example numbers is enough. There's 
not much deep logic behind the 4*RTTVAR AFAIK - probably 4 worked ok in tests 
that Van did back then. Okay though, as fine tuning would mean making more 
assumptions about the path which is unknown in TCP - its just a conservative 
calculation, and the RTO being way too large often just doesn't matter much 
(thanks to DupACKs). Anyway, sometimes it can - and then a dropped packet can 
be pretty bad.

Cheers
Michael


> 
> On Mar 20, 2015, Michael Welzl  wrote:
> 
> On 20. mar. 2015, at 17.31, Jonathan Morton  wrote:
> 
> 
> On 20 Mar, 2015, at 16:54, Michael Welzl  wrote:
> 
> I'd like people to understand that packet loss often also comes with delay - 
> for having to retransmit.
> 
> Or, turning it upside down, it’s always a win to drop packets (in the service 
> of signalling congestion) if the induced delay exceeds the inherent RTT.
> 
> Actually, no: as I said, the delay caused by a dropped packet can be more 
> than 1 RTT - even much more under some circumstances. Consider this quote 
> from the intro of 
> https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01  :
> 
> ***
> To get a sense of just how long the RTOs are in relation to
> connection RTTs, following is the distribution of RTO/RTT values on
> Google Web servers. [percentile, RTO/RTT]: [50th percentile, 4.3];
> [75th percentile, 11.3]; [90th percentile, 28.9]; [95th percentile,
> 53.9]; [99th percentile, 214].
> ***
> 
> That would be for the unfortunate case where you drop a packet at the end of 
> a burst and you don't have TLP or anything, and only an RTO helps...
> 
> Cheers,
> Michael
> 
> 
> -- Sent with K-@ Mail - the evolution of emailing.

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

2015-03-20 Thread Steinar H. Gunderson

On Fri, Mar 20, 2015 at 05:03:16PM -0700, David Lang wrote:
> 1. If you mark packets as congested if they have ECN and drop them
> if they don't, programmers will mark everything ECN (and not slow
> transmission) because doing so gives them an advantage over
> applications that don't mark their packets with ECN

I'm not sure if this is actually true. Somehow TCP stacks appear to be tricky
enough to mess with that the people who are capable of gaming congestion
control algorithms are also wise enough not to do so. Granted, we are seeing
some mild IW escalation, but you could very well make a TCP that's
dramatically unfair to everything else and deploy that on your CDN, and
somehow we're not seeing that.

(OK, concession #2, “download accelerators” are doing really bad things with
multiple connections to gain TCP unfairness, but that's on the client side
only, not the server side.)

Based on this, I'm not convinced that people would bulk-mark their packets as
ECN-capable just to get ahead in the queues. It _is_ hard to know when to
drop and when to ECN-mark, though; maybe you could imagine the benefits of
ECN (for the flow itself) to be big enough that you don't actually need to
lower the drop probability (just make the ECN probability a bit higher),
but this is pure unfounded speculation on my behalf.

/* Steinar */
-- 
Homepage: http://www.sesse.net/
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

> On 21. mar. 2015, at 01.03, David Lang  wrote:
> 
> On Fri, 20 Mar 2015, Michael Welzl wrote:
> 
>>> On 20. mar. 2015, at 17.31, Jonathan Morton  wrote:
 On 20 Mar, 2015, at 16:54, Michael Welzl  wrote:
 I'd like people to understand that packet loss often also comes with delay 
 - for having to retransmit.
>>> Or, turning it upside down, it’s always a win to drop packets (in the 
>>> service of signalling congestion) if the induced delay exceeds the inherent 
>>> RTT.
>> 
>> Actually, no: as I said, the delay caused by a dropped packet can be more 
>> than 1 RTT - even much more under some circumstances. Consider this quote 
>> from the intro of 
>> https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01  :
> 
> You are viewing this as a question to drop a packet or not drop a packet.
> 
> The problem is that isn't the actual question.
> 
> The question is to drop a packet early and have the sender slow down, or wait 
> until the sender has filled the buffer to the point that all traffic 
> (including acks) is experiencing multi-second latency and then drop a bunch 
> of packets.
> 
> In theory ECN would allow for feedback to the sender to have it slow down 
> without any packet being dropped, but in the real world it doesn't work that 
> well.

I think it's about time we finally turn it on in the real world.

> 1. If you mark packets as congested if they have ECN and drop them if they 
> don't, programmers will mark everything ECN (and not slow transmission) 
> because doing so gives them an advantage over applications that don't mark 
> their packets with ECN

I heard this before but don't buy this as being a significant problem (and 
haven't seen evidence thereof either). Getting more queue space and 
occasionally getting a packet through that others don't isn't that much of an 
advantage - it comes at the cost of latency for your own application too unless 
you react to congestion.

>  marking packets with ECN gives an advantage to them in mixed environments
> 
> 2. If you mark packets as congested at a lower level than where you drop 
> them, no programmer is going to enable ECN because flows with ECN will be 
> prioritized below flows without ECN

Well longer story. Let me just say that marking where you would otherwise 
drop would be fine as a starting point. You don't HAVE to mark lower than you'd 
drop.

> If everyone use ECN you don't have a problem, but if only some 
> users/applications do, there's no way to make it equal, so one or the other 
> is going to have an advantage, programmers will game the system to do 
> whatever gives them the advantage

I don't buy this at all. Game to gain what advantage? Anyway I can be more 
aggressive than everyone else if I want to, by backing off less, or not backing 
off at all, with or without ECN. Setting ECN-capable lets me do this with also 
getting a few more packets through without dropping - but packets get dropped 
at the hard queue limit anyway. So what's the big deal? What is the major gain 
that can be gained over others?

Cheers,
Michael

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?


On Sat, 21 Mar 2015, Steinar H. Gunderson wrote:


On Fri, Mar 20, 2015 at 05:03:16PM -0700, David Lang wrote:

1. If you mark packets as congested if they have ECN and drop them
if they don't, programmers will mark everything ECN (and not slow
transmission) because doing so gives them an advantage over
applications that don't mark their packets with ECN


I'm not sure if this is actually true. Somehow TCP stacks appear to be tricky
enough to mess with that the people who are capable of gaming congestion
control algorithms are also wise enough not to do so. Granted, we are seeing
some mild IW escalation, but you could very well make a TCP that's
dramatically unfair to everything else and deploy that on your CDN, and
somehow we're not seeing that.


It doesn't take deep mucking with the TCP stack. A simple iptables rule to OR a 
bit on as it's leaving the box would make the router think that the system has 
ECN enabled (or do it on your local gateway if you think it gives you higher 
priority over the wider network)


If you start talking about ECN and UDP things are even simpler, there's no need 
to go through the OS stack at all, craft your own packets and send the raw 
packets



(OK, concession #2, “download accelerators” are doing really bad things with
multiple connections to gain TCP unfairness, but that's on the client side
only, not the server side.)

Based on this, I'm not convinced that people would bulk-mark their packets as
ECN-capable just to get ahead in the queues.


Given the money they will spend and the cargo-cult steps that gamers will do in 
the hope of gaining even a slight advantage, I can easily see this happening



It _is_ hard to know when to
drop and when to ECN-mark, though; maybe you could imagine the benefits of
ECN (for the flow itself) to be big enough that you don't actually need to
lower the drop probability (just make the ECN probability a bit higher),
but this is pure unfounded speculation on my behalf.


As I said, there are two possibilities

1. if you mark packets sooner than you would drop them, advantage non-ECN

2. if you mark packets and don't drop them until higher levels, advantage ECN, 
and big advantage to fake ECN


David Lang___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

On Sat, 21 Mar 2015, Michael Welzl wrote:

On 21. mar. 2015, at 01.03, David Lang wrote:

On Fri, 20 Mar 2015, Michael Welzl wrote:

On 20. mar. 2015, at 17.31, Jonathan Morton wrote:

On 20 Mar, 2015, at 16:54, Michael Welzl wrote:
I'd like people to understand that packet loss often also comes with delay -
for having to retransmit.

Or, turning it upside down, it’s always a win to drop packets (in the service
of signalling congestion) if the induced delay exceeds the inherent RTT.

Actually, no: as I said, the delay caused by a dropped packet can be more than
1 RTT - even much more under some circumstances. Consider this quote from the
intro of https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 :

You are viewing this as a question to drop a packet or not drop a packet.

The problem is that isn't the actual question.

The question is to drop a packet early and have the sender slow down, or wait
until the sender has filled the buffer to the point that all traffic
(including acks) is experiencing multi-second latency and then drop a bunch
of packets.

In theory ECN would allow for feedback to the sender to have it slow down
without any packet being dropped, but in the real world it doesn't work that
well.

I think it's about time we finally turn it on in the real world.

1. If you mark packets as congested if they have ECN and drop them if they
don't, programmers will mark everything ECN (and not slow transmission)
because doing so gives them an advantage over applications that don't mark
their packets with ECN

I heard this before but don't buy this as being a significant problem (and
haven't seen evidence thereof either). Getting more queue space and
occasionally getting a packet through that others don't isn't that much of an
advantage - it comes at the cost of latency for your own application too
unless you react to congestion.

but the router will still be working to reduce traffic, so more non-ECN flows
will get packets dropped to reduce the
loadhttp://email.chase.com/10385c493layfousub74lnvqaahg7lbwdgdvonyya/C?V=emlwX2NvZGUBAUNVU1RfTEFTVF9OTQFMQU5HAVJFV0FSRFNfQkF

MQU5DRQExNi43MwFnX2luZGV4AQFDVVNUX0ZJUlNUX05NAURBVklEAUxBU1RfNAE1NDE3AWxfaW5kZXgBAXByb2ZpbGVfaWQBNDg0Mzk5MjEyAW1haWxpbmdfaWQBMTE
0OTI5NTU5AV9XQVZFX0lEXwE4NTY2MDAxNzQBX1BMSVNUX0lEXwExNjgwMTYwMQFVTlFfRU5STF9DRAEyMTEyMzkzOTE1AWVtYWlsX2FkX2lkAQFMU1RfU1RNVF9EQVR
FATAyLzAxLzE1AWVtYWlsX2FkZHIBZGF2aWRAbGFuZy5obQFfU0NIRF9UTV8BMjAxNTAzMjAyMTAwMDABcHJvZmlsZV9rZXkBQTE0NjQ3MjgxMTQ%3D&KwXv5L3yGN8q
uPM67mqc0Q

marking packets with ECN gives an advantage to them in mixed environments

2. If you mark packets as congested at a lower level than where you drop
them, no programmer is going to enable ECN because flows with ECN will be
prioritized below flows without ECN

Well longer story. Let me just say that marking where you would otherwise
drop would be fine as a starting point. You don't HAVE to mark lower than
you'd drop.

If everyone use ECN you don't have a problem, but if only some
users/applications do, there's no way to make it equal, so one or the other
is going to have an advantage, programmers will game the system to do
whatever gives them the advantage

I don't buy this at all. Game to gain what advantage? Anyway I can be more
aggressive than everyone else if I want to, by backing off less, or not
backing off at all, with or without ECN. Setting ECN-capable lets me do this
with also getting a few more packets through without dropping - but packets
get dropped at the hard queue limit anyway. So what's the big deal? What is
the major gain that can be gained over others?

for gamers, even a small gain can be major. Don't forget that there's also the
perceived advantage "If I do this, everyone else's packets will be dropped and
mine will get through, WIN!!!"

David Lang___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

> On 21 Mar, 2015, at 02:25, David Lang  wrote:
> 
> As I said, there are two possibilities
> 
> 1. if you mark packets sooner than you would drop them, advantage non-ECN
> 
> 2. if you mark packets and don't drop them until higher levels, advantage 
> ECN, and big advantage to fake ECN

3: if you have flow isolation with drop-from-longest-queue-on-overflow, faking 
ECN doesn’t matter to other traffic - it just turns the faker’s allocation of 
queue into a dumb, non-AQM one.  No problem.

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?


On Sat, 21 Mar 2015, Jonathan Morton wrote:


On 21 Mar, 2015, at 02:25, David Lang  wrote:

As I said, there are two possibilities

1. if you mark packets sooner than you would drop them, advantage non-ECN

2. if you mark packets and don't drop them until higher levels, advantage ECN, 
and big advantage to fake ECN


3: if you have flow isolation with drop-from-longest-queue-on-overflow, faking 
ECN doesn’t matter to other traffic - it just turns the faker’s allocation of 
queue into a dumb, non-AQM one.  No problem.


so if every flow is isolated so that what it generates has no effect on any 
other traffic, what value does ECN provide?


and how do you decide what the fair allocation of bandwidth is between all the 
threads?


David Lang___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?