"WiFi X"

[steve30]

I just got this 5 minute long advert on Youtube prior to watching an EEVBlog video, so I thought it was worth posting here.

It claims that ISPs have a 'dirty secret'; basically traffic shaping, and slow people down in the evenings. Well, traffic shaping in ISPs isn't really a secret. The video shows what appears to be a 'WiFi Repeater' which will improve the range (fair enough), but also claims to bypass this ISP traffic shaping  .

Here's the website: https://get-wifi-x.com/

[AVGresponding]

Probably just a repeater, which will give a speed boost in poor signal areas of your house I suppose.

I don't see how it's possible to bypass ISP speed controls when it's clearly routing through the existing hub anyway   

[Raj]

Probably just a repeater, which will give a speed boost in poor signal areas of your house I suppose.

I don't see how it's possible to bypass ISP speed controls when it's clearly routing through the existing hub anyway   

unless the ISP is slowing specific sites and these hubs are making other's hub become their vpn exit nodes  (just kidding)

a local cache server would definitely speed up frequently visited pages btw.

[madires]

Slow internet access in the evening is mostly caused by lots of users enjoying internet content at the same time and overbooking by the ISP. No need for the ISP to spend much effort in managing complex traffic shaping rules across the network.

Circumventing traffic shaping is possible when the ISP did a bad job in configuring QoS for VoIP or other services, i.e. if they only check the DiffServ bits in the IP packet to move a packet to the fast track queue. If they also check for ports and/or IP addresses then it won't work. My guess is that WiFi X simply overwrites the DiffServ bits, something a SOHO router (OpenWRT is great for that) can do also.

BTW, it's feasible to offer internet access with user driven QoS and corresponding billing.

[Jeroen3]

I'm not capable to create more than one pppoe with my ISP. It's point-to-point and the remote router doesn't accept more than 2 (one for ipv4 and one for ipv6).

Well, you can bypass traffic shaping by masking the packet signature, but you have to unmask it somewhere. This is what they all a VPN.

[madires]

Some ISPs limit speed by dial up instances, so their server only handles one type of speed limitation.

To prevent users from dialing more than they paid for, ISPs usually offer pppoe to Ethernet converter (built with coax/fiber modem in the same box).

I guess this device is a pppoe client that bypasses the internal pppoe of modem and dials more connections than you paid for.

Usually ISPs/telcos limit throughput at the data link layer because it's the most simple and effective way. At the network layer (IP in this case) it's harder since it will increase the router load. And RADIUS takes care about users trying to establish multiple PPPoE links.

[madires]

I'm not capable to create more than one pppoe with my ISP. It's point-to-point and the remote router doesn't accept more than 2 (one for ipv4 and one for ipv6).

That setup is a bit strange, since PPP is designed to support multiple protocols in one session. So running IPv4 and IPv6 in one PPPoE link is fully supported. Of course, you can run a PPPoE link for each protocol, but it's uncommon and needs to be supported by the ISP.

Side note: An initial intention of PPPoE was that each PC in a LAN could have its own internet access via a shared DSL modem.

Well, you can bypass traffic shaping by masking the packet signature, but you have to unmask it somewhere. This is what they all a VPN.

... and the VPN traffic ends up in the same "best effort" queue as any other traffic.

[Jeroen3]

The strange pppoe setup is probably because it is the only provider that supports ipv6 in the netherlands.
In what traffic shaping group you end up with the vpn depends on how you mask the traffic.

[madires]

The strange pppoe setup is probably because it is the only provider that supports ipv6 in the netherlands.

Just one? Because of the lack of IPv4 addresses we already have IPv6-only servers/services.

In what traffic shaping group you end up with the vpn depends on how you mask the traffic.

... depends on what your ISP does or supports. They can overwrite any of your DiffServ settings if they like to.

[NiHaoMike]

