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

[Greg White <[e-mail]>]

See [GW].

On 2/3/23, 1:17 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Greg,


Section 5.2. Traffic Protection
- draft: NQB PHB SHOULD support a "traffic protection" function...and either re-mark [offending] flows/packets as Default and reclassify them to the QB queue or discard the offending traffic.


Please discuss the consequences of both options, re-marking & reclassification as default QB on one side and discard on the other. 

[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.  In addition, https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection-06#section-5.5 has some discussion of the rationale for implementing re-classification.  I'd be curious to know what specifically you'd like to see here, and if you have any suggestions for text that would meet your requirements.


- draft: Such a function SHOULD be implemented in an objective and verifiable manner, basing its decisions upon the behavior of the flow rather than on application-layer constructs.
“flow” is neither specified nor defined by your draft (and the draft doesn’t refer to a specification of flow given by another document). 

[GW] Fair point. As you mentioned in another thread, we have a section in the DOCSIS spec (and referenced in the Q-protection draft) which discusses this. I'll add some language here (and probably also reference the DOCSIS spec as an example). 

Objectively verified against which requirements (a requirement which can be verified is, e.g.: a sending rate SHOULD average at least the configured rate when measured over any
time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate).
The draft doesn’t contain neither a specification, nor a definition, what a flow is, and it doesn't determine requirements on flow rates, which can be verified. All it offers is descriptive text to the latter.

[GW] The statement is that the implementation should be both objective and verifiable, which it then clarifies to mean that it bases its decisions on flow behavior rather than on *what* a flow is. The immediately preceding sentence defines the "function" as being one that can identify flows that are inconsistent with the sender requirements in Section 4.1.    So, what we're trying to get at is that the decision to take action SHOULD be driven by these objective aspects, and that it SHOULD be possible to verify that this is the case (presumably by introducing flows with different behavioral characteristics, or I suppose by inspecting source code).   I think it is important to state this. 

- draft: it is RECOMMENDED that traffic protection algorithms base their decisions on the detection of actual queuing, as opposed to simply packet arrival rate or data rate.


The draft doesn’t specify or define what is meant by “actual queuing”. It also doesn’t provide a reference.

[GW] It seems straightforward to me that "detection of actual queuing" means monitoring either the queue depth or queue delay in the NQB queue, and using this metric in the decision process. Would you prefer different words?


- draft: The traffic protection function MUST be designed to fail gracefully in the case that the flow state is exhausted.


I’m surprised to find a MUST here, while the major part of the queue protection mechanism isn’t specified. But to me, this requirement is vague too, as the draft doesn’t specify what is meant by “failing gracefully, if flow state is exhausted”.

[GW] What would you suggest?


Regards,


Ruediger






-----Ursprüngliche Nachricht-----
Von: tsvwg <[e-mail] <mailto:[e-mail]>> Im Auftrag von [e-mail] <mailto:[e-mail]>
Gesendet: Donnerstag, 12. Januar 2023 01:34
An: [e-mail] <mailto:[e-mail]>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-15.txt




A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.


Title : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
Authors : Greg White
Thomas Fossati
Filename : draft-ietf-tsvwg-nqb-15.txt
Pages : 25
Date : 2023-01-11


Abstract:
This document specifies properties and characteristics of a Non-
Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB
PHB is to provide a separate queue that enables smooth, low-data-
rate, application-limited traffic flows, which would ordinarily share
a queue with bursty and capacity-seeking traffic, to avoid the
latency, latency variation and loss caused by such traffic. This PHB
is implemented without prioritization and can be implemented without
rate policing, making it suitable for environments where the use of
these features is restricted. The NQB PHB has been developed
primarily for use by access network segments, where queuing delays
and queuing loss caused by Queue-Building protocols are manifested,
but its use is not limited to such segments. In particular,
applications to cable broadband links, Wi-Fi links, and mobile
network radio and core segments are discussed. This document
recommends a specific Differentiated Services Code Point (DSCP) to
identify Non-Queue-Building flows.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/>


There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html>


A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15>




Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts