Ketan,
ketan bajaj wrote (this moved up from the end):
>> > The issue i'm trying to raise here is why bother TCP to
>> > distinguish between
>> > packet loss due to corrution or due to congestion, why not make the
>> > corruption loss transparent to sender tcp ? Some of the work
>> > ive seen in
>> > doing the above, are split-connection and berkeley snoop
>> > designs. But they
>> > are limited to a particular satellite network topologies, where the
>> > satellite hop is the last hop of the end-to-end path. What about more
>> > generic topologies ?
As I understand it, your original question was "Why bother trying to make TCP
distinguish between corruption loss and congestion loss, why not make corruption
loss transparent to the sending TCP." Consider the ways to 'hide' corruption
losses from TCP. The ways to do this are: 1) FEC 2) retransmissions (ARQ) below
TCP.
FEC lowers the effective bandwidth of the channel, but is otherwise benign to
TCP. Note that the entity controlling the TCP endpoints may not be the
satellite channel provider, and hence may not have control over the amount of
FEC used on the satellite channel. If the FEC on the channel is too low, the
error rate may be detrimental to TCP throughput. That is, the throughput of a
'standard' TCP will be low if the error rate is too high. If there is enough
FEC on the channel to essentially eliminate all errors, it might yield a very
low bandwidth pipe. There may be technical and/or economic reasons for a
satellite channel provider to set the amount of FEC at a particular level
independent of what is best for TCP throughput.
ARQ introduces variability into TCP's perceived RTT, which can cause problems.
I believe there was a recent discussion of this on the mailing lists for
end-to-end-interest and pilc.
Given the above, we've been investigating methods to allow TCP to distinguish
between losses due to congestion and those due to corruption. Such a TCP
enhancement might improve throughput without affecting TCP's ability to
appropriately manage congestion. This approach assumes some sort of link layer
error detection and network layer signaling to inform TCP of corruption events.
Our thought is that a TCP enhanced to respond appropriately to corruption loss
wouldn't suffer the same throughput degradation as a 'standard' TCP in an
error-prone environment. This is one thrust of the SCPS work that we've done
that you cite below (more comments on that in a bit).
Your comments on proxies raise some other interesting points, addressed below.
>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.
Even with transport layer proxies, you can have end-to-end semantics at the
application layer, thus the applications can compute round trip times.
(Applications generally don't have access to TCP's notion of round trip time.
Rather, any application RTT is maintained by the application itself, and is
generated from the end-to-end interactions of the application with its peer.)
>Moreover if data is lost over a terrestrial 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.
If a transport layer gateway is built properly, TCP's flow control mechanisms
can propagate to provide, if it's necessary, end-to-end flow control, even with
split connections. We have experimented with a transparent transport-layer
gateway based on the SCPS enhancements to TCP. All of the
things that folks (including ourselves!) are prone to saying about such gateways
apply, but we were surprised by the amount of transport layer semantics that we
were able to preserve. As we mentioned, end-to-end flow control can be
preserved, mitigated somewhat by the send and receive buffers of the
concatenated connections. The end-to-end completeness semantic can be preserved
by delaying the acknowledgment of a FIN received from the source until that FIN
has propagated to the far end and its acknowledgment has been received by the
gateway. (Of course, even with end-to-end TCP, there's no absolute guarantee of
data delivery without an application-layer handshake, because of the possibility
of a remote system crash after a local-side close. Many applications have such
a handshake.)
>
>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.
This is the case with any modification or enhancement to TCP - some systems
have the enhancements and some don't. The enhancements to TCP called SCPS-TP
behave like any other TCP options - if a remote system knows about the option,
it gets used. If not, it doesn't. As with any other enhancements to TCP, such
as SACK, partial deployment is not really an issue. Those systems that have the
enhancement derive the benefit, and those that don't do not. There is nothing
unfair about not misinterpreting corruption loss as congestion loss. It is just
unfortunate for those systems that haven't deployed the enhancement.
>
>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.
The root cause of TCP's poor performance in error-prone high bandwidth-delay
product channels is that it interprets all loss as congestion. When the source
of loss is not congestion, invoking a congestion response is a misinterpretation
that leads to poor performance. If one can eliminate losses due to corruption
(with FEC, etc.), great. However, in some environments, it's either not
possible or economically feasible to do this.
The modifications that we have explored with SCPS-TP are intended to improve
TCP performance in those situations without negatively impacting TCP behavior
in the more traditional environments.
Hope this helps,
Bob Durst
[email protected]
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:55 EST