I was going through following link. Why is SNMP usually run over UDP and not TCP/IP? I don't understand that why UDP perform well compare to TCP in lossy network? Can someone please clarify?
3 Answers
UDP does not behave well in a lossy network by itself. UDP is simply used for a different kind of applications:
- If a small loss of data is not the main problem you can use UDP. That's why UDP is used for real time audio where latency is bad but a small loss of data can be worked around. It is used for things like syslog or SNMP where you can risk to loose a few data.
- If you instead need a reliable data transport, i.e. no loss of data then TCP is better because it acknowledges all the received data and will retransmit lost packets. Thus TCP is used for the Web, for mail transport etc.
Apart from that neither TCP nor UDP are designed for networks with a high packet loss. They both expect a small packet loss because of congestion etc and expect the underlying layers (i.e. ethernet, WLAN..) take care of major delivery problems.

- 114,247
- 10
- 131
- 172
-
ok... I got it...but I was just wondering that why one packet loss in SNMP dont matter much , is it because of timer? I mean suppose a network element went down , and it reported a alarm , now there is just single packet which contain information that NE is down, but that packet is lost , so may be because of some timer implementation , NE will report it status after 5 minute , that time we can hope packet reach to snmp manager, is this may be reason we are ok with some packet loss in SNMP? – pankaj kushwaha Aug 06 '15 at 08:01
-
If you have lots of loss in your network the chances are higher that some UDP packets make it through and some will be lossed that you get a full TCP transfer without packet loss working within in acceptable time. So UDP might be the way in this case because the impact of problems is smaller. Same with syslog (which can also run over TCP but is mostly used with UDP). – Steffen Ullrich Aug 06 '15 at 08:23
-
As you can see in Wes Hardaker's answer to http://stackoverflow.com/questions/3565975/why-is-snmp-usually-run-over-udp-and-not-tcp-ip, delivery of a `trap` is not guaranteed, so if you need guaranteed delivery over UDP you should configure your agent to send `inform` messages instead. – Jolta Aug 06 '15 at 11:00
First of all, since this question is about networks and not programming, It doesn't belong here - anyhow;
TCP is a slower, more reliable protocol than UDP is. In comparison, UDP is much faster and efficient. For example, TCP has much more flags (window-length, syn, ack, etc) - And also starts and ends a connection in a very stable way - the Three way handshake - while all UDP has is Source IP, dest IP, length, Source port, dest port, and checksum.
In order to send all those extra packets to start and end a connection, and the verficiation process for each single packet takes time - while UDP is a stream of data, which doesn't mind the loss of a few bytes here and there, TCP is a reliable protocol - which in turn takes longer and is less efficient.
That's a very general explanation - I highly suggest you read more.

- 1,823
- 17
- 45
-
1
-
1@user2864740 I'm speaking about TCP being connection oriented, and UDP being just a raw stream of data (no syn, ack, fin, etc. - the least which is required to establish a server-client network.) – A. Abramov Aug 06 '15 at 07:32
TCP: At the lower levels of the protocol stack, due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets may be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. If the data still remains undelivered, its source is notified of this failure. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the receiving application. Thus, TCP abstracts the application's communication from the underlying networking details. TCP is optimized for accurate delivery rather than timely delivery, and therefore, TCP sometimes incurs relatively long delays (on the order of seconds) while waiting for out-of-order messages or retransmissions of lost messages. It is not particularly suitable for real-time applications such as Voice over IP. For such applications, protocols like the Real-time Transport Protocol (RTP) running over the User Datagram Protocol (UDP) are usually recommended instead. (source wikipedia)
SNMP does real time monitoring hence over UDP.
For an explaination more in context http://confessionsofalinuxpenguin.blogspot.in/2012/11/udp-or-tcp-for-lossy-networks.html
for snmp data details. some graphs about tcp vs udp in a lossy network http://www.ietf.org/proceedings/72/slides/opsarea-2.pdf

- 3,460
- 11
- 27
-
2Provide relevant in-answer information. Links are good, but should only be references to support the answer. – user2864740 Aug 06 '15 at 07:52
-
@keutoi: links are really good , and contain information relevant to question, thanks...Glorfindel is right , link can go down any time , so your answer may become irrelevant in future, – pankaj kushwaha Aug 06 '15 at 08:03
-
_[Your answer is in another castle: when is an answer not an answer?](http://meta.stackexchange.com/questions/225370/your-answer-is-in-another-castle-when-is-an-answer-not-an-answer)_. Consider editing your answer to contain a summary of the article pointed to by the link. – Aug 06 '15 at 08:23
-
@all Thank You for your feedback. Most of the above edited answer is not my own. so i thought to just provide with relevant links rather than copy someone's work. You are right some times links may be down or spam, it is good to include essential parts of the answer. – rajashekar Aug 06 '15 at 08:48
-