video streaming is designed for use over what transport method

Video Streaming

Video streaming

R. Pereira , E.G. Pereira , in Pervasive Computing, 2016

1 Introduction

Video streaming has received much attention for some time now, and its popularity has grown manifold in the last decade, particularly with the deployment of widely known video streaming services, such as YouTube, Netflix, Hulu, Daily Motion, and others. Video streaming now accounts for a large share of the total traffic the Internet, and as such the transmission mechanisms used by video servers have an impact not only on the quality of the video presentation to the clients, but also on the total traffic impact on the network.

Developments in the 1980s in the field of video compression, alongside the first steps in the popularization of the Internet in the early 1990s, created the natural motivation for video data to be transmitted over the Internet. Due to the voluminous nature of video data, the concept of streaming quickly grew in popularity as it enabled viewers of a video to view the data without having to first fully download the whole video. Since then, the technologies that impact on video processing and streaming (networking, computing, compression, storage, etc.) have evolved continually at a high pace.

As a result, many new techniques for video streaming have developed. Moreover, with the continual expansion of computing, now encompassing everyday objects, the concepts of ubiquitous and pervasive computing describe a world in which the boundaries between the virtual and real world have been blurred. Wireless networks and mobile computing now feature in most distributed applications, leading to a substantially new challenge for video streaming: the computing/memory/energy capabilities of small mobile devices, and the low-quality channels interconnecting them and linking them to the Internet, impose limitations on the quality of videos that can be streamed. It also suggests the need for multiple encoding levels for each title, so that devices and networks of different characteristics can be supported.

In this chapter, we review a range of relevant aspects associated with streaming: in Section 2, the main architectures are discussed; Section 3 considers in some detail the streaming mechanisms that use the HTTP protocol at the application level; Section 4 provides an overview of the structure and organization of content delivery networks (CDNs); Section 5 presents a discussion of mobile peer-to-peer streaming; Section 6 focuses on compression/encoding schemes and their relationship to streaming mechanisms, followed by Cloud Based Encoding and Transcoding in Section 7. We then discuss the Internet of Things (IoT) and applications related to video streaming. Concluding remarks are presented in Section 10.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128036631000139

Computer networks performance modeling and simulation

Francisco J. Suárez , ... Daniel F. García , in Modeling and Simulation of Computer Networks and Systems, 2015

2.3.3 Video traffic

Video conferencing and streaming services are very popular in modern networks and demand a huge amount of resources, so accurate video traffic models are needed. Like voice traffic models, video traffic models consider components at user and packet levels. Components at user level are the user model, that describes the requests from the client side to the server side, and the session model, based on protocols like RTSP (Real Time Streaming Protocol). Regarding packet level, the components are the codec model and the transport model based on RTP. The main parameters of the session model are session duration (between client and server) and session inter-arrival time (between client requests). Finally, the most important parameters of the codec model are the same as for voice codec models, that is, packet size and packet inter-arrival time.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128008874000079

Application support issues

Anthony Steed , Manuel Fradinho Oliveira , in Networked Graphics, 2010

13.3.1 Audio and video

Audio and video streaming is increasingly important for NG and NVEs. Real-time audio is often incorporated in NGs, and various NVEs support video and audio streaming services. This is a huge topic in its own right (e.g. Austerberry, 2005), but we'll pull out a few features of network support and application support that are particularly useful for NVEs and NGs.

The first aspect to note is that there are quite a range of network protocols that support streaming. We'll concentrate on the IETF standards, but there are also standard protocols from the International Telecommunication Union (ITU) and various proprietary protocols in common tools such as Skype™ and RealNetworks. The IETF protocols include RTP, RTCP, RTSP, SIP and RSVP. An overview can be found in Perkins (2003).

