Form: Reply
Text: (12 lines follow)
Mark,
It sounds like its almost coming down to a matter of semantics. I would
propose that if a 'grey' mechanism results in a modified, but clearly
identified, TCP stream, it may be included. If the result is clearly NOT
TCP (and I would include UDP here) then it shouldn't be included.
Some spoofing terminates TCP at gateways and uses a more link-sensitive
protocol between them. This is clearly not TCP and shouldn't be included -
in my opinion.
I will be happy to debate this some more.
Thanks Matt
Original text: (64 lines follow)
>From MALLMAN@SMTPGATE (Mark Allman) {[email protected]}, on 25/3/98
11:56 AM:
To: HALSEM@INTELSAT (matthew halsey)
Cc: TRAVIS@SMTPGATE (Eric Travis) {[email protected]}, TCP-OVER@SMTPGATE
{[email protected]}
Matt-
Thanks for the comments. The following is an attempt to explain how
I have decided to include the mitigations that are currently listed
(or written) in the draft.
> 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.
Some of the mitigations that will help "Internet over Satellite" are
changes to TCP. Our charter calls for us to document these. Others
are obviously not changes to TCP (such as application layer
mitigations). These seem out of bounds, according to the charter.
Then, there is the third area: The grey area. And, it seems to me
that spoofing is grey. So, the question becomes what to do with the
grey mechanisms?
We could make the rule that if a given mechanism doesn't require
changes to the end-host TCP implementation that it is out-of-bounds
for this document. But, it seems to me that such a hard and fast
rule will leave out part of the story of TCP-over-satellite. Some
of the mechanisms that have been researched and been proposed are
implemented in the middle of the network (at gateways). But, that
doesn't necessarily precluse them from altering TCP connections just
as profoundly as a TCP implementation at the end-node might. For
instance, ACK spacing is done at a gateway to force the TCP sender
to pace segments out. The sender could implement its own pacing
without any help from the gateway. These two mechanisms would
probably be very similar in the end. So, when deciding what
mitigations to include I considered how much these grey mechananisms
impacted TCP connections.
And, it seems to me that spoofing profoundly changes TCP connections
(in terms of both performance and the semantics of a "connection").
Therefore, it seems to me to be "in bounds" for inclusion in the
document.
But, thats just my opinion... As I said above, I (/the WG) have not
established any hard and fast rules for what is to be included in
this document. I have been judging the mechanisms on a case-by-case
basis. Obviously the choice is not mine to make, but rather the WG
must decide in the end. I have made some choices to get things
started. But, I will be happy to add and delete sections based on
the consensus of the group. So, fire away...
allman
--- http://gigahertz.lerc.nasa.gov/~mallman/Use Proportional Font: true Previous From: MALLMAN@SMTPGATE (Mark Allman) {[email protected]} Previous To: HALSEM@INTELSAT (matthew halsey) Original to: HALSEM@INTELSAT (matthew halsey) Previous Cc: TCP-OVER@SMTPGATE {[email protected]}, TRAVIS@SMTPGATE (Eric Travis) {[email protected]} Original cc: TCP-OVER@SMTPGATE {[email protected]}, TRAVIS@SMTPGATE (Eric Travis) {[email protected]} Attachment Count: 0
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST