Re: tc question about ingress bandwidth splitting

[Philip Prindeville <philipp_subx@redfish-solutions.com>]

> On Mar 23, 2020, at 3:36 AM, Marc SCHAEFER <schaefer@alphanet.ch> wrote:
> 
> On Mon, Mar 23, 2020 at 07:47:11AM +0100, Gáspár Lajos wrote:
>> Just a tip: AFAIK, you can only limit your sending bandwith... Everything
>> what you already received is already on your device... :)
> 
> Right, however in case you do not have control on the sending
> device, you can slow down or loose TCP ACKs to slow down
> the opposite direction TCP traffic.


Exactly.  That’s my desire.

The sender calibrates based on 4 observed end-to-end path properties:

1. min path MTU, i.e. the smallest of all per-hop path MTU’s (likely doesn’t come into play here);
2. end-to-end delay, i.e. the summation of all per-hop delays, which we can artificially increase (shape) on the final internal hop to affect sender pacing;
3. end-to-end bandwidth, again the minimum bandwidth for the slowest hop along the path, which we can also artificially increase on the final internal hop to affect sender pacing;
4. end-to-end loss, the product of the reliability of all per-hop lossiness (hopefully we won’t be increasing lossiness, with the last hop having a reliability of 1.0, assuming that delay provides enough back pressure that we don’t need to actually drop any packets);

So the intention is to use (2) and (3) to apply back-pressure to the sender to influence his congestion avoidance.

Hopefully that makes things a little more clear!

So, back to my main question… what do the tc/htb commands look like to configure a tree that’s spread out across multiple (well, two in this case) interfaces?  Is that even possible?

I guess I could do all of the shaping on the “wan” interface, including on ingress… and just use the destination subnet (post NATting, obviously) on ingress, and based on the source subnet or “indev” on egress.

Thanks,

-Philip