Draft: draft-ietf-taps-interface

Commentary: and addresses 
 Section : Low Latency : : I really dislike the term /bandwidth efficiency/ - because we are not talking here of bandwidth in MHz , and certainly of not how efficiently the bandwidth is used from a radio perspective . Could we say /efficiently of using the available capacity/ ? I also have problems undrestaing what was intended by /and delay variation/ - because it does n’t read correctly to me . What is intended ? Section : Constant Rate : : still dislike /bandwidth efficiency/ - see above . /rate adaptive/ should this be /rate - adaptive/ ? Section : Scavenger / Bulk : : /for less - than - best - effort treatment , and so on./ can we explicitly point to the scavenger traffic class , rather than just the transport behaviour ? e.g. add /or to assign the traffic to a lower effort service/ ? ? Should we expand these abbreviations on first use ? : NAT , ICE , STUN , SIP Section : Connection Groups { # groups } Could we consider removing the following clause ... I am not sure that I buy the specification text that reads : /An ideal transport system implementation would assign the Connection the capacity share ( M - N ) x C / M , where N is the Connection 's Niceness value , M is the maximum Niceness value used by all Connections in the group and C is the total available capacity . / I ’d prefer to feel comfortable that we have running code that does this - NEAT does not implement this approach , it could do something I am sure - but do we have to write this as if we specify this in the API ? I do not like the words /about capacity allocation/ --- my rationale is that this does n’t imply using an allocation method - I ’d much prefer /about the way capacity is shared/ Similarly : /exact capacity allocation/ -- I ’d prefer : /the way an implementation shares capacity/ /For example , infinite  is not possible on a Message over a Connection not providing reliability . / This did n’t read quite correct to me , is this better : /For example , it is not possible to set an infinite  for a Message over a Connection that does not provide reliability . / or /For example , a Connection must provide reliability to allow a Message to set an infinite  . / The concept of /an infinite Lifetime/ is just a tiny little odd , does this mean the value is set to infinite - or do we really expect persistent non - volatile storage of the message until it is sent ? , I 'd perhaps geel happier if we explained this as /an infinitie value for the lifetime property means that .... / Section : Niceness { # send - niceness } The term /normal/ /Note that this inversion of normal schemes for expressing priority has a convenient property : priority increases as both Niceness and Lifetime decrease./ I wonder if this actually is clearer just to say : /This encoding of the priority has a convenient property that the priority increases as both Niceness and Lifetime decrease./ /It is most naturally represented as a non - negative integer./ the other terms are defined more concretely . Is there any reason we do not start the niceness section by saying Niceness is a numeric ( non - negative integer ) quantity . I did n't read the appendexes because I thought they were still being edited - happy to read when asked . 
 I 'll try to take care of these early next week , together with a few other updates I planned for that period . 
 About this one : I 'd rather keep this : otherwise it 's not clarified anywhere what the real meaning of a niceness value is - is it a linear priority , is it like doubling priorities per value ( as  was forced to invent here , for lack of any other available definition : ) , or what ? And BTW , indeed we do implement it like this in NEAT - AFAIK both the SCTP scheduler and Safiqul 's coupled cc .  patch do this . 
 We need to distinguish between sending unreliably , but congestion controlled , and sending unreliably without congestion control ( the application must know if it has to perform congestion control or not ) . This should influence at least the protocol and path selection properties . 
 lgtmLooks good
Paragraph (version A):
The transport services API will resolve names internally, when the
Initiate(), Listen(), or Rendezvous() method is called establish a
Connection.  The API does not need the application to resolve names,
and premature name resolution can damage performance by limiting the
scope for alternate path discovery during Connection establishment.
The Resolve() method is, however, provided to resolve a Local
Endpoint or a Remote Endpoint in cases where this is required, for
example with some NAT traversal protocols (see rendezvous).
Paragraph (version B):
The transport services API will resolve names internally, when the
Initiate(), Listen(), or Rendezvous() method is called establish a
Connection.  The API does not need the application to resolve names,
and premature name resolution can damage performance by limiting the
scope for alternate path discovery during Connection establishment.
The Resolve() method is, however, provided to resolve a Local
Endpoint or a Remote Endpoint in cases where this is required, for
example with some Network Address Translator (NAT) traversal
protocols (see rendezvous).
Paragraph (version A):
The application expects to send/receive data at a constant rate
after Connection establishment.  Delay and delay variation should
be minimized at the expense of bandwidth efficiency.  This implies
that the Connection may fail if the desired rate cannot be
maintained across the Path.  A transport may interpret this
capacity profile as preferring a circuit breaker RFC8084 to a rate
adaptive congestion controller.
Paragraph (version A):
The application is not interactive.  It expects to send/receive a
large amount of data, without any urgency.  This can be used to
select protocol stacks with scavenger transmission control, to
signal a preference for less-than-best-effort treatment, and so
on.
Paragraph (version B):
The application expects to send/receive data at a constant rate
after Connection establishment.  Delay and delay variation should
be minimized at the expense of bandwidth efficiency.  This implies
that the Connection may fail if the desired rate cannot be
maintained across the Path.  A transport may interpret this
capacity profile as preferring a circuit breaker RFC8084 to a
rate-adaptive congestion controller.
Paragraph (version B):
The application is not interactive.  It expects to send/receive a
large amount of data, without any urgency.  This can, for example,
be used to select protocol stacks with scavenger transmission
control, to signal a preference for less-than-best-effort
treatment, or to assign the traffic to a lower-effort service.
Paragraph (version B):
This property specifies whether the application would like the
Connection to be congestion controlled or not.  Note that if a
Connection is not congestion controlled, an application using such a
Connection should itself perform congestion control in accordance
with RFC2914.  Also note that reliability is usually combined with
congestion control in protocol implementations, rendering "reliable
but not congestion controlled" a request that is unlikely to succeed.
Paragraph (version A):
are given about capacity allocation and each implementation is free
to implement exact capacity allocation as it sees fit.
Paragraph (version B):
are given about the way capacity is shared.  Each implementation is
free to implement a way it shares capacity that it sees fit.
Paragraph (version A):
Send Parameters may be inconsistent with the properties of the
Protocol Stacks underlying the Connection on which a given Message is
sent.  For example, infinite Lifetime is not possible on a Message
over a Connection not providing reliability.  Sending a Message with
Send Properties inconsistent with the Transport Preferences on the
Connection yields an error.
Paragraph (version B):
Send Parameters may be inconsistent with the properties of the
Protocol Stacks underlying the Connection on which a given Message is
sent.  For example, a Connection must provide reliability to allow
setting an infinitie value for the lifetime property of a Message.
Sending a Message with Send Properties inconsistent with the
Transport Preferences on the Connection yields an error.
Paragraph (version A):
Niceness represents an unbounded hierarchy of priorities of Messages,
relative to other Messages sent over the same Connection and/or
Connection Group (see groups).  It is most naturally represented as a
non-negative integer.  A Message with Niceness 0 will yield to a
Message with Niceness 1, which will yield to a Message with Niceness
2, and so on.  Niceness may be used as a sender-side scheduling
construct only, or be used to specify priorities on the wire for
Protocol Stacks supporting prioritization.
Paragraph (version A):
Note that this inversion of normal schemes for expressing priority
has a convenient property: priority increases as both Niceness and
Lifetime decrease.
Paragraph (version B):
Niceness is a numeric (non-negative) value that represents an
unbounded hierarchy of priorities of Messages, relative to other
Messages sent over the same Connection and/or Connection Group (see
groups).  A Message with Niceness 0 will yield to a Message with
Niceness 1, which will yield to a Message with Niceness 2, and so on.
Niceness may be used as a sender-side scheduling construct only, or
be used to specify priorities on the wire for Protocol Stacks
supporting prioritization.
Paragraph (version B):
This encoding of the priority has a convenient property that the
priority increases as both Niceness and Lifetime decrease.
Paragraph (version A):
Response time (latency) should be optimized at the expense of
bandwidth efficiency and delay variation when sending this
message.  This can be used by the system to disable the coalescing
of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; to signal a
preference for lower-latency, higher-loss treatment; and so on.
Paragraph (version A):
Delay and delay variation should be minimized at the expense of
bandwidth efficiency.
Paragraph (version A):
This Message may be sent at the system's leisure.  This can be
used to signal a preference for less-than-best-effort treatment,
to delay sending until lower-cost paths are available, and so on.
Paragraph (version B):
Response time (latency) should be optimized at the expense of
efficiently using the available capacity when sending this
message.  This can be used by the system to disable the coalescing
of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; to signal a
preference for lower-latency, higher-loss treatment; and so on.
Paragraph (version B):
Delay should be minimized at the expense of efficiently using the
available capacity.
Paragraph (version B):
This Message may be sent at the system's leisure.  This can be
used to signal a preference for less-than-best-effort treatment,
assign the traffic to a lower effort service, delay sending until
lower-cost paths are available, and so on.
Paragraph (version B):
Congestion control: This boolean property informs about the
protocol carrying out congestion control or not.  This property is
read-only.