I'm not sure the implication is valid. Spoofing is, essentially, a delay
mitigation mechanism whereas the TCP options are, essentially, error
mitigation techniques. There is nothing in the TCP Options (to my
knowledge) that will improve short file transfer, such as web browsing, when
the link is error-free.
Therefore I would not suggest making this last assumption.
Thanks Matt
-------------
Original Text
>From BORDER@SMTPGATE (John Border) {[email protected]}, on 24/3/98 9:15 AM:
To: MALLMAN@SMTPGATE {[email protected]}
Cc: TCP-OVER@SMTPGATE {[email protected]}
> > 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...
I agree that the area is outside of the scope of the WG documents. I
was wondering if some verbage should be added to the overview document
with this problem as another motivating factor to encourage
implementing TCP extensions to improve TCP performance over
satellite. (I am not sure if it fits.)
John
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:36 EST