[R-C] Feedback mechanisms

[John Leslie]

Randell Jesup <randell-ietf at 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 at jlc.net>