Re: summary and follow-up: transparent tcp improvements

Eric Travis <travis@gst.com> Wed, 17 April 2002 00:32 UTC

Message-ID: <3CBCC2BA.2080907@gst.com>
Date: Tue, 16 Apr 2002 20:32:58 -0400
From: Eric Travis <travis@gst.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6
MIME-Version: 1.0
To: karl.jonas@ieee.org
Cc: tcpsat@grc.nasa.gov
Subject: Re: summary and follow-up: transparent tcp improvements
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcpsat@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 3272
Lines: 87

Karl,

>The FOLLOW-UP question is:
>Is there experience with tcp spoofing, increasing the throughput
>from the sender over the wired network towards the gateway, and
>removing slow-start (and possibly modifying congestion avoidance)
>(by the gateway) towards the mobile terminal behind the (long delay 
>
>and fully controlled) wireless link ?
>tcp sender -- (network) -- gateway -- (wireless link) -- mobile receiver
>
>(no modifications on sender/receiver, low bandwidth and long dely on 
>the wireless link, many small tcp connections as typically in http /
>www-traffic)
>

What you are looking for seems to be an entity that be
can dropped in at the interface between your wireless
links and their interconnection to the/a relatively
"uncontrolled" internet (intranet); Via deployment of
this magic box you'd like:

   a. To garner as much bandwidth over the tethered
      network path as if your mobile client were
      co-located with this entity

   b. To maximize the data throughput over the tetherless
      path > In The Direction Toward The Mobile Device <

   c. To leave as unmodified the protocol stacks (and
      any other configuration specific parameters) on
      both the mobile device and the random data sources
      from which the mobile wishes to extract data/content

Since you state that the tetherless portion of your
network path is "fully controlled", the magic box you
seem to desire should (keyed to the above):

   a. Act as a transparent proxy for the mobile device
      (either at the application layer or a the transport
      layer);  All associated distastefulness and pitfalls
      acknowledged[*] by you and related to your users/subscribers
      (right?)

   b. Pace the data (in the form of proper TCP segments)
      toward the mobile device at a rate prescribed by
      your "fully controlled" wireless link's configuration
      parameters.

   c. The above pacing should be *reliable*, making use
      of (and properly interpreting) the well defined TCP
      semantics - as the mobile device is going to be
      utilizing an unmodified TCP.

   d. Bonus: Retransmit any segments lost over the
      tethered network (for whatever reason) without
      requiring them to be retransmitted over the
      tetherless path (improving both power utilization
      and responsiveness)

If I have gotten the above correct, then to answer your question:

   Yes, we do have experience doing precisely this;

   Yes, it works very well (but also introduces all
   the risks associated with the violence of shoving
   something in the middle of a TCP connection)

Since the mailing lists are not places for advertising
or plugs (shameless of otherwise), I've previously sent
you appropriate pointers/contact information for a
TCP Tranquility (SCPS-TP) gateway implementation.

Remember as you go down this path:

  since you are accreting transport state at the
  interface of the wireless/wired regions, you are
  going to have to have some mechanism(s) (outside
  the scope of your transport protocol/spoofing
  techniques) for handing off this state (these
  transport connections) as your mobile roams.
 
Eric
(travis@gst.com)

[*] unfortunately for those who choose to live
    an honest life, there are no free lunches.