Requesting a 10KB http page today takes roughly 6 round trips,
assuming nothing is dropped, and if 5% of the packets were dropped,
it would be even worse (question for the analytically inclined --
how much worse? With coarse grained timeouts it would be really bad,
but even suppose we assumed the timeout took exactly 1 RTT -- it would
still be pretty bad.) And even worse if you include queueing delay.
By the way, using TTCP would eliminate only one of the 6 round trips!
The challenge is, can we make a small request be optimal -- take on the
order of 1 RTT -- in other words, make small stuff go an order of
magnitude faster than the situation today?
How would we do this? Let's assume we have lots of Detour
routers spread around the Internet. Then I think it means
1. client -> nearest Detour router; router makes it appear that connection
is established, so client forwards request immediately to router,
without waiting for end-to-end connection. Need to be careful of
failure modes, but perhaps we establish a peer to the Detour router
that is informed of all short connections managed by the router,
and if the router fails, jams Resets back to the clients.
Thus, router has entire packet train for the connection.
2. Detour router -> Detour router; short request/reply is prioritized
to be put into tunnel ahead of long connections, and router measures
traffic characteristics to make sure tunnel reduces congestion
on the opaque routers being tunneled over. But no need for slow start
in dumping the packet train in the tunnel. Sequence number
is used on tunnel to provide "soft" NAKs for dropped packets on tunnel.
(NAKs are soft in that if they get dropped, endpoint can recover. NAKs
should be selective -- ie, SNAKs). Router needs to keep copy of packet
only for a single round trip over the tunnel; if no SNAK is received, it
drops the packets -- ah, the advantages of soft state. For short connections,
buffer management should be by credits, and if the credits would run out
before entire request would get through, the entire packet train is dropped,
(No buildup of queued packets due to misbehavior or lack of capacity
of downstream router.) For long requests, can use straight RED (or
whatever).
3. Detour router -> server, and back to client Same as #1 and #2.
tom