[rmcat] WGLC review: Harald Alvestrand

[Harald Alvestrand <[e-mail]>]

Here's my review of draft-ietf-rmcat-cc-requirements-02. I hope it's useful.

Summary:

Content seems just about ready for IETF Last Call (modulo a few nits).
Form needs some work.

Structural:

I feel two sections are missing:

- Term definitions. There’s a pointer to -overview, but many terms are 
not defined there. Nor is it good to have a normative dependency on 
-overview outside of WebRTC, since this is going to be hanging around in 
dependency hell “forever”.

Especially the terms “flow” and “fair” seem to be works of art for this 
memo, but also “starvation”.

- Evaluation considerations. This is mainly to have somewhere to move 
requirement 11 to. Now that we have draft-singh-rmcat-cc-eval adopted as 
a WG document, this may be deleted as “overtaken by events” - but an 
informative reference to that document may be a Good Thing.

The role of bullets and sub-bullets needs to be managed. Most of the 
time, bullets give requirements (except when they don’t), and the 
sub-bullets give additional information to expand on understanding the 
requirements, or further detail about implementation techniques that can 
be used to achieve them. But sometimes not.

Nits:


Section 2

1.C Too many hyphens - web-browsing, local-bottleneck, quickly-enough 
all need to lose their hyphens.

1.D “are often are layered” -> “are often layered”, “may on an access 
link” -> “may be on an access link”, “fir” -> “for”

2. Don’t use the “fair” term. Use “behave reasonably”.

3. Commas - “The algorithm should, where possible, merge”.
Technical: Flows with different Diffserv PHBs may experience different 
congestion, so amount of merge needs to be conservative. DSCP markings 
occur in section 6, but need to be menthined here too.

5. Suggest reformulating the point as “When the streams to be managed 
are all RTP streams, backchannel information needs to be sent via RTCP 
or via header extensions in an RTP channel going in the opposite 
direction.” We then need a sub-bullet noting that there are cases when 
there is no RTP channel in the opposite direction.

6. A WebRTC doesn’t seem to have settled on these 4 classes; 
draft-dhesikan doesn’t. General requirement should be that feedback flow 
has DSCP markings that cause it to travel faster than audio, so that the 
contribution of jitter in the feedback path to estimate errors is as 
small as possible.

8. “As best as possible” is not English. “As far as possible”?
Define “starvation” somewhere.

10. “both if the initial bandwidth is above or below the bottleneck 
bandwidth” looks meaningful, but doesn’t parse grammatically.

10.A. “other problems for user experience” is too abstract. Say “Can 
cause packet loss, which gives other problems for the user experience”.

11 does not belong in requirements. It belongs in evaluation.

12 should relate to bullet 10 - starting a flow and resuming a flow 
should have some of the same characteristics, including how much you 
trust previous estimates of capacity to the same destination.