Sliding Window at Transport and Data-Link layers [closed]

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 9 years ago.

Why do we need sliding window mechanism at the Transport as well as Data Link Layers? TCP has its own sliding window mechanism for managing flows and errors. Also, data link layer has similar mechanisms. Isn't this redundant?

Answer 1

TCP's and UDP's error control are a single checksum covering each packet. If it fails, the entire packet must be discarded, and then, when the receive fails to acknowledge receipt of the data after a timeout, the data must be resent. Even if data corruption was introduced on one data link between two routers along the network path, the data must be resent from the original sender and make the whole journey across multiple network hops again. This is quite expensive, so this kind of data integrity checking is suitable when the error rate is quite low and the cost of retransmitting is amortized over many successfully transmitted packets. Also, the simple checksum is not that robust and it will miss some errors.

Certain kinds of network links might be expected to have error rates that are too high for the IP transport protocols to deal with efficiently, and so they should provide their own layer of error detection (or even forward error correction) in order for IP to work well over them. Originally, (analog) modems are well known to have introduced this kind of integrity protection (e.g. V.42) as their speeds got higher and higher. I don't know much about the details of the kinds of physical links that are popular these days, but I'd say it's a good bet that one or more of DOCSIS, ADSL, wifi, and/or 3G/4G/LTE incorporate this kind of technology. I would also note that I consider all of this to be happening at the physical layer (Layer 1), not at the datalink layer (Layer 2), although debate is possible on that because the OSI layer model is never an exact fit for the real world of networking.

This kind of error control doesn't necessarily imply that the physical layer (or datalink layer, if you prefer) has any kind of sliding window. It might have in some of the more complex schemes designed for the most unreliable kinds of physical links, but all of the simplest kinds of error checking doesn't: for example, the PPP and ethernet FCS. With an FCS, much like with a UDP checksum, a corrupted packet will simply be dropped, and the protocol has no memory or window from which to retransmit the failed frame, and it doesn't acknowledge successfully received frames to the sender (which is necessary in any kind of sliding window protocol to advance the window).

All that being said, the transport layer error control mechanism remains essential because it is end to end. Only at this layer will errors other than errors introduced by the transmission medium be caught. The IP transport protocols' checksums will catch corruption that occurred inside routers, errors introduced by physical media that doesn't or can't catch errors, or errors in host devices or device drivers.

That's for error control. Some of the same can be said about flow control: although some complex schemes can exist to handle kinds of physical links that would be otherwise problematic for IP to work over, most be the simple schemes don't involve any kind of sliding window. For example, when communicating over an RS-232 serial link, flow control is a simple binary control line: when it's asserted, the other end sends data, and when it's deasserted, the other end pauses. It doesn't remember any previously transmitted data in a window and it doesn't receive acknowledgements.

One final comment: UDP is an unreliable transport protocol. When using UDP, the application is responsible for managing timeouts and retransmissions. There is lots of variability in how well individual applications deal with it. Some to it pretty badly. Since (forward) error correction is at least provided by some of the most notoriously unreliable physical link layers, at least the situation is tolerable in that UDP, though unreliable, "usually" works. The same can be said about some non-TCP, non-UDP transport protocols.