SEAL detects cell misordering

Wang, Z.; Crowcroft, Jon

doi:10.1109/65.145159

Cited by 15 publications

(11 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Although this simplifies the design [16], it can introduce limitations. In MPE, these buffers are associated with 'active' PIDs, leading to a common constraint on the number of MPE reassembly buffers (corresponding to PIDs) that may be used in parallel [13].…”

Section: Fragmentation and Paddingmentioning

confidence: 97%

GSE: A flexible, yet efficient, encapsulation for IP over DVB‐S2 continuous generic streams

Cantillo¹,

Collini-Nocker

Bie³

et al. 2008

Satell Commun Network

View full text Add to dashboard Cite

SUMMARYThe second-generation specification for Digital Video Broadcast over Satellite, DVB-S2, defines an improved and adaptive physical layer. A new framing structure at the link layer, known as the generic stream (GS), is introduced offering an alternative to the well-known MPEG transport stream (TS). This paper presents the requirements for and the design of an encapsulation protocol to transport IPv4 and IPv6 datagrams and other network protocol packets directly over DVB-S2 using this GS profile. The resulting generic stream encapsulation (GSE) is a novel method that provides flexible encapsulation with support for fragmentation. A flexible extension header format allows GSE to carry additional header information, suitable for enhanced features, such as link layer encryption and IP header compression. The paper assesses GSE performance by simulation using realistic traffic profiles and attenuation fading. This demonstrates considerable improvement in efficiency compared with the MPE/MPEG-2 TS, especially when used with adaptive coding and modulation (ACM). Although designed for DVB-S2 systems, the new encapsulation is suitable for other second-generation physical layer standards.

show abstract

Section: Fragmentation and Paddingmentioning

confidence: 97%

GSE: A flexible, yet efficient, encapsulation for IP over DVB‐S2 continuous generic streams

Cantillo¹,

Collini-Nocker

Bie³

et al. 2008

Satell Commun Network

View full text Add to dashboard Cite

show abstract

“…Wang and Crowcroft showed that CRC-32 was effective at catching certain types of data reordering [15]. In a simulation of network file transfers using IP over ATM with real file system data, Stone et al [14] showed that CRC-32 caught a wide range of packet splices in which ATM cells from different packets were combined, but that the Internet checksum detected cell erasures at a rate of only 1 in 2 10 .…”

Section: Prior Workmentioning

confidence: 97%

“…Probably the strongest message of this study is that the networking hardware is often trashing the packets which are entrusted to it. A tremendous 5 Since there are 2 1 6 unordered pairs (x, 1 − x) which are congruent to 1, and each pair can appear in either order in the original, this specific case will be caught at a rate of 1 in 2 15 , assuming uniformly-distributed input. 6 If a damaged ACK somehow becomes the first to ack some data, then either (a) the data was indeed received, in which case the ack has done no harm; or (b) the data was lost, in which case the ack will cause the connection endpoints to become inconsistent and the connection will eventually fail.…”

Section: Don't Trust Hardwarementioning

confidence: 99%

When the CRC and TCP checksum disagree

Stone¹,

Partridge²

2000

Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication

View full text Add to dashboard Cite

Traces of Internet packets from the past two years show that between 1 packet in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where link-level CRCs should catch all but 1 in 4 billion errors. For certain situations, the rate of checksum failures can be even higher: in one hour-long test we observed a checksum failure of 1 packet in 400. We investigate why so many errors are observed, when link-level CRCs should catch nearly all of them.We have collected nearly 500,000 packets which failed the TCP or UDP or IP checksum. This dataset shows the Internet has a wide variety of error sources which can not be detected by link-level checks. We describe analysis tools that have identified nearly 100 different error patterns. Categorizing packet errors, we can infer likely causes which explain roughly half the observed errors. The causes span the entire spectrum of a network stack, from memory errors to bugs in TCP.After an analysis we conclude that the checksum will fail to detect errors for roughly 1 in 16 million to 10 billion packets. From our analysis of the cause of errors, we propose simple changes to several protocols which will decrease the rate of undetected error. Even so, the highly non-random distribution of errors strongly suggests some applications should employ application-level checksums or equivalents.

show abstract

“…T HE behavior of checksum and cyclic redundancy check (CRC) algorithms have historically been studied under the assumption that the data fed to the algorithms was uniformly distributed (see, for instance, the work on Fletcher's checksum [2] and the AAL5 CRC [4] and [12]). If one assumes random data drawn from a uniform distribution one can show a number of nice error detection properties for various checksums and CRC's.…”

Section: Introductionmentioning

confidence: 99%

Performance of checksums and CRCs over real data

Stone

Greenwald

Partridge³

et al. 1998

IEEE/ACM Trans. Networking

View full text Add to dashboard Cite

Checksum and cyclic redundancy check (CRC) algorithms have historically been studied under the assumption that the data fed to the algorithms was uniformly distributed. This paper examines the behavior of checksums and CRC's over real data from various UNIX file systems. We show that, when given real data in small to modest pieces (e.g., 48 bytes), all the checksum algorithms have skewed distributions. These results have implications for CRC's and checksums when applied to real data. They also can cause a spectacular failure rate for both the TCP and ones-complement Fletcher checksums when trying to detect certain types of packet splices. When measured over several large file systems, the 16 bit TCP checksum performed about as well as a 10-bit CRC.We show that for fragmentation-and-reassembly error models, the checksum contribution of each fragment are, in effect, colored by the fragment's offset in the splice. This coloring explains the performance of Fletcher's sum on nonuniform data, and shows that placing checksum fields in a packet trailer is theoretically no worse than a header checksum field. In practice, TCP trailer sums outperform even Fletcher header sums.

show abstract

SEAL detects cell misordering

Cited by 15 publications

References 2 publications

GSE: A flexible, yet efficient, encapsulation for IP over DVB‐S2 continuous generic streams

GSE: A flexible, yet efficient, encapsulation for IP over DVB‐S2 continuous generic streams

When the CRC and TCP checksum disagree

Performance of checksums and CRCs over real data

Contact Info

Product

Resources

About