Last Call Review of draft-ietf-rmcat-cc-requirements-05
review-ietf-rmcat-cc-requirements-05-opsdir-lc-baker-2014-08-06-00

In my opinion, the draft needs at least one revision round, and possibly more,
before it is ready for IESG evaluation.

> From: Fred Baker <fred at cisco.com>
> Subject: Ops-Dir Review of draft-ietf-rmcat-cc-requirements
> Date: August 5, 2014 at 12:09:22 PM PDT
> To: draft-ietf-rmcat-cc-requirements.all at tools.ietf.org
> Cc: ops-dir at ietf.org
>
> 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 > >

https://tools.ietf.org/html/rfc5348

> 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:
>     PROPOSED STANDARD)
>
> 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”? > >

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail