On 20. mar. 2015, at 19.29, David Lang da...@lang.hm wrote:
On Sat, 21 Mar 2015, Michael Welzl wrote:
On 21. mar. 2015, at 01.03, David Lang da...@lang.hm wrote:
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote:
On 20
On 20. mar. 2015, at 19.25, David Lang da...@lang.hm 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
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
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 g.wh...@cablelabs.com wrote:
Netalyzr is great for network geeks, hardly consumer-friendly, and even so
the network buffer measurements part is buried in 150 other
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote:
I'd like people to understand that packet loss often also comes with delay -
for having to retransmit.
Or,
On 21. mar. 2015, at 01.03, David Lang da...@lang.hm wrote:
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote:
I'd like people to understand that packet loss
On Sat, 21 Mar 2015, Jonathan Morton wrote:
On 21 Mar, 2015, at 02:25, David Lang da...@lang.hm 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
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
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
On 21. mar. 2015, at 00.47, David P. Reed dpr...@reed.com 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
On 21 Mar, 2015, at 02:25, David Lang da...@lang.hm 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:
On 21 Mar, 2015, at 02:38, David Lang da...@lang.hm wrote:
On Sat, 21 Mar 2015, Jonathan Morton wrote:
On 21 Mar, 2015, at 02:25, David Lang da...@lang.hm wrote:
As I said, there are two possibilities
1. if you mark packets sooner than you would drop them, advantage non-ECN
2. if
FYI, we have this in France.
http://www.arcep.fr/index.php?id=8571tx_gsactualite_pi1[uid]=1701tx_gsactualite_pi1[annee]=tx_gsactualite_pi1[theme]=tx_gsactualite_pi1[motscle]=tx_gsactualite_pi1[backID]=26cHash=f558832b5af1b8e505a77860f9d555f5L=1
ARCEP is the equivalent of FCC in France.
User
*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 influence
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
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 dave.t...@gmail.com wrote:
On Thu, Mar 19, 2015 at 6:53 AM, dpr...@reed.com wrote:
How many years has it been since Comcast said they were going to fix
bufferbloat in
On 3/20/15, 9:48 AM, Jim Gettys
j...@freedesktop.orgmailto: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
Hi David,
On Mar 20, 2015, at 14:31 , David P. Reed dpr...@reed.com 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
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
Sent from my iPhone
On 20. mars 2015, at 16:31, Jim Gettys j...@freedesktop.org wrote:
On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl mich...@ifi.uio.no wrote:
Folks,
I think I have just seen this statement a little too often:
That’s right, Jim. The “some packet loss is good”
On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no 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
On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl mich...@ifi.uio.no 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
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no 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
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
On 3/19/15, 1:11 PM, Dave Taht dave.t...@gmail.com wrote:
On Thu, Mar 19, 2015 at 6:53 AM, dpr...@reed.com 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
On Thu, Mar 19, 2015 at 6:53 AM, dpr...@reed.com wrote:
How many years has it been since Comcast said they were going to fix
bufferbloat in their network within a year?
It is unfair to lump every individual in an organization together. All
orgs have people trying to do the right thing(s), and
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
27 matches
Mail list logo