Information may be segmented or broken up into smaller chunks for transmission across a physical medium.
The maximum transmission unit or M2 of an outgoing interface depends on the physical medium.
As an example, the M2 of Fast Ethernet is thousand 500 bytes.
However, TCP can theoretically support 65,495 bytes in a single packet.
When that is sent to the lower layers of the AC model, that will need to be broken up into fragments
for transmission across the physical medium, which, for example, only supports 5500 bytes.
Data is therefore broken up into smaller chunks and the receiver using TCP will need to put those fragments
back together again.
The maximum segment size or mass is the largest amount of data in bytes that TCP is willing to send
in a single segment.
For best performance, the MSRPS should be set small enough to avoid IP fragmentation, which can lead
to excessive transmissions if there's packet loss.
TCP supports something called maximum segment size and path M2 discovery or path maximum transmission
unit discovery with the sender and the receiver can automatically determine what the maximum transmission
unit is on a path between them, and TCP will only put enough data into a single packet that fits that
MMBtu, thus avoiding fragmentation of packets and thus avoiding the overhead associated with fragmentation
and the putting together of the IP fragments.
Path MTU discovery is optional in IP version four, but has now become mandatory in IP version six because
of the efficiencies that it brings to the TCP transmission and the fact that IP version six does not
support fragmentation on routers along the path between two hosts.
UDP does not support this and requires higher layer protocols to sort out the fragments.
Flow control.
TCP uses end to end flow control to avoid having the sender send data too quickly for the receiver to
receive it and process it reliably.
If the sender transmits data faster than the receiver can handle, the receiver will drop the data which
will require retransmission.
Retransmission will waste time and network resources, which is why most flow control mechanisms try
to maximize the transfer rate while minimizing the requirements to retransmit.
You may, as an example, have a PC with a powerful CPU sending data to a handheld PDA, which can only
process data at a much lower rate.
The PDA should therefore regulate the data flow so it's not overwhelmed.
In TCP basic flow, control is implemented by acknowledgement from the receiver in receipt of data transmitted.
TCP uses something called a sliding window to control the flow of data.
Windowing will allow a receiving computer to advertise how much data it's able to receive before transmitting
an acknowledgement to the sending computer.
In each TCP segment, the receiver will specify in the receiver window field the amount of additional
received data in bytes that it is willing to buffer for the connection.
The sending host can only send up to that amount of data before it must wait for an acknowledgement
and window size update from the receiving host.
UDP does not implement flow control.
And in a VoIP environment is an example which uses UDP.
Even though there's no physical connection between two handsets involved in a telephone call, the call
will stay up and the sender will merrily continue sending huge amounts of data, even though the receiver
cannot process the received data.
UDP relies on higher layer protocols to implement flow control.
Once again, TCP is connection orientated and UDP is connection less.
TCP will establish the session connection and maintain the connection during the entire transmission.
Once a transmission is complete, the session is terminated.
UDP does not set up sessions and will just send the data in the hope that the receiver will receive
it.
Once again, TCP implements reliability, where every segment transmitted is acknowledged.
And if the segment went missing, it is retransmitted.
UDP does not implement reliability and once again relies on high layer protocols to implement any reliability
if required in certain cases, such as voice over IP or video transmitted over an IP infrastructure.
Reliability is not required.
There is no point re transmitting lost voice packets.
So a quick comparison between UDP and TCP or a reliable protocol and a best effort or unreliable protocol.
TCP once again is connection orientated.
No data is transmitted before a session is established.
A three way handshake takes place before any data is transmitted.
They are acknowledgments of data received and sequence numbers to track transmission of data.
UDP, on the other hand, is connection less and does not track data and does not ensure delivery of
data.
TCP uses sequenced numbers.
UDP does not.
Applications that use TCP include HTTP, email and FTP.
Applications that use UDP include voice streaming applications like voice over IP and video streaming
applications.
Because of the nature of VOIP or video, there is no reason to retransmit in a VoIP environment.
The talker will be required to repeat what they said if the listener was unable to decipher what was
communicated.
If you've ever used Skype at times, it may sound like the person speaking is under water, or they
sound more like a machine than the person you know speaking.
But you may still be able to understand what they've said.
And thus, even though data went missing, the conversation can continue.
Or if it gets bad enough, you would ask the speaker to repeat what they said.
In a video streaming environment.
You may notice that part of the image is not refresh properly, but you're still able to follow what's
happening in the video because of the time sensitive nature of voice and video.
It is pointless re transmitting data and thus TCP is not used in these environments.
UDP is used.
So UDP is a transport layer protocol.
It resides at layer four when the OCI model.
It provides applications with access to the network layer or layer three without the overhead of reliability
mechanisms.
As discussed, this is ideal for voice of IP or video applications.
Its connection less where one way datagram is sent to a destination without advanced notification to
the destination device.
There is no communication before transmission of data.
The data just arrives at the receiver and it's expected that the receiver handle that data.
UDP is capable of providing very limited error checking the UDP datagram does include an optional checksum
value which the receiving device can use to test the integrity of the data.
The UDP header also includes a destination port number and if that datagram is directed to an inactive
port on the receiving device, a return message can be transmitted to indicate that that port is unreachable.
I'm going to discuss port numbers in more detail in a moment.
It's a very important concept to understand.
UDP provides best effort delivery.
There is no guarantee that data is delivered.
Packets may be misdirected, duplicated or lost on their way to the destination.
There is no guarantee of receipt.
Higher layer protocols will need to implement reliability if required.
There are also no data recovery features in UDP.
Once again, higher layer protocols will need to recover from lost or corrupted packets.
TFTP, as an example, has a built in mechanism to handle data loss and TFTP.
Using UDP has its own built in sequencing and retransmission mechanisms as it cannot rely on UDP to
implement reliability.
The UDP header is very simple.
It has a 16 bit source port number, a 16 bit port destination number.
So these specify the port number used by the source and a port number used by the destination.
It has a 16 bit UDP length field that specifies the length in bytes of the entire data gram.
In other words, the header and the data, the minimum length for UDP data gram is eight bytes because
that's the length of the header.
Theoretically, the maximum size is 65,535 bytes, but IP version four will impose a maximum limit of
65,507 bytes.
Optionally, a UDP checksum can be used for error checking.
This is optional in IP version four but is not optional and IP version six.