Re: [Ecn-sane] [tsvwg] per-flow scheduling

[Sebastian Moeller <moeller0@gmx.de>]

> On Jun 23, 2019, at 00:09, David P. Reed <dpreed@deepplum.com> wrote:
> 
> [...]
>  
> per-flow scheduling is appropriate on a shared link. However, the end-to-end argument would suggest that the network not try to divine which flows get preferred.
> And beyond the end-to-end argument, there's a practical problem - since the ideal state of a shared link means that it ought to have no local backlog in the queue, the information needed to schedule "fairly" isn't in the queue backlog itself.  If there is only one packet, what's to schedule?
>  
[...]

Excuse my stupidity, but the "only one single packet" case is the theoretical limiting case, no? 
Because even on a link not running at capacity this effectively requires a mechanism to "synchronize" all senders (whose packets traverse the hop we are looking at), as no other packet is allowed to reach the hop unless the "current" one has been passed to the PHY otherwise we transiently queue 2 packets (I note that this rationale should hold for any small N). The more packets per second a hop handles the less likely it will be to avoid  for any newcomer to run into an already existing packet(s), that is to transiently grow the queue.
Not having a CS background, I fail to see how this required synchronized state can exist outside of a few steady state configurations where things change slowly enough that the  seemingly required synchronization can actually happen (given that the feedback loop e.g. through ACKs, seems somewhat jittery). Since packets never know which path they take and which hop is going to be critical there seems to be no a priori way to synchronize all senders, heck I fail to see whether it would be possible at all to guarantee synchronized behavior on more than one hop (unless all hops are extremely uniform).
I happen to believe that L4S suffers from the same conceptual issue (plus overly generic promises, from the RITE website:
"We are so used to the unpredictability of queuing delay, we don’t know how good the Internet would feel without it. The RITE project has developed simple technology to make queuing delay a thing of the past—not just for a select few apps, but for all." this seems missing a conditions apply statement)

Best Regards
	Sebastian