[MUD-Dev] [TECH] TCP fundamental throughput limits?

[ceo]

Someone recently pointed out to me that TCP is limited to a
theoretical maximum throughput for any given pair of RTT and percent
packet loss.

I'd never thought about it before, but it certainly makes perfect
sense when using AIMD (basically: when packets are not being
dropped, it increases speed linearly, when they ARE being dropped,
it decreases speed exponentially). The decrease massively outstrips
the increase, so it makes sense that for given RTT + packet loss,
you will only be able to hit a given throughput, on average.

This of course matters hugely when you have a huge bandwidth - or
very high RTT or packet loss. The latter comes into play with mobile
device gaming, and e.g. MUDding from a handheld client over 3G
systems, where RTT's have been historically very high.

However, I thought that very few (if any) TCP implementations were
using simple AIMD, and that most were considerably better. I know
that my old favourite (TCP Vegas) is not in general usage (sob, sob
:)), but I thought other improvements were.

However, there are several companies making grand claims that their
TCP replacements are "up to 100 times faster than TCP, and tupically
30 times faster...at least 3 times faster".

I was wondering if anyone on this list is acquainted with current
typical TCP implementations and/or knows anything about quite how
serious these theoretical limits are in practice?

Certainly, it can potentially put a new spin on the "TCP vs UDP"
debate which I've not seen before...e.g. perhaps something like "for
mobile devices with 500ms+ RTT's, don't bother with TCP at
all". (nb: I've not done the maths to work out what the critical
threshold for RTT/packet losses is, but the sales literature is
based on 200ms and fairly small
packet loss).

Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev