> On 20. mar. 2015, at 19.25, David Lang wrote:
>
> 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 (a
> On 20. mar. 2015, at 19.29, David Lang wrote:
>
> 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,
> On 21 Mar, 2015, at 02:38, David Lang wrote:
>
> 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 yo
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 ad
> 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
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 co
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 advantag
> 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
- f
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 pac
> 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
>
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 w
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 ha
> 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 t
> 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
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 bea
> 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 t
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 hav
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
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
FYI, we have this in France.
http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1701&tx_gsactualite_pi1[annee]=&tx_gsactualite_pi1[theme]=&tx_gsactualite_pi1[motscle]=&tx_gsactualite_pi1[backID]=26&cHash=f558832b5af1b8e505a77860f9d555f5&L=1
ARCEP is the equivalent of FCC in France.
U
On 3/20/15, 9:48 AM, "Jim Gettys"
mailto:j...@freedesktop.org>> wrote:
I think this was the hope that the buffer size control feature in Docsis could
at least be used to cut bufferbloat down to the "traditional" 100ms level, as I
remember the sequence of events. But reality intervened: buggy i
SamKnows is carefully constructed politically to claim that everyone has great
service and no problems are detected. They were constructed by opponents of
government supervision - the corporate FCC lobby.
Don't believe they have any incentive to measure customer relevant measures
M-Lab is bette
I don't know.
From my personal experience, I feel like the "expert" wearing ties
watch the speed meter and the needle moving across the red bar.
We just need to be sure about the colors: when the latency goes into the
crazy region
the needle has to cross a RED bar! GREEN is good, RED is bad (exc
>*I realize not everyone likes the Ookla tool, but it is popular and about
>as "sexy" as you are going to get with a network performance tool.
Ookla has recently been acquired by Ziff-Davis
(http://finance.yahoo.com/news/ziff-davis-acquires-ookla-120100454.html).
I am not sure have that may influe
On Thu, Mar 19, 2015 at 3:58 PM, Livingood, Jason <
jason_living...@cable.comcast.com> wrote:
> On 3/19/15, 1:11 PM, "Dave Taht" wrote:
>
> >On Thu, Mar 19, 2015 at 6:53 AM, wrote:
> >> How many years has it been since Comcast said they were going to fix
> >>bufferbloat in their network within
Hi David,
On Mar 20, 2015, at 14:31 , David P. Reed wrote:
> The mystery in most users' minds is that ping at a time when there is no load
> does tell them anything at all about why the network connection will such
> when their kid is uploading to youtube.
But it does, by giving a bas
The mystery in most users' minds is that ping at a time when there is no load
does tell them anything at all about why the network connection will such when
their kid is uploading to youtube.
So giving them ping time is meaningless.
I think most network engineers think ping time is a useful meas
Hi All,
I guess I have nothing to say that most of you don’t know already, but...
On Mar 20, 2015, at 00:18 , Greg White wrote:
> Netalyzr is great for network geeks, hardly consumer-friendly, and even so
> the "network buffer measurements" part is buried in 150 other statistics.
The b
I agree. Having that ping included in Ookla would help a lot more
Luca
On 03/20/2015 12:18 AM, Greg White wrote:
Netalyzr is great for network geeks, hardly consumer-friendly, and even so
the "network buffer measurements" part is buried in 150 other statistics.
Why couldn't Ookla* add a simult
Netalyzr is great for network geeks, hardly consumer-friendly, and even so
the "network buffer measurements" part is buried in 150 other statistics.
Why couldn't Ookla* add a simultaneous "ping" test to their throughput
test? When was the last time someone leaned on them?
*I realize not everyone
I do think engineers operating networks get it, and that Comcast's engineers
really get it, as I clarified in my followup note.
The issue is indeed prioritization of investment, engineering resources and
management attention. The teams at Comcast in the engineering side have been
the leaders in
On 3/19/15, 1:11 PM, "Dave Taht" wrote:
>On Thu, Mar 19, 2015 at 6:53 AM, wrote:
>> How many years has it been since Comcast said they were going to fix
>>bufferbloat in their network within a year?
I¹m not sure anyone ever said it¹d take a year. If someone did (even if it
was me) then it was
32 matches
Mail list logo
