Here are my review comments for SCReAM draft. Overall this a wel= l-structured draft. It has explained the basic design principles of the SCR= eAM, and has provided sufficient details regarding several key modules (net= work 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 o= f SCReAM by presenting challenges from wireless LTE-like access links. &nbs= p;However, I am missing the logic behind why a self-clocked algorith= m will work better in a wireless environment? It is not clear from the desi= gn of SCReAM that it is specifically tailored for transmission over wireles= s. 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 a= ll RMCAT solutions?
While the draft has explained in detail o= perations of the “network congestion control” and “media = rate control” modules, it has not explained how “sender transmi= ssion control” should be carried out. For instance, it is uncle= ar how it “limits the output of data” and how exactly it paces outgoing packets. Will be ni= ce to have a subsection to cover this module as well. Will also be n= ice to point out explicitly how the sending window size, as calculated by t= he network congestion control module (in Sec. 4.1.2.4) relates to transmission control.
Currently, discussions on h= ow SCReAM takes characteristics of realtime media in to account are spread = out throughout the draft. Sometimes that disrupts the flow of explanation o= f how the algorithm proceeds. Example: end of 4.1.3. Is there a way t= o 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 dra= ft. Will be nice for us to align the key terminologies used by both d= rafts. 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 a= djust?
Sec. 3: typo: “Addition of media a = rate control function” =3D> “Addition of a media rate contro= l function”
Sec. 3.1 (and the use of OWD throughout this draf= t): both in the LEDBAT draft (also conventionally), the term one-way-= delay refers to the end-to-end delay that includes both path propagation de= lay 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-w= ay-delay minus base delay. Wil= l be good to avoid such confusion, and maybe pick an alternative term such = as “relative one-way-delay”, or simply “queuing delayR= 21;.
Sec. 4.1.1.1: Why is it that for “PRE_CONGES= TION_GUARD” and “TX_QUEUE_SIZE”, a range of values = are given as opposed to a default value like others? What default val= ue should an implementer pick for these constants? Missing default value fo= r “T_RESUME_FAST_INCREASE"
Sec. 4.1.1.2: looks lik= e this list is fairly incomplete. For instance, it is missing owd_fra= ction 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 = 220;gain”, “off_target”, “current_rate”. Typo under “send_wnd (0)”: “when CWND is up= dated” =3D> “when cwnd is updated”
Sec.= 4.1.2: It says in the text (page 12) that “The OWD fraction i= s sampled every 50ms …”. On the other hand, the value of = ow_fraction is only updated upon the arrival of a feedback message, the int= erval 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 clarification= s in the draft.
Sec 4.1.2.2: page 15: instead of hard-c= oding the value of “0.2” in pseudo-code, will be better to assi= gn 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” = =3D> “… 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 anothe= r.
Sec 4.1.3: Based on the pseudo code on page 20, cal= culation 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 (pa= ge 21): typo: “The vary reader …” =3D> = 220;The very reader …”
Sec. 4.2: one suggestion/r= equest for the feedback message description is to specify the # of bytes us= ed 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? <= /li>
Sec. 6.2.: broken reference on SREaAM_Cplusplus_Implementation
How is the sending window, as calculated in

Thanks,

Xiaoqing

--_000_D2A05D132DA66xiaoqzhuciscocom_-- From nobody Wed Dec 23 13:45:52 2015 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986B31A87A9 for ; Wed, 23 Dec 2015 13:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBjtyYDdVZJ4 for ; Wed, 23 Dec 2015 13:45:47 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CB31A87AD for ; Wed, 23 Dec 2015 13:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16623; q=dns/txt; s=iport; t=1450907147; x=1452116747; h=from:to:subject:date:message-id:mime-version; bh=4ME+Lu0qNN3m9gC9uBv0w/RLfQsXMFtHqj1fFaKcIBM=; b=IzgUoxIDJD+pAPaoAM9kucPvA7teay97n14ilm8Fii6HVLdinbKf6/Lq VPLMzCO4x4eIDG1ovb0U5XdTCpGWIQLNOMl+37dgMz8WqGiCyUSB4ogYL tFQk684xdq3udd9XawtNC5HKAhgTHTORyzQGEGQtO1yKdNK7+8z1iUbxP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANBgCuFXtW/4gNJK1egm5MgTEOBoxLs?= =?us-ascii?q?m6GDwKBKjwQAQEBAQEBAYEKhDQBAgRnAQQKFQEIEQMBAhYSORQJCgQBEhuIFMB?= =?us-ascii?q?8AQEBBwEBAQEBAR2GVoR/hHcfhCcFlwMBjUuBXIRGgyaFMYVYiGIBOSuCDiCBX?= =?us-ascii?q?XKEIIEIAQEB?= X-IronPort-AV: E=Sophos; i="5.20,470,1444694400"; d="scan'208,217"; a="58092366" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Dec 2015 21:45:45 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tBNLjjjV007146 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Dec 2015 21:45:45 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Dec 2015 15:45:45 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Wed, 23 Dec 2015 15:45:45 -0600 From: "Xiaoqing Zhu (xiaoqzhu)" To: "Xiaoqing Zhu (xiaoqzhu)" , "rmcat@ietf.org" Thread-Topic: [rmcat] Review of draft-ietf-rmcat-scream-cc-02 Thread-Index: AQHRPctHL02T8HNxQE2iiOdc3Q70iA== Date: Wed, 23 Dec 2015 21:45:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.12.208] Content-Type: multipart/alternative; boundary="_000_D2A071BC2DB12xiaoqzhuciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 21:45:50 -0000 --_000_D2A071BC2DB12xiaoqzhuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My apologies for hitting the =93send=94 button too soon. Please kindly ign= ore the last line in my review comments below. It was basically the residual text in asking about how the sending window c= alculation relates to the transmission control module (already in my list o= f general comments). Thanks, Xiaoqing From: rmcat > on beha= lf of Xiaoqing Zhu > Date: Wednesday, December 23, 2015 at 3:37 PM To: "rmcat@ietf.org" > Subject: [rmcat] Review of draft-ietf-rmcat-scream-cc-02 Hi, Here are my review comments for SCReAM draft. Overall this a well-structur= ed draft. It has explained the basic design principles of the SCReAM, and h= as provided sufficient details regarding several key modules (network conge= stion control, media rate control, etc.) at the sender. It is expected tha= t the authors will update the draft with further details on feedback messag= e 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. H= owever, I am missing the logic behind why a self-clocked algorithm will wor= k better in a wireless environment? It is not clear from the design of SCRe= AM that it is specifically tailored for transmission over wireless. Also,= does it make more sense to move some of the discussions on challenges of w= ireless 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 =93network = congestion control=94 and =93media rate control=94 modules, it has not expl= ained how =93sender transmission control=94 should be carried out. For ins= tance, it is unclear how it =93limits the output of data=94 and how exactly= it paces outgoing packets. Will be nice to have a subsection to cover thi= s module as well. Will also be nice to point out explicitly how the sendi= ng 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 realtim= e media in to account are spread out throughout the draft. Sometimes that d= isrupts 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=92ve given this draft a thorough read, it seems to me that= the collection of modules in Fig. 1 corresponds well with the overview fig= ure 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 =93A rate based = congestion control has only one mechanism to adjust =85.=94 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 =93more=94 mechanisms to adjust? * Sec. 3: typo: =93Addition of media a rate control function=94 =3D> = =93Addition of a media rate control function=94 * Sec. 3.1 (and the use of OWD throughout this draft): both in the LED= BAT draft (also conventionally), the term one-way-delay refers to the end-t= o-end delay that includes both path propagation delay and queuing delay. I= n this draft, if I understood it correctly, OWD is used to refer only the q= ueuing 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 a= s =93relative one-way-delay=94, or simply =93queuing delay=94. * Sec. 4.1.1.1: Why is it that for =93PRE_CONGESTION_GUARD=94 and =93T= X_QUEUE_SIZE=94, a range of values are given as opposed to a default value= like others? What default value should an implementer pick for these cons= tants? Missing default value for =93T_RESUME_FAST_INCREASE" * Sec. 4.1.1.2: looks like this list is fairly incomplete. For instan= ce, it is missing owd_fraction although it=92s being referred to in the res= t of the list. It is also missing variables that showed up later in equati= ons, such as =93gain=94, =93off_target=94, =93current_rate=94. Typo unde= r =93send_wnd (0)=94: =93when CWND is updated=94 =3D> =93when cwnd is updat= ed=94 * Sec. 4.1.2: It says in the text (page 12) that =93The OWD fraction = is sampled every 50ms =85=94. On the other hand, the value of ow_fraction = is only updated upon the arrival of a feedback message, the interval of whi= ch can range between 10s of ms to 200ms (according to Sec.5). So, what hap= pens when the feedback interval is 100ms? Would the same owd_fraction valu= e show up twice in the list, or the span of 20 samples exceed 1 sec? Pleas= e add some clarifications in the draft. * Sec 4.1.2.2: page 15: instead of hard-coding the value of =930.2=94= 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: =93=85. by adjusting the owr_target=94 =3D> =93= =85 By adjusting the owd_target=94. * 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., fas= t increase, reacting to loss events) to another. * Sec 4.1.3: Based on the pseudo code on page 20, calculation of the me= dia target rate does not depend on the current rate from network congestion= control when the sender is in fast increase mode. Would this cause overflo= w/underflow at the RTP queue? * Sec 4.1.3 (page 21): typo: =93The vary reader =85=94 =3D> =93The ve= ry reader =85=94 * Sec. 4.2: one suggestion/request for the feedback message descriptio= n is to specify the # of bytes used for each field. One related question i= s 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 --_000_D2A071BC2DB12xiaoqzhuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2F49732411CA25488158380F6CB72888@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

