If we have a some Mbps connection between source and destination and known latency and the source has two processes sending data via TCP and UDP respectively, which of two process will have a higher throughput and how to calculate it?
I am not a computer science student and I don't know networks.
TCP and UDP are both using the IP layer and will both have the same network available to them. Depending on the protocol you use you could get more throughput via UDP. This would require you to write a protocol to transfer data that was more aggressive than TCP or discard data without having to resend it.
If you did write a protocol more aggressive than TCP it would likely be banned by anyone managing a network that came into contact with it since it will degrade TCP sessions on that network.
If you could discard any data that came through then you wouldn't waste the bandwidth resending the lost packets in TCP and UDP would be a more natural choice but since you care about bandwidth I'm guessing that thats not the case?
Related
I have a real-time application (C++ using websockets) that has to communicate through a congested LAN. Because it's realtime, delays can't be tolerated. Will UDP perform better than TCP in this case?
I cannot tolerate packet loss, but can address it through retries if using UDP.
In a congested network UDP will send its packets faster than TCP. This is because TCP actively tries to avoid overloading the network using a mechanism called congestion control. UDP has no such mechanism; its send speed is limited only by the resources of the sender.
If your first priority is to just send the packets, then UDP is the way to go. However, your probably also want them to arrive at the other end, which is a separate problem.
Sending UDP packets into a congested network at a high rate will only cause it to become more congested, leading to long delays and packet loss.
The problem here is neither TCP nor UDP - but the congested network. If the road is congested, it doesn't matter whether you're driving a car or a bus, you'll be late either way.
So, it doesn't matter all that much which protocol you choose. To send something quickly over a congested network you need a solution at the network level, possibly some QoS mechanism to prioritize some packets over others. QoS can give you the network equivalent of bus lanes that allow buses to quickly pass congested roads at the expense of other traffic.
Let's assume TCP Reno version
I have this situation: a VoIP (UDP) stream and a TCP session on the same host.
Let's say at t=10s the TCP opens the session with the TCP receiver (another host), they exchanges the max window during the 3-way handshake and then they start the stream with the slow start approach.
At t=25s, a VoIP stream starts. Since it's an UDP stream, the aim is to saturate the receiver. Not having any congestion control, it should be bursting packets as much as it can.
Since there is this concurrency in the same channel and we are assuming that in the topology of the network no router goes down etc (so no anomalies), my question is:
Is there any way for achieve packet loss for the VoIP stream?
I was thinking that since VoIP is sensible to jitter, and the slow-start approach of TCP is not really slow, the packet loss could be achieved because the routers queues add variation of delay and they are "flooded" by the TCP early packets.
Is there any other reason?
A couple of comments first:
VoIP will not usually 'saturate' the receiver (or the network) - it will simply send as many packets as it needs for the particular codec you are using. In other words it won't just keep growing until it fills the network.
VoIP systems are sensitive to jitter as you note. Packet loss is actually related to this as a VoIP system will generally consider a packet lost if it arrives outside the jitter buffer window. So even though the packet may not in fact be lost, and only delayed, if it arrives outside the jitter buffer window it is effectively lost as far as the VoIP system is concerned.
Answering your specific question: yes other traffic can create delayed packets which may appear lost to the VoIP receiver. It is worth nothing that in a link where UDP and TCP are sharing the bandwidth, TCP is better 'behaved' than UDP in that it will try to limit itself to avoid congestion. UDP does not and hence may actually get more than its fair share of the bandwidth compared to the TCP traffic because of this.
i have a question about the trasport layer of the iso/osi network stack.
It's common to think that TCP is reliable but slow and UDP is fast but not reliable.
In several network applications, it is mandatory to implement an application-level ACK system also with TCP transport protocol in order to manage link interruptions and so on.
Assuming that the application scenario is this: local (small) network, typical small packet size (max 512 bytes), application-level ack system implementation. Why not use the protocol UDP as transport protocol in order to exploit its features such as speed, low latency and broadcast communication?
Thanks to all.
If you don't care about the Delivery (failure or successful delivery) of your message than UDP will be always a best choice.. But if you want to be sure whether the message is delivered or failed than think about other protocols rather than UDP.
In a small LAN it shouldnt be a big problem to use UDP, when the transferd Data isnt too "important" (which means if a packet is lost its no problem). More informations about the scenario are nessesary, if you use UDP you have to implement functions that check if you received all the information of the sender manually.
if you need the speed and if some lost packets are no problem (Voice Chat for instance) then use UDP.
TCP has a greater computation overhead to ensure reliable delivery of packets. But, since modern networks are fast, is there any scenario in which performance of UDP outweighs the reliability of TCP?
Is there any other particular advantage of UDP over TCP?
I can see two cases, where UDP would have an upper hand over TCP.
First, one of the attractive features of UDP is that since it does not need to retransmit lost packets nor does it do any connection setup, sending data incurs less delay. This lower delay makes UDP an appealing choice for delay-sensitive applications like audio and video.
Second, multicast applications are built on top of UDP since they have to do point to multipoint. Using TCP for multicast applications would be hard since now the sender would have to keep track of retransmissions/sending rate for multiple receivers.
It depends on your usage. If your application is time sensitive, like Voice over IP, then you don't care about missing packets. What you care about is the delay in that case.
You should have a look at this answer: What are examples of TCP and UDP in real life?
You could also look at the Wikipedia related section: http://en.wikipedia.org/wiki/User_Datagram_Protocol#Comparison_of_UDP_and_TCP
Applications that require constant data flow, bulk data and which require fastness than reliability uses UDP over TCP.
udp provides better application level control over what data is sent....since the data is packaged in a udp segment and immediately passed over to the network layer......hence no-frills segment delivery service is observed.
There is no need for connection establishment hence no delay(unlike tcp...which requires handshaking before the actual data transfer)
There is no need to maintain connection state in the end systems(ie no need for send and receive buffers,congestion control parameters and sequence and acknowledgement number parameters)..hence more active clients could be supported
Small packet header overhead for udp(only 8 bytes) where as tcp has 20 bytes of header
Facebook uses UDP connections instead of TCP/IP to connect to theirs Memcached Servers
There are couple of differences of UDP over TCP.
First, TCP is connection-based whereas UDP is connectionless.
Connection-based: Make sure that all messages will arrive and arrive in the correct order.
Connectionless: It does not guarantee order or completeness.
Second, Here is why UDP is faster over TCP:
UDP does not require ACK message back
UDP has no flow control
No duplication verification at the receiving end
Shorter header
I was told that for a High Frequency Trading (HFT) system that requires low-latency, TCP is used over UDP. I was told that with TCP you can make point to point connections, whereas you cannot with UDP, however from my understanding you can send UDP packets to specific IP/port.
There are several arguments used in this article as to why UDP > TCP for gaming but I can see relevance for HFT.
Why would TCP be a better protocol to use for HFT?
(Admins: My previous post of this question was silently removed with no explanation. If I am violating terms of use please alert me of this instead of silently removing the question)
UDP is superior to TCP if you don't need some of the features TCP provides. Every feature has a cost, and so if you don't need features, you are paying that cost for no reason.
In an HFT application, you need pretty much every feature TCP requires. So if you picked UDP, you'd have to implement those features yourself. That means you'd have to implement connection establishment, connection teardown, retransmissions, transmit pacing, windows, and so on.
If there was a way to do all those things that was better than the way TCP was doing it, TCP would be doing it that way. You'd have one hand tied behind your back because TCP is heavily optimized by some of the best minds on the planet and implemented in/with the kernel.
There's no reasons to expect a stream of data over an already-established TCP connection would be slower than the same data over UDP, plus you get checksumming, retries, and all the other TCP goodness. UDP mainly wins in cases where you can afford to discard the reliability or where the overhead of many TCP handshakes would be too expensive, such as with common DNS queries.
TCP is faster for when using a few connections, the important difference is that modern NICs perform significant amounts of acceleration on TCP and not really that much for UDP. This means there is more overhead to process each UDP packet and as such they cannot compete unless you need to send to multiple recipients simultaneously.
However the UDP multicast route still suffers the same problems as unicast UDP per datagram overheads. Therefore many HFT systems use hardware accelerated systems that can multiplex the streams across many NICs via TCP, example Solace.
These days though you want to completely bypass the kernel with say a userspace IP stack such as by Solarflare or Mellanox, or even skip both the kernel and IP stack with RDMA.
Quite simply, if you need connection reliability (ensuring that every byte of data transmitted is received), you should be using TCP regardless.
As you mentioned, UDP is more suitable for games, where 100% accurate real-time tracking of every object would use quite a large amount of bandwidth and is unnecessary (this is where slow connections encounter lag).
There is no special difference between a TCP port and a UDP port, beyond the type of connection being used (send the packet and forget it, UDP style, or negotiate a connection and sustain it, TCP style) and the service listening on the server side. e.g. TCP/25 would usually reveal a SMTP server, whereas UDP/25 would not.
Basically, modern TCP implementations are going to be just as fast as UDP, if you're keeping the connection alive. If TCP is having to resend a packet, you'd need to resend it in UDP too. Plus for UDP you're going to end up implementing the same reliability code (retransmission of dropped packets) that TCP has already implemented.