Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is)

[[e-mail]]

Greg,

I won't explain to the audience how NQB works under various usage conditions appearing in operational networks. That's a task of the editor and the authors. I'd like to ask the chairs to correct me, if I'm wrong.

Regards,

Ruediger



-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Sonntag, 12. März 2023 02:11
An: Fred Baker <[e-mail]>
Cc: Geib, Rüdiger <[e-mail]>; [e-mail]
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is)

Thanks Fred. See below [GW2]

On 3/11/23, 5:29 PM, "Fred Baker" <[e-mail] <mailto:[e-mail]>> wrote:

Sent using a machine that autocorrects in interesting ways...

> On Mar 11, 2023, at 4:05 PM, Greg White <[e-mail] <mailto:[e-mail]>> wrote:
> 
> [GW] Sections 6 & 12 already mention the consequences of both options on an application (and the consequences there are fairly obvious). I guess you are asking more broadly, what are the consequences of PHB implementers choosing the re-marking/re-classification option vs choosing the discard option, in a game-theory sense? For applications that are sensitive to packet loss, I suppose PHB implementations that choose the discard option would create a stronger disincentive for application mismarking, but on the other hand would likely create a greater degradation even for NQB-compliant applications in overload situations, as compared to PHB implementations that choose re-marking/re-classification. For applications that are out-of-order intolerant (i.e. treating a sequence gap the same as a packet loss), I suppose the two PHB implementations are roughly equivalent. 


Discarding is a measurable event if the packet contains something that can be treated as a sequence number. Dropping it into a different queue can improve the effective rate of the packet, or delay it, depending on the momentary statistics of the other queue; if the queue happens to be empty at that nanosecond, for example, it effectively adds the rates of the two queues for the duration f the packet.

[GW2] Well, I said "roughly" equivalent....   The expectation is that the other queue is a deep-buffered one carrying traditional congestion-controlled flows, so it's not unlikely that the other queue has a delay much greater than the NQB queue. But, you are right, it definitely isn't guaranteed that this is the case. A packet re-directed to an empty QB queue could, in fact, be dequeued before lower-sequence-numbered ones that remain in the NQB queue. That single re-directed packet could then invalidate all of those lower-sequence-numbered packets in an out-of-order intolerant application, and thus be more impactful than discard. Or, if the application is out-of-order tolerant, it could be less impactful than discard.  Keep in mind that these two queues share a single aggregate rate shaper and are not rate shaped independently, so the rate of the NQB queue when the QB queue is empty is the same as the sum of the rates of the two queues when neither is empty. 

I suspect your statement of the impact is somewhat cavalier.

[GW2] Yes, my goal was to invite suggestions for text that would fill the gap that Ruediger felt needed to be filled.  Since I'm not exactly sure what he'd like to see here, I thought I'd try to draw him out with some stabs in the dark.