[e2e] Is a non-TCP solution dead?

[Cannara]

Could be useful Jon, as long as all the processors with queues of interest on
the path aren't discriminating among protocols, ports, etc. and placing these
pkts in separate queues with separate attributes (priority, loss algorithm,
etc.).  The complexity of current packet-processing devices is extremely high
in relation to their costs, so lots of things can happen to packets along a
path now.

Alex

Jon Crowcroft wrote:
> 
> 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:-)

--
Alex
79xj6L SII (BRG + wires)
86xj6 SIII (Black)
61 Sprite MkII (Red)
Menlo Park, Calif.