Subject: [rmcat] Review of draft-ietf-rmcat-scream-cc-02

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 23 Dec 2015 21:37:12 +0000

Hi,

Here are my review comments for SCReAM draft.  Overall this a well-structured draft. It has explained the basic design principles of the SCReAM, and has provided sufficient details regarding several key modules (network congestion control, media rate control, etc.) at the sender.  It is expected that the authors will update the draft with further details on feedback message from the receiver.

First, some general, high-level comments:

  *   The introduction section seems to motivate the self-clocked algorithm of SCReAM by presenting challenges from wireless LTE-like access links.  However, I am missing the logic behind why a self-clocked algorithm will work better in a wireless environment? It is not clear from the design of SCReAM that it is specifically tailored for transmission over wireless.   Also, does it make more sense to move some of the discussions on challenges of wireless access links (e.g., LTE) to the requirement document instead, since they need to be considered by all RMCAT solutions?
  *   While the draft has explained in detail operations of the "network congestion control" and "media rate control" modules, it has not explained how "sender transmission control" should be carried out.  For instance, it is unclear how it "limits the output of data" and how exactly it paces outgoing packets.  Will be nice to have a subsection to cover this module as well.   Will also be nice to point out explicitly how the sending window size, as calculated by the network congestion control module (in Sec. 4.1.2.4) relates to transmission control.
  *   Currently, discussions on how SCReAM takes characteristics of realtime media in to account are spread out throughout the draft. Sometimes that disrupts the flow of explanation of how the algorithm proceeds. Example: end of 4.1.3.  Is there a way to move them into the discussion section instead?
  *   Now that I've given this draft a thorough read, it seems to me that the collection of modules in Fig. 1 corresponds well with the overview figure in the NADA draft.  Will be nice for us to align the key terminologies used by both drafts. Might be something to consider for the next meeting :)

Now, some more specific, miscellaneous comments/questions:

  *   Sec. 1.2:  I am not so sure about the statement that "A rate based congestion control has only one mechanism to adjust ...." Fundamentally, both window-based and rate-based congestion control needs to decide on how often and how much data to pump to the network. So why would a window-based scheme have "more" mechanisms to adjust?
  *   Sec. 3:  typo:  "Addition of media a rate control function" => "Addition of a media rate control function"
  *   Sec. 3.1 (and the use of OWD throughout this draft):  both in the LEDBAT draft (also conventionally), the term one-way-delay refers to the end-to-end delay that includes both path propagation delay and queuing delay.  In this draft, if I understood it correctly, OWD is used to refer only the queuing delay portion, which is really one-way-delay minus base delay.  Will be good to avoid such confusion, and maybe pick an alternative term such as "relative one-way-delay", or simply "queuing delay".
  *   Sec. 4.1.1.1:  Why is it that for "PRE_CONGESTION_GUARD" and "TX_QUEUE_SIZE",  a range of values are given as opposed to a default value like others?  What default value should an implementer pick for these constants? Missing default value for "T_RESUME_FAST_INCREASE"
  *   Sec. 4.1.1.2:  looks like this list is fairly incomplete.  For instance, it is missing owd_fraction although it's being referred to in the rest of the list.  It is also missing variables that showed up later in equations, such as "gain", "off_target", "current_rate".    Typo under "send_wnd (0)": "when CWND is updated" => "when cwnd is updated"
  *   Sec. 4.1.2:   It says in the text (page 12) that "The OWD fraction is sampled every 50ms ...".  On the other hand, the value of ow_fraction is only updated upon the arrival of a feedback message, the interval of which can range between 10s of ms to 200ms (according to Sec.5).  So, what happens when the feedback interval is 100ms?  Would the same owd_fraction value show up twice in the list, or the span of 20 samples exceed 1 sec?  Please add some clarifications in the draft.
  *   Sec 4.1.2.2:  page 15:  instead of hard-coding the value of "0.2" in pseudo-code, will be better to assign it a constant and add to the list in Sec. 4.1.1.1.
  *   Sec 4.1.2.3:  typo:  ".... by adjusting the owr_target" => "... By adjusting the owd_target".
  *   Sec 4.1.2.3:  page 16:  again, some hard-coded values (0.26, 20, 100) in the pseudo-code
  *   Sec. 4.1.2:  it will be helpful to add a paragraph or a flow diagram to explain how the algorithm switches from one mode of operation (e.g., fast increase, reacting to loss events) to another.
  *   Sec 4.1.3: Based on the pseudo code on page 20, calculation of the media target rate does not depend on the current rate from network congestion control when the sender is in fast increase mode. Would this cause overflow/underflow at the RTP queue?
  *   Sec 4.1.3 (page 21):  typo:  "The vary reader ..." => "The very reader ..."
  *   Sec. 4.2:  one suggestion/request for the feedback message description is to specify the # of bytes used for each field.  One related question is whether the field of total_loss_count and total_ECN_count will encounter wrap-around issues when the conference call lasts for a long time.  Is that something to worry about?
  *   Sec. 6.2.: broken reference on SREaAM_Cplusplus_Implementation
  *   How is the sending window, as calculated in

Thanks,
Xiaoqing

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 23 Dec 2015 21:45:45 +0000

My apologies for hitting the “send” button too soon.  Please kindly ignore the last line in my review comments below.

It was basically the residual text in asking about how the sending window calculation relates to the transmission control module (already in my list of general comments).

Thanks,
Xiaoqing

From: rmcat <[email-masked]<mailto:[email-masked]>> on behalf of Xiaoqing Zhu <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 23, 2015 at 3:37 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [rmcat] Review of draft-ietf-rmcat-scream-cc-02

Hi,

  *   The introduction section seems to motivate the self-clocked algorithm of SCReAM by presenting challenges from wireless LTE-like access links.  However, I am missing the logic behind why a self-clocked algorithm will work better in a wireless environment? It is not clear from the design of SCReAM that it is specifically tailored for transmission over wireless.   Also, does it make more sense to move some of the discussions on challenges of wireless access links (e.g., LTE) to the requirement document instead, since they need to be considered by all RMCAT solutions?
  *   While the draft has explained in detail operations of the “network congestion control” and “media rate control” modules, it has not explained how “sender transmission control” should be carried out.  For instance, it is unclear how it “limits the output of data” and how exactly it paces outgoing packets.  Will be nice to have a subsection to cover this module as well.   Will also be nice to point out explicitly how the sending window size, as calculated by the network congestion control module (in Sec. 4.1.2.4) relates to transmission control.
  *   Currently, discussions on how SCReAM takes characteristics of realtime media in to account are spread out throughout the draft. Sometimes that disrupts the flow of explanation of how the algorithm proceeds. Example: end of 4.1.3.  Is there a way to move them into the discussion section instead?
  *   Now that I’ve given this draft a thorough read, it seems to me that the collection of modules in Fig. 1 corresponds well with the overview figure in the NADA draft.  Will be nice for us to align the key terminologies used by both drafts. Might be something to consider for the next meeting :)

  *   Sec. 1.2:  I am not so sure about the statement that “A rate based congestion control has only one mechanism to adjust ….” Fundamentally, both window-based and rate-based congestion control needs to decide on how often and how much data to pump to the network. So why would a window-based scheme have “more” mechanisms to adjust?
  *   Sec. 3:  typo:  “Addition of media a rate control function” => “Addition of a media rate control function”
  *   Sec. 3.1 (and the use of OWD throughout this draft):  both in the LEDBAT draft (also conventionally), the term one-way-delay refers to the end-to-end delay that includes both path propagation delay and queuing delay.  In this draft, if I understood it correctly, OWD is used to refer only the queuing delay portion, which is really one-way-delay minus base delay.  Will be good to avoid such confusion, and maybe pick an alternative term such as “relative one-way-delay”, or simply “queuing delay”.
  *   Sec. 4.1.1.1:  Why is it that for “PRE_CONGESTION_GUARD” and “TX_QUEUE_SIZE”,  a range of values are given as opposed to a default value like others?  What default value should an implementer pick for these constants? Missing default value for “T_RESUME_FAST_INCREASE"
  *   Sec. 4.1.1.2:  looks like this list is fairly incomplete.  For instance, it is missing owd_fraction although it’s being referred to in the rest of the list.  It is also missing variables that showed up later in equations, such as “gain”, “off_target”, “current_rate”.    Typo under “send_wnd (0)”: “when CWND is updated” => “when cwnd is updated”
  *   Sec. 4.1.2:   It says in the text (page 12) that “The OWD fraction is sampled every 50ms …”.  On the other hand, the value of ow_fraction is only updated upon the arrival of a feedback message, the interval of which can range between 10s of ms to 200ms (according to Sec.5).  So, what happens when the feedback interval is 100ms?  Would the same owd_fraction value show up twice in the list, or the span of 20 samples exceed 1 sec?  Please add some clarifications in the draft.
  *   Sec 4.1.2.2:  page 15:  instead of hard-coding the value of “0.2” in pseudo-code, will be better to assign it a constant and add to the list in Sec. 4.1.1.1.
  *   Sec 4.1.2.3:  typo:  “…. by adjusting the owr_target” => “… By adjusting the owd_target”.
  *   Sec 4.1.2.3:  page 16:  again, some hard-coded values (0.26, 20, 100) in the pseudo-code
  *   Sec. 4.1.2:  it will be helpful to add a paragraph or a flow diagram to explain how the algorithm switches from one mode of operation (e.g., fast increase, reacting to loss events) to another.
  *   Sec 4.1.3: Based on the pseudo code on page 20, calculation of the media target rate does not depend on the current rate from network congestion control when the sender is in fast increase mode. Would this cause overflow/underflow at the RTP queue?
  *   Sec 4.1.3 (page 21):  typo:  “The vary reader …” => “The very reader …”
  *   Sec. 4.2:  one suggestion/request for the feedback message description is to specify the # of bytes used for each field.  One related question is whether the field of total_loss_count and total_ECN_count will encounter wrap-around issues when the conference call lasts for a long time.  Is that something to worry about?
  *   Sec. 6.2.: broken reference on SREaAM_Cplusplus_Implementation
  *   How is the sending window, as calculated in

Thanks,
Xiaoqing