[Bloat] bbr on slashdot

[Sebastian Moeller]

> On Nov 3, 2019, at 00:38, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> 
> Sebastian Moeller said:
>> Interestingly, the naive expectation in the vice text is equal sharing
>> between all concurrent flows, if only we had a system that could actually
>> help achieving this kind of set-up that is fair to each flow... 
> 
> Is there consensus on what a flow is?  

	I believe yes, a "flow" is the set of packets that all share the same [5|3]-tuple of source and destination address as well as the protocol and if they exist source and destination port numbers.
 But as you point out that is not necessarily to only useful flow definition for the purpose of link-sharing.


> Or what the unit of traffic that 
> fairness measures should be?

	I would say the consensus is that the status quo, "no fairness guarantee of any kind (as long as nobody gets starved)" is decidedly not what users expect. In a sense any better definition will be an improvement.

> 
> It seems to me that it depends on where you are located.

	Sure, except the current anything goes is also not optimal for any party (well those that push large aggregate traffic volumes are fine with the status quo I would guess, as almost everything else will require more resources).

> 
> Consider upstream traffic:
> 
> If I'm a workstation or server, I probably want to give equal weight to each 
> connection.

	Yes, but then just do equal weight scheduling on your egress, no?

> 
> If I'm an exit router at a residence, I probably want to give equal weight to 
> each IP Address.

	But which one the src or dest one?

>  If not, pigs can game the system by making multiple 
> connections.

	Which is, as I might add not worse than what we have right now, multiple connections already give an improvement in the current system (witness those download managers that use multiple parallel TCP connections). And sending more packets into the network will cause congestion that affects everybody else already, 5-tuple fairness actually increases the difficulty of gaming the system (not by much, but the attacker now needs to put some randomness into the packet headers). Using less header information will make the attackers work more and more challenging, even though attacks will always be possible, but IMHO the valie od per-flow-fairness is not increased robustness against attacks, but rather a better predictable performance under normal conditions.
	As a "transit" provider, I would probably look only at the IP header, which means either source, destination, or source and destination addresses or prefixes for IPv6  as flow defining entities (in that case just randomizing port numbers will not gain much for an attacker, now IP addresses need to be randomized).


>  But if I have a server, maybe I want to reserve or limit the 
> bandwidth it gets - reserve to keep the workstation/laptop traffic from 
> killing the server and limit so the workstation/laptop people can get some 
> work done when the server is busy.

	And nothing in a default per-flow fairness world will prohibit you doing this, just as it is possible in the current anything goes world, no?

> 
> If I'm an ISP customer facing router, I probably want to give equal weight to 
> each customer, probably scaled by how much bandwidth they are paying for.
> 
> I don't know how to handle backbone routers.  You probably want to treat each 
> customer as a flow, again scaled by how much bandwidth they are paying for.  

	In theory perhaps, in practice that scaling either requires to tag each packet with the bandwidth allotment or a costly lookup. As far as I can tell the current solution is to restrict enduser rates at the first viable choke point, the internet access link and simply not care in the back-bone or at peerings. IMHO using any flw definition at back-bone or peering links will be a big improvement over the status quo, so I believe the actual choice is not that inmportant as long as one is chosen.


> But an IP level packet doesn't tell you anything about which customer it came 
> from.

	Well yes and no, unless spoofed, the source IP-address pretty much tells you the source "customer", in IPv6 its is going to be the prefix for most end users on IPv4 it will be the full /32. IMHO the goal should not not to find the optimal solution (which heavily depends on the optimization criterium), the goal should be to improve upon the status quo, and make network performance easier to predict.

> 
> If this is old news, please point me at a good writeup.

	I have no write-up of this available, but none of my points above are original in any way, so I am sure must be write-ups somewhere.

Best Regards
	Sebastian


> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat