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

[Howie DeFelice]

It seems the real problem is that the default TCP window size is too small for high latency links and it's not always easy to change it except when running a Linux OS. That may not be completely accurate but I'm sure Phil can correct me without even having to think about it 🙂


  *   Howie AB2S

________________________________
From: Michelle Thompson <mountain.michelle at gmail.com>
Sent: Tuesday, February 26, 2019 5:37 PM
To: Howie DeFelice
Cc: Phil Karn; Michelle Thompson via Ground-Station
Subject: Re: [Ground-station] MPTCP, network coding, ICN, and satellites!

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<mailto: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<mailto: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<mailto: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%7C15c6e742a28b4b50d49508d69c3b22da%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636868175129380955&sdata=oWcvu90vulaEz1ioifCG%2BoB5MQhtDQVTryZP%2BVFkQZw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190226/5b010b15/attachment.html>