My apologies for hitting the =93send=94 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 win= dow calculation relates to the transmission control module (already in my l= ist of general comments).

Thanks,

Xiaoqing

From: rmcat <rmcat-bounces@ietf.org> on behalf of Xiaoqing= Zhu <xiaoqzhu@cisco.com> Date: Wednesday, December 23, 2015 = at 3:37 PM
To: "rmcat@ietf.org" <rmc= at@ietf.org>
Subject: [rmcat] Review of draft-ie= tf-rmcat-scream-cc-02

Hi,

First, some general, high-level comments:

The introduction section seems to motivate the self-clocked algorithm o= f SCReAM by presenting challenges from wireless LTE-like access links. &nbs= p;However, I am missing the logic behind why a self-clocked algorith= m will work better in a wireless environment? It is not clear from the desi= gn of SCReAM that it is specifically tailored for transmission over wireles= s. 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 a= ll RMCAT solutions?
While the draft has explained in detail o= perations of the =93network congestion control=94 and =93media rate control= =94 modules, it has not explained how =93sender transmission control=94 sho= uld be carried out. For instance, it is unclear how it =93limits the = output of data=94 and how exactly it paces outgoing packets. Will be nice t= o 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 n= etwork congestion control module (in Sec. 4.1.2.4) relates to transmission control.
Currently, discussions on h= ow SCReAM takes characteristics of realtime media in to account are spread = out throughout the draft. Sometimes that disrupts the flow of explanation o= f how the algorithm proceeds. Example: end of 4.1.3. Is there a way t= o move them into the discussion section instead?
Now that I=92ve g= iven this draft a thorough read, it seems to me that the collection of modu= les 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 draft= s. 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 =93A rate bas= ed congestion control has only one mechanism to adjust =85.=94 Fundamentall= y, both window-based and rate-based congestion control needs to decide on h= ow often and how much data to pump to the network. So why would a window-based scheme have =93more=94 mechanisms to adjust? &= nbsp;
Sec. 3: typo: =93Addition of media a rate control= function=94 =3D> =93Addition of a media rate control function=94

