Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-nada-12: (with COMMENT)

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Hi Benjamin,

Thanks a lot for reviewing this draft.  The draft has been updated to address
some of the points raised by your comments. See more detailed responses below
in line (tagged [Authors]).  The revised draft can be viewed at: 

https://tools.ietf.org/html/draft-ietf-rmcat-nada-13

Best regards,
Xiaoqing


On 9/5/19, 12:23 PM, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-rmcat-nada-12: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Thanks for this document; it provides a clear picture of an interesting
    scheme, and it will be interesting to see further reports of its
    efficacy.  I just have some essentially editorial comments, that may not
    even be worth responding to, so I will try to sneak them in after the
    telechat.
    
    Do we need to say anything further about aborting the flow when the
    level of congestion does not support even the minimum bitrate supported
    by the encoder?  Mirja thinks this is sufficiently well-known that we
    probably don't need to, which seems reasonable to me.

[Authors] The rate calculated by the congestion control module is always capped
from below by the minimum rate, and it would be up to the application to decide
whether to abort the flow if even the minimum rate cannot be supported. Therefore
we didn't mention how to handle that in this draft.  


    
    Section 4
    
       o  Accelerated ramp-up: when the bottleneck is deemed to be
          underutilized, the rate increases multiplicatively with respect to
          the rate of previously successful transmissions.  The rate
    
    "multiplicatively" is synonymous with "exponentially" here?
    (Thank you for specifying it this way, though, to make clear what the
    multiplier value is.)

[Author] Yes, the behavior of the rate during ramp-up phase would look roughly
Like "exponentially growing" so the term is synonymous to "exponential". 
We mostly chose this term as a mirror of TCP's AIMD process (where
We want the increase to be multiplicative) __ 


    Section 4.3
    
                                       QBOUND
           gamma = min(GAMMA_MAX, ------------------)     (3)
                                   rtt+DELTA+DFILT
    
    It seems impossible for the minimum to be GAMMA_MAX with the defaults
    for QBOUND, DELTA, and DFILT, since the second argument to min() is less
    than 50/(120+100) = 0.23, which is much less than the default GAMMA_MAX
    of 0.5.
    
[Author] You are right that for the given set of default values the min() operation
Is not needed. However, some implementation may choose a less aggressive GAMMA_MAX (e.g., 0.1) 
or may operate with more frequent feedback intervals (e.g., DELTA = 50ms), so we
wanted the equation to provide a mechanism for capping the multiplier value, if needed. 


    Section 5.1.1
    
       one-way delay and base delay.  By re-estimating the base delay
       periodically, one can avoid the potential issue of base delay
       expiration, whereby an earlier measured base delay value is no longer
       valid due to underlying route changes.  All delay estimations are
    
    I think that clock *rate* skew between peers could also cause issues
    with base delay values growing less useful over time.  Clock rate skew
    is much less prominent than absolute clock skew, though.
    
[Author] Thanks for calling out the factor of clock rate skew. We've definitely
seen its (negative) impact in our real-world experiments and that was one of the
main reason for adding the update of baseline delay values.  We've updated the
draft to capture that as a factor of consideration, both in Sec. 5.1.1 and later in
Section 6.1. 

In Sec. 5.1.1: 

	... By re-estimating the base delay periodically, one can avoid the potential
   	issue of base delay expiration, whereby an earlier measured base delay value
	is no longer valid due to underlying route changes or cumulative timing difference
	introduced by the clock rate skew between sender and receiver.

In Sec. 6.1: 

	... As discussed in [RFC6817], the time horizon for tracking the minimum OWD
	needs to be chosen with care: it must be long enough for an opportunity to
	observe the minimum OWD with zero standing queue along the path, and sufficiently
	short so as to timely reflect "true" changes in minimum OWD introduced by route
	changes and other rare events and to mitigate the cumulative impact of clock rate
   	skew over time. 


       based on sender timestamps with a recommended granularity of 100
       microseconds or higher.
    
    Is this a normative requirement?
    Also, pedantically, I think "granularity of 100 microseconds or higher"
    has "higher" apply to the numerical value 100, so it would
    include a granularity of 1 second.  I see that later on we recommend
    measuring the delay as an integer multiple of 100 microseconds, so this
    seems like the intended sense, but does the scheme become less useful if
    the granularity of the measurment becomes too coarse-grained (e.g., the
    second granularity I mentioned above)?  If so, we may want to put a
    bound on the other direction as well.


[Authors] Actually, our intended meaning is "granularity of 100 microseconds or finer", 
so we revised that text accordingly. In mentioning multiple units of 100 microsecond
in Sec. 5.3 (Feedback Message Requirements), the idea is to stick with the granularity
of 100 microseconds in measurement, and then expressed the measured delay using 
that as the unit.

[Authors] We didn't discuss extensively on the impact of timer granularity in this draft
since that would be the focus of the cc-feedback-message draft. We simply recommended
a value that we used.  
    
    Section 5.3
    
       o  Aggregated congestion signal (x_curr): the most recently updated
          value, calculated by the receiver according to Section 4.2.  This
          information is expressed with a unit of 100 microsecond (i.e.,
          1/10 of a millisecond) in 15 bits.  This allows a maximum value of
          x_curr at approximately 3.27 second.
    
    There's perhaps a minor editorial mismatch between the "information is
    required" intro and declarative "is expressed in [specific format]".
    (Similarly for r_recv.)
    
[Authors] Thanks for catching this.  The description of x_curr in Sec. 5.3 has been
changed to the following to allow other forms of expression: 

... This information can be expressed with a unit of 100 microsecond (i.e.,
      1/10 of a millisecond) in 15 bits.