Real-time Transport Protocol (RTP) (Schulzrinne et al. 2003) is a protocol designed to carry data that needs to be delivered in real time. RTP messages are normally carried on UDP, so there is no connection or retransmission provided by the transport. RTP packets add information related to ordering and timing, the source of information and its type. An overview of the RTP packet format is given in Figure 13.4. We don't describe the full variety of options and configuration, but note some important features. First, bits 9–15 of the header correspond to a payload type, defining the type of data that the RTP packet contains. A few of the possible values are shown in Table 13.1, which is based on Perkins (2003). There are thus a range of audio and video codecs that can be carried; it is up to the endpoints of the stream to negotiate which payloads to use. Following this there is a sequence number. It is necessary to order the packets so that the stream can be reconstructed correctly. The next field is the timestamp. Because this is real-time data, a timestamp is needed to indicate when to playout particular information. Refer to the discussion in Section 10.2.3; RTP also uses NTP to measure transmit and playout times. Next come two identifiers: the Synchronization Source (SSRC) and the Contributing Source (CSRC). The SSRC identifies the sender of the data: it is commonly a random number chosen by the application when it is sent. Because multiple participants can send RTP messages to the same address (e.g. using multicast, see Section 4.6.1), this is needed to disambiguate which audio or video stream this is attached to. Thus RTP supports parallel streams. CSRCs are used to identify hosts that might have altered the stream by mixing it or translating it. There may be zero or more CSRCs. One example is to identify all the participants in an audio session where there is actually a mixed process that combines several audio signals into one stream to save bandwidth. The format of the payload header and payload obviously depend on the format used for the payload.

Table 13.1. Some of the Potential RTP Payloads

Description	Specification (RFC)	Type Num	Format
ITU G.711 μ-law audio	1890	0	AUDIO/PCMU
GSM full-rate audio	1890	3	AUDIO/GSM
ITU G.711 A-law audio	1890	8	AUDIO/PCMA
PureVoice QCELP audio	2658	12	AUDIO/QCELP
MPEG Audio (e.g. MP3)	2250	14	AUDIO/MPA
Motion JPEG video	2435	26	VIDEO/JPEG
ITU H.261 video	2032	31	VIDEO/H261
MPEG I/II video	2250	32	VIDEO/MPV

It is beyond the scope of this book to describe the formats for encoding audio and video for streaming. However, we note that data are often broken into frames (short snippets of audio or actual frames of video) that need to be encoded. Each frame is encoded into multiple packets in such a way that each RTP packet will not be fragmented by the network. One important feature is that missing packets are not automatically resent: the receiver must cope and generate a replacement. This could be as simple as playing out silence in audio, but much more sophisticated schemes are possible (see Perkins, 2003, Chapters 8 and 9 Chapter 8 Chapter 9 , or Perkins et al. 1998). With video for example, if a packet is lost, there will be a "hole" in the image. This can be filled in by interpolating colors, using the previous image, or if the camera is moving, attempting to track the camera or objects in the camera view and use more appropriate pieces to fill in the hole. Alternatively, we can use forward error correction (FEC) algorithms to encode the data so that loss can be reconstructed, or we can redundantly encode the data so that each packet contains a high-quality version and a low-quality substitute for another packet.

Alongside RTP comes RTP Control Protocol (RTCP) (Schulzrinne et al., 2003). RTCP provides feedback about participants in sessions, quality and synchronization across streams. There are five different types of messages: receiver reports (RR), sender reports (SR), source description (SDES), membership management (BYE) and application-defined (APP). RR messages are sent by receivers back to the sources on the network. They carry information about the loss rate they are experiencing, jitter, etc. This allows a sender to get a good summary of the quality at which they are being received. If a lot of loss is occurring they might change to a lower-quality codec for example. SR messages are sent by participants that have recently sent RTP data. They are used to synchronize time across media streams, for purposes such as lip-synchronization of audio in one stream with video in another. SDES messages describe the participants in the session. Users generally have control over what information is sent, but its typical that the SDES message includes their name. This allows audio or video streams to be associated with a participant and labeled appropriately in a user interface. The BYE message is used by participants leaving the session. APP messages, as might be expected, depend on the application.

RTP and RTCP are thus concerned with real-time transmission data. Setting up a session requires another set of protocols. This is the function of Real-Time Streaming Protocol (RTSP) and Session Initiation Protocol (SIP). RTSP is used to set up RTP streams from media servers (Schulzrinne, Rao, & Lanphier, 1998). Thus the content is stored on a server. RTSP allows the receiver to control the server by, for example, playing and pausing the RTP stream. For setting up multisource live sessions, such as teleconferences, the SIP can be used (Rosenberg et al., 2002).

Finally, the relationship to RSVP (see Section 3.6.2) is that audio and video streaming are one occasion when it would be useful to have reserved bandwidth so the session maintains a high quality throughout.

