3

We recently switched from a business-class cable connection (100/20) to a symmetrical (100/100) fiber one. This serves a front office, a media department, and several client computers on any given day.

While on the former service we up/downloaded many multi-gig media files from client and graphics computers, with no problems except what you'd expect when several people are competing for limited bandwidth. It all worked, it just slowed down.

But with this new service we get periods where (the supplier says) we "saturate" the connection and all connectivity ends for everyone. What is really going on here? I would guess most traffic is 'web-based' in that it's mediated through ports 80/443, with some FTP.

And some of the file transfers do proceed at amazing speeds -- the remote ends can easily keep up with our puny 100Mb/s, where in the past it was rare to see any given connection exceed 30Mb/s. It's just that when three or more of these up/down transfers are going on, it eventually, to put it crudely, 'clogs the pipes'.

So what's really going on? Why would a faster service with a more dedicated channel be susceptible to this sort of degradation? I've always thought of TCP as somewhat self-balancing in that multiple connections would degrade together, that one or two connections couldn't 'hog' the bandwidth. Is that wrong?

Improve this question
11
  • 2
    Your provider is blowing smoke.
    – Ron Trunk
    Sep 13 '16 at 11:33
  • @RonTrunk I believe that, but it would be helpful to know what we should expect and how to counter their argument. What can explain this behavior? Is there anything we can do to mitigate it, or to demonstrate to them what the issue is so they can fix it? All they've offered is traffic graphs showing where we "saturated" the pipe. It's my contention that we should be able to sustain 100Mb/s indefinitely, with performance degrading internally and proportionally per connection as demand goes up. True?
    – Jim Mack
    Sep 13 '16 at 12:21
  • You should look up TCP synchronization. Unless you have some mitigation, this can wreak havoc on your connections. Unfortunately, you have no control over incoming traffic because it has already used your bandwidth by the time you see it.
    – Ron Maupin ♦
    Sep 13 '16 at 12:31
  • If you record a network packet capture of the event, then somebody may be able to infer why it happens and whether or not your ISP has a case to answer. When you say "ends for everyone", what exactly does this mean? Does everybody go home for the rest of the day, or what :-)
    – marctxk
    Sep 13 '16 at 12:58
  • 1
    @JimMack, are they seriously telling you that when there's too much load the link-light goes out? Ask them to explain in writing how that happens and tell them that you will get an expert opinion on their analysis. Apart from the fact that we'd all like to have a laugh, it may force them to take you seriously.
    – marctxk
    Sep 13 '16 at 14:57
2

A cable network would only allow a few large 30mb downloads whereas a 100mb fiber never decreases unless its a shared bandwidth line. It seems much more likely your managed service provider isn't giving true 100mb. A speed test may say you have 100mb down but that doesn't mean your throughput is equivalent. For example, cable service providers will have everyone saying they have 100mb down the street but in reality, if your neighbor is using alot, your speed(throughput) will decrease. This is not the case with true fiber.

Improve this answer
1
  • I would have have a Pcab/trace route done to see if your packet loss is high within your internal topology, then adjust your drop tail in the internal networking equipment if that was where the network congested.. Again, congestion on their end is simply them managing better and them stop throttling your true throughput.
    – AVofCheb
    Sep 13 '16 at 15:42
1

TCP will send packets at an increasing rate until it starts to see packet loss, then it will back off. Normally this works pretty well, however there are a couple of things that can frustrate it.

One is oversized buffers, this can easilly occour when a relatively slow link is terminated on a peice of big high end equipment. TCP will fill up the large buffer leading to high latency for all traffic.

Another is poorly implemented artificial rate limits. If the link allows an initial burst of high speed traffic then suddenly imposes a limit then again TCP can respond badly.

Really your provider should be sorting this out, but if they can't/won't then the soloution is to introduce an artificial rate limit on your end that is slightly slower than the provider's limit. You can then control the buffer size and prioritisation rules (if any) at that artificial limit). The buffers at the provider's end should never fill up.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.