Change:
this message. Response time (latency) should be optimized at the expense of <del> bandwidth efficiency and delay variation when sending this </del> <ins> efficiently using the available capacity when sending this </ins> 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. <del> Delay and delay variation should be minimized at the expense of bandwidth efficiency. </del> <ins> Delay should be minimized at the expense of efficiently using the available capacity. </ins> This Message may be sent at the system's leisure.  This can be used to signal a preference for less-than-best-effort treatment, <del> to delay sending until lower-cost paths are available, and so on. </del> <ins> assign the traffic to a lower effort service, delay sending until lower-cost paths are available, and so on. </ins> 7.2.

Discussion:
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 doesn’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 doesn’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 Lifetime is not possible on a Message over a Connection not providing reliability. / This didn’t read quite correct to me, is this better: /For example, it is not possible to set an infinite Lifetime 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 Lifetime.

/ 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 didn'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 Harald was forced to invent here, for lack of any other available definition: URL ), or what? And BTW, indeed we do implement it like this in NEAT - AFAIK both the SCTP scheduler and Safiqul's coupled cc. kernel 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