On a practical level, there are many tools that can be used to explore streaming audio and video. Two widely used tools with a long history are the Robust Audio Tool (RAT) and Videoconferencing Tool (VIC) (AVATS Project, 2009). These are still commonly used on the MBone (Ericksson, 1994) to support high-end teleconferencing in systems such as AccessGrid® (AccessGrid, 2009). There are many other voices over IP systems available. A few are targeted specifically at group communication for teams in NGs. These include Roger Wilco (GameSpy, 2009) and the open-source Mumble (Mumble, 2009) amongst several others. One aspect of real-time audio that is not yet well supported is spatialization of audio within the virtual environment. Toolkits such as DIVE (see Section 9.2) support RTP-based audio. Another point of reference is Radenkovic (2004).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123744234000136

A survey on cloud-based video streaming services

Xiangbo Li , ... Magdy Bayoumi , in Advances in Computers, 2021

3.6.2 Digital rights management

Another security aspect in video streaming is the copyright issue. This is particularly prominent for subscription-based video streaming services (such as Netflix). DRM is the practice of securing digital contents, including video streams, to prevent unlawful copying and distribution of the protected material. Specifically, its goals are typically centered around controlling access to the content, enforcing rules about usage, and identifying and authenticating the content source. As such, contents protected with DRM are typically sold as a license to use the contents, rather than the content itself. DRM solutions to meet these goals often incorporate tools such as encryption, watermarking, and cryptographic hashing [ 94].

The process of DRM starts with encryption, video contents are encrypted and stored in the video repository and DRM providers keep the secret keys. Fig. 6 summarizes the steps to stream a video protected with DRM. Upon request to stream an encrypted video, after downloading it, the secret key is requested from the DRM provider server to decrypt the video.

Currently, there are three major DRM technologies, namely Apple's Faireplay [95], Microsoft's PlayReady [96], and Google's Widevine [96]. These technologies are able to serve most of the devices and platforms in the market. To cover all devices, streaming service providers have to encrypt every video content with three different DRM technologies and store them in the repository. The three DRM technologies supported platforms are shown in Table 2.

Table 2. DRM supported platforms.

	Chrome	FireFox	IE 11	Safari	Android	iOS	Windows phone	ChromeCast	Roku	Apple TV	Xbox
Fairplay				✓		✓				✓
PlayReady			✓	✓			✓	✓	✓		✓
Widevine	✓	✓			✓			✓

With the increasing demand to stream DRM-protected VOD, an off-line application-driven DRM interceptor has been proposed in [97] that is the awareness of the network connection status of the client device. In this case, if the interceptor application decides that the client device is offline, it requests the license/key for the protected content. The license/key is controlled by the interceptor application. Accordingly, the requests of license/key are handled by the interceptor application that retrieves them from a locally data-store, and then send the key/license to the DRM module.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/S0065245821000280

A brief history of business and competitive information, and the rise of social tools

Scott Brown , in Social Information, 2012

Lifecasting

Lifecasting can encompass live video streaming, and can be taken to the extent of "always on" broadcasting of your life. You can think of lifecasting as the extreme end of the social networking spectrum: continuous broadcast of a person, a room, or a life. Examples in this category include:

■: UStream
■: Livestream
■: Justin.tv.

As you can see, these categories are not always clearly delineated, and likely will become less so in the future, as social tools incorporate more cross-functionality. For example, DailyMotion, the video site, also provides live streaming video from several sources – which also means it falls into the Lifecasting category. Facebook has gaming elements, as we've already discussed. It also has location functionality like Foursquare, as well as microblog capabilities, like Twitter. Google Plus currently has a feature called Hangouts, which allows for a group of up to ten people to have a video conference.

The purpose of the above categorization is not to provide definitive categories for each tool, but to help you think about the primary functionality of each tool, so that you can understand them and choose the right ones for your research.

While we will look at tools that have features from several of these categories, we will be focusing primarily on the following categories of tools:

■: networking
■: publishing
■: blogs and microblogs
■: social search engines
■: video/audio/images.

These tools provide some of the richest resources for business and competitive information.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781843346678500017

New digital media formats

Ophelia Cheung , ... Susan Patrick , in New Approaches to E-Reserve, 2010

Moving ahead

