Network Traffic
- 3/18/2009
The Usual
any questions?
Client-Server Traffic
Many clients each send a small-packet request to the server. The server responds by returning many large packets to its clients. The big packet sizes are outbound. (Number of connections is also big, but isn't directional.)
TCP
- TCP flow control optimizes traffic flow for the two end-points using the advertised window. What's the most traffic each one can handle?
- TCP congestion control optimizes traffic flow for the wide-area network, assuming that packet loss is due to network congestion, using the congestion window. What's the most traffic the network can handle?
- advertised and congestion windows were discussed in Class03
- TCP optimizes traffic flow for the client, the server (both flow control), and the network (congestion control).
Peer-to-Peer Traffic
(BitTorrent as P2P example) A downloader sends many small-packet requests to peers. The peers respond by returning many large packets. The big packet sizes are inbound. (Number of connections is also big.)
Change of Perspective
Same picture, different perspective.
Likewise
The server picture could be re-drawn too.
TCP and P2P
Because it was designed with client-server in mind (or in spite of the fact), TCP works ingeniously well for BitTorrent too. Symmetric, full duplex TCP/IP networks are just as good for servers as for BitTorrent!
Another Take
Video
- Video, like YouTube, uses a lot of bandwidth (throughput), and is sensitive to jitter. (Live video is also sensitive to latency.)
- 640 x 480 (pixels), x 256 (conservative number of colors per pixel), x 30 (frames per second), uses 2,359,296,000 bits per second (without compression). Yes, nearly 2.5 Gbps! Compression gets it down to 1.5 Mbps for a nice HD stream (bigger than 640x480 with more colors!).
Practical
When there are major events that many people want to watch, the Networking group goes on alert to see how our Internet traffic responds. Do we need to protect research traffic? Do we need to worry about our Internet bill, based on 95% usage, going up to unexpected and un-budgeted levels? (We want to stay in the million-dollar and 500 Mbps range, so we watch Cacti.)
The Inauguration
We were pleasantly surprised that the inauguration on January 20th did not cause much of a spike in network traffic. We did get a security alert from our netflow monitor that there was an unusual increase in multicast traffic. We discovered that many people were watching, as expected, and that they were using multicast sources like CNN and Ustream.tv. This was the first wide-spread use of multicast in a while, and it worked remarkably well without any help from us.
Inauguration Traffic
The NCAA Tournament
Every March, we see an increase in network traffic with a corresponding decrease in customer calls during UNC tournament games.
Tournament Traffic
WHY?
Unicast
Multicast
Inauguration Information
- How many people watched Obama's inauguration on the web?
- Liz Gannes "was able to tally 70 million views, and notes that U.S. TV outlets totaled about 37.8 million viewers."
- CNN, Facebook win presidential inauguration live streaming contest
- The day live web video streaming failed us (MCNC has an Akamai caching server, so CNN was fine here.)
- CBS Best Inauguration Video Quality, Hulu, C-SPAN The Worst, Others Not Loading (I don't think this reviewer had a prime Internet position!)
Tournament Information
- Most people who watched the NCAA tournament online did it at work (duh!)
- This service "would be useful to watch out-of-market games in your area" but "the reality is that it was primarily utilized by people at work. According to CBS, about 90% of the online viewership were at-work viewers. This, of course, shocks no one. It merely confirms the assumptions, and makes it increasingly likely that network administrators will be attempting to block the site this year."
- Block it? Hardly! We un-cap for it!
- March Madness on Demand from CBS and NCAA
More About Multicast
| one-to-... | |
| unicast | one |
| anycast | nearest |
| multicast | many |
| broadcast | all |
join a multicast group to listen to that conversation/traffic, like IRC
Multicast Scopes
- multicast TTL (number of router hops):
- 128 for any
- 64 for intercontinental, for US peers
- 48 for external peers
- 32 for national
- 16 for local/metropolitan
- 0 for internal peers
- multicast addresses
- wikipedia
- administratively-scoped multicast 239.0.0.0/8
- local scope 239.255.0.0/16, later 239.254.0.0/16 and 239.253.0.0/16 too
- organization local scope 239.192.0.0/14, later 239.0.0.0/10 and 239.64.0.0/10 and 239.128.0.0/10 too
- global scope 224.0.1.0-238.255.255.255
Multicast Helper: IGMPv3
- IGMP: Internet Group Management Protocol in RFC 3376
- node: multicast join, multicast leave
- router: membership query (general, group specific, group and source specific)
- our switches do IGMPv3 snooping
Multicast Helper: PIM-SM
- PIM-SM or PIM-Sparse Mode: Protocol Independent Multicast, Sparse Mode
- PIM-Sparse Mode in RFC4601 and requirements in RFC 4602
- with PIM-SM, only routers and switches that know they need to join a multicast group do so
- prune first or last? which scales?
- sparse mode: few subscribers, dispersed
- dense mode: large cluster of subscribers, pooled