[R-C] Feedback mechanisms

[Randell Jesup]

On 8/15/2012 7:08 AM, Piers O'Hanlon wrote:
> Hi Bill,
>
> In reference to point your (1) - I'd have thought the RMCAT flows would differ from streaming/TCP community as they are generally going to be sending flows in both directions simultaneously so we're often (with ADSL, Cable) going to be limited by that upstream capacity for actually sending media in most cases - so the sender's [b]ack-channel is going to be using the 'downstream' channel which won't be limiting feedback much.

Two-way flows will be the norm, though not the only use-case for RMCAT.  
(For example, watching/controling remote security cameras). But since 
they're both the norm and the harder case, it makes sense to optimize 
for them.

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 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.  It would add much more to the packet rate than to 
the bandwidth used, 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.

This WiFi issue (if confirmed) might be a reason to consider either 
piggybacking feedback and/or reducing feedback frequency, at least in 
stable situations.

-- 
Randell Jesup
randell-ietf at jesup.org