Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

With the # in parens being success rate, the timing makes little sense to me.

A TCP connection with 10% loss will work and transfer (it's gonna suck) and be very very very slow but their TCP 10% loss example is faster somehow?

TCP being reliable will just get slower with loss until it eventually can't transmit any successful packets within some TCP timeout (or some application-level timeout).

Even a 50% packet loss connection will work, within some definitions of the word "work" and also this brings up the biggest missing point in that chart: this all depends heavily on latency.

50% loss on a connection with 1ms latency is much more tolerable than 1% loss on a connection with 1000ms latency and will transfer faster (caveats around algorithms and other things apply, but this is directionally correct).

A real chart for this would be a graph where X is the % of packet loss and Y is the latency amount with distinct lines per protocol (really one line per defined protocol configuration, eg tcp cubic w/nagle vs without and with/without some device doing RED in the middle or different RED configurations, etc, many parameters to test here).

If this sounds negative, it's not, I think the research around effective high-latency protocols is very interesting and important. I was thinking recently (probably due to all the SpaceX news) about what the internet will look like for people on the moon or on mars. The current internet will just not work for them at all. We will require very creative solutions to make a useful open internet connections which isn't locked down to Apple/Facebook/Google/X/Netflix/etc.



A big problem with TCP's loss avoidance is that it assumes the cause of loss is congestion, so if you use it on a network with random packet loss it can just get slower and slower and slower until it effectively stops working entirely.


Agreed that it's a problem but probably not a huge one today on the internet since most loss is actually a result of congestion.

It has led to some weird things whereby the L2 protocols (thinking wifi and LTE/cellular) have their own reliability layer to combat the problem you're describing. I'm not sure if things would be better or worse if they didn't do this and TCP was responsible, the iteration of solutions for it would be much slower and probably could never be as good as the current situation where the network presents a less-lossy layer to TCP.

We have to completely rethink things for interplanetary networking.

I thought I recognized your username, I remember jailbreaking the original iPhone on IRC with you helping :)


> I thought I recognized your username, I remember jailbreaking the original iPhone on IRC with you helping :)

Yep, same author of Cydia [1].

[1] https://en.wikipedia.org/wiki/Cydia


Sure, but this is a simulator with random packet loss that has nothing to do with congestion, isn't it?


That's what TCP-SACK (Westwood variant) and SCPS-TP are for, to deal with packet loss due to bit corruption as well as congestion.

https://egbert.net/images/tcp-evolution.png

https://en.m.wikipedia.org/wiki/Space_Communications_Protoco....


Similarly, I wonder if nyxpsi has congestion control? It's probably tricky to implement if you are trying work with a crap network. I guess you could see how packet loss or latency responds to throughput, but then you need to change the throughput periodically while transmitting, which slows down the transfer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: