[Sis-csi] noting unusual CCSDS security critique

[Scott, Keith L.]

Lloyd,

While it's true that TCP's tuned for performance in an Internet
environment will have problems when traversing highly asymmetric links,
that doesn't mean that you can't run a TCP connection across such
links.  A pair of performance enhancing proxies (PEPs) (e.g. SCPS-TP
proxies) at each end of a link like you describe can be configured to
run at close to the line rate down and to reduce the ack channel
bandwidth to fit the uplink.  

The reason to do this would be to allow users to run unmodified
TCP-based applications on the end hosts and to not worry about the
vagaries of the connection.  This also allows the data transfer to
extend beyond the single space-to-ground link case, since the
terrestrial portion of the path can use 'standard' TCP with congestion
control.  There are other issues here, like how to keep those
applications from trying to send data outside of a pass.  There are
ways to apply backpressure  from the PEPs when there's no pass, or one
can use CFDP/DTN.

CFDP's extended procedures (and DTN) can go beyond what the PEP
approach or single-link protocols like Saratoga can do, like support
multi-hop data transfers when there is no contemporaneous end-to-end
path.  As in the PEP scenario, CFDP and DTN can be configured to highly
utilize reserved resources (like scheduled downlinks) where appropriate
and to employ congestion control in shared portions of the network to
support getting the data all the way to destinations beyond the ground
station.

		--keith

>-----Original Message-----
>From: sis-csi-bounces at mailman.ccsds.org 
>[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Lloyd Wood
>Sent: Wednesday, October 05, 2005 4:30 PM
>To: Scott Burleigh
>Cc: sis-csi at mailman.ccsds.org
>Subject: Re: [Sis-csi] noting unusual CCSDS security critique
>

[snip]

>You can't get TCP to run at any decent rate over 8Mbps down/9600bps
>back; the bottleneck on the acks is a major constraint, and you'll
>never get out of slow start. TCP's probing of available capacity to
>ensure fairness is not useful when you're scheduling access to the
>downlink and are concerned with link utilization across the downlink.
>Given that TCP's design is clearly not suitable for this scenario, why
>go to the trouble of running an implementation?

[snip]