Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: Three - couple of questions about traffic engineering  (Read 2490 times)

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Three - couple of questions about traffic engineering
« on: October 05, 2020, 02:26:53 PM »

Hi,
I wonder whether anyone can answer either of these questions. 

Firstly on 4G our data rates both up and down vary from time to time.  So for the upload directing in particular I was wondering whether this rate is actually visible to the router, for example if the rate is 9 meg does that mean the router is actually transmitting at no more than 9 meg, or could it be transmitting at a higher rate with the limit applying somewhere with the network.  The reason for asking is that I want to apply some upstream QoS which would obviously be easy if the router is the bottleneck.  Otherwise I need to shape down to the slowest speed I expect to get.

Second question was with regard to carrier traffic management.  I've seen speculation that the mobile operators lower the priority of what they call "tethered" traffic, and I've seen this blamed for poor performance using a 4G router.  I wonder whether anyone had any factual knowledge of this, and if so whether there are workarounds.  Personally I don't really think I'd call our performance on Smarty as "poor", but I wouldn't say no to any improvement.  I've stuck a line into the LTE router config to re-write TTL, as that is something it's been suggested they look at to distinguish tethered traffic.   I couldn't swear it's helped but it hasn't had any downside apart from making traceroute look a little odd.

Thanks, Tony S
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Three - couple of questions about traffic engineering
« Reply #1 on: October 05, 2020, 04:43:44 PM »

As for your first question, I would assume that upstream traffic is rate-limited in the router or radio device if the two are distinct entities. There’s no point in accepting a lot of traffic, transmitting it and then throwing it away further on in the path, as that’s just wasting network capacity and it allows an abuser to hog the network in his cell. But what do I know?
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Three - couple of questions about traffic engineering
« Reply #2 on: October 05, 2020, 06:19:52 PM »

What I was meaning may be best show in an analogy.  If I have an ADSL connection directly on the router, with an upstream rate of say 750k then the router can't transmit faster than 750k, and if more traffic is offered then the router will have to drop the traffic.  Conversely if the router has a Fast Ethernet connection to a device which itself has that 750k limit, the router can send way more traffic, and the excess will be dropped at that device.

In the first instance QoS on the router doesn't need to know the line rate, in the second instance it needs to have an artificial rate limit applied to make sure it's the router deciding what to drop.  And that's a pain if the rate is subject to change as the rate would have to be set to the lowest expected speed.

The question is whether LTE is more like the first or the second.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Three - couple of questions about traffic engineering
« Reply #3 on: October 05, 2020, 06:47:18 PM »

No QoS. The router buffers traffic then drops it once the buffer is full.
Logged

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5260
    • Thinkbroadband Quality Monitors
Re: Three - couple of questions about traffic engineering
« Reply #4 on: October 05, 2020, 07:25:52 PM »

No QoS. The router buffers traffic then drops it once the buffer is full.

Thus why you need QoS to prevent buffer bloat, you artificially drop the traffic early to reduce the delay in getting packets out.

We know on VDSL that Openreach actually had 1Mbit upstream blocked off with QoS on their modems (likely a percentage of the upload rate) as the modem DOES know the link rate.

With 4G I do not believe its possible as like WiFi what the link rate says and what you can actually achieve can vary wildly.  QoS relies on knowing the speed of the link and it not changing.
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Three - couple of questions about traffic engineering
« Reply #5 on: October 06, 2020, 07:46:18 AM »

No QoS. The router buffers traffic then drops it once the buffer is full.

Maybe "QoS" is too broad a term, what I'm specifically referring to is a congestion management function.  Terminology out of the way any half decent router can be configured so that as the buffer starts to fill it preferentially forwards certain packets (or frames) and drops others, and this will start to happen as soon as any data is buffered not just when the queue is full.  However this does depend on that interface being the bottleneck either inherently or by shaping it down to the known path bandwidth.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Three - couple of questions about traffic engineering
« Reply #6 on: October 06, 2020, 08:07:57 AM »

QoS relies on knowing the speed of the link and it not changing.
I don't believe that it necessarily relies on the speed not changing, so long as the router interface dequeues at the current speed then its prioritisation will work. However if the speed at the router transmission is fixed, but there are variable bottlenecks further on then it won't work.  In that case you'd need to shape down to the lowest speed ever expected.

However I don't think I'm any further on with my specific question.  I think I need to look for details of the actual LTE signalling and see whether devices are waiting their turn on the shared bandwidth, or blindly transmitting at the theoretical rate and hoping for the best.  I don't know how easy it's going to be to find that, at the moment I haven't even found what modulation is in use (Three - Band 20 by the way).
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Three - couple of questions about traffic engineering
« Reply #7 on: October 07, 2020, 01:04:05 PM »

Maybe "QoS" is too broad a term, what I'm specifically referring to is a congestion management function.  Terminology out of the way any half decent router can be configured so that as the buffer starts to fill it preferentially forwards certain packets (or frames) and drops others, and this will start to happen as soon as any data is buffered not just when the queue is full.  However this does depend on that interface being the bottleneck either inherently or by shaping it down to the known path bandwidth.

Likely either FIFO or WFQ.

Basic kit isn't that smart. It relies on higher level protocols to handle congestion management. Nice as it would be to be able to measure the capacity across a link end to end that requires visibility of the connection end to end which only happens between end stations on Internet networks, with one providing feedback to the other somewhere between transport and application layer.

EDIT: If the Internet were that smart there wouldn't be as much need for the type of technology I deploy  :) ISP networks can and do have some traffic of a higher priority than others but most of it, necessarily, falls into Best Effort and gets to fight it out with everything else for capacity.

Check when core networks saturate, you can see it on TBB BQMs. Indiscriminate buffering then dropping of traffic once wait times expire is the usual thing as most of us have normal residential services so are piled into the lowest, or no, priority queue. Leased line services will usually be using MPLS or be tagged in other ways within the packet headers and treated differently.
« Last Edit: October 07, 2020, 01:08:18 PM by CarlT »
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Three - couple of questions about traffic engineering
« Reply #8 on: October 07, 2020, 02:01:49 PM »

Likely either FIFO or WFQ
Cisco is what I'm most at home with, and it's normally WAN where we're applying QoS so there's the whole raft of Cisco abbreviations from LLQ to CBWFQ to WRED and combinations to suit, probably all meaningless out of the Cisco context.  At home I'm using Mikrotik and now we're talking "mangle", "prerouting", "marks" and "queue trees".  The effect is the essentially the same.
« Last Edit: October 07, 2020, 02:04:44 PM by aesmith »
Logged

meritez

  • Content Team
  • Kitizen
  • *
  • Posts: 1623
Re: Three - couple of questions about traffic engineering
« Reply #9 on: October 07, 2020, 02:11:35 PM »

At home I'm using Mikrotik and now we're talking "mangle", "prerouting", "marks" and "queue trees".

What are you using for the 4G connection?
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Three - couple of questions about traffic engineering
« Reply #10 on: October 07, 2020, 02:11:46 PM »

However that's straying from the original question, which I think I'll probably have to find out for myself.  I can apply some strict priority, then max out the upload and see if my chosen traffic is impacted.  On ADSL where the upload is easily overloaded a simple prioritisation of small packets was very effective at stopping downloads getting choked whenever Icloud or Google Drive had a lot to send.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Three - couple of questions about traffic engineering
« Reply #11 on: October 07, 2020, 02:12:55 PM »

What are you using for the 4G connection?
I'm using a Mikrotik SXT, currently placed in the attic, and I'm getting my signal on Band 20 from a mast 12 km away.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Three - couple of questions about traffic engineering
« Reply #12 on: October 07, 2020, 03:37:27 PM »

The queuing strategies are pretty standard and you can, of course, handle them relatively gracefully on your side. Basic fair queuing usually hits the spot.

Some FQ variant or FIFO are the most likely ones to find on ISP networks and, I presume, this holds true for mobile carrier networks too.

The best you can do is ensure FQ so that small packets are immediately serviced however full the queue on the router is. I reckon that alongside layer 4-7 congestion control should provide a decent experience unless congestion is really bad.
« Last Edit: October 07, 2020, 05:18:41 PM by CarlT »
Logged

meritez

  • Content Team
  • Kitizen
  • *
  • Posts: 1623
Re: Three - couple of questions about traffic engineering
« Reply #13 on: October 08, 2020, 11:22:47 AM »

I'm using a Mikrotik SXT, currently placed in the attic, and I'm getting my signal on Band 20 from a mast 12 km away.

Thank you, Smarty/Three have 2 x 5mhz allocations in Band 20.

According to Cellmapper, the maximum speed you can expect from Band 20 is 18 meg down and 12 up on a 5mhz connection and 37 down 25 up on a 10 mhz connection: https://www.cellmapper.net/4G-speed

Is your SXT LTE6 or the original?

Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Three - couple of questions about traffic engineering
« Reply #14 on: October 08, 2020, 12:09:55 PM »

It's the Cat 4 version, the one they called "SXT LTE Kit" or RBSXTR&R11e-LTE.  The Cat 6 wasn't available at that time.

Where did you see Three having two 5MHz bands, all the info I've seen shows just a 5MHz allocation.   We get around 20-25 meg down and just over 9 up.  Looking at that Cellmapper page it seems to depend on modulation as well, and as far as I understand that is negotiated on the fly.
Logged
Pages: [1] 2