Sec. 3.1 (and the use of OWD throughout this draft): both in the LE= DBAT draft (also conventionally), the term one-way-delay refers to the end-= to-end delay that includes both path propagation delay and queuing delay. &= nbsp;In this draft, if I understood it correctly, OWD is used to refer only the queuing delay portion, which is really one-w= ay-delay minus base delay. Wil= l be good to avoid such confusion, and maybe pick an alternative term such = as =93relative one-way-delay=94, or simply =93queuing delay=94. <= li>Sec. 4.1.1.1: Why is it that for =93PRE_CONGESTION_GUARD=94 and = =93TX_QUEUE_SIZE=94, a range of values are given as opposed to a defa= ult value like others? What default value should an implementer pick = for these constants? Missing default value for =93T_RESUME_FAST_INCREASE&qu= ot;

Sec. 4.1.1.2: looks like this list is fairly incomplete. = For instance, it is missing owd_fraction although it=92s being referr= ed to in the rest of the list. It is also missing variables that show= ed up later in equations, such as =93gain=94, =93off_target=94, =93current_= rate=94. Typo under =93send_wnd (0)=94: =93when CWND is updated=94 =3D= > =93when cwnd is updated=94

Sec. 4.1.2: It says i= n the text (page 12) that =93The OWD fraction is sampled every 50ms =85=94.= 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 clarification= s in the draft.

Sec 4.1.2.2: page 15: instead of hard-c= oding the value of =930.2=94 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: &n= bsp;typo: =93=85. by adjusting the owr_target=94 =3D> =93=85 By ad= justing the owd_target=94.

Sec 4.1.2.3: page 16: again,= some hard-coded values (0.26, 20, 100) in the pseudo-code

Se= c. 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 i= ncrease, reacting to loss events) to another.

Sec 4.1.= 3: Based on the pseudo code on page 20, calculation of the media target rat= e 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: =93The= vary reader =85=94 =3D> =93The very reader =85=94

Sec. 4.2: &nb= sp;one suggestion/request for the feedback message description is to specif= y 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-arou= nd issues when the conference call lasts for a long time. Is that something to worry about? <= /li>

Sec. 6.2.: broken reference on SREaAM_Cplusplus_Implementation

How is the sending window, as calculated in

Thanks,

Xiaoqing

--_000_D2A071BC2DB12xiaoqzhuciscocom_--