Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

[Eric Travis <[e-mail]>]

On Tue, 31 Mar 1998, Christian Huitema wrote:

> By the way, it should be noted that the only rationale, if any, for
> TCP spoofing in the satellite relays is the inadequacy of the end-to-end
> TCP implementation.  The specificities of satellites and their interaction
> with transport protocols have been known for more than 15 years, and the
> cure is also very well known: use large windows, use selective 
> acknowledgments.  The only slightly researchy subject is the possible
> use of pacing mechanisms to avoid the swings caused by large windows.
> TCP support both large windows and selective acknowledgements.  A user
> that opts for end to end encryption will still get good performances
> over satellite links if they also select proper TCP implementations.

Actually, no... (!)

For one thing, you are assuming that both ends of a transport connection
are aware that they have a path including a long-delay path. Good
assumption 15 years ago, bad today and in the future.

Rather than rehash the problem space here, let me just say that BOTH sides
of a TCP connection must use a "proper TCP implementation" when the path
includes a satellite hop. For ad hoc connectivity this is a dicey
proposition at best; Even if the anonymous ftp server at foo.bar.com 
was RFC-1323 capable, what makes anyone think it can offer appropriate
windows for the available bw-delay product? 

Second, satellite links take far longer to recover from congestion than
their terrestrial counterparts (it turns out to be an r**2 thing with the
increase in ratios of relative delays in the path); 

There are many other little nits that make me disagree with the notion
that the problems are "solved" already. Suffice it to say, my vision
of future "last hop" connectivity to the Internet backbone is going
to be more asymmetric and possibly dirty.

For satellite users with long delays, short of upgrading every TCP
implementation known on Earth (and flying above) and providing omniscient
capabilities to the TCP implementations & applications as to proper
socket buffer sizes something else needs be done for performance
enhancement.

Spoofing conjures up bad images - but there is great benefit to overall
performance to splitting a connection. Spoofing/proxying is not just for
long delay paths, but also for noisy environments (such as
wireless/mobile). It has it's end-to-end downsides, but it's happening
already and should be brought out of the closet - if for no other reason
than to categorize the impacts (positive and negative) to the larger
network.

No need to debate it here, we can take it to tcp-over-satellite 
(exclusively) if you so desire.

Regards,

Eric