It's not unreasonable to put rate limits on inbound ICMP traffic going to the control plane of the router. But the VoIP loss is unacceptable, I agree.

Sean

On Tue, Oct 19, 2010 at 12:00 PM, John Lange <john@johnlange.ca> wrote:
When the loss occurs it's all the way from hop 1 to the far end.

They've used the "ICMP is at a lower priority" excuse before. It
doesn't hold much water with me because that is essentially just an
admission that the router is overload and has to start dropping stuff
which would be fine if only ICMP got dropped but the packet loss is
also happening on voice traffic.

John


On Tue, Oct 19, 2010 at 11:17 AM, Adam Thompson <athompso@athompso.net> wrote:
> If MTR shows loss at hop 1 but *not* at hop 2, that's just their router ignoring your ICMP packets and doesn't actually indicate packet loss.
>
> *sigh*  I can't believe I'm defending Shaw...
>
> -Adam
>
> -----Original Message-----
> From: John Lange <john@johnlange.ca>
> Sender: roundtable-bounces@muug.mb.ca
> Date: Tue, 19 Oct 2010 11:14:16
> To: Continuation of Round Table discussion<roundtable@muug.mb.ca>
> Reply-To: Continuation of Round Table discussion <roundtable@muug.mb.ca>
> Subject: Re: [RndTbl] Shaw packet loss
>
> Just for reference; I use mtr for testing this.
>
> Here is the command line. As you can see, I've set a very aggressive
> packet rate (20/second).
>
> # mtr -r -w -c 500 -n -i 0.05 www.google.ca
>
> I actually stick it in a loop so I can keep it running and see periodic results:
>
> # while true ; do date ; mtr -r -w -c 500 -n -i 0.05 www.google.ca ; done
>
> When I see loss, it's always at the first hop yet it doesn't seem to
> matter which gateway it is. These are all Shaw business customers so
> may not be affecting residential.
>
> John
>
> On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
>> On 10-10-19 10:39 AM, Sean Walberg wrote:
>>> On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
>>>
>>>
>>>>         Then there is their policy of slowing down the entire connection if
>>>> they determine someone is using bittorrent on a LAN (even if the user
>>>> caps the up and down speeds)
>>>
>>>
>>> Do you have a source for this? Are you sure it's not because you're starving
>>> out your upstream and therefore not able to get ACKs out?
>>>
>>> Sean
>>>
>>
>>        Give it a try. Grab a movie or something. Use a bittorrent client
>> capable of capping the up and down speed. Ktorrent can do this. See what
>> you can get for both up and down uncapped. Then try running say Firefox
>> and look at its performance. Stop the bittorrent transfer and look at
>> Firefox again in a few minutes. Set up a cap in bittorrent say 10K on
>> both the up and down (bear in mind this is supposed to be a
>> multi-megabit connection). Restart your bittorrent and see what happens
>> with Firefox. You'll notice the bittorrent will transfer to what ever
>> maximum you set while other programs will barely function on the
>> internet. Local transfers on the LAN are fine though.
>>
>>                                Later
>>                                Mike
>>
>>_______________________________________________
>> Roundtable mailing list
>> Roundtable@muug.mb.ca
>> http://www.muug.mb.ca/mailman/listinfo/roundtable
>>
>
>
>
> --
> John Lange
> www.johnlange.ca
>
> _______________________________________________
> Roundtable mailing list
> Roundtable@muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>
>
> _______________________________________________
> Roundtable mailing list
> Roundtable@muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>



--
John Lange
www.johnlange.ca

_______________________________________________
Roundtable mailing list
Roundtable@muug.mb.ca
http://www.muug.mb.ca/mailman/listinfo/roundtable



--
Sean Walberg <sean@ertw.com>    http://ertw.com/