Hi Stuart,
> On Oct 20, 2022, at 20:32, Stuart Cheshire <chesh...@apple.com> wrote:
>
> On 20 Oct 2022, at 02:36, Sebastian Moeller <moell...@gmx.de> wrote:
>
>> Hi Stuart,
>>
>> [SM] That seems to be somewhat optimistic. We have been there before, short
>> of mandating actually-working oracle schedulers on all end-points,
>> intermediate hops will see queues some more and some less transient. So we
>> can strive to minimize queue build-up sure, but can not avoid queues and
>> long queues completely so we need methods to deal with them gracefully.
>> Also not many applications are actually helped all that much by letting
>> information get stale in their own buffers as compared to an on-path queue.
>> Think an on-line reaction-time gated game, the need is to distribute current
>> world state to all participating clients ASAP.
>
> I’m afraid you are wrong about this.
[SM] Well possible, would not be a first. ;)
> If an on-line game wants low delay, the only answer is for it to avoid
> generating position updates faster than the network carry them.
[SM] +1; it seems I misconstrued the argument I wanted to make when
bringing up gaming though. If you allow I will try to lay out why I believe
that for some applications like some forms of gaming a competent scheduler can
be leaps and bounds more helpful than the best AQM.
Let's start with me conceding that when the required average rate of an
application exceeds the networks capacity (for too much of the time) that
application and that network path are not going to become/stay friends.
That out of the way, the application profile I wanted to describe with
the "gaming" tag is an application that on average sends relatively little,
albeit in a clocked/bursty way, where every X milliseconds it wants to send a
bunch of packets to each client; and where the fidelity of the predictive
"simulation" performed by the clients critically depends on not deviating from
the server-managed "word-state" for too long. (The longer the simulation runs
without server updates the larger the expected deviation becomes and the more
noticeable any actions that need to be taken later once world-updates arrive,
so the goal is to send world-state relevant updates as soon as possible after
the server calculated the authoritative state).
These burtst will likely be sent close to the server's line rate and
hence will create a (hopefully) transient queue at all places where the
capacity gets smaller along the path. However the end result is that these
packets arrive at the client as fast as possible.
> One packet giving the current game player position is better than a backlog
> of ten previous stale ones waiting to go out.
[SM] Yes! In a multiplayer game each client really needs to be informed
about all other players'/entites' actions. If this information is often? send
in multiple packets (either because aggregate size exceeds a packet's "MTU/MSS"
or because implementation-wise sending one packet per individual entity
(players, NPCs, "bullets", ...) is preferable. Then all packets need to be
received to appropriately update world-state... the faster this goes the less
do clients go out of "sync".
> Sending packets faster than the network can carry them does not get them to
> the destination faster; it gets them there slower.
[SM] Again I fully agree. Although in the limit case on an otherwise
idle network sending our hypothetical bunch of packets from the server either
at line rate or paced out to the bottleneck-rate of the path should deliver the
bunch equally fast. That is sending the bunch as bunch is IMHO a rationale and
defensible strategy for the server relieving it from having to keep state for
the capacity for each client.
> The same applies to frames in a screen sharing application. Sending the
> current state of the screen *now* is better than having a backlog of ten
> previous stale frames sitting in buffers somewhere on their way to the
> destination.
[SM] I respectfully argue that a screen sharing application that will
send for prolonged durations well above a path's capacity is either not
optimally designed or mis-configured. As I wrote before, I used (the free
version of nomachine's) NX remote control across the Atlantic to southern
California, and while not all that enjoyable it was leaps and bounds more
usable than what you demonstrated in the video below. (I did however make
concessions, like configuring NX to expect a slow WAN link manually, and did
not configure full window dragging on the remote host).
> Stale data is not inevitable. Applications don’t need to have stale data if
> they avoid generating stale data in the first place.
[SM] Alas no application using an internet path is in full control of
avoiding queueing. Queues have a reason to exist (I personally like
Nichols/Jacobsen description of queues acting as shock absorbers), especially
over shared path with cross traffic (at least until we finally roll-out these
fine oracle schedulers that I encounter sometimes in the literature to all
endpoints ;) ).
I do agree that applications generally should try to avoid dumping
excessive amounts of data into the network.
>
> Please watch this video, which explains it better than I can in a written
> email:
>
> <https://developer.apple.com/videos/play/wwdc2015/719/?time=892>
[SM] Argh, not a pleasant sight. But also not illustrating the case I
was trying to make.
To come back to my point, for an application profile like the game
traffic (that does not exceed capacity except in very short timeframes) a
flow-queueing scheduler helps a lot, independent of whether the greedy flows
sharing the same path are well behaved or not (let's ignore active malicious
DOS traffic for this discussion). Once you have a competent scheduler the
queueing problem moves from one "unfriendly" application can ruin an access
link for all other flows to unfriendly applications can mostly make their own
live miserable. To be clear I think both competent AQM and competent scheduling
are desirable features that complement each other.*
Regards
Sebastian
*) It goes without much saying that I consider L4S an unfortunate combination
of not competent enough AQM with an inadequate scheduler, this is IMHO "too
little, too late". The best I want to say about L4S is, that I think trying to
signal more fine-grained queuing information from the network to the endpoints
is a decent idea. L4S however fails to implement this idea in an acceptable
fashion. In multiple ways; bit banging the queueing state in a multi-packet
stream appears at best sub-optimal, compared to giving say each packet even
few-bit accumulative queue-filling-state counter. Why? Because such a counter
can be used to deduce queue filling rate quick enough to have a fighting chance
to actually tackle the "when to exit slow-start" question, something that L4S
essentially punted on (or did I miss a grand anouncement of paced chirping
making it into a deployed network stack?).
>
> Stuart Cheshire
>
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
