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

[Michelle Thompson]

This is the PEPs, right? They get a lot of attention in this book.

-Michelle W5NYV




On Tue, Feb 26, 2019 at 10:25 AM Howie DeFelice <howied231 at hotmail.com>
wrote:

> HTS satellites, at least the ones operated by Intelsat, are not any
> different than wide beam satellites in terms of TCP performance due to
> delay. Most all modern satellite modems use an Ethernet interface and have
> some form of TCP acceleration integrated into the  modem to mitigate the
> TCP window issue due to transit delay. As Phil stated, BER performance has
> a significant effect on throughput performance. The higher performance of
> the smaller spot beams on HTS satellites coupled with improved FEC makes
> obtaining good BER much easier than it was even just 10 years ago.
>
> Howie AB2S
> ------------------------------
> *From:* Ground-Station
> <ground-station-bounces at lists.openresearch.institute> on behalf of
> Michelle Thompson via Ground-Station
> <ground-station at lists.openresearch.institute>
> *Sent:* Tuesday, February 26, 2019 8:01 AM
> *To:* Phil Karn
> *Cc:* Michelle Thompson via Ground-Station
> *Subject:* Re: [Ground-station] MPTCP, network coding, ICN, and
> satellites!
>
> 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
> <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openresearch.institute%2Fmailman%2Flistinfo%2Fground-station&data=02%7C01%7C%7C75ee541f99d24b5fb90008d69bf020a5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636867852969923802&sdata=Q1Fr6ko8yCtUbHak1VsBlgA5tAfRFusMQrg%2FPEm437E%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190226/5dc5efaa/attachment.html>