[rmcat] Comments on draft-jesup-rmcat-reqs-01

[Kevin Gross <[e-mail]>]

I've been on a few airplanes recently and have had some quality time with
RMCAT drafts and my red pen.

I do think that improving the existing adopted drafts (and creating new
ones) will be the best way to make progress on this project.


Abstract

Reverse first two clauses to avoid immediately raising people's hairs:
s/Congestion control is needed for all data transported across the
Internet, in order to promote fair usage and prevent congestion
collapse./In order to promote fair usage and prevent congestion collapse,
congestion control is needed for all data transported across the Internet./

s/which needs by low-delay/which needs low-delay/

"Evaluation" is the domain of draft-singh-rmcat-cc-eval: s/used to
evaluate/used to assess/

s/in order to figure out/in order to determine/


Section 1 (Introduction)

Need to mention where the congestion control algorithm will operate: in
network equipment, in end stations, both?


Section 2

Point 2B. This paragraph is a placeholder and should be recast as an
editor's note so that it is clear that we we don't intend to publish like
this. Have we made any progress defining fairness?

Point 3 claims that managing multiple streams as one flow
improves performance  This benefit is not obvious to me and should be
justified.

s/The algorithm should where possible merge information/The algorithm
should, where possible, merge information/

Point 5B advocates violating RFC 3550. This is a controversial and arguably
unnecessary proposal.

Point 5F claims that backchannel data should be minimized. This surely
cannot not be a blanket recommendation as there are systems with ample
bandwidth in the reverse direction. Increasing backchannel data may be
preferable to the alternatives such as FEC for achieving reliability.

Point 10A or 10B should discuss starting with a potentially unreasonably
high offered rate. This invites congestion collapse but is probably the
fastest way to determine bottleneck bandwidth.

Point 10B needs to specify what the "other problems" are.

Point 11 s/local-lan (WiFi/etc)/local (LAN, WiFi, etc.)/

Point 11 add a reference for LEDBAT

Point 12 add a reference for (VAD/DTX). Here's a crappy one
http://en.wikipedia.org/wiki/Discontinuous_transmission


Additional requirements to consider adding to section 2:

Efficiently use available link bandwidth. Don't leave link idle
unnecessarily. Don't degrade goodput significantly.

Add list of contention scenarios we brainstormed at IETF86:
0/ Single flow
1/ Competing with other interactive multimedia flows
2/ Competing with long-lived TCP
3/ Competing with bursty TCP (web browser)
4/ Competing with ledbat or bittorrent
5/ Competing with unresponsive flows (no congestion or flow control, not
necessarily CBR)


Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org