1. IP v6 has a couple of advantages over IP v4. The first one being the address length is 128 bits, over 32 bits in v4. Multicasting allows, “Multiple destinations in a single send operation.” (ipv6.com, 2013) This allows for one to many communications over a network. This allows only one packet to be sent, and be sent to multiple receivers. A v6 packet has a header and a payload. The header has a fixed portion, containing the source and destination addresses, hop counter, and any classifying information. The address is eight groups of 16-bit values; shown as 4 hexidecimal digits. The biggest reason for v6 is that there was a need for more IP addresses and helps route the numerous packets over each network. The three types of addresses are unicast, multicast, and anycast.

2.

One of the greatest changes in Internet usage in recent years has been the onset of high bandwidth video streaming services such as Hulu, Netflix, and Amazon streaming media. Although a notably larger number of American homes have access to higher bandwidth connections such as cable and 4G wireless speeds, the underlying infrastructure of the Internet remains largely the same as it has been for many years (Pandya, 2009). In Huston’s article, the concept known as ‘jitter’ is used to allow TCP traffic to adjust the packet delivery rate to compensate for data flow between endpoints on the greater WAN. In the case of streaming providers, it seems logical to assume that most consumers would see a higher amount of buffering than would be acceptable for such a service, especially from users of cellular networks.

            Although I was not able to find anything specific about how these various streaming applications are configured to accommodate jitter, I can make some inferences. In the case of streaming content from Windows Media Player, transmission is usually based largely on UDP traffic as opposed to TCP traffic (Li, Claypool, & Kinicki, 2002). In order for the stream to appear virtually seamless, it seems to indicate that the application or the server which sends the stream to the client has some sort of traffic analysis that may even pre-buffer content to reduce traffic bottlenecks. According to Li, Claypool, and Kinicki’s research regarding the differences between Media Player and Real Player, their research seemed indicative that the RealPlayer software itself managed the MTU of streaming traffic to limit the actual TCP stream from being buffered. It seems plausible, then, that the software client used by streaming providers may have a similar system in place which has allowed them to successfully deliver high-bandwidth video without a large amount of traffic breaks.