1

I understand that under the TCP/IP Protocol Suite, error control, flow control and other such services are provided by both, the Transport Layer and the Data Link Layer.

My doubt is specific to error control using the Sliding Window protocol (used by the Transport Layer, if I'm not mistaken) and the Stop-and-Wait ARQ (used by the DLL). Do both these processes occur (in the context of the respective layers) simultaneously? Or is it one or the other?

I also understand that for the Transport Layer, we are concerned with frames at either end points, whereas for the DLL, we are concerned with frames at each hop that a frame makes. Thus, my confusion is this: when we refer to frames in both Sliding Window and Stop-and-Wait ARQ, which Layer's PDU's are we talking about? How do these two processes occur?

| improve this question | |
  • 1
    This (education) question keeps popping up. In the real world, most data-link protocols do no error control beyond dropping frames that are damaged (bad CRC), and flow-control is poorly supported (if at all). "I also understand that for the Transport Layer, we are concerned with frames at either end points" Actually, frames are data-link datagrams. At the transport layer, the datagrams are called datagrams for UDP (User Datagram protocol) or segments for TCP. – Ron Maupin♦ May 9 '18 at 14:44
  • 1
    In any case, your question is really too broad. You need to narrow the focus by asking about specific protocols. Also, all education, certification, or homework" questions are off-topic here. – Ron Maupin♦ May 9 '18 at 14:46
  • Thank you for your response, Ron. Apologies for the broad question. Please close the question if you deem fit, however, I thought about my question again and here's what I gathered from it: say the transport layer at the sender end sends a particular segment to the receiver end transport layer (logically). This segment is packetized, from where each packet goes to the data link layer where it is converted into frames. The DLL then checks and sends each frame, and when the data reaches the receiver, the entire segment is given to the TL to check for errors. Am I going in the right direction? – Utkarsh Pant May 9 '18 at 15:01
  • Yes, the segments are eventually encapsulated in frames, but the transport layer is ignorant of the frames. The data-link layer will general put a CRC on the frame, but really does no error control beyond checking if the CRC is good on the receiving and, and dropping bad frames. Your flow and error control happen at the transport layer, although not all transport protocols do that, either. We can answer questions about specific protocols, but what happens for a connectionless protocol, e.g. ethernet, IP, or UDP, is very different than what happens for a connection-oriented protocol, e.g. TCP. – Ron Maupin♦ May 9 '18 at 15:05
  • Actually, there's forward error correction in various Ethernet PHYs at the OSI layer 1, starting with 10 gigabit Ethernet... – Zac67 May 9 '18 at 19:37
3

When you say error control, I think you are referring to error detection and correction. There are theoretical protocols and real-world protocols.

In the real world (in the vast majority of networks you will encounter in 2018), the dominant data-link protocols are Ethernet (802.3) and Wi-Fi (802.11). There are still other WAN protocols used by large carriers, such as PoS, but their use is waning.

Neither Ethernet nor WiFi have any error control, other than discarding corrupted frames (as @ronmaupin points out). If a frame is corrupted, it is simply dropped with no notification to the sender or receiver. It is up to higher level protocols to perform any error recovery.

There are (or should I say were) some DL protocols that did do error detection, such as X.25, but these are essentially obsolete. As the reliability of networks has improved, they are no longer needed. I haven't seen them in over 20 years.

But for all protocols, the layers are independent. DL protocols don't know what upper level protocols they are carrying, and upper level (like TCP) have no info on how the segments are transported.

| improve this answer | |
0

At transport level, TCP only concerns with end-to-end retransmission of lost packets, and the customary acknowledgements needed to facilitate this. I would prefer to call this "error recovery" rather than control mechanism. This end-to-end recovery only works well when the underlying network has a very low ratio of errors, and thus dropped packets. IIRC, the TCP/IP minimum requirements RFC requires that links provide a 1E-9 error discard rate or lower.

To that end, if a physical network link already features a packet error rate which is lower than 1E-9 or better, all it needs to do is validate the packet it receives from the wire and discard any packet that failed the validation due to a transition errors.

For links that do not perform as required, need to implement additional error recovery mechanisms, so that the error rate perceived by Layer 3 is compliant (otherwise, the error recovery initiated by transport will result in poor user experience).

To that end, wireless Ethernet (a.k.a. Wi-Fi) implements a combination of Forward-Error-Corretion (FEC) as well as a link-level retransmission mechanism.

Some of the newest wired Ethernet variants, e.g. the 10Gbps 10GbaseKR and all 25Gbps, 50Gbps, 100Gbps standards also implement a FEC layer, which at a cost of slightly reduced effective throughput, reduce the effective packet error rate to comply.

Fos historical accuracy I would also add that indeed X.25 (as well as Frame Relay) implemented a link-level (hope-to-hop) retransmission mechanism to facilitate error recovery, and the reason is that these protocols were designed to work on top of very long runs of unconditioned twisted pair copper wires, same ones designed and installed to carry 3.8KHz bandwidth of analogue voice, and would not exhibit a sufficiently low packet error rate without these link-level error recovery mechanisms. FEC would have been too costly (due to low base transmission rate).

| improve this answer | |
  • "Ethernet (a.k.a. Wi-Fi)" That's like calling token ring, FDDI, etc. variants of ethernet. Ethernet and Wi-Fi are two completely separate protocols. Yes they are both IEEE 802 LAN protocols, but they have different frames, ethernet uses CSMA/CD but Wi-Fi uses CSMA/CA, etc. – Ron Maupin♦ May 10 '18 at 0:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.