At which point in message transmission from client to host (or vice versa) is the message actually sliced into packets?
From my current understanding, the application puts an entire file in the socket and hands it over to TCP entirely. TCP first buffers the file/message, and when the time is right (when is the time right?) cuts chunks of the buffer data (creates packets) and adds TCP headers to transform chunks into segments.
Why do we talk about packets in the application layer, if there are no packets in the application layer at all? Just whole files... This doesn't add right.
Can someone confirm my understanding?
A TCP-based application has a message to send. What the message is depends on the application — it could be just a small request, or a whole file. It passes the message to the transport layer (TCP), which chops up the message into segments and passes them one by one to the network layer (Internet Protocol). The network layer adds a header to each packet, and passes it to the link layer (Ethernet), which handles frames.
So, in principle, we have:
messages at the application layer;
segments at the transport layer;
packets at the network layer; and
frames at the link layer.
In practice, however, people are not that pedantic, and tend to mix the notions up. You'll often hear people speak about TCP packets (the correct term would be IP packets with a TCP payload), and they will even speak about the application sending packets (the correct formulation would be that the application passes messages to the transport layer). Most of the time the inexact terminology is not a problem, since context disambiguates things.
The data are sliced into, and encapsulated by segments at the transport layer (UDP, TCP). The segments are encapsulated by packets by the network layer (IPv4, IPv6, etc.). The packets are encapsulated by frames at the data-link layer (ethernet, etc.).
Related
I got basic question. Trying to understand the mechanism how network layer identify when it receive packet larger than its interface MTU configured and has to fragment it.
For example. If the data to be transmitted by application is 2000byte where as the NIC on the server is having MTU 1500. Network layer has to do fragmentation now but how it knows it has to do it. Does the Transport layer give the full 2000byte data to network layer and than network layer compares it with the interface MTU configured and decide accordingly
If the data to be transmitted by application is 2000byte
There are transport-layer (L4) protocols (most prominently TCP) that do all the chunking for an application. TCP is MTU-aware and segments its data automatically into the optimal chunks.
Other L4 protocols don't do any chunking of their own (e.g. UDP). Any application data is simply encapsulated into a datagram and passed to the network layer. If necessary, the network layer then fragments the encapsulating IP packet across several data-link-layer frames.
we know that transport layer protocols like tcp control the flow and take care of the reliability by slide window and acknowledges ...etc. the data link layer with LLC sub layer has the same functionality for reliable connections also. the first question : is this means that both layers do the same functions twice? or when we use tcp in transport layer there is no need for LLC reliability functions ?how is it working ?
the second question: since IP layer is unreliable when it sends and receives packets, is this means that routers witch are layer 3 devices with no tcp protocol above it depends on LLC sub layer to takes care about the reliability "I mean between two routers" ?
I dont think you need other reliability, in words of disruption, both IP and Physical protocls (such as Ethernet) have CRC and Checksum in order to prevent disruption, but in terms of packet loss, TCP is what's called a stream protocol - it transfers you a stream of bytes, Sequence / Acknowledgment number server that purpose and help you keep track of bytes sent/read by client, if some weird "jump" in those numbers would be made, an ACK message wont be sent by receiving side, and protocol's sender would re-send lost packets hence I don't think that you need some reliability in terms of packet loss as TCP covers that for all downwards layers.... not sure I fully understood your question though, thats when we use TCP
about using pure IP and physical layer protocols, I honestly have no idea how to prevent packet-loss yet disruption is prevented by as mentioned earlier - checksums
Recently I dug a bit deeper into the matter of network protocols and the OSI model, when noticed, that incoming TCP datagrams (correct me if this is the wrong term) are splitted into several parts, when they exceed a certain size - in this case it's propably my router's MTU. I captured those datagrams using SharpPcap in order to extract some information i am looking for, if you are wondering where I got this information from.
Anyway I was wondering if the reassembly of fragmented packets shouldn't be task of the IP layer, since it definitely provides information to accomplish this (id, fragmentation flags, fragment offset). Furthermore I read, that the TCP layer is to be interpreted as a stream-based protocol. But this actually implies, that it's up to the TCP layer to care about filling the application's buffer the right way, so that the initial piece of information is reconstructed and may be flushed "up" all further layers.
Before I made this observation I actually thought, that the TCP layer should care about reassembling those datagrams, but none of the mentioned layers does...
This leads to the following question(s):
Why are the TCP datagrams I receive not reassembled and what layer SHOULD actually take care about this?
The ip layer handles fragmentation and reassembly, http://en.wikipedia.org/wiki/IP_fragmentation.
When you use a tool like SharpPcap that uses winpcap/airpcap/libpcap, you are receiving the raw datagrams from the device you are capturing on. For many adapters this is an ethernet datagram that then contains an ip frame etc.
This is in contrast to data received after processing by the networking stack, where the reassembly is performed.
So, its expected that you won't get reassembled datagrams from SharpPcap (or many other capture libraries) because the data is being captured at the adapter level, not inside of our as an output of the networking stack that is performing reassembly.
You can perform the reassembly after capture either yourself or using a library that provides this functionality. You could also add such a component to Packet.Net (the packet processing library that SharpPcap is using) to provide this reassembly.
According to my knowledge if an internet application has to be designed, we should use either a connection-oriented service or connection-less service, but not both.
Internet's connection oriented service is TCP and connection-less service is UDP, and both resides in the transport layer of Internet Protocol stack.
Internet's only network layer is IP, which is a connection-less service. So it means whatever application we design it eventually uses IP to transmit the packets.
Connection-oriented services use the same path to transmit all the packets, and connection-less does not.
Therefore my problem is
if a connection oriented application has been designed, it should transmit the packets using the same path. But IP breaks that rule by using different routes.So how do both TCP and IP work together in this sense? It totally confuses me.
You, my friend, are confusing the functionality of two different layers.
TCP is connection oriented in the sense that there's a connection establishment, between the two ends where they may negotiate different things like congestion-control mechanism among other things.
The transport layer protocols' general purpose is to provide process-to-process delivery meaning that it doesn't know anything about routes; how your packets reach the end system is beyond their scope, they're only concerned with how packets are being transmitted between the two end PROCESSES.
IP, on the other hand, the Network layer protocol for the Internet, is concerned with data-delivery between end-systems yet it's connection-less, it maintains no connection so each packet is handled independently of the other packets.
Leaving your system, each router will choose the path that it sees fit for EACH packet, and this path may change depending on availability/congestion.
How does that answer your question?
TCP will make sure packets reach the other process, it won't care HOW they got there.
IP, on the other hand, will not care if they reach the other end at all, it'll simply forward each different packet according to what it sees most fit for a particular packet.
Note:
Let's assume that IP was connection-oriented, would that mean packets would follow the same-path?
Not necessarily, it depends on what the word 'connection' at this layer means, if it means negotiating certain options related to security, for instance, you may still have all your packets being forwarded through different routes over the Internet.
EDIT:
Not to confuse you though, most connection-oriented services at the network-layer and below mean that the connection, when established, also establishes a virtual-path that all 'packets' must follow, for further information read about:
Virtual circuit and frame-relay networks
This link answers your question pretty well http://www.tcpipguide.com/free/t_ConnectionOrientedandConnectionlessProtocols-3.htm
Some people consider this (TCP) to be like a “simulation” of circuit-switching at higher network layers; this is perhaps a bit of a dubious analogy. Even though a TCP connection can be used to send data back and forth between devices, all that data is indeed still being sent as packets; there is no real circuit between the devices. This means that TCP must deal with all the potential pitfalls of packet-switched communication, such as the potential for data loss or receipt of data pieces in the incorrect order.
The TCP protocol deals with the problem of IP packets arriving out of order or being lost, to give you the feeling they arrive through a single FIFO channel. Yes, TCP is smart enough to do that, there's no need for a dedicated underlying channel.
The TCP protocal is implemented by the sending/receiving machines, once the packets leave the sending machine, the routers they travel along know nothing about TCP, they just use IP to get the packets from the source the to destination. Then, it is the destination machines job to, using TCP, make sure that all the packets arrive and that they arrive in the correct order. The internet itself doesn't know anything about TCP, it's just a layer (often software) that gives connection to a connectionless medium (the internet).
So onces a packet leaves a destination, it can go along any path (mostly) as long as it gets to the desintation, regardless of the higher level protocol (such as TCP or UDP).
I mean, it's a bit more complicated then that, but as far as I can remember that's the general Idea.
Refer my short points properly,
1) Connection oriented means ==> reserving resources(buffer,cpu,bandwidth etc.)..but "Where??".(where resources are reserved?? This where is reason of your confusion, so following is ans.).
2) Connection oriented at Transport Layer means ==> Reserving the resources at Both End processes/Ports.(Since TCP is a transport layer,then its responsibility is to reserve the resources at both end processes only,irrespective of whats happening in the intermediate path.)
3) Connection oriented at Network Layer means ==> Reserving the resources at Network Layers.(Now In the whole journey of a packet from source to destination, Network layer is found at all intermediate routers too(but not transport layer). Hence if any protocol at Network layer is connection oriented then,its responsibility is to reserve resources at all intermediate routeres too i.e. all packets will have to follow same intermediate path, But IP is connection less hence,intermediate resources will not be reserved. i.e journey of a packets may follow different paths etc.)
#CONCLUSION:==> Intermediate path is decided by Network Layer, hence if IP then paths may be different.(IP may contain TCP),But TCP is responsible for Resource reservation at both End processes ,irrespective of Intermediate path of packet.
router works on three layers only (physical , data link and Network layers) , so routers will take decision depending only on the info. of network layer (IP protocol ) hence there is no information available about its TCP or UDP at the router
What units are used in network terminology? Where do we use them?
I know the following - but I'm not sure what their meaning is:
Fragment
Segment
Packet
Frame
Datagram
Can they be assigned to a specific OSI-Layer? Is it more complex?
Taking from Section 1.2 in TCP/IP Illustrated: Vol 1 by Richard Stevens et al.,
consider the 4 layered TCP/IP stack:
+-------------+-------------------------+
| Application | Telnet, FTP, etc |
+-------------+-------------------------+
| Transport | TCP, UDP |
+-------------+-------------------------+
| Network | IP, ICMP |
+-------------+-------------------------+
| Link | drivers, interface card |
+-------------+-------------------------+
Segment: If the transport protocol is TCP, the unit of data sent from TCP to
network layer is called Segment.
Datagram: This is used in 2 layers. If the network protocol is IP, the unit of
data is called Datagram. At transport layer, if protocol is UDP, we use datagram
there as well. Hence, we differentiate them as UDP Datagram, IP Datagram.
Frame: Physical layer representation.
Packet: It is a more generic term used either transport layer or network layer.
TCP Packet, UDP Packet, IP Packet etc. I have not seen it to represent
Physical layer data units.
Fragment: My guess here is that when a unit of data is chopped up by a
protocol to fit the MTU size, the resultant unit of data is called Fragments.
But I am guessing.
These terms are used to refer at which OSI layer we are referring to, the data remain same but the headers and trailers are getting added or removed.
In Phy layer i.e. physical layer the actual data is in "bits" i.e. 0 and 1.
When it reaches to data link layer or Layer 2 it becomes "frame" with source and destination mac address getting added.
When it reaches the third layer or the networking layer it becomes a "packet" with source and destination IP address attached to it.
Finally it become "segment" at Layer 4 or TCP/IP layer. Basically "segment" term is used for TCP connections and "datagrams" for UDP.
So what about other layers like : session, presentation and application ? In these layers the data is termed as "PDU" or "protocol data unit".
So when someone says, that a "frame" is being received by a networking device, then you know that the device is switch.
Router receives a packet and process it.
The answer above is complete. Nevertheless, I think the term packet came from packet switching if I remembered that correctly ..
There are 2 types :
Circuit switching is a methodology of implementing a telecommunications network in which two network nodes establish a dedicated communications channel (circuit) through the network before the nodes may communicate. The circuit guarantees the full bandwidth of the channel and remains connected for the duration of the communication session. The circuit functions as if the nodes were physically connected as with an electrical circuit.(Wiki)
Packet switching is a digital networking communications method that groups all transmitted data – regardless of content, type, or structure – into suitably sized blocks, called packets.(Wiki)
I would have defined it myself, but just to be sure.
So here is the Packet Term. In regard of fragment I concur with Josua Schmid's answer.
I agree with the answers above, but it is important to emphasize that this is assuming the TCP/IP stack. If we use the OSI model, which in my opinion is more widespread, we would have the following case:
Transport layer: Segment if TCP, Datagram if UDP
Network layer: Datagram, Fragment can be used if split (it would still be a datagram)
Data-Link layer: Frame in MAC sublayer, frame or bit in LLC sublayer (depends on what level you work with, they are not interchangeable)
Physical layer: Bit
And as mentioned in previous answers packet is more generic, it can be used for Transport, Network or Data-Link layer, but NOT for the physical layer. At this level it has not been "packed" yet. So I would say this is the biggest difference between the TCP/IP Stack model and the OSI model. The OSI model breaks down the physical layer from the TCP/IP stack into two layers: Data Link and Physical.
Hope this helps.
Frame as physical layer representation doesn't sound 100% accurate to me. It is mostly in the data-link layer, which is above the physical.
For a more operational definition, I would say that a frame is a protocol data unit that has means to determine its boundaries. Examples:
an HDLC frame has flags at the beginning and end and a bit stuffing
mechanism
an Ethernet frame uses preamble and SFD
GFP uses HEC frame delineation, like ATM
A cell, as in ATM, just to introduce one term more, is a fixed-length frame.
A packet is instead a protocol data unit that relies on a lower layer unit to determine its boundaries. It may fit exactly in one frame or be broken into fragments if required. In the latter case fragmentation and reassembly mechanisms must be devised. Datagram is mostly a synonym for packet.
An application data stream can be broken into segments. A segment is carried over a datagram, then segments are reassembled into the original application stream. This is typically done by the TCP layer. So in TCP we have application stream over TCP segment over IP datagram over data-link frame. In UDP there is no segmentation, so the UDP datagram is one-to-one mapped onto the IP datagram.
a Datagram is....
A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network. (... used in UDP)
a Segment is ....
A protocol data unit which consists a TCP header and an application data piece (packet) which comes from the (upper) Application Layer
Packet: The basic unit of communication between a source and a destination in a network is a packet. Packets are data units within the network layer in the OSI model. The packet is in a Network layer.
Fragment:Packets can often be larger than the maximum size, so each packet is also divided into smaller pieces of data called fragments. The Network layer is responsible for fragmentation.
Segment: A segment is a broken piece of a packet with a TCP header in each of them. segments increase the efficiency of network performance and improve security. Segments are in a Transport Layer.
Frame:Similar to a Packet, frames are small parts of a message in the network. a frame is the unit of data used in the OSI model’s data link layer.
Datagram:The datagram represents a data unit of transfer in networking. Data transmitted in a network is divided into smaller parts called datagrams. Transport layer
In addition, there is something class bit, this is in a Physical layer