[e2e] Is a non-TCP solution dead?

[Jon Crowcroft]

gprs - natures way of telling tcp to slow down? :-)

so how about this  - we run a UDP flow along side the TCP flow 
at some percentage of the TCP rate (sort of like the rtcp/rtp policy)
 - we use smaller packets so we get a packet pair effect from them

e.g. if 576 byte TCP mss, then 57.6 byte udp mss (well say 64 and 512
for good measure - so if TCP is running at 30kbps (nominal GPRS 3
channel rate for example) and we have the usual lamentable 1 sec rtt,
then we ought to be operating at 8 packet per rtt of TCP, so lets send
8 packet a sec of UDP (note they are 10 times smaller so thats around
10%) - coz they are 10 times smaller, we can see any queue effect
build up- we could send them with unifrom random intervals drawn from
the range [0-.2] secs (if the average ought to be .1 say... and then
we get samples of the queue and queue variance - if this correlates
with what TCP says is congestion, we let tcp do its thing. if it
doesn't, we also tell tcp not to - if we can't tell tcp not to, we let
the UDP flow take up the slack for the precalculated TCP recovery
time, and Roberto est ton oncle....

we could call it
TCP UDP System Hybrid

maybe i am a day late though with this suggestion (too many pointless
RFCs to read:-)