The GPRS networks where I have seen high latencies typically suffer from "buffer bloat". As a result, instead of dropping packets in the event of congestion, they just fill up the (overly large) buffers, demonstrating larger and larger queuing delays until finally the buffers are full, and (often multiple) losses ensue. TCP then backs off, and both rate (and delay) begin to build again.
On Thu, Aug 18, 2011 at 6:02 PM, Mark Rejhon <[email protected]> wrote: > > In most cases, you are right. However, it's also important to > determine what the latency spike is being caused by. GPRS is more > usually closer to 500ms-1000ms latency. Whenever there's a latency > spike, it's sometimes due to congestion, and if it is due to a > bandwidth starvation scenario, then lengthening the interval is the > best way to ensure the survival of XEP-0301 (where the alternative is > potentially a spontaneous disconnection or several seconds of lagging > oth of buffered-up 1000ms packets). Other times, latency spike are NOT > caused by bandwidth starvation issues or overload issues, but you do > not always know that. In situations of connections normally averaging > 1000ms or less, spiking to 3000ms, it is usually the safest and lesser > evil (less screen-to-screen latency) to lengthen the transmission > interval, in order to reduce screen-to-screen lag by reducing the > number of bytes that "piles up" in massive congestion. > > Also, I point out that your paragraph "section 10.2 is sufficient" > appears to contradict the next paragraph, "I do not think that is > needed..." because section 10.2 implies that it is needed. > > Sincerely, > Mark Rejhon >
