
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@jesup.org