[Ground-station] MPTCP, network coding, ICN, and satellites!

[Michelle Thompson]

Late 2018.

HTS people seem to have different results, experiences, and opinions with
traditional TCP working on their links.

-mdt

On Tue, Feb 26, 2019, 01:43 Phil Karn via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> On 2/25/19 09:11, Michelle Thompson via Ground-Station wrote:
> > One of the books I picked up at Information Theory and Applications
> > Conference was Network and Protocol Architectures for Future Satellite
> > Systems.
>
> When did it come out?
>
> > The first problem you run into is that TCP views long latency links as
> > congestion and does what it's good at and slows things down.
>
> This problem was addressed 20+ years ago with TCP header timestamps and
> window scaling, both of which have been universally deployed for some
> time now.
>
> Header timestamps solves the problem I addressed my round trip timing
> algorithm in the late 1980s. I chose to do it without changing TCP, but
> given that the protocol could be changed, timestamps was a much better
> solution.
>
> Window scaling got around TCP's original 64KB window limit, meaning that
> it couldn't send more than 64 kilobytes per round trip time. This
> rapidly became a problem on terrestrial fiber, not just geostationary
> satellites. The SYN (synchronize, or connection setup) packets convey a
> "scale" parameter that is the base-2 log of the value to be multiplied
> by all subsequent window advertisements in the session. E.g., if the
> window scale parameter is 5, then all window announcements should be
> left-shifted by 5 bits.
>
> This completely solves the problem for bulk transfers over long delay
> channels **provided** that the packet loss rate is kept small. TCP still
> has problems when packets are lost more often than roughly once per
> round trip time. There are additional enhancements (selective ACKs) to
> handle this problem, but it is still best to design the subnet for a
> much lower packet loss rate. How you do this is left up to the subnet
> designer. See RFC 3819, Advice for Internet Subnetwork Designers.
>
> Phil
>
>
> _______________________________________________
> Ground-Station mailing list
> Ground-Station at lists.openresearch.institute
> http://lists.openresearch.institute/mailman/listinfo/ground-station
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190226/c21c05b8/attachment.html>