I'm taking a course on networking right now and trying to understand where the three protocols are used. I understand that they are efforts to make the unreliable link layer (IP) reliable.
Are they actually implemented anywhere? Does TCP implement any of them? And for that matter, are there any other protocols that operate on the transport layer other than TCP and UDP?
I'm using the book Computer Networking by Kurose & Ross.
Any help is greatly appreciated!
"where the three protocols are used. I understand that they are efforts to make the unreliable link layer (IP) reliable."
First, do not get RDT confused with GBN and SR because GBN and SR are RDT protocols. When we talk about RDT, it's like we are talking in general.. RDT specifies the requirements of a reliable data transfer protocol, the requirements are retransmission, error detection, and acknowledgments. As long as any protocol (maybe one that you make and get approved IETF :) ) satisfies those requirements can be considered a rdt protocol. Good examples of rdt are SW (stop and wait), GBN, and SR.
That answers first question, except I cant help myself to mention the error you at the end of the question, not the "link layer" I'm sure you meant the network layer.
"Are they actually implemented anywhere? Does TCP implement any of them? "
Again, for a protocol to be reliable, it doesn't have to be considered GBN or SR as long as it satisfies rdt principles. For instance, we wouldn't call TCP a GBN protocol or SR protocol but rather its own.. however it does share some with both, such as cumulative acks (though in a slightly different way, as it doesn't have an ack timer as GBN) and it keeps out of order packets in its buffer to eventually reorder them (same as SR while SR uses independent acks).
"And for that matter, are there any other protocols that operate on the transport layer other than TCP and UDP?"
Sure, you can even make your own as I mentioned before and consult with IETF ;) but TCP and UDP are the most prevalent and widely used protocols.
Hope that clarifies it.
Yes, TCP implements all of them, although "selective repeat" is an option (RFC 2018).
Your second question is a little harder to answer because it always devolves into a semantic argument. There are other protocols (OSPF and EIGRP to name two) that ride on top of IP and have their own transport functions built in. But they don't fit neatly into the OSI model, so you can call them either transport or application layer protocols depending on your point of view.
Related
I am new to networking and I have a doubt on what would happen if we interchange the use of security protocols with their respective transport layer protocols.
Will there be any kind of affect on the delivery performance?
And How is one security protocol different and optimised for specific transport protocol it is designed to be used for?
If you read DTLS - RFC 6347, you will read, that it contains a lot of counter measures for UDP usage. It also explains, why using TLS (with its inherent assumption) will not work for UDP.
If DTLS over TCP would makes sense, depends mostly from your expectations. So why would you like to do that?
What purpose is UDP for..if it delivers packets without any order (and given the fact that packets may get lost on the way or sent to other network).
UDP as many very usefull use cases.
Just a few off the top of my head:
1/ Your payloads are small (will hold in a single "packet") and you want to go fast. That's why DNS uses UDP when the data size does exceeds 512 bytes (99% of the cases?):
https://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
And you do hundreds of DNS requests every day. How many TCP 3-way handshakes and connection tear-down saved by this? How may petabytes or network load saved on "the internet"? I'd say that's quite useful!
2/ You do not know who you are talking too, or even if someone is listening or wishing to reply. In other words, you cannot or do not want for sure to establish an actual connection, like TCP would do. There may not be a TCP service listening for you. For example, the SSDP protocol from UPnP uses UDP to discover devices/services:
https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
With UDP tough, you can send your data "in the wild" even if nobody is listening to you. Which leads me to point 3...
3/ You want to talk to multiple hosts, or even "everyone". That's multicasting and broadcasting, and it's very easy to do in UDP. The SSDP mentioned above is an example of such case. On the other hand, if you want to do multicast or broadcast on TCP, that becomes very tricky from the start. You'll have to subscribe to multicast group and blablabla. A multicast daemon may help (ex: https://github.com/troglobit/smcroute), but it's really way more difficult in TCP than with UDP.
4/ Your data is realtime, if the target is missing it there's no point for it to ask for a "please send it again, I did not get it and/or not in the correct order". That's too late, sorry. The receiver better forget it, go on and try to catch-up. A typical use case here can be live audio/video (telephony conversations, real time video streaming). There's no point for the receiver to try to get old, expired data again and again in case of TCP missed segment(s). You can only accumulate network data debt doing this. Better forget it and move on to the new, real-time data that keep coming in. You cannot "pause" real-time incoming data. If you want actual real-time, not pseudo real-time like you get in your web browser.
And I'm sure other posters will find many use-cases for UDP.
So UDP is very, VERY useful. You use it daily without noticing it. The networking world would be a pitiful place without it. You would really miss it. The "TCP/IP" should really be renamed "TCP-UDP/IP".
This was my advocacy for the unfairly despised but Oh-so-useful UDP. :-)
Typically, use UDP in applications where speed is more critical than reliability. For example, it may be better to use UDP in an application sending data from a fast acquisition where it is acceptable to lose some data points. You can also use UDP to broadcast/multicast to any/many machine(s) listening to the server.
Applications may want finer control over the performance characteristics or the reliability of their communications. For this, the operating system exposes IP’s “best-effort datagrams” to the application for it to do whatever it wants with them.
To do this, the OS provides UDP — the “user” datagram protocol. It’s just like IP, in that the service is best-effort datagrams, but instead of delivering those datagrams “to a computer,” there’s an added layer of addressing that says which application is interested in them (and like TCP, UDP does this with a port number).
Applications can run whatever they want on top of UDP — anything that runs on best-effort datagrams. There are lots of protocols you can run on top of that abstraction.
In general:
TCP is for high-reliability data transmissions
UDP is for low-overhead transmissions
I would like to understand what happens when we type "google.com" in our browser wrt OSI model. What all protocols comes into picture AT EACH LAYER any how does they know which one to be used?
Also I would like to know, TCP/UDP which one to be used in Transport layer is decided for network/application? That is for a normal web page like google.com TCP must be used but for video streaming UDP. how is this conveyed to network?
Is the browser also part of this as it is helping. Should it also come under application layer?
Http comes under Application layer of OSI model. now for this particular example, what will come under Presentation and Session layers? Will the sessions be maintained in session layer or HTTP will be doing it on their behalf?
It sounds like you would like a tutorial on TCP/IP. May I suggest a couple of good books
URLs in webpages have a prefix that tells the applications what to do with that link. For instance, ftp:// opens an ftp session, which uses tcp (ref RFC 959 - File Transfer Protocol). As a general rule, the URL prefixes correspond to a standardized protocol, which was specified via RFC. The RFC denotes which transport protocol is used.
EDIT
In the case of youtube, their videos have a http:// URL prefix, but after you make the request, it is redirected to a rtsp:// URL. RTSP can be streamed over UDP.
To answer questions like this, you may find that wireshark is very useful to investigate these things... keep in mind that wireshark works best on wired connections.
Applications don't use any layer of the OSI protocol stack. They use TCP or UDP from the TCP/IP stack, and they 'know which' because of they are programmed to use one or the other or both. The OSI model is obsolete and certainly doesn't apply to TCP/IP.
EDIT: The OSI layer model is a Procrustean bed into which TCP/IP does not fit. You should forget about OSI immediately. It doesn't describe anything in the real world.
Some games today use a network system that transmits messages over UDP, and ensures that the messages are reliable and ordered.
For example, RakNet is a popular game network engine. It uses only UDP for its connections, and has a whole system to ensure that packets can be reliable and ordered if you so choose.
My basic question is, what's up with that? Isn't TCP the same thing as ordered, reliable UDP? What makes it so much slower that people have to basically reinvent the wheel?
General/Specialisation
TCP is a general purpose reliable system
UDP +whatever is a special purpose reliable system.
Specialized things are usually better than general purpose things for the thing they are specialized.
Stream / Message
TCP is stream-based
UDP is message-based
Sending discrete gaming information maps usually better to a message-based paradigm. Sending it through a stream is possible but horribly ineffective. If you want to reliably send a huge amount of data (File transfer), TCP is quite effective. That's why Bit-torrent use UDP for control messages and TCP for data sending.
We switched from reliable to unreliable in "league of legends" about a year ago because of several advantages which have since proven to be true:
1) Old information becomes irrelevant. If I send a health packet and it doesn't arrive... I don't want to have to wait for that same health packet to resend when I know its changed.
2) Order is sometimes not necessary. If I'm sending different messages to different systems it may not be necessary to get those messages in order. I don't force the client to wait for in-order messages.
3) Unreliable doesn't get backed up with messages... ie waiting for acknowledgements which means you can resolve loss spikes much more quickly.
4) You can control resends when necessarily more efficiently. Such as repacking something that didn't send into another packet. (TCP does repack but you can do it more efficiently with knowledge about how your program works.)
5) Flow control of message such as throwing away messages that are less relevant when the network suddenly spikes. The network system can choose not to resend less relevant messages when you have a loss spike. With TCP you'd still have a queue of messages that are trying to resend which may be lower priority.
6) Smaller header packet... don't really need to say much about that.
There's much more of a difference between UDP and TCP than just reliability and sequencing:
At the heart of the matter is the fact that UDP is connectionless while TCP is connected. This simple difference leads to a host of other differences that I'm not going to be able to reasonbly summarize here. You can read the analysis below for much more detail.
TCP - UDP Comparative Analysis
The answer in in my opinion the two words: "Congestion control".
TCP goes to great lengths to manage the bandwidth of the path - to use the most of it, but to ensure that there is space for other applications. This is a very hard task, and inherently it is not possible to use 100% of the bandwidth 100% of the time.
With UDP, on the other hand, one can make their own protocol to send the packets onto the wire as fast as they want - this makes the protocol very unfriendly to other applications, but can gain more "performance" short-term. On the other hand, it is with high probability that if the conditions are appropriate, this kind of protocols might contribute to congestion collapse.
TCP is a stream-oriented protocol, whereas UDP is a message-oriented protocol. Hence TCP does more than just reliability and ordering. See this post for more details. Basically, the RakNet developers added the reliability and ordering while still keeping it as a message-oriented protocol, and so the result was more lightweight than TCP (which has to do more).
This little article is old, but it's still pretty true when it comes to games. It explains the two protocols, and the havoc these folks went trying to develop a multiplayer internet game. "X-Wing vs Tie Fighter"
Lessons Learned (The Internet Sucks)
There is one caveat to this though, I run/develop a multiplayer game, and I've used both. UDP was much better for my app, but alot of people couldn't play with UDP. Routers and such blocked the connections. So I changed to the "reliable" TCP. Well... Reliable? I don't think so. You send a packet, no errors, you send another and it crashes (exception) in the middle of the packet. Now which packets made it? So you end up writing a reliable protocol ON TOP OF tcp, to simulate UDP - but continuously establish a new connection when it crashes. Take about inefficient.
UDP + Stop and wait ARW = good
UDP + Sliding Window Protocol = better
TCP + Sliding Window Protocol with reconnection? = Worthless bulkware. (IMHO)
The other side effect is multi-threaded applications. TCP works well for a chat room type thing, since each room can be it's own thread. A room can hold 60-100 people and it runs fine, as the Room thread contains the Sockets for each participant.
UDP on the other hand is best served (IMO) by one thread, but when you get the packet, you have to parse it to figure out who it came from (via info sent or RemoteEndPoint), then pass that data to the chatroom thread in a threadsafe manner.
Actually, you have to do the same with TCP, but only on connect.
Last point. Remember that TCP will just error out and kill the connection at anytime, but you can reconnect in about .5 seconds and send the same information. Most bizzare thing I've ever worked with.
UDP have a lower reliability give it more reliability by making it send a message and wait for respond if no respond came it resend the message.
Why does the UDP protocol not support streams like TCP protocol does?
Others have given perfectly good answers, but I think an analogy may help.
Imagine that UDP is a bit like a mailman - putting letters through people's doors, but never checking that they actually see the letter, or that the person even exists. This is cheap, and works well for junk mail send to many people (read: broadcast packets).
TCP is more like a messenger who will knock on your door and deliver a message in person. If you're not in, he'll come back and try a bit later. Eventually, you'll get the message - or the messenger will know that he hasn't delivered it. You can also send a message back to the sender via the messenger.
Don't try to read too much into my analogy - it's not like there's actually a single "messenger" in TCP - but it might help in terms of thinking about things. In particular, imagine you were sending a whole series of letters to someone, which they had to read in order - that can't work (reliably) with a mailman, as you might come down to find 10 letters sitting on your doormat, with no idea what order to read them in. The mailman might have dropped a few on the way, as well - and no-one will know. That's not a suitable basis for a reliable stream.
(On the other hand, it's a fine model for newspaper distribution. If you happen to miss a few, that's not a problem - you'll still get the later ones, which will be more interesting to you by then. That's why some streaming media solutions use UDP, despite it not giving a reliable actual stream.)
Well ...
UDP is a datagram protocol. It is intended to let applications send invidual datagrams, without a high-level protocol controlling what goes on.
A "stream" is a high-level concept, and thus not possible for UDP to support.
Many applications end up re-implementing parts of TCP on UDP, to get the particular mixture of latency, order independence, error handling, and bandwidth that they need.
The reason is simple: It doesn't, because it doesn't, because that wasn't one of the design goals for the protocol.
Making UDP work as a stream would mean adding almost every feature that TCP has. You'd end up with two identical protocols. What'd be the point?
UDP was meant to be the minimal lightweight protocol. It was meant to complement TCP.
If you define a 'stream' as a 5-tuple of IP(& L4) header, UDP does support streams. I guess what you mean to convey is whether UDP supports connections (where in each stream, aka, 5-tuple, is treated as a logical connection) and reliability of delivery of packets belonging to that stream is more or less guaranteed. Whereas, in case of UDP, althrough the packets are part of a stream (5-tuple), there's no effort to ensure reliability, instead relying on the underlying network layer to make proper delivery. If it fails, so be it.
Jon Skeet's analogy makes perfect sense.