[R-C] Feedback mechanisms
Randell Jesup
randell-ietf at jesup.org
Wed Aug 15 15:35:17 CEST 2012
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
More information about the Rtp-congestion
mailing list