> > As informational documents, part of their value should be more
> > than pointing out existing RFCs - it should (in my opinion)
> > address things that can improve TCP performance, as well as things
> > we know people do and are potentially harmful (worst common
> > practices?).
>
> I agree. I don't think the research issues draft is pointing at
> many RFCs.
Looking at the wording, I can see that interpretation but the plural
documents referred to both drafts. The "mechanisms" draft certainly
is pointing exclusively at existing RFCs. :o)
The flow had turned from applicability for inclusion in a "research"
document to what is applicable for the scope of the group as a whole.
This and a proposed litmus test is the context for the quote.
> Furthermore, I agree with you that TCP isn't the only thing we need
> to look at. As you pointed out, we need to look at proxies,
> application protocols, etc., etc., etc. My point in limiting the
> document is not to discount these mechanisms as unneeded. My point
> in limiting the scope is to get _something_ done. It would take a
> very long time to get a document together that covered all things
> that people can do to their satellite networks to make them work
> better. I think the goal of this WG is to focus on TCP. I think
> that more informational documents may be needed on ``other
> mechanisms'' that help out. My point is to try to keep things
> mostly focused on TCP in order to avoid getting bogged down in a
> very large, hard to finish document.
TCP performance improvement is a holistic thing. Improvements are
restricted:
To modify TCP itself is not a choice in the short term.
Anything that requires two-ends of a connection to have
a subset of optional enhancements requires upgrading
all installed TCPs. This is not going to happen in the
short term.
Unfortunately, this includes widespread deployment of
RFC-1323 or RFC-2018 code. Notice the words, *deployment
of code*. Enabling those options is something else on
top of that. Setting the buffer sizes to useful values
is added requirements/complexity. These are real-world
issues.
For closed, well coordinated/managed communities, OK;
Even if divine intervention made transition quick and
painless, the appropriate use of these enhancements
requires more intervention.
Most traffic over satellite links is probably ad hoc in
nature (random telnet, ftp, http, etc.) can I expect a
random information provider to provide the options a
satellite path requires and the proper parameterization?
Ironically, this is what drives one to spoof :o(
So realistically, most of the things that satellite users can
do to improve performance are not strictly TCP related.
Condensing the collected learning and options of operating in the
satellite environment *is* tough. Doing so in an approachable
document is even worse - but I still think it is necessary.
We've been here before :o)
The traffic/questions posted to this list are clues as to
what is required for the user community. Attempting to address
this is (along with a fair amount of guilt) is what pushed us
to divert efforts to our "Journeyman's Guide" distillation.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST