Why is UDP in the Transport Layer ?

[p.evans]

Trying to figure this one out. I am hoping it is an EASY answer that I am just missing.

I understand that UDP deals with transporting data, that is not my question. Why is it in the Transport layer if according to a Cisco Admin's post on Cisco's learning site, it shows the Transport Layer as, "Ensures that messages are delivered error-free, in sequence, and with no losses or duplications" https://learningnetwork.cisco.com/s/article/osi-model-reference-chart.

According to RFC768, The UDP protocol is transaction oriented, and delivery and duplicate protection are not guaranteed.

We all know that UDP can lose packets and they do arrive out of order (thus not in sequence). 

Any ideas. Thanks again and hopefully I am not making anyone smack their face after reading this

Peter

[Georg Pauwen]

Hello,

I don't pretend to know why exactly the OSI model was designed the way it is, but I remember that for transport layer protocols (TCP/UDP), reliability services are not mandatory, but rather optional. That is why TCP and UDP operate at the same layer, one does 

In addition, numerous applications (such as streaming video and DNS) use UDP because TCP's error checking mechanisms make it e.g. too slow.

[Peter Paluch · Accepted solution]

Hello Georg, hello Peter,

Georg is spot on. Let's leave the debate of "TCP/IP isn't designed according to OSI model" aside for a moment, and let's focus on how the OSI model is commonly presented: Every its layer is assumed to be providing a perfect service - guaranteed, lossless, ordered, ...

But that's not really true, and that's not what we even want. For example, in the same article you have mentioned, Peter, the data link layer (Layer2) is described as providing "error-free transfer of data frames from one node to another over the physical layer, allowing layers above it to assume virtually error-free transmission over the link." Really? : ) Take Ethernet for example. It does not provide any of the reliability in that description. It just transmits frames one by one, and at most is able to detect if a frame got corrupt in transit, but it does not retransmit it anyway. The only retransmissions in wired Ethernet were related to collisions which are long a matter of past. But ocassional drops in Ethernet, mostly to frame buffer exhaustion in switches, are a normal thing. And what about WiFi? That's even worse since there, collisions are still a thing and the quality of the medium (elmag spectrum in a given space) is very volatile. We are far from that ideal "error-free transfer ... allowing layers above it to assume virtually error-free transmission over the link". If this was true about data link layer, anyway, why would we even expound so heavily on the reliability features on the transport layer?

The truth is that different applications have different needs for the reliability features, so they are truly optional. If a service needs a reliable delivery, we have protocols that can guarantee that. If a service needs an unreliable service, we again have protocols that provide exactly that type of service. And just to make sure: "unreliable" does not mean that the service has the inclination to introduce errors - just that it does not add any additional quality guarantees on top of what is provided by the layers below.

Coming back to TCP and UDP, they both provide data segmentation (in UDP, very rudimentary - what you send is what you receive; in TCP, it's a stream of bytes regardless of how you initially sent the data), and they identify the sending and receiving process on the hosts (a running program - an application) by port numbers. This is something we always want and need. And now, if the application needs a connection-oriented approach with guaranteed data delivery, flow control, congestion control and automatic segmentation, at the cost of possibly losing the fluency in transmitting the data, it picks TCP. If the application is okay to send the data without interruption but no feedback whether they arrived or not, and how well they arrived, it picks UDP. Also, if an application needs to do multicasting, TCP is not an option because, due to its connection-oriented nature, it cannot establish a one-to-many type of communication.

So that's why the TCP and UDP both are placed on the transport layer because, within the TCP/IP architecture, they both provide the same essential services expected from this layer: Identifying the sending and receiving process on the end host, segmenting data passed from the sending process and delivering them to the receiving process. That's the bare minimum that every transport protocol in the transport layer is expected to offer.

And for the OSI model, whenever the services described at each layer come with some claims about their guaranteed level of service, the descriptions should include the following disclaimer: "... if that level of reliability is requested or expected by the upper layers". : )
My 1 Euro : )
Best regards,
Peter

[paul driver]

lol

Apologies @Peter Paluch didnt see you had already joned the discussion..

[Peter Paluch]

Paul,

C'mon, why would you apologize? : ) Perish the thought at once, sir! : )

I'm glad you're here!

Best regards,
Peter

[paul driver]

Hello
As you know udp/tcp are transport protocols, and data needs to send be it connection or connectionless thus dependent on the application producing it..

So working from top/bottom of the OCI model
When a host needs to send data, That data needs to be transported, as such that data will to be encapsulated with a transport header (transport layer -tcp/udp) thus it then becomes a segment, This segment is then sent downstream to the network layer which again encapsulates the segment with an ip header making it now a packet (datagram), Again proceeding downstream to the datalink layer to be encapsulated further with a L2 header and trailer which then makes it a frame.

From here on the switch will forward the frame

[Giuseppe Larosa]

Hello @p.evans ,

transport layer in OSI model provides the capability to transfer data but error-free in sequence and with no losses and duplication are not mandatory attributes.

In simple words whatever protocol is over IPv4 or IPv6 is considered OSI Layer 4 so from this point of view also ICMP would be layer 4 , OSPF protocol 89 is Layer 4. EIGRP protocol 88 is layer 4, GRE and so on.

To be noted there are applications based on UDP that provides all  the missing features and are used for carrying VOIP packets.

UDP is simpler then TCP.

There are applications that cannotr run over TCP like multicast all multicast streams are based on UDP as there is no session concept and no session setup. TCP cannot be used for multicast.

So what you have read in the Cisco Learning Network are actually properties of TCP not of every transport protocol.

Take the habit to compare different sources there is no single study source that is perfect and complete.

You can search for the following books:

"Internetworking with TCP/IP" Douglas Comer

"TCP/P illustrated vol I" Stevens

Hope to help

Giuseppe

[Joseph W. Doherty]

"Ensures that messages are delivered error-free, in sequence, and with no losses or duplications"

Actually, I believe, it's possible to construe this may be true for UDP.

The key, here, might be understanding a "message" has bounds.

Assuming a message can/must be contained with a single user datagram, which might encompass multiple IP packets, if the datagram is "delivered" (delivery, itself, not guaranteed), the message will be error-free, in sequence ("The quick brown fox.") will not be delivered (up the stack) as "fox quick. brown The"), without loss (no "The quiwn fox.") and without duplication ("The quick brown fox.The quick brown fox.")

IP packets, considered as datagrams, is very similar to L4 user datagrams, but L3 is concerned with routing a packet, not so much higher level user concerns.

UDP, builds on IP datagrams, adding some additional "message" features, like port numbers for higher level "routing" (above the network itself), and allowing datagrams independently sized from L2 and/or L3 media issues.

Is it possible, for example, for an application to generate a 4K UDP on 1500 byte Ethernet?  If so, assuming the message is delivered, will it, the message, be error-free, in sequence (for that message, not in relation to other messages) and without loss or duplication (of message contents)?