In April 2008, video streaming moved ahead in a major way, when a large nursing series of 64 videos was purchased along with streaming rights, streamed by DE and made accessible for specific courses through Blackboard. In the same year, a set of heavily-used fashion videos, developed by a Ryerson faculty member, were also successfully streamed, and made available through OPAC E-Reserve, considerably lessening pressure and waiting time for these popular videos. In the academic year 2008/9, an additional 30 library videos, at faculty request, were streamed through E-Reserve.

The library is increasingly trying to negotiate with distributors for streaming rights for the whole university, rather than individual courses, in hopes of achieving cost savings as well as increased access. More distributors have also jumped on the streaming bandwagon, and companies like Films for Sciences and the Humanities offer streamed content from their own server, accessible through both the OPAC and course management systems such as Blackboard. The National Film Board of Canada (NFB) has considerably increased access to online content, with their Online Screening Room of over 800 titles free for home use, and available to universities for an annual subscription of $899 for the whole university. Each film carries its own URL and can be embedded quite easily into other online media, emailed or shared on Twitter, Digg and del.icio.us. It also offers Described Video and Closed Captioning capabilities (Dekker, 2009). The stable URL facilitates the potential for linking in e-reserve. In October, 2009, NFB launched their iPhone application, downloadable free from iTunes, so that their library of on-line videos can be watched on the smart phones.

Ryerson Library has also subscribed to two major streamed video databases, Theatre in Video and Dance in Video. Both these databases allow faculty to create playlists. These databases have the capability for users to create playlists or folders (collections of tracks, albums, images, clips, reference material, and even other playlists) around a specific theme, so that materials selected or downloaded can be shared with/ viewed by other users. This presents opportunities for faculty to create reading lists to share with students in their classes, an equivalent of the e-reserve concept, but so far none have been through the library's E-Reserve department. In addition, the ProQuest Nursing database provides nearly 100 training videos which can be downloaded and included in reading lists.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781843345091500059

Flow Control for Video Applications

Subir Varma , in Internet Congestion Control, 2015

This chapter discusses congestion control for video streaming applications. With the explosion in video streaming traffic in recent years, there arose a need to protect the network from congestion from these types of sources and at the same time ensure good video performance at the client end. The industry has settled on the use of TCP for transmitting video even though at first cut, it seems to be an unlikely match for video's real-time needs. This problem was solved by a combination of large receive playout buffers that can smoothen out the fluctuations caused by TCP rate control and an ingenious algorithm called HTTP Adaptive Streaming (HAS) or Dynamic Adaptive Streaming over HTTP (DASH). HAS runs at the client end and controls the rate at which "chunks" of video data are sent from the server, such that the sending rate closely matches the rate at which the video is being consumed by the decoder. This chapter describes the work in this area, including several ingenious HAS algorithms for controlling the video transmission rate.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128035832000062

Possible strategies

Ophelia Cheung , ... Susan Patrick , in New Approaches to E-Reserve, 2010

The streaming initiative

Another Ryerson E-Reserve initiative is video streaming, an area that is of interest to a wide array of services within the institution. In September 2008, E-Reserve called for a brainstorming session of all parties on campus involved in streaming initiatives. The meeting was attended by the library's own systems personnel, Special Collections Librarian, Institutional Repository Librarian, E-Reserve and Audio Visual Librarian and staff, DE Manager and the Assistant Director, and managerial and staff representatives from the CCS department. Apparently, each area had been involved in some aspects of video streaming but had not come together to hash out goals, constraints, requirements and future strategy. Audio Visual Services in the library has been reviewing its collection to identify more heavily used VHS to either purchase DVD replacements or consider the streaming options with distributors. The urgency of VHS replacement stemmed mainly from the impending withdrawal of VHS equipment support for smart classroom showings on campus, currently handled by the Media Services division of CCS. Special Collections is a new library department and the Institutional Repository is an even newer development. Both have an interest in digitization projects. DE wanted to make sure that any centralized streaming initiative would recognize their local need of extracting content from a variety of sources to compile their own course content for streaming on their local media server. The Rogers Communications Centre (a multi-media facility which serves the university's programs in media and electronic communications) brought attention to the demands on the institution's technical infrastructure, the compatibility and support of different streaming formats such as Windows Media Player and Flash, and the staff expertise required. The existing streaming support (bandwidth and staff resources) was designed more for live Webcasting of events rather than massive digitization projects for subsequent streaming. The DMP was part of an institution-wide iTunes and podcasting project. The meeting was a mere starting point for amalgamating the interests of various stakeholders. Nothing substantial was planned for the next step of co-operation but the very fact that the library was instrumental in getting these groups together in one room was a great step forward. Another set of silos had been broken down. Participation in this meeting signaled to all parties concerned that streaming is more than a localized and exclusive project but has the potential for further co-operation and collaboration in future.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781843345091500072

Digital CCTV

Vlado Damjanovski , in CCTV (Third Edition), 2014

The need for compression and networking

The following simplified calculations will help understand the amount of streaming data when analog signal is converted to digital using the ITU-601 recommendations, before compression is applied. Multiplying the samples of each line (864 for PAL and 858 for NTSC) with the number of lines in the system (625 and 525), then with the number of TV frames of the system (25 and 30) and assuming 8 bits representation of luminance and 8 of the color differences (4 for Cr and 4 for Cb), we get approximately the same bit rate for both (NTSC and PAL) digitized TV systems.

For PAL: 864 × 625 × 25 × (8 + 8) = 216 Mb/s, of which the active video streaming is 720 × 576 × 25 × 16 = 166 Mb/s.

For NTSC: 858 × 525 × 29.97 × (8 + 8) = 216 Mb/s, of which, similarly, the active video streaming is 720 × 480 × 29.97 × 16 = 166 Mb/s.

This is a bit rate for a digitized uncompressed live video streaming, according to ITU-601 with 4:2:2 sampling. If the 4:4:4 sampling strategy is used, or even 10 bits instead of 8 bits sampling (which is done in the broadcast TV for video editing and processing), this number of over 166 Mb/s streaming becomes almost twice as large. Streaming 166 Mb/s of just one video signal is impossible even with a 100BaseT network. This would be required by just one live camera, let alone multiple cameras, as we use in CCTV. So the first and most important thing that needs to be applied to the digitized video signal is compression. Digital CCTV would be impossible without video compression.

Various video compressions are used in broadcast television as well, or on the Internet for streaming, DVD video, or Blue-Ray. However, the CCTV industry makes the most of it as it goes to the extreme with the compression technologies, often making best compromises between highest possible compressions and maximum picture quality. This is especially important when using multiple cameras into a typical DVR (multiplexed recording with typically 16, 18, 24, or 32 cameras).

A typical uncompressed full frame video image might be over 1.244 MB in size in PAL (720 × 576 × 3 = 1.2 MB) where we assume 3 colors and 8-bit sampling. Hence 8 bits can be converted to 1 byte. In CCTV we work with a compressed image size (typically JPG) of less than 100 kB, and often even lower than 10 kB.

If we have 25 fps (frames per second) at good quality image compression, at 100 kB each frame, we would get 2,500 kB/s for "live streaming." This number when converted to kb/s produces around 20 Mb/s (2.5 MB/s x 8). The Video compression is more efficient than this due to the temporal factor, so that for the same visual quality we could use MPEG-2 at 4 Mb/s for example, which is at least 5 times less bandwidth when compared to the image compression. With the modern H.264 encoders, we could produce a similar visual quality with only 1 Mb/s, which makes it a 20 times less streaming bandwidth compared to a M-JPG or 20 Mb/s as above.

When video compressions is used it is not expressed in field or frame size in kB, but rather as a streaming in kb/s or Mb/s. So, for example, a high DVD quality video compression using MPEG-2 works with around 4 Mb/s. A decent quality of MPEG-4 streaming over the Internet can be around 256 to 512 kb/s. How far you can go in increasing the compression depends on how much detail one is willing to sacrifice from the image and the type of compression used, but, again, there is no doubt: compression must be applied. The only question is: which one?

Certain image processing can be done on a digitized signal, before or after the compression. Some processing makes a simple division and recalculation in order to put the images in smaller screens (as is the case with split screen compressors or multiplexers), other processing may perform sharpening (which is actually an algorithm where every pixel value of the image is changed on the basis of the values of the pixels around it) or video motion detection, and still others may reduce the noise in the signal, and so on.

Digital networks today are used not only for sending e-mails and web browsing, but they have become the main transport media for digital CCTV.

One of the biggest advantages of digital video was the possibility to transmit the video over almost any network. Whether this is copper Cat-6 cable, fiber optics Ethernet, or Wi-Fi it is almost irrelevant, as digital video is data like any other digital signal. Certainly, special considerations have to be made in regards to the bandwidth and speed, but video can be sent over almost any modern network.

Although a typical advice for a new system would be to run the digital CCTV network on it's own, there are projects where using an existing network will prove beneficial and will save a lot of money. Certainly, an agreement from the responsible IT people is needed, but digital CCTV system can easily be retrofitted in such environments. Separation of traffic is possible with the so-called Virtual LANs (V-LANs), which offer extra security and guaranteed bandwidth.

Despite the distance limitations of local (copper) networks, longer distances are easily achieved by using fiber, wireless, and combined networks with repeaters (this is usually done by network switches and routers).

In today's age of Internet it is quite obvious that a local closed circuit system can easily become a global and open system, connecting continents as if they were across the street.

We will discuss the networking theory used in CCTV later on, but before we go onto the networking in CCTV, let us first describe each of the compression technologies as we see and use them in CCTV.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124045576500082

Network coding for transport

Justus Rischke , Zuo Xiang , in Computing in Communication Networks, 2020

20.1 Introduction

The current Internet is dominated by content delivery applications, such as video streaming, which are tolerant to packet loss. Future applications, such as the real-time steering and control of robots, will require a novel networking infrastructure that can reliably deliver data. For example, a robot would stop working if 3–5 contiguous packets were lost.

However, in the current Internet, there can be packet losses of up to 1%, even in the network core [311]. Multimedia applications can tolerate losses due to caching or the use of error concealment mechanisms. On the other hand, many other applications, such as data transfer, are critically affected and thus rely on reliable data transfer services from underlying layers, such as TCP. The trade-off is a higher latency and reduced throughput due to the flow and error control algorithms of TCP, and the TCP throughput already suffers with a loss ratio as low as 1%.

To reduce packet losses in the network, FEC has been proposed in the earlier days of the Internet [312]. Newer techniques have been proposed, for example, NC by Ahlswede et al. [170] and the extension RLNC [313], which tries to achieve more in terms of error correction and low latency. The idea of RLNC is creating new packets, including redundant packets, from linear combinations of the original ones using randomly generated coding coefficients. This makes RLNC applicable for a distributed networking environment, such as the Internet. Furthermore, RLNC allows us to recode, that is, to form newly encoded packets, at an intermediate network node to avoid retransmissions from the source. This reduces latency and losses, as demonstrated later by hands-on examples in Section 20.3. In addition, multiple coding schemes have been proposed, namely CRLNC [314], PACE [315], and systematic coding [186], to overcome the limitations of traditional block coding in terms of latency and the ability to code on-the-fly. RLNC requires a paradigm shift from conventional store-and-forward to compute-and-forward; for that, network nodes need the computing capability to code packets. For a more in-depth discussion of network coding, we refer the interested reader to Chapter 9.

Several approaches using SDN have been proposed to bring RLNC into reality [316,317]. SDN-capable network nodes can flexibly redirect an incoming flow of packets to a compute node to perform encoding before forwarding the encoded packets to the destination.

The NC-as-a-Service approach as proposed by Szabo et al. [196] allows us to encode TCP and UDP communications without changing existing technologies and thus to improve throughput, reliability, and QoS.

On the other hand, modifications of existing protocols have been proposed to include RLNC, namely for TCP [194] and QUIC [318]. Fig. 20.1 shows the difference between traditional TCP and TCP with network coding (NC-TCP).

Traditional TCP individually acknowledges each packet, that is, if a packet is lost, then the receiver retransmits the acknowledgment of the last packet until the sender repeats the lost packet. As a result, the lost packet ultimately stalls all consecutive packets, which reduces the throughput. NC-TCP, on the other hand, will acknowledge linear independent packets, which can be used to decode the original source packets. In this way, NC-TCP is less susceptible to losses when compared to traditional TCP.

Another application of network coding for transport is multicast. Multicast communication is essential for live video streaming or scalable file delivery.

The problem in multicast communication is the missing ARQ mechanism for repairing losses. FEC with a rateless code, such as RLNC, can improve the resilience without the need for costly feedbacks of the receiver. Fig. 20.2 illustrates the traditional multicast, which sends the individual packets $p_{1}, p_{2}$ , in comparison with coded multicast, in which linear combinations $α p_{1} \oplus β p_{2}$ of the original source packets are sent instead.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128204887000359