Subject: RE: tcp enhancement

From: Dean Martin <[email-masked]>
Date: Fri, 23 Jul 1999 06:08:07 -0400 (EDT)

Hi
The terms spoofing has different meaning and generally denotes systems
which send false acknowledgements to the end node to trick it into
sending data faster than what TCP specifies. In this case, spoofing
does not take into account the risk of congestion.  Whereas when  in
the case of protocol conversion at the same level a new congestion
mecanism is used. What is important in the split configuration (Flash
or Mentat) that there is a low throughput variation as a function of
the bit error rate for the new protocol.

-----Message d'origine-----
De:	ketan bajaj [SMTP:[email-masked]]
Date:	vendredi 23 juillet 1999 09:12
À:	[email-masked]
Cc:	[email-masked]
Objet:	RE: making satellite channel loss transparent

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
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: William D Ivancic <[email-masked]>
Date: Mon, 26 Jul 1999 08:37:57 -0400

>.....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 
>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, 
>sender tcp to fast retranmission, and thus poor performance.
>
>ketan

We can always engineer the optimum solution for a particular problem.
However, TCP is a compromise that works in nearly all environments and
works very well in many of those environments.  Proposing a solution that
works well for Satellites at the expense of most other environments such as
LANs may not be the best way to proceed.

Will Ivancic 
*********************************************
William D. Ivancic
NASA Glenn Research Center
21000 Brookpark Rd.   MS 54-8
Cleveland, Ohio  44135
USA
Phone:   1 216 433 3494
FAX:     1 216 433 8705
Email:   [email-masked]
             [email-masked]	
http://ctd.grc.nasa.gov/5610/5610.html	
*********************************************

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 26 Jul 1999 16:34:42 +0100 (BST)

On Mon, 26 Jul 1999, William D Ivancic wrote:

> works very well in many of those environments. 

TCP is a compromise that works well in human-scale environments. At
the small end of the bandwidth*delay product, it's way too much
overhead for parallel processing. At the large end, it's too chatty
for deep space communications with half-hour or more propagation
delays.

If you're going to attack the real problem, make sure you identify it
as lack of SACK implementation first (RFC2581/2582/2018), because use
of SACK by both ends alters the response to corruption and decreases
the number of retransmits.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>