# ISP throttling on the PPP interface.

## dE_logics

I was wondering how the PPP interface works.

Suppose, the ISP provides the Internet connection via PPP; Linux spawns a PPP interface to get access to the connection and the speed of the connection is limited not to the medium (like Ethernet, wireless etc...), but by the ISP at it's point of presence.

In case the rate of incoming packets (from the Internet) or outgoing packets is higher than the speed the ISP limits, where will the input/output packet queue be placed? On the PPP interface or on the ISP's end?

----------

## NeddySeagoon

dE_logics,

There won't be a queue.  If your ISP, or a carrier does throttling, its by dropping your outgoing packets so they do not receive responses any faster than they can//want to deliver them to you.

This avoids them discarding data that has already travelled (uselessly) over their network

Its interesting that you mention PPP.  The MTU for PPPoE is 1492, as the PPP header (eight bytes) has to fit into a standard Ethernet packet.

This means that all your interfaces that originate packets that may travel over a PPPoE link should use a MTU of 1492, not the default 1500.

This avoids packet fragmentation and reassembly which will have a significant impact on your data rate when the system is trying to send packets >1492 bytes.

----------

## szatox

if it's ISP that limits speed (and usualy it is), he limits it on his end. He can't even access your end, can he? At least he shouldn't.

Anyway, check out HTB for details (hieracial token bucket) - ofcourse it's not the only way, but the idea behind it will be pretty much the same regardless of particualr implementation.

Also, some ISPs only care for how fast you can download and don't even bother with throtling your upload speed, so they only need the easy part with outgoing packets (From their point of view - those you will se as incoming). Limiting speed of incoming packets seems to be a bit more tricky and might require looping them over virtual network interface so you can limit them in outgoing queue as well.

----------

## dE_logics

 *NeddySeagoon wrote:*   

> dE_logics,
> 
> There won't be a queue.  If your ISP, or a carrier does throttling, its by dropping your outgoing packets so they do not receive responses any faster than they can//want to deliver them to you.
> 
> This avoids them discarding data that has already travelled (uselessly) over their network
> ...

 

Same for packets which are sent (from the client)?

What I was originally wondering about the PPP protocol, is that the protocol checks if the line is free; to throttle the traffic, the ISP claims the the line is not free queuing up the packet on the client's end. If the client forces a packet thought, the connection is dropped.

I'm glad that you reminded me of the MTU. There is a PPP modem which negotiates the actually PPP connection. My local LAN has MTU of 1500, that mean the router must be fragmenting the packet to get it fit into 1492?

----------

## dE_logics

 *szatox wrote:*   

> if it's ISP that limits speed (and usualy it is), he limits it on his end. He can't even access your end, can he? At least he shouldn't.
> 
> Anyway, check out HTB for details (hieracial token bucket) - ofcourse it's not the only way, but the idea behind it will be pretty much the same regardless of particualr implementation.
> 
> Also, some ISPs only care for how fast you can download and don't even bother with throtling your upload speed, so they only need the easy part with outgoing packets (From their point of view - those you will se as incoming). Limiting speed of incoming packets seems to be a bit more tricky and might require looping them over virtual network interface so you can limit them in outgoing queue as well.

 

I'm trying to QoS, so I was analyzing if something can be done on my end.

If the queue is not in my control (or there's no queue at all), I'll throttle the connection on my end -- that way I decide which packets to go first and ensure nothing is dropped.

----------

## NeddySeagoon

dE_logics,

Your downlink cannot be throttled - there is nothing special about PPP there.

There is no queue either.

To avoid the need for queueing, the uplink is controlled by dropping packets so that data does not arrive at network boundary faster than it can be delivered to you.

This makes your network resend the packets that get dropped.

Your router will be splitting packets bigger that 1492 bytes into two that you send and reassembling any fragments that it receives from the outside world.

However, there is a process called link MTU discovery, which if it works will set the MTU actually used to the minimum MTU supported along the route, so no fragmentation occurs anywhere.

----------

## dE_logics

 *NeddySeagoon wrote:*   

> dE_logics,
> 
> Your downlink cannot be throttled - there is nothing special about PPP there.
> 
> There is no queue either.
> ...

 

Apparently MTU discovery is not working, my MTU is set at 1500.

----------

## krinn

 *dE_logics wrote:*   

> Apparently MTU discovery is not working, my MTU is set at 1500.

 

Than you should fix it.

Look at what a bad MTU will gave you : https://forums.gentoo.org/viewtopic-t-935256.html

----------

## NeddySeagoon

dE_logics,

You can discover the link MTU with ping.

Send various size packets with the 'do not fragment' bit set.  The largest packet that gets a non error response in the link MTU.

Whatever you discover is a good MTU setting.

----------

## krinn

There's no real need to make any MTU discovery for PPP, the size standard is set to 1492.

----------

## dE_logics

It's 1440 here.

----------

## NeddySeagoon

dE_logics,

1440 means that somewhere along the route you tested is a node with a MTU of 1440.

Thats a good value to set for all of the interfaces on your network.

----------

## dE_logics

Thanks for clarifying all of this.

----------

## krinn

Well, you better ask your ISP about it.

If it disable MTU discovery and use non standard size, there's something wrong then.

----------

## NeddySeagoon

krinn, 

That's a whole new nest of vipers.

----------

