> On Nov 3, 2019, at 00:38, Hal Murray <[email protected]> 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
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
