Best protocol for high bandwidth high latency situation?

[Ipno]

Trying to transfer large files over a high bandwidth high latency situation. Think satellite. I control both ends and both server and client are unix. I've been trying various things to see what protocol is the best for this kind of operation?

Latency is around 700-800ms.

 

[Jeff7181]

Interesting question. I don't have a clue but being a networking student, I'm interested to hear what some possible solutions would be.

 

[spidey07]

This is a funtion of TCP, not an application layer protocol

Just use FTP and use a very large TCP window (provided you have very little packet loss)

 

[Jeff7181]

What would be considered a "very large" TCP window?

 

[n0cmonkey]

AFS?

 

[Nothinman]

UUCP? =)

Just make sure your FTP server and client resume automatically and you should be fine.

 

[Jeff7181]

Hmmm... am I misunderstanding, or are others misunderstanding? When you say protocol I think layer 3... as in... you're looking for an alternative to TCP/IP that would be better suited to a high bandwidth and high latency connection.

 

[spidey07]

Originally posted by: Jeff7181
Hmmm... am I misunderstanding, or are others misunderstanding? When you say protocol I think layer 3... as in... you're looking for an alternative to TCP/IP that would be better suited to a high bandwidth and high latency connection.

Each layer has it's own protocol.

Part of TCP (a layer 4 protocol) is taking into consideration delay, loss and other factors to ensure reliable connecion oriented transport layer. From there layers 5-7 can do whatever they want.

When I said large TCP window - the biggest one you can use without decreasing performance. Window size will adjust depending on conditions (loss, delay, etc). But you want to tell it to try and use the largest it can on high bandwidth/high delay networks.

 

[MrEgo]

Ever since I've started reading this forum, I've come to realize that spidey is the man when it comes to networking.

With that being said, what does the TCP window do exactly? A few years ago, before I got DSL, I was getting insanely horrible latency when I subscribed to AT&T broadband cable, and the tech support guy recommended that I increase my TCP window. It didn't seem to help, but why would he recommend that?

 

[spidey07]

Originally posted by: MrEgo
Ever since I've started reading this forum, I've come to realize that spidey is the man when it comes to networking.

With that being said, what does the TCP window do exactly? A few years ago, before I got DSL, I was getting insanely horrible latency when I subscribed to AT&T broadband cable, and the tech support guy recommended that I increase my TCP window. It didn't seem to help, but why would he recommend that?

There's tons of good resources on dslreports.com (I think that's the name of the site, don't really go there).

To really understand what is going on takes a whiteboard and a lot of math. To put it simply:

TCP window size is the amout of data that can be sent from the TCP sender to the Receiver before an acknoldgement must be sent from the receiver.

1) Hi server, I want some stuffs
2) Hello client, I want to give you some stuffs, I've got a whole warehouse full of containers ready for shipment, I can send 800 thousand bytes of stuff (window size) but they'll be in smaller 1500 byte containers without you giving me a phone call that says you missed a shipment or that container somehow got lost. Once I've sent the full 800 thousand bytes of stuff, I expect a phone call to confirm you got it all.
3) Cool, I can receive 800 thousand bytes of stuff and I agree on the container size (max segment size)

This is all that is needed for the TCP 3-way handshake. 3 packets. Bing, Bang, Boom.

The complicated part is what TCP does based on statistics from the shipment of these containers - that's where the math comes in.

What does this have to do with latency? Let's say you talk to server and say you can only handle 8 thousand bytes at a time before you have to phone him? So in the original scenario you have to pick up the phone, call the server, say "hey, I got your measely 8 thousand bytes, keep it coming and why in the world am I calling you when your delivery is just fine? Just gimme more and I'll let you know when I've had enough. This whole acknoldgement thing is getting out of hand and causing us to not more data efficently. It's wasting time. Throughput is data/time."

 

[Jeff7181]

Originally posted by: spidey07

Originally posted by: Jeff7181
Hmmm... am I misunderstanding, or are others misunderstanding? When you say protocol I think layer 3... as in... you're looking for an alternative to TCP/IP that would be better suited to a high bandwidth and high latency connection.

Each layer has it's own protocol.

Part of TCP (a layer 4 protocol) is taking into consideration delay, loss and other factors to ensure reliable connecion oriented transport layer. From there layers 5-7 can do whatever they want.

When I said large TCP window - the biggest one you can use without decreasing performance. Window size will adjust depending on conditions (loss, delay, etc). But you want to tell it to try and use the largest it can on high bandwidth/high delay networks.

So it has to be something in the Transport layer? Or is that just the most logical layer to address the issue? (assuming of course he can't do anything about the medium being high latency)

 

[V00D00]

You could use TFTP. If it's a reliable connection, or if it has lower layer error checking you will cut out some overhead with UDP / TFTP.

Also along with window size frame size can be increased. That depends on your link equipment though. For instance you need a special nic & switch to use jumbo frames (9000 byte packets instead of 1500). That greatly increases total throughput.

What hardware are you going to be working with? Are you looking for applications to do this or just protocol ideas? Are you programming for the nix api or some special hardware?

 

[spidey07]

Originally posted by: V00D00
You could use TFTP. If it's a reliable connection, or if it has lower layer error checking you will cut out some overhead with UDP / TFTP.

Also along with window size frame size can be increased. That depends on your link equipment though. For instance you need a special nic & switch to use jumbo frames (9000 byte packets instead of 1500). That greatly increases total throughput.

What hardware are you going to be working with? Are you looking for applications to do this or just protocol ideas? Are you programming for the nix api or some special hardware?

You're f'in kidding me? Right?

 

[Jeff7181]

Since UDP doesn't verify reciept, wouldn't that be very poor choice? As you go up in the OSI layers, isn't more processing required? So why rely on software in the application layer to do ECC when you can take care of it at a lower level with less overhead?

(I'm not criticizing your answer, I want to learn. If there's a reason it makes sense to use UDP and let ECC happen at the application layer, I want to know what it is.)

 

[Ipno]

Yes, thanks about TCP window size information, and I'm wondering however if the process can be futher (albeit slightly) improved if there was any way to say, send packets now, validate them later within the TCP framework, as in the way zmodem did in the days of old. Or does TCP do this already? In my experiments with ethereal watching traffic from such things as ftp, scp, nfs, samba and yes, even afs, it doesn't appear to, but I may be missing something.

 

[Ipno]

In my search, I have found an interesting site discussing TCP congestion control algorithms.

link

 

[robmurphy]

Does anyone have experience of changing the window size for XP SP2. The commands on the net for XP/win2k do not appear to make any difference. I think the keys and values needed for XP changed with SP2. I did not find anything on Microsoft's site, it may well be there I just could not find it. There is also RFC 1323, and that is supposed to be implemented in XP, but again the details as how to turn it on for SP2 is not clear.