Subject: RE: making satellite channel loss transparent

From: "ketan bajaj" <[email-masked]>
Date: Fri, 23 Jul 1999 00:11:55 PDT

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

> > 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 ?
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: Jamshid Mahdavi <[email-masked]>
Date: 23 Jul 1999 07:22:08 -0700

> tcp to fast retranmission, and thus poor performance.

In the absense of explicit information, the sender *must* assume that
a lost packet is an indication of congestion.  You can't change this
aspect of TCP, although you could try to find a way to let the sender
know that a particular packet loss was due to corruption rather than
congestion.

Alas, I think this is probably not the only cause of poor TCP
performance over satellite...

--J

---

From: Alex Cannara <[email-masked]>
Date: Fri, 23 Jul 1999 08:23:08 -0700

This is an issue that would be helped by good ECN and new sender code,
if the sender then could assume lack of ECN implies error loss -- thus
keep sending with no backoff.  In simple loss cases on normal WANs, <1%
loss gives >20% slowdown in typical, current TCP throughput.

Alex

---

From: Alex Cannara <[email-masked]>
Date: Fri, 23 Jul 1999 08:47:35 -0700

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

---

From: Jamshid Mahdavi <[email-masked]>
Date: 23 Jul 1999 09:32:01 -0700

> loss gives >20% slowdown in typical, current TCP throughput.

Unfortunately, you can't make this assumption ("lack of ECN implies
error loss").

I believe that Phil Karn (I hope I'm attributing this correctly) has
suggested something like an "ICMP Corruption" message which a router
could send back if a packet failed a link layer CRC error.  Kevin just
explained this to me yesterday, and I think it sounds like a
reasonable idea (provided you could get it implemented in the routers
-- but it would only need to be implemented in hosts/routers which
were connected to high error links, so maybe it would be OK).  If
something like this were implemented, then the sender could be *sure*
that the loss was not due to congestion.

Note that this doesn't have the problem of the ICMP Source Quench,
which is that you generate *more traffic* in response to congestion.

Note that there is one danger with this: misunderstanding.  For
example, consider an ATM AAL5 packet which arrives with one cell
missing.  The people writing the code need to recognize that this is a
result of *congestion*, not corruption.  I could easily imagine
someone getting this wrong.

I don't know enough about wireless to know if there are similar
situations where apparent corruption can actually be caused by
congestion conditions (which then ought to warrant a TCP backoff).

--J

---

From: [email-masked] (Robert C. Durst)
Date: Fri, 23 Jul 1999 18:38:07 -0400

Ketan,

>> > satellite hop is the last hop of the end-to-end path. What about more 

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.

>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 

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.)

>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.

>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-masked]

---

From: Alex Cannara <[email-masked]>
Date: Fri, 23 Jul 1999 20:17:58 -0700

Jamshid,

I agree, the use of some mechanism that makes a clear distinction
between loss and congestion available to the sender is what would make
things much better.  I think others have also mentioned that loss and
congestion can become correlated in wireless links, due to how
contention can occur.  This would mean that such links would need to
resolve the contention themselves (e.g., as does Ethernet), or provide
the proper info to the sender(s) so efficient transport-layer recoveries
are made.

Alex