Draft: draft-ietf-taps-interface

Commentary: ( well , the priority framework is still confusing , this PR makes it clear that that is intentional , and why ) 
  ( I think ) said that he 'd check this offline after the Sep 11 interim . 
 At 8.1.2 you say lower values have higher priorities for connPrio . But later , at msgPrio , higher values have higher priority , and in the examples where you speak of the interaction of connPrio and msgPrio , you imply that higher means higher for both properties . Please check for consistency and clarify . 
 Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this , e.g. PR which I do n't know ... too many iterations have mangled the text . 
 Aha , now I see what happened : following some more PRs , also , in PR , re - introduced some text saying that sends on Connections with lower - priority values will be prioritized over sends on Connections with a higher - priority value . This reverses the logic for some part of the text - I suspect that ( very understandably ! ) forgot what happened and this created this mix . We have been editing these documents for way too long ! 
 I 'm not sure the priority framework really fits together . Sec 6.4 says we ' should ' do something that sounds like WFQ , but 7.1.5 allows the application to decide what happens . Meanwhile message priority suggests a strict priority - based scheduler . Meanwhile , in sec 8.1.3.2 " Note that this property is not a per - message override of the connection Priority - see Section 7.1.3 . Both Priority properties may interact , but can be used independently and be realized by different mechanisms . " At the risk of overindexing on a partly - baked draft in httpbis , how would I implement strict priority of HTTP/3 streams over a taps API that implements QUIC ? Would I need to request strict priority in both connection priority and message priority ? Or I guess connection priority would be sufficient ? 
 We seem comfortable with the mechanisms in the API , but we should have more text connecting the various sections explaining priority . 
 My comment concerned " 7.1.3 . Priority ( Connection ) " , my thought was this just influences the sender - side to control queuing within a connection group . If so , if it worth calling this property " Group Priority " and explain this is sender - side ? 
 I find the priority framework perhaps overspecified at the connection level and underspecified at the message level , with the interaction between the two left explicitly unstated . I would almost rather see the priority type and meaning left completely implementation - specific ; otherwise , my suspicion is that someone will write an application using numeric priorities , declare victory when it works fine on one platform , and not understand that the behavior is not universal . In general , I think if  is going to produce a consistent , easily - understandable , and portable API , it needs to stick to easily - understood abstractions . Message - level priority is sort of like the TCP URG mechanism ( though better specified and more useful , for sure ) , but I 'm thinking urgent messages sent explicitly out - of - band ( e.g. , new Connection ) with implementation - specific QoS will produce more consistent , predictable , and understandable outcomes in the pessimal case . 
 Ok for me ( and thanks for doing this!)Some nits , but I believe this addresses my concerns in the issue .
Paragraph (version A):
Calling Clone on a Connection yields a group of Connections: the
parent Connection on which Clone was called, and a resulting cloned
Connection.  The connections within a group are "entangled" with each
other, and become part of a Connection Group.  Calling Clone on any
of these Connections adds another Connection to the Connection Group,
and so on.  "Entangled" Connections share all Connection Properties
except "Priority (Connection)", see conn-priority.  Like all other
Properties, Priority is copied to the new Connection when calling
Clone(), but it is not entangled: Changing Priority on one Connection
does not change it on the other Connections in the same Connection
Group.
Paragraph (version B):
Calling Clone on a Connection yields a group of Connections: the
parent Connection on which Clone was called, and a resulting cloned
Connection.  The connections within a group are "entangled" with each
other, and become part of a Connection Group.  Calling Clone on any
of these Connections adds another Connection to the Connection Group,
and so on.  "Entangled" Connections share all Connection Properties
except "Connection Priority", see conn-priority.  Like all other
Properties, Connection Priority is copied to the new Connection when
calling Clone(), but it is not entangled: Changing Connection
Priority on one Connection does not change it on the other
Connections in the same Connection Group.
Paragraph (version A):
The Connection Property "Priority" operates on entangled Connections
as in msg-priority: when allocating available network capacity among
Connections in a Connection Group, sends on Connections with higher
Priority values will be prioritized over sends on Connections with
lower Priority values.  A transport system implementation should, if
possible, assign each Connection the capacity share (M-N) x C / M,
where N is the Connection's Priority value, M is the maximum Priority
value used by all Connections in the group and C is the total
available capacity.  However, this Priority setting is purely
advisory, and provides no guarantees about the way capacity is
shared.  Each implementation is free to implement a way to share
capacity that it sees fit.
Paragraph (version B):
The Connection Priority Connection Property operates on entangled
Connections using the same approach as in msg-priority: when
allocating available network capacity among Connections in a
Connection Group, sends on Connections with lower Priority values
will be prioritized over sends on Connections with higher Priority
values.  Capacity will be shared among these Connections according to
the Connection Group Transmission Scheduler property (conn-
scheduler).  See priority-in-taps for more.
Paragraph (version A):
This Property is a non-negative integer representing the relative
inverse priority (i.e., a lower value reflects a higher priority) of
this Connection relative to other Connections in the same Connection
Group.  It has no effect on Connections not part of a Connection
Group.  As noted in groups, this property is not entangled when
Connections are cloned, i.e., changing the Priority on one Connection
in a Connection Group does not change it on the other Connections in
the same Connection Group.
Paragraph (version B):
This Property is a non-negative integer representing the relative
inverse priority (i.e., a lower value reflects a higher priority) of
this Connection relative to other Connections in the same Connection
Group.  It has no effect on Connections not part of a Connection
Group.  As noted in groups, this property is not entangled when
Connections are cloned, i.e., changing the Priority on one Connection
in a Connection Group does not change it on the other Connections in
the same Connection Group.  See priority-in-taps.
Paragraph (version A):
Note that this property is not a per-message override of the
connection Priority - see conn-priority.  Both Priority properties
may interact, but can be used independently and be realized by
different mechanisms.
Paragraph (version B):
Note that this property is not a per-message override of the
connection Priority - see conn-priority.  The Priority properties may
interact, but can be used independently and be realized by different
mechanisms; see priority-in-taps.
Paragraph (version B):
The Transport Services interface provides two properties to allow a
sender to signal the relative priority of data transmission: the
Priority Message Property msg-priority, and the Connection Priority
Connection Property conn-priority.  These properties are designed to
allow the expression and implementation of a wide variety of
approaches to transmission priority in the transport and application
layer, including those which do not appear on the wire (affecting
only sender-side transmission scheduling) as well as those that do
(e.g.  I-D.ietf-httpbis-priority.
Paragraph (version B):
A Transport Services system gives no guarantees about how its
expression of relative priorities will be realized; for example, if a
transport stack that only provides a single in-order reliable stream
is selected, prioritization information can only be ignored.
However, the Transport Services system will seek to ensure that
performance of relatively-prioritized connections and messages is not
worse with respect to those connections and messages than an
equivalent configuration in which all prioritization properties are
left at their defaults.
Paragraph (version B):
The Transport Services interface does order Connection Priority over
the Priority Message Property.  In the absense of other externalities
(e.g., transport-layer flow control), a priority 1 Message on a
priority 0 Connection will be sent before a priority 0 Message on a
priority 1 Connection in the same group.