On Tue, 3 Mar 2015, valdis.kletni...@vt.edu wrote:
On Mon, 02 Mar 2015 11:17:33 +0100, Mikael Abrahamsson said:
We have a huge amount of information in our TCP stacks that either are
locked in there and not used properly to help users figure out what's
going on, and there is basically zero inf
On Mon, 2 Mar 2015, Dave Taht wrote:
I note that there are conflicting definitions of CS1 (background).
Comcast, re-marks about 90% I see to CS1 from whatever it was
originally, in the hope that it is treated as background. The ancient
firmware in commercial home routers *prioritizes* CS1 on e
> On Mar 1, 2015, at 7:57 PM, Dave Taht wrote:
>
> How can we fix this user perception, short of re-prioritizing ping in
> sqm-scripts?
IMHO, ping should go at the same priority as general traffic - the default
class, DSCP=0. When I send one, I am asking whether a random packet can get to
a g
On Mon, 02 Mar 2015 11:17:33 +0100, Mikael Abrahamsson said:
> We have a huge amount of information in our TCP stacks that either are
> locked in there and not used properly to help users figure out what's
> going on, and there is basically zero information flow between the
> applications using TC
On 3/2/2015 3:14 PM, David Lang wrote:
> On Mon, 2 Mar 2015, Joe Touch wrote:
>
>> On 3/2/2015 1:40 AM, Brian Trammell wrote:
>> ...
>>> The real solution is to create a utility called "ping" that uses
>>> traffic that gets prioritized the same way as the traffic you care
>>> about instead of IC
On 3/2/2015 1:40 AM, Brian Trammell wrote:
...
> The real solution is to create a utility called "ping" that uses
> traffic that gets prioritized the same way as the traffic you care
> about instead of ICMP echo request/reply. Users don't care about
> the packets on the wire so much as they do t
Maybe I should mention https://github.com/apenwarr/blip
HTTP ping, using deliberate 204 responses. Will run over whatever version
of HTTP/SPDY/QUIC your browser happens to be using at the time.
On 3 March 2015 at 10:34, David Lang wrote:
> On Mon, 2 Mar 2015, Joe Touch wrote:
>
> On 3/2/2015
On Mon, 2 Mar 2015, Joe Touch wrote:
On 3/2/2015 3:14 PM, David Lang wrote:
On Mon, 2 Mar 2015, Joe Touch wrote:
On 3/2/2015 1:40 AM, Brian Trammell wrote:
...
The real solution is to create a utility called "ping" that uses
traffic that gets prioritized the same way as the traffic you care
On Mon, 2 Mar 2015, Joe Touch wrote:
On 3/2/2015 1:40 AM, Brian Trammell wrote:
...
The real solution is to create a utility called "ping" that uses
traffic that gets prioritized the same way as the traffic you care
about instead of ICMP echo request/reply. Users don't care about
the packets on
On Mon, 2 Mar 2015, Dave Dolson wrote:
Would you do that to TCP or UDP traffic?
At IETF I often hear laments about middle-boxes breaking the internet by being
"clever" with certain types of traffic.
It seems that policing ICMP falls into that category.
There may have been bugs in the past, bu
On Mon, Mar 2, 2015 at 12:06 PM, Wes Felter wrote:
> What about a token bucket policer, so more than N ICMP/second gets penalized
> but a normal ping won't be.
If I haven't expressed this too many times before, I want to thank you
all for existing.
It is the quality and caliber of all the folk o
Would you do that to TCP or UDP traffic?
At IETF I often hear laments about middle-boxes breaking the internet by being
"clever" with certain types of traffic.
It seems that policing ICMP falls into that category.
There may have been bugs in the past, but I'm not aware that ICMP packets are
any
On Mon, 2 Mar 2015, Andrew Mcgregor wrote:
So, are you suggesting that, for example, Chrome's rather extensive network
debugging information get more publicised? We can probably arrange that.
That would be good. I have no idea what debugging info you are referring to.
David Lang_
I'm rather new to the aqm community, but IMHO, it is wrong to deprioritize the
ping traffic by default. I would not have expected a forwarding agent to do
this.
And I think measuring ping times and loss is a reasonable thing to do, never
expecting forwarding agents along the path to place more
hi Dave,
> On 02 Mar 2015, at 04:57, Dave Taht wrote:
>
> On this thread over here, an otherwise pretty clueful user chose
> openwrt's qos-scripts over the sqm-scripts, because sqm-scripts had
> *higher ping loss*.
I am not proud of the fact that I am not surprised by this.
> How can we fix th
On Mon, 2 Mar 2015, Brian Trammell wrote:
Gaming protocols do this right - latency measurement is built into the
protocol.
I believe this is the only way to do it properly, and the most likely
easiest way to get this deployed would be to use the TCP stack.
We need to give users an easy-to-u
On Sun, 1 Mar 2015, Dave Taht wrote:
but wow, it never occurred to me - in all these years - that ping was
the next core metric on simple tests. I can be really dumb.
How can we fix this user perception, short of re-prioritizing ping in
sqm-scripts?
People will make all kinds of judgement ca
17 matches
Mail list logo
