John-
Thanks for the comments...
> I finally got a chance to read the latest draft. An area of
> interest to me is TCP spoofing (since it is included in several of
> our products). I think the existing TCP spoofing section is
> pretty good, getting the idea across without touching on specifics
> (an important point since many versions of spoofing do exist).
> One of our products is capable of achieving TCP throughput (using
> spoofing) of up to 2.5 Mbps on links with an RTT of as long as 2
> seconds. If it is worthwhile to include such a high speed example
> in the draft, I can provide more details.
We would be very happy to include brief performance results with a
pointer to the appropriate literature. If you can point me towards
that, I would appreciate it.
> What I really wanted to offer up, though, is an observation.
> The product I work with is mainly used to implement private
> networks. But, I think this observation is going to eventually
> carry over into the Internet. What we are finding is that our
> customers are starting to do a lot of stuff on top of UDP in order
> to get around perceived limits of TCP. They simply implement
> their own error recovery, etc. on top of UDP. (Also, I know of at
> least one product (not ours) which implements TCP spoofing by
> converting it to UDP over the WAN.) Using UDP totally bypasses
> TCP congestion control. This is not so bad with a private network
> where other methods of congestion control can be implemented.
> But, if this does start showing up in the Internet, it might cause
> a lot of problems. I guess I am just offering this up as another
> reason why we need to solve some of the perceived TCP problems
> related to long delay paths...
This may become a very real problem... Even applications, such as
audio/video streaming, that are not necessarily just trying to "get
around" TCP's congestion control (i.e., UDP with no error recovery
mexhanism is the appropriate vehicle) can cause problems. All
UDP-based applications should respond to congestion signals. Kevin
Fall and Sally Floyd have a new paper on the subject of identifying
non-responsive flows at the gateway and penalizing these flows
accordingly. (I believe Sally has put the paper on her web page:
http://www-nrg.ee.lbl.gov/floyd/).
Even though this is an important area, it seems to me to be beyond
the scope of the two WG documents as it is really a mechanism for
gateways to use and not really a change to TCP. Of course,
dissenting opinions always welcome...
allman
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:36 EST