Just a few comments on the comments:
>I think an additional mechanism should be documented, which is acking
>every packet. This is fully allowed by the existing standards, and
>results in the congestion window opening appreciably faster.
While being more aggressive is certainly the "right thing" for long-delay
paths, are we sure we want to recommend this behavior when shared paths
are involved? Since a connection is notified and responds to network
congestion in quanta of RTT, a long fat pipe that has built up momentum
will be pumping a lot of data into a congested bottleneck... I'm not sure
that would get satellite subnets the good-neighbor award;
Since most people are going to want a single stack for both terrestrial
and satellite paths, do we want to encourage everyone acking every packet
as the general case? It might give some fantastic benchmarking numbers for
a vendor, but everyone being more aggressive might degrade overall
performance.
Finally, there are significant asymmetry issues with this - sure it is
legal, but (in my opinion) the impacts on behavior *in this environment*
really push its deployment into the research bin.
>> Another common situation arises when both
>> the incoming and outgoing traffic are sent using a satellite
>> link, but the uplink has less available capacity than the
>> downlink. This asymmetry can have an impact on TCP performance.
>
>I was confused whether this is referring to the incoming and outgoing
>using the *same* satellite link, and the asymmetry comes from uplink/
>downlink capacity asymmetries; or if they're using different satellite
>links.
Like with mobile phones, the forward and reverse links are discrete.
Generally, one of these is *much* smaller, as it is/was generally expected
to be supporting only housekeeping and control operations.
>> satellite links. There are some situations where FEC cannot be
>> expected to solve the noise problem (such as military jamming, deep
>> space missions, noise caused by rain fade, etc.).
>
>It's not obvious why deep space missions have this problem. It's clear
>for the others that you can suffer from large outage blocks, rendering
>FEC ineffective. Is that the same problem with deep space?
I'm likely the reason for deep space being there, I think we need to get
rid of it.
The real scope of this document is more or less geared toward SATCOM
applications and we will never be use anything like TCP for deep-space
distances (for instance: you might can a chance to transmit your acks a
week after you get the data - a very cool problem, but not within domain
of TCP's inherent congestion-control). Splitting the connection:
TCPish <-> Protocol-X <-> TCPish
is the solution for deep space situations.
>IMHO, add:
>
>> | Ack every packet | Recommended | 4.X | R |
Because of the above concerns, we should be careful about this.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST