<div dir="auto"><div>Late 2018. </div><div dir="auto"><br></div><div dir="auto">HTS people seem to have different results, experiences, and opinions with traditional TCP working on their links. </div><div dir="auto"><br></div><div dir="auto">-mdt</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019, 01:43 Phil Karn via Ground-Station <ground-station@lists.openresearch.institute> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2/25/19 09:11, Michelle Thompson via Ground-Station wrote:<br>
> One of the books I picked up at Information Theory and Applications<br>
> Conference was Network and Protocol Architectures for Future Satellite<br>
> Systems. <br>
<br>
When did it come out?<br>
<br>
> The first problem you run into is that TCP views long latency links as<br>
> congestion and does what it's good at and slows things down. <br>
<br>
This problem was addressed 20+ years ago with TCP header timestamps and<br>
window scaling, both of which have been universally deployed for some<br>
time now.<br>
<br>
Header timestamps solves the problem I addressed my round trip timing<br>
algorithm in the late 1980s. I chose to do it without changing TCP, but<br>
given that the protocol could be changed, timestamps was a much better<br>
solution.<br>
<br>
Window scaling got around TCP's original 64KB window limit, meaning that<br>
it couldn't send more than 64 kilobytes per round trip time. This<br>
rapidly became a problem on terrestrial fiber, not just geostationary<br>
satellites. The SYN (synchronize, or connection setup) packets convey a<br>
"scale" parameter that is the base-2 log of the value to be multiplied<br>
by all subsequent window advertisements in the session. E.g., if the<br>
window scale parameter is 5, then all window announcements should be<br>
left-shifted by 5 bits.<br>
<br>
This completely solves the problem for bulk transfers over long delay<br>
channels **provided** that the packet loss rate is kept small. TCP still<br>
has problems when packets are lost more often than roughly once per<br>
round trip time. There are additional enhancements (selective ACKs) to<br>
handle this problem, but it is still best to design the subnet for a<br>
much lower packet loss rate. How you do this is left up to the subnet<br>
designer. See RFC 3819, Advice for Internet Subnetwork Designers.<br>
<br>
Phil<br>
<br>
<br>
_______________________________________________<br>
Ground-Station mailing list<br>
Ground-Station@lists.openresearch.institute<br>
<a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="noreferrer noreferrer" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br>
</blockquote></div></div></div>