Kitz Forum

Broadband Related => Broadband Technology => Topic started by: aesmith on October 05, 2020, 02:26:53 PM

Title: Three - couple of questions about traffic engineering
Post by: aesmith 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
Title: Re: Three - couple of questions about traffic engineering
Post by: Weaver 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?
Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: niemand on October 05, 2020, 06:47:18 PM
No QoS. The router buffers traffic then drops it once the buffer is full.
Title: Re: Three - couple of questions about traffic engineering
Post by: Alex Atkin UK 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith 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).
Title: Re: Three - couple of questions about traffic engineering
Post by: niemand 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 (https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) or WFQ (https://en.wikipedia.org/wiki/Weighted_fair_queueing).

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.
Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: meritez 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?
Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: niemand 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: meritez 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?

Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith 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.
Title: Re: Three - couple of questions about traffic engineering
Post by: meritez on October 08, 2020, 02:20:25 PM
2 x 5mhz allocations: https://3g.co.uk/guides/what-frequencies-does-three-network-use

Site that gives far more detail, though 3 now support Carrier Aggregation of B3+B20, and B32, etc, not just B1+B3: https://halberdbastion.com/intelligence/mobile-networks/three-uk-3
Title: Re: Three - couple of questions about traffic engineering
Post by: aesmith on October 08, 2020, 04:31:56 PM
Cheers, I wonder if they use the two bands as alternatives in different places.  My router just says 5MHz and the cell information says
Bandwidth*   5 MHz
Uplink Frequency   834.5 MHz
Downlink Frequency   793.5 MHz

Title: Re: Three - couple of questions about traffic engineering
Post by: niemand on October 09, 2020, 03:05:07 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.

----

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.

Missed these.

The amount of spectrum you're provided, LTE uses frequency division on the uplink, depends on your data requirements so it constantly varies. There's a scheduler that in concert with your device works out an allocation then provides it dynamically.

The modulation order and, hence, efficiency, also change depending on conditions. Can be 2 or 4 bits per Hz with 6 bits per Hz optional on uplink.

With these in mind there's no way for the device to know what the bandwidth is until the cell tower has informed it of its upstream frequency allocation during that period alongside the modulation order to use for that burst.