Telechat Review of draft-ietf-rmcat-cc-requirements-06

Request Review of draft-ietf-rmcat-cc-requirements
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2014-10-28
Requested 2014-10-09
Authors Randell Jesup, Zaheduzzaman Sarker
Draft last updated 2014-10-24
Completed reviews Genart Last Call review of -05 by Alexey Melnikov (diff)
Secdir Last Call review of -05 by Steve Hanna (diff)
Opsdir Last Call review of -05 by Fred Baker (diff)
Opsdir Telechat review of -06 by Fred Baker (diff)
Opsdir Telechat review of -07 by Fred Baker (diff)
Assignment Reviewer Fred Baker 
State Completed
Review review-ietf-rmcat-cc-requirements-06-opsdir-telechat-baker-2014-10-24
Reviewed rev. 06 (document currently at 09)
Review result Not Ready
Review completed: 2014-10-24


I reviewed draft-ietf-rmcat-cc-requirements-05 in August. That review follows.


, it would appear that the sum of the changes between -05 and -06 was to add the paragraph

        A.  Jitter (variation in the bitrate over short timescales) also
            is relevant, though moderate amounts of jitter will be
            absorbed by jitter buffers.  Transit delay should be
            considered to track the short-term maximums of delay
            including jitter.

adjust the letters on the other elements of that list, and update two bibliographic elements. The remainder of my comments remain unaddressed.

In my opinion, the draft remains less than ready.

On Aug 5, 2014, at 12:09 PM, Fred Baker <fred at> wrote:

> Hi. I’m doing a review of your document for the Ops Directorate. A couple of questions and/or comments.
> The abstract asserts that
>   Congestion control is needed for all data transported across the
>   Internet, in order to promote fair usage and prevent congestion
>   collapse.  The requirements for interactive, point-to-point real time
>   multimedia, which needs low-delay, semi-reliable data delivery,
> You might enjoy reading RFC 1633, which was a starting point for all this. Real-Time applications falls broadly into two categories, one of which might be called “broadcast” or “unidirectional delivery" and another might be called “interactive”. When video is delivered as entertainment using a protocol such as RTP, it really doesn’t matter if it goes to the moon and back; the issue is jitter, which might overstretch the bounds o a jitter buffer. If data arrives at the rate it was sent and without too much accumulated jitter, the TV-show-or-whatever will do just fine, simply being delayed by the path delay. The other category has some responder, often human (but not always), and as such has some concept of an RTT. The longer the RTT, the greater the likelihood that it will change human interactions or interaction styles, or make some exchange take longer than it otherwise might. 
> I find the lack of a discussion of broadcast/unidirectional delivery surprising. I understand that the RTCWEB charter limits it to interactive communications, but I seriously wonder whether we will not use the same tools for video display purposes. I’m not sure why, if RTCWEB is used for ten second or two minute videos or for video interaction, it would not also be used for two hour videos...
> The document says it contemplates "no more than 100s of milliseconds end-to-end delay”. ITU Voice calls have historically called for a maximum of 150 ms end to end delay, and even a geosynchronous satellite connection generally has no more than 300-350 ms (the 650-700 ms commonly reported is round trip - out and back). So I wouldn’t automatically describe “100s of milliseconds” as “limited”. I would describe “tens of milliseconds” as limited.
> In section 2 part 2, it says that "The algorithm must be fair to other flows”. I was surprised by the lack of a reference to

> 5348 TCP Friendly Rate Control (TFRC): Protocol Specification. S.
>     Floyd, M. Handley, J. Padhye, J. Widmer. September 2008. (Format:
>     TXT=133185 bytes) (Obsoletes RFC3448) (Updates RFC4342) (Status:
> which specifically targets multimedia applications. To that end, and noting that the requirement is for low-delay paths (which is operationally a routing or provisioning issue, or an AQM issue, not a congestion control issue), I was surprised that the requirements did not include the comment that whatever algorithms are chosen should minimize self-induced latency. To clarify the point, standard TCP Congestion Control (RFC 5681) maximizes throughput while *maximizing* latency - it increases the effective window until it forces a drop. The limit on TCP throughput is that it moves one window per round trip, so that
>                             effective window
>          bandwidth used = -------------------- * (scaling factor)
>                                 mean RTT
> Given a bottleneck in the path, once the bottleneck is reached, increasing the effective window doesn’t increase throughput; it increases RTT. So if you want to have a minimal-latency path, self-induced latency is a factor, and latency derived from competing sessions is a factor. And it turns out that “just over-provision bandwidth” has issues as well; modern codecs are variable rate, and will jump to the next higher rate if they perceive available capacity. Just as TCP increases its window until it perceives loss, they increase codec rate until they perceive a problem. So “just add bandwidth” isn’t necessarily a solution unless the maximum rate of a session is known. This is why RFC 6057 was imposed by Comcast after simply trying to shut BitTorrent down, and why LEDBAT is a latency-based algorithm. 
> Is there a place for a reference to conex? What would the interaction with conex be?
> This statement confuses me:
>   7.   The algorithm should not require any special support from
>        network elements (Explicit Congestion Notification (ECN)
>        [RFC3168], etc).  As much as possible, it should leverage
>        available information about the incoming flow to provide
>        feedback to the sender.  Examples of this information are the
>        ECN, packet arrival times, acknowledgments and feedback, packet
>        timestamps, and packet losses; all of these can provide
>        information about the state of the path and any bottlenecks.
> So it should not require ECN, and it should leverage available information such as ECN. Is the point about the difference between “require” and “use”?




 Message signed with OpenPGP using GPGMail