Note that spoofing has been around for many years for LAN protocols,
such as LLC, where folks like Cisco create effectively routed links for
unroutable protocols by acking locally, etc. Then, of course, we have
gateways (SNA to TCP, etc.), and, those nasty firewalls.
If the transport (e.g., LLC) isn't trying to do fancy calculations to
make up for its own incomplete design, then this works just fine. Some
LAN protocols, like DEC LAT, could not handle long round-trip delays
directly, but didn't go into backoff la-la land when they timed out,
they just multiplied (RTT div 0.08 for LAT) their traffic! If a
transport, perhaps derived from TCP, were given the smarts to: a) know
which packet (not just byte) is being acked, b) when just congestion is
occurring (not error loss), and c) when error loss is actually occurring
(e.g., reliable ECN), then great improvements in throughput in real
situations could be gained.
Note that TCP is alleged to be a "feedback control system" via its RTT
calcs, etc. However, it is mostly open loop and has no clear idea of
why an ack didn't come back yet, or the real reason why 3 acks were
repeated by the receiver. It ain't a feedback control system yet,
despite all the years its been poked at. The new millenium will need
more.
Alex
ketan bajaj wrote:
>
> thanks for the feedback, i agree that techniques such as spoofing (splitting
> the tcp connection) from companies mentioned like flash-networks & mentat,
> and explict signalling NASA JPL's SCPS-TP, and other techniques given in tcp
> pep, improve performance.
>
> topology : (sender)x------G1- - - - G2-------y(receiver)
> where G1-G2 is the satellite hop
>
> But, spoofing would violate the end-to-end tcp semantics, as the sender
> could receive an ack from the proxy receiver(G1) at one of the satellite
> link ends, before the data packet reaches the actual receiver (y).
> Calculating the correct round trip time could be crucial to some
> applications. Moreover if data is lost over a terrestial link which is after
> the satellite hop, then the sender won't be informed of the congestion loss,
> as the other satellite link end (G2) would do the recovery.
>
> Whereas in case of NASA's SCPS-TP, the hosts would require modification to
> process the corruption signal from the satellite link. Any protocol which
> requires the end hosts to be modified wouldn't be easy to deploy in the
> existing network. If it is deployed partially at some hosts, other hosts
> using the same satellite channel would be at a loss.
>
> Still we don't have a protocol which is completely transparent and preserves
> all existing semantics of tcp.
> What i'm trying to say is why not attack the real problem. The root cause
> for tcp's poor performace over satellite channels is that it fast
> retransmits on receiving 3 duplicate acks (reducing its window), and as the
> delay*bandwidth product over a satellite channel is large, the no. of data
> packets in the end-to-end pipe are large, so a loss due to corruption,
> results in a number of duplicates acks being generated, moving the sender
> tcp to fast retranmission, and thus poor performance.
>
> ketan
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:55 EST