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.
Thanks Matt
-------------
Original Text
>From TRAVIS@SMTPGATE (Eric Travis) {[email protected]}, on 24/3/98 4:33 PM:
To: HALSEM@INTELSAT (matthew halsey)
Cc: TCP-OVER@SMTPGATE {[email protected]}
Matt,
I think that I agree in spirit, but the devil is in the details:
>I'm not sure the implication is valid. Spoofing is, essentially, a delay
>mitigation mechanism whereas the TCP options are, essentially, error
>mitigation techniques. There is nothing in the TCP Options (to my
>knowledge) that will improve short file transfer, such as web browsing,
>when the link is error-free.
I'm not sure that the current TCP options are error mitigation techniques
(with the possible exception of SACK);
RFC-1323 options are large-window mitigation techniques, but not
necessarily related to long-delays (large windows let you support large
bandwidth-delay products, timestamps improves RTT estimation and PAWS
removes ambiguity associated with possible sequence space wrap). RFC-2018
(SACK) certainly can help with respect to recovering from losses due to
errors, but I'd classify it a loss-recovery mitigation (the distinction
between errors and congestion-based losses being significant).
One can "spoof" specifically to mitigate errored links. I *know*
this is a different spoofing than John was addressing, but it is a
spoofing technique.
A final nit (sorry): I'm not convinced that for short transfers in a
satellite environment, any of the TCP options help even if the link is
NOT error free. Perhaps SACK can save you from a RTO - but maybe not.
If your transfer is larger than your initial cwnd and less than the
bandwidth-delay product, your performance is always going to suffer.
RFC-1644 would be a win for the 2nd through Nth connections between a
particular pair of hosts.
Optional increase of the initial cwnd to 2 segments should help short
transfers, but that's not a really a protocol option in the same
sense - it has no option number. It's a proposed *implementation* choice,
and possibly a system-wide configuration option. There is no standard API
proposed for turning this on/off for particular connections - something
I'd like to see instead of having to provide this behavior as default.
Ioctls will probably be available for some implementations, but this is
decidedly non-portable.
In my opinion, the complexity introduced by adding spoofing and/or
UDP-based alternatives to network architectures is a good motivation for
attacking the problems at the transport protocol - and should, therefore,
be discussed somewhere.
It really doesn't fit into either draft, but nevertheless, I still think
it's something that should have been (be?) addressed by this group.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:36 EST