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

[Michelle Thompson]

Ok, that's what this book describes happening. You have summarized it in
better language. I'll forward your contact information to Now Publishing.
:+)

At some level, I'm grumpy about middleboxes and things like PEP cluttering
up the joint, but the improvement is obvious.

This book says that MPTCP and network coding will "probably" replace the
PEPs, but I dunno - it seems like gateways are a recurring and permanent
part of an increasingly complex landscape.

-Michelle W5NYV




On Tue, Feb 26, 2019 at 2:33 PM Howie DeFelice <howied231 at hotmail.com>
wrote:

> Yes. You terminate the TCP connection locally into a proxy server that
> "spoofs" the connection into thinking the packet has been accepted and it
> should send the next one. In reality the proxy has coordinated with the
> distant end and is transferring the data using a more delay tolerant
> protocol. If the PEP function is not included in the modem or you're trying
> to use modems that don't implement PEP the same way, you can do it in
> external hardware or create the PEP in software on the communicating
> devices. The first time I ran into this many years ago I had a 45 Mbps
> satellite link but could not get the FTP session to move any faster than
> 120 Kbps.  I've learned a little about how all this network stuff works
> since then 🙂
>
> Howie AB2S
> ------------------------------
> *From:* Michelle Thompson <mountain.michelle at gmail.com>
> *Sent:* Tuesday, February 26, 2019 1:50 PM
> *To:* Howie DeFelice
> *Cc:* Phil Karn; Michelle Thompson via Ground-Station
> *Subject:* Re: [Ground-station] MPTCP, network coding, ICN, and
> satellites!
>
> 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://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openresearch.institute%2Fmailman%2Flistinfo%2Fground-station&data=02%7C01%7C%7C9ef0f3e40de549e98a5408d69c1b6c4b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636868038919582030&sdata=jetjFSMuPUe%2Fr6%2B%2Bb88vFclYNy9CYUXOgbftTxW8Qlk%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190226/c876bad9/attachment.html>