This is why I am a firm believe in head-end shaping, especially for wireless networks.

In the wireline model, shaping at the access node (before the CPE) can make more sense for various reasons.

Josh Reynolds
CIO, SPITwSPOTS
www.spitwspots.com

On 04/28/2015 06:30 PM, David Milholen wrote:
Gotcha...
similar to sdp overload ...


On 4/27/2015 8:59 AM, Ken Hohhof wrote:
I don’t think you’re understanding the situation that we are speculating is happening. He is using Cambium QoS. However, he is seeing twice that amount of traffic destined to the customer, the SM is throwing half of it away (as it should), and as a result the customer’s service sucks. The problem is that the sender is not observing traditional congestion control, it is not backing off the sending rate when it sees high packet loss. That’s why I say it is similar to a DoS attack, someone sending far more traffic than the subscriber can receive.
*From:* David Milholen <mailto:dmilho...@wletc.com>
*Sent:* Monday, April 27, 2015 7:05 AM
*To:* af@afmug.com <mailto:af@afmug.com>
*Subject:* Re: [AFMUG] 450SM sustain bucket throttle not working..
This is why we like setting the QOS at the subscriber. If I remember the cambium burst allocation ignores tcp and udp and work strictly on a token bit system. We do not receive these complaints. The only time I hear them is if we get overloaded at the backhaul link.


On 4/26/2015 8:58 PM, Ken Hohhof wrote:
I think George forgot the sarcasm emoticon.
Also note that the problem here is the edge provider is sending more than the customer’s plan rate, ignoring TCP congestion control. Not only does this consume Internet bandwidth over and above what the customer has subscribed to, it makes anything else the customer is trying to do on the Internet unusable because normal TCP is unusable with 50% packet loss. It is not surprising the customer calls saying his Internet is slow.
There’s a saying that comes to mind, involving a 5 pound bag.
*From:* Faisal Imtiaz <mailto:fai...@snappytelecom.net>
*Sent:* Sunday, April 26, 2015 8:37 PM
*To:* af@afmug.com <mailto:af@afmug.com>
*Subject:* Re: [AFMUG] 450SM sustain bucket throttle not working..
I see that the net neutrality is going to be the next boogieman under the bed for WISP's from now on...
Please, please, please, correct your understanding on Net-Neutrality...
It allows for one to traffic shape any and all kinds of traffic, as long as :-
   a) You declare your practice on your website.
b) You DON"T DO IT specific to A SPECIFIC Network.. i.e. all VOIP, or all Video, or ALL Streaming.. (applying a throttle on video to netflix while allowing Hulu would be considered a violation, but applying throttle to all types of video content is NOT !)
:)
Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232
Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
------------------------------------------------------------------------

    *From: *"George Skorup (Cyber Broadcasting)"
    mailto:geo...@cbcast.com
    *To: *af@afmug.com
    *Sent: *Sunday, April 26, 2015 7:12:13 PM
    *Subject: *Re: [AFMUG] 450SM sustain bucket throttle not working..
    So you'd be purposely slowing down or blocking legitimate
    traffic from an edge provider to the customer? Oh no, net
    neutrality violation!

    So when everyone starts with the 4k streaming and we're selling
    the customer 20Mbps, then we have to take on 40Mbps because of
    this!?

    On 4/26/2015 5:58 PM, Ken Hohhof wrote:

        I could justify declaring such traffic an attack and
        blocking the source as malicious.
        *From:* George Skorup (Cyber Broadcasting)
        <mailto:geo...@cbcast.com>
        *Sent:* Sunday, April 26, 2015 4:30 PM
        *To:* af@afmug.com <mailto:af@afmug.com>
        *Subject:* Re: [AFMUG] 450SM sustain bucket throttle not
        working..
        Yep, I see this all the time and Ken is exactly right. The
        Canopy QoS works exactly as designed, the AP is definitely
        not delivering more than the sustained rate, but is instead
        discarding the extra 50%. I've tested this situation
        thoroughly. Stick a MT simple queue in at the upstream
        router and the 2X rate traffic stops hitting the AP's
        ethernet interface, but it's still coming in at double the
        sustained rate farther upstream. There's no way around it
        except throwing bandwidth at it.

        This is CDN traffic. And when the customer thinks they can
        install one of those "internet download managers" to speed
        up their connection. The only thing it does is screw with
        TCP acks or window sizes or something which just puts more
        traffic on your transit just to be discarded at the
        congestion point (SM, queue, Procera, whatever). Gotta love it.

        You'd think with 70% of the internets being streaming video
        they'd think hmm.. maybe we can cut down on the peering
        congestion by NOT doing this crap. But no.

        On 4/26/2015 11:01 AM, Ken Hohhof wrote:

            Sorry to answer a question with a question, but are you
            measuring at the SM, or at some upstream router?
            The reason I ask, is I have seen some CDN traffic that
            does not seem to follow traditional TCP congestion
            control.  It will send at twice the rate limit, causing
            50% packet loss to its own traffic and everything else
            to that same subscriber. Evidently some TCP geniuses
            have decided to use latency rather than packet loss as
            the indicator of congestion, and that the objective is
            goodput not throughput.  Works for last mile
            technologies like T1 and DSL with big buffers at the
            head end of the fixed speed serial connection, not so
            good with the type of rate limit queues we tend to use
            unless we can provision the queues with big buffers.
            Probably not your problem, but I thought I’d bring it up
            just in case.
            *From:* Kurt Fankhauser <mailto:li...@wavelinc.com>
            *Sent:* Sunday, April 26, 2015 10:50 AM
            *To:* af@afmug.com <mailto:af@afmug.com>
            *Subject:* [AFMUG] 450SM sustain bucket throttle not
            working..
            I have a 450 SM that is rate limited in the SM to
            1500kbps download on the sustain side. I noticed last
            night that this customer was pulling a steady almost
            3mbps download for several hours on end. How is this
            possible? Is there a problem with 13.2 firmware? Its a
            3.65ghz SM.
            see attached.

            Kurt Fankhauser

            Wavelinc Communications

            P.O. Box 126

            Bucyrus, OH 44820

            http://www.wavelinc.com <http://www.wavelinc.com/>

            tel. 419-562-6405

            fax. 419-617-0110




--

--

Reply via email to