On Wed, 25 Mar 1998, matthew halsey wrote:
> 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.
Matt,
I understand and respect your position. This is, however, generating way
more traffic than it is worth.
Spoofing *does* impact TCP streams; spoofing means many things (including
artificially spacing of Acks to shape traffic). Spoofing is a TCP issue
because it is done to mitigate the poor performance of TCP in certain
conditions.
Most spoofing techniques fall into the "research" bucket if for no other
reason than we don't necessarily understand their impacts on overall
network welfare. To me, this alone is a good reason to address it and
caution against deployment except in private networks.
Other reasons are against widespread spoofing are complexity, asymmetric
paths, gaping security holes and they tend to make the network more
brittle and less robust. This is a good motivation for end-to-end
mechanisms that aren't dependent on assistance from within the network.
I tend to think that an informational document shouldn't duck this topic,
it's a good motivator for addressing problems in the transport protocol
itself. The world won't stop spinning either way.
For a while, we were discussing whether such a topic was applicable for
*anything* produced by this working group. It looks like we're beyond that
now, and this is cool.
Further pondering of value of spoofing is probably best left done over
a drink in LA. :o)
Peace,
Eric
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST