Randell Jesup <randell-ietf@jesup.org> wrote:
Two-way flows will be the norm, though not the only use-case for RMCAT.
Yes.
(For example, watching/controling remote security cameras).
Indeed, that will probably be a use-case (as well as baby-monitors which send mostly audio). Actually, both of those are a weird case where buffering frames at the sender for later media-on-demand is at least somewhat desirable...
But since they're both the norm and the harder case, it makes sense to optimize for them.
Agreed.
In steady-state, both flows should be living near the congestion point. Typically (though not always), the bottlenecks will be either access links (typically upstreams) or wifi links.
(Both being potential bottlenecks, of course; and passing through both unfortunately being a too-common case.)
Both will have large amounts of traffic (on the order of say 40-300 packets per second). Adding more packets for per-packet acks would certainly add to congestion and reduce available bandwidth.
Quite true. :^( But we should recall that adding more packets _during_ congestion is what we really want to avoid. Thus, rather than optimize for the fewest packets when there is no congestion, we'd do better to optimize for the fewest packets when there _is_ congestion. Recalling the ARPAnet "RFNM" (request for next message): there was no such thing as "congestion collapse" in the original ARPAnet design, because senders waited for the (reliable) return of the RFNM before sending more traffic. (We can't reproduce that model with unreliable packets, but the principle of reducing the sending rate whenever feedback is _not_ received can quite completely avoid "congestion collapse".)
It would add much more to the packet rate than to the bandwidth used,
Indeed -- if we use separate packets for the feedback...
which on an access link may not make a large difference, but on a WiFi link (in line with the comments by Jim Gettys and Van Jacobson at IETF) may cause significant reduction in throughput.
(Fundamentally, both WiFi and DOCSYS upstream must wait for a sending window. The window has a minimum size: thus for "small" packets, it approaches "pure per-packet" overhead.)
This WiFi issue (if confirmed) might be a reason to consider either piggybacking feedback and/or reducing feedback frequency, at least in stable situations.
Piggybacking on existing audio packets is essentially free. In the absence of media packets in the opposite direction, a "heartbeat" of, say, half an average RTT is probably appropriate. -- John Leslie <john@jlc.net>