In some cases, you actually could get greater bandwidth by running many streams in parallel, usually when the limit is something other than the line to your house. (If you're getting close to the advertised bandwidth, such a device is unlikely to increase it.) Then there's blocking ads so they don't waste bandwidth...

[TomS_]

In what traffic shaping group you end up with the vpn depends on how you mask the traffic.

Eh? The ISP shouldn't care what VPN you use, or if you're even using a VPN at all. To them, it's all IP traffic, and they will shape (or perhaps police) it all equally to what ever rate is required to offer the speed you purchase.

I also don't understand what exactly you mean by "mask"?

[AVGresponding]

Internet data packets have several layers of data.

The "mask" being referred to is the IPv4 address the packet originates from. You can alter it to make it look like it came from somewhere else by changing the mask, which is what translates the intra addy to the outer one, sort of.
I'm not the greatest at explaining this stuff...

[TomS_]

Internet data packets have several layers of data.

The "mask" being referred to is the IPv4 address the packet originates from. You can alter it to make it look like it came from somewhere else by changing the mask, which is what translates the intra addy to the outer one, sort of.
I'm not the greatest at explaining this stuff...

I work as a network engineer, so I know how IP works. 

Im trying to understand what "mask" is supposed to mean, because that isnt terminology I am used to. Unless people are talking about "masquerading", which is terminology I have seen when using Linux as a router, but sounds like another way to say NAT.

But I dont think Ive ever heard of any residential ISP classify different types of traffic and shape or police them differently on an individual service basis - that requires a lot of grunt in the BRAS or LNS. There have been discussions about doing that on a network-wide basis in the US, ala network neutrality, but thats a commercial play between network operators and content providers and not at all something intended to benefit the end user (except when the content provider agrees to pay the network operator to provision or allow more bandwidth to improve the end user experience). In my experience, ISPs will typically just count all traffic equally and shape or police your service to x speed. Maybe some niche ISPs do it... Would be interested to hear of any specific examples so I could look into it.

So as I understand it, and I have built and run access level ISP networks and infrastructure in my time, simply using a VPN isnt going to somehow magically make you avoid what ever traffic shaping/policing your ISP implements. There are still IP packets coming from your broadband service which count towards what ever throughput quota your service is assigned.

Otherwise, a VPN is just a VPN. Its not "masking" anything in any kind of special way, its just doing what a VPN does - encapsulate your traffic and encrypt it in transit to some other location. No different to a corporate VPN, just maybe with a slightly more user friendly interface wrapped around it. Any other suggestion is just marketing BS that all of these VPN companies come up with to justify their existence IMO.

[madires]

Changing the source IP address is called spoofing. Unless you're trying do DOS some service address spoofing won't help you much. If you change the source address the response will be sent to the spoofed address, not to you. So you won't be able to establish a TCP connection for example. Also some ISPs have anti-spoof filters in place.

The term "mask" could relate to changing port numbers, e.g. running a VPN via TCP port 80 to make it look like HTTP. That's a common way to evade firewall rules. But if that traffic runs through an ALG (application layer/level gateway) or a DPI firewall it will be detected as non-HTTP and dropped.

About traffic shaping / QoS I'd like to add that ISPs/telcos offering VoIP typically apply QoS rules to prioritize VoIP traffic. Any other traffic goes into the "best effort" queue. And there's another thing to know. Even without any QoS configuration carrier-grade routers prioritize network management and routing protocols, while everything else is "best effort".

[AVGresponding]

Spoofing isn't what I was intending to mean, I was referring to IPv4 masking that's used between an intranet and the internet to effectively increase the number of available addresses.

[olkipukki]

Here's the website: https://get-wifi-x.com/

Their 'Terms of Use' stated:
redirected to https://amazingtechsale.com/intl/legal/term.php?prod=wifiultraboost&net=1005&variation=wifix

By making a purchase on this website you enter into an agreement with NOVADS OU, company registered in Hong Kong , having its registered office at:
Valukoja 22, 3th Floor Tallinn, Estonia, 11415 .

This agreement will be governed by the laws of Hong Kong.
OVADS OU as the contracting party for its customers is responsible for dispute management,
cancellations and refunds related to payments for purchases made on this website

 

Meanwhile 'Contact Us'...

Contact WifiX

Contact our Customer service team Call:
International: +44 20 3808 9234, available 24h
Brazil: +552135003992, available between 9:00am to 14:00pm, Monday to Friday (Brazil Time, GMT-5)
Send an email to: support@hyperstech.com

NOVADS OU
Valukoja 22, 3th Floor Tallinn, Estonia, 11415

and a public print out from Estonia's company house leads to http://novads.co => https://igadget24.com with similar "superb" gadgets 

[TomS_]

Even without any QoS configuration carrier-grade routers prioritize network management and routing protocols, while everything else is "best effort".

I find that an interesting statement. Routing protocols will indeed mark their traffic with some high priority (exactly which one escapes me right now, and my google foo is failing to find an answer quickly), but as I understand it, unless you actually configure QoS and act on those markings, those packets will just be pooled with all other traffic and effectively become BE like everything else.

Ive been working primarily with optical networks and automation the last couple of years, so if something has changed then maybe Ive missed it...

[madires]

Spoofing isn't what I was intending to mean, I was referring to IPv4 masking that's used between an intranet and the internet to effectively increase the number of available addresses.

That's commonly called NAT.

[madires]

I find that an interesting statement. Routing protocols will indeed mark their traffic with some high priority (exactly which one escapes me right now, and my google foo is failing to find an answer quickly), but as I understand it, unless you actually configure QoS and act on those markings, those packets will just be pooled with all other traffic and effectively become BE like everything else.

The details differ based on each implementation, but generally speaking each interface has a set of queues for outgoing packets to make QoS work. Locally generated netmgt/routing specific packets are put into the high priority queue automatically without any QoS related configuration. It's simply the default action.

Ive been working primarily with optical networks and automation the last couple of years, so if something has changed then maybe Ive missed it...

It's an old feature.

[OwO]

Getting a bigger share of the bandwidth is very easy, all you need to do is make TCP not back off as aggressively when there is packet loss. Your ISP never limits your *line rate*, which is how fast you are physically able to transmit packets. The way your ISP limits your speed is to drop packets above a certain data rate. However if you have not hit your speed cap (set by your subscription), you can usually get more packets through by transmitting more packets in the first place (the loss rate is constant). TCP does not help you with this; as soon as it sees packet loss it backs off the send rate.

[madires]

Sorry, but your comment is contracting itself. If your ISP limits your throughput by a rate limit how would changing TCP's sliding window increase throughput (besides the protocol's efficiency)? In case of a hard rate limit any additional packet above the limit will be simply dropped. Most rate limit implementations also allow the configuration of bursts, i.e. allowing some packets more for a short period. But if you exceed those too, the additional packets will be dropped again. A prevalent problem of SOHO routers and WIFI APs is bufferbloat which conflicts with TCP's way of handling congestions. I have no idea how many vendors have added/enabled CoDel. It's supported by linux for a while.

In the EU the customer's data throughput is usually limited by the line because it's simple to do and reduces load on the access routers. Rate-limiting on access routers with hundreds of subscribers is more expensive (resources). By line I mean the line profile used by the access technology, e.g. DSL, not the physical line. I can set a specific DSL profile in the DSLAM/MSAN to limit the throughput. Even if you run multiple PPPoE links over that DSL line you can't exceed the line's data throughput. And since DSL runs over telephone wire you also have less interference problems between lines when using limited DSL profiles instead of using the maximum possible. I don't know the reason why some ISPs prefer to rate-limit on access routers. At first glance it sounds like a bad idea.

[TomS_]

The details differ based on each implementation

Definitely seem to be the case. I had to go ask some other network friends, and they mostly said the same thing: depends on vendor/hardware/software and/or default settings.

I feel like Ive been living a lie all of this time. 

[OwO]

However if you have not hit your speed cap (set by your subscription), you can usually get more packets through by transmitting more packets in the first place (the loss rate is constant). TCP does not help you with this; as soon as it sees packet loss it backs off the send rate.

I'm talking about the case of backbone packet loss, when you aren't getting the advertised speeds. In that case you can increase your throughput by adjusting TCP to tolerate higher packet loss.

[TomS_]

In the EU the customer's data throughput is usually limited by the line because it's simple to do and reduces load on the access routers. Rate-limiting on access routers with hundreds of subscribers is more expensive (resources). By line I mean the line profile used by the access technology, e.g. DSL, not the physical line.

Previous ISPs I have worked at also rate limited at the LNS/BRAS.

If a customer is the receiver of some "unwanted attention", then without rate limiting at the BRAS/LNS, you'll end up forwarding potentially many gigabits/sec into your access network. If you also rate limit the customer session to the same as their downstream rate, then the BRAS/LNS just drops excess traffic.

Doesnt really help the rest of your network, and is definitely more resource hungry, but saves your access network and the rest of the customers on it until you can blackhole the destination.

[madires]

However if you have not hit your speed cap (set by your subscription), you can usually get more packets through by transmitting more packets in the first place (the loss rate is constant). TCP does not help you with this; as soon as it sees packet loss it backs off the send rate.

I'm talking about the case of backbone packet loss, when you aren't getting the advertised speeds. In that case you can increase your throughput by adjusting TCP to tolerate higher packet loss.

Time for some basics. TCP has a built-in mechanism to deal with packet loss and congestion. To ensure reliable packet transport the receiver acknowledges received packets. For more efficiency the receiver acknowledges several packets in a row by one ACK packet. The sender waits for the ACK and then sends the next batch of packets. If the sender doesn't receive ACKs within some timeout period he will retransmit the lost packets. The maximum number of un-acknowledged packets is controlled by the "sliding window" algorithm. With a low packet loss (no congestion) the window will be large. And with a high packet loss (congestion) the window size will be small. That way TCP adapts itself automatically to the available data rate / packet loss between sender and receiver.

How would you adjust TCP to tolerate a higher packet loss?