In message <[email protected]>, "Lynch
, Tom" writes:
> After careful review of the Draft "Enhancing TCP over Satellite Channels
> using Standard Mechanisms (v01)" we came to the conclusion that the
> document seems to lack a goal/focus. What are we trying to achieve?
> Now that we have identified the factors that limit performance in a
> satellite based network, and identified different approaches to mitigate
> some of these problems, will any specific recommendations be made to
> change the requirements to the TCP protocol? Are we going to suggest
> that some of the enhancements that are currently in most current
> releases (such as Fast Retransmit, Windows scaling) be upgraded to
> Required Status? Perhaps it is time to revisit the goals of the group.
> Otherwise this document runs the risk of being short lived and ignored.
>
>
> Thomas J Lynch
> AT&T Laboratories
> [email protected]
>
> Dr. Enrique G. Cuevas
> Satellite Communications
> International Network Technology Development
> AT&T Laboratories
> [email protected]
I'm not sure why the document would be ignored. In a nutshell it says
that there are some really stupid ways to use TCP some of which are
changeable defaults and some of which are built in to specific less
cluefull vendor implementations and there are smarter ways to use TCP
*as is*. Using TCP *as currently defined* but insuring that your
vendor supports certain RFCs (such as Path MTU Discovery, RFC1323 and
in particular window scaling, and SACK) and making sure these options
are enabled and some configuration done can make a few decimal orders
of magnitude difference in performance.
In considering this as an Informational RFC, this sort of thing
strikes me as *very* useful information. It describes the worst and
best that can be done using the existing standards. It is a useful
product of the WG though not nessecarily the only product of the WG.
Curtis
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:34 EST