Eric,
No, I am not trying to start a holy war either. I also feel that an I-D
must contain valuable information.
However, I believe that there is a scope which must be adhered to in order
to get anything done and achieve something of value.
What I am saying is that the TCPSAT group's I-Ds should focus on TCP over
Satellite specifically. Therefore FEC is valid as it is a satellite issue.
SACK, ACK spacing etc are valid becuase they are TCP issues. As Mark's
email says, there is grey in between. I am not advocating or discouraging
the use of spoofing, I am just saying that I believe it to be outside of the
scope of this document, but not necessarily beyond the scope of an other
I-D. My personal views on what should and shouldn't be included are
expressed in response to Mark.
Let me know what you think.
Thanks Matt
-------------
Original Text
>From TRAVIS@SMTPGATE (Eric Travis) {[email protected]}, on 25/3/98 12:03 PM:
To: HALSEM@INTELSAT (matthew halsey)
Cc: TCP-OVER@SMTPGATE {[email protected]}
Matt,
Please don't get me wrong, overall I think we're on the same page.
Personally, I think spoofing is the wrong direction to go;
A correct addressing of this issue would explain why attempting
to use spoofing "avoid using TCP" is the wrong approach.
What was being suggested is explaining the problems with this
increasingly common "technique for mitigating TCP performance
problems" and stressing the need for the adoption of mainstream
improvements to TCP. I'm still not sure why that is inappropriate
for a document produced by this group.
It's a slippery slope after all, using the same argument:
"It does not address an improvement which can be made to TCP"
I could claim the lower-layer mitigation regarding FEC (from the draft):
"The use of forward error correction coding (FEC) on a satellite
link should be used to bring the performance of the link to at
least fiber quality."
is not related to TCP and therefore out of scope. Thankfully, I don't
believe that would be a valid or useful position; though the "at least
fiber quality" is an expensive hurdle.
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?).
There is merit in pointing out what is bad in an informational document.
By taking an overly narrow focus, one ignores the fact that TCP
performance improvement is a holistic thing. We avoid suggesting the
use of proxies, caches, replication, intelligent network planning,
proper router buffer allocations, motivations for deploying of fair
queuing etc. These things *impact* TCP performance over satellite,
and therefore, seem to be applicable. They are also more feasible
than ubiquitous use (NOT deployment) of the required TCP enhancements
in the near future.
There *are* best-common practices that really do improve TCP performance.
We leave the impression that short of deploying the proper TCP
enhancements at *both* ends of a connection, there is little anyone
can do to improve their existing performance. This is not true, and
almost validates that ridiculous LA Times article of 18 months ago.
Please understand, I'm not trying to start a holy war (though my
frustration does sometimes shine through). I just question what is
really accomplished by such a narrow focus in informational documents.
Consensus seems to indicate my dissenting opinion on most things is in
the minority, and that's OK :o)
My goal is to provide good service (and information) to my users.
I know that is your goal too.
Regards,
Eric
On Wed, 25 Mar 1998, matthew halsey wrote:
> I have just had a discusssion on spoofing with one of my colleagues. He
> pointed out a fundamental reason why we don't feel that it should be
> included in the TCPsat I-Ds and that is because it is not a TCP
> modification. It does not address an improvement which can be made to TCP
> but rather addresses a method to avoid using TCP. The drafts concern TCP
> over Satellite and so should stick to TCP issues rather than general
> Internet over Satellite issues.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST