Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-15.txt

[Sebastian Moeller <[e-mail]>]

Hi Ruediger,

> On Mar 30, 2023, at 09:23, [e-mail] wrote:
> 
> Alex,
> 
> is that Maxwells Demon scheduler working similar as the one on slide 5 of
> https://datatracker.ietf.org/meeting/116/materials/slides-116-iccrg-alternative-best-effort-abe-for-service-differentiation-trading-loss-versus-delay  ?
> 
> The scheduler described by that publication isn't NQB, it trades low delay for packet loss during congestion. Another notable difference is, that NQB allows packets which can't be scheduled by the low delay queue, to get access to the default queue. Hence these packets are the only ones being able to access both schedulers, low delay and default. So there's no strict priority in NQB scheduling at the NQB scheduler itself, however there's exclusive access to scheduler resources for a particular kind of traffic (NQB at the expense of default/QB). In the end I think, NQB is able to seize more bandwidth than QB.

	[SM] I assume the problem is that it seems intended to put NQB traffic into the LL-queue of an L4S scheduler. So it appears as if the goal for the NQB PHB is to not put additional constraints on the L4S scheduler. Now, this is clearly speculation, but it is based on the docsis' low-latency design. The consequence of that is however that the NQB queue can be abused easily (reasonably paced traffic that is application limited below 50% of capacity but that is above the 1 Mbps recommended rate, will see both reduced latency variability and potentially a larger capacity share (assuming more than one additional flow). 
	Side-note: I disagree with the notion, that assuring that QB and NQB share the capacity equitably between classes is an acceptable goal. As far as I understand the goal should be that all individual flows get roughly the same chance" to transmit their packets, which to me means rough per-flow equitable sharing (everything else ends up picking winners and loosers, which is fine as explicit policy, but IMHO not as default for a PHB that claims compatibility with DF traffic)

[SM] The current draft claims:
"The PHB is also designed to minimize any incentives for a sender to mismark its traffic, since neither higher priority nor reserved bandwidth are being offered. "

but the recommended optional enforcements do not actually assure that, see the described way to gain >= 50% of capacity for a single NQB flow over multiple QB flows in the likely earliest NQB deployment (as part of low-latency docsis).



> 
> While the authors of the above material present a fair amount of measurement results giving some indication how the scheduler impacts transport while not having been editing any ID, I note that the authors of NQB, a standards track doc, didn't publish any measurement or simulation result within IETF. 

	[SM] +1; this is also unexpected, given that within the docsis low-latency frame work there already should be a usable implementation available that could already have been submitted to laboratory and real-world testing (with knowingly participating networks).


> 
> A kind of priority or "unfair advantage" (not sure it's the right term) results from shallow queues, once the default queue depth is approaching congestion free RTT. I didn't give it a deep thought, but could that say, the default queue of such an experiment is of sub-optimal depth if it is on the order of the RTT or bigger (and should be decreased)?

	[SM] I would guess that the default queue would be sized in accordance to some theory (e.g. expected BDP, or expected BDP/square-root(number concurrent flows), or similar). Exactly because to serve for example TCP-Reno flows at acceptable utilization the deep queue is deep, and is expected to show some delay variability. It is partly that variability that NQB aims to "keep away" from the NQB queue. This clearly requires an "unfair transmit slot access" but that is IMHO part of the PHB's definition and purpose*, however the (potentially/likely) unfair access to >= 50% of link capacity is not something the draft sufficiently discusses.

Best Regards
	Sebastian


*) It is clear to me that this requires some form of prioritization, hence I argue that the draft should not claim "without prioritization".



> 
> Regards, Ruediger
> 
> 
> Alex wrote: 
> 
> The following thought experiment should illustrate that moving from a single queue, to two queues with a scheduler between them, can be positive sum for latency/delay:
> 
> We have two traffic types A and B. In the "control group" case, they are in the same queue. In the test case, we separate them into two queues. The queue for type A offers the same treatment the original single queue. The queue for type B has a different treatment with a shallow queue.
> 
> The scheduler between the two is  Maxwell's Demon. The demon knows exactly which time slots the packets from each type *would have used* if they had been moving through as single queue. It schedules as follows:
> * When a packet of type A would have exited the single queue, the demon lets through a packet from queue A. 
> * When a packet of type B would have exited the single queue, the demon lets through a packet from queue B.
> * If a packet from the appropriate queue is not available, it lets the slot go empty.
> 
>