1.

Name the application-layer and transport-layer protocols that are used to support the popular Internet applications:

Application

Application layer protocol

Transport layer protocol

Internet Banking

The SSL/TLS protocols run on layers beneath the application protocols (e.g. PGP, S/MIME, HTTP, SMTP, etc.) and above the TCP transport protocol. SSL/TLS, Secure Shell (SSH)

HTTP encapsulates SSL to (HTTPS) BitTorrent YouTube

P2P HTTP MSNP/P2P P2P

TCP TCP/UDP TCP UDP

Yahoo Messenger Skype

2. EXPLAIN, in your own words, how the Internet works by describing the services offered at each protocol layer and the inter-working of the protocol layers in the Internet protocol suite.

Internet protocol suite is the set of communications protocols that implement the protocol stack on which the Internet and most commercial networks run. It has also been referred to as the TCP/IP protocol suite, which is named after two of the most important protocols in it: the Transmission Control Protocol (TCP) and the Internet Protocol (IP), which were also the first two networking protocols defined. The TCP/IP protocol suite contains four abstraction layers: The hardware link layer, the routing network layer, the data flow handling transport layer, and the program specific application layer.

Function and service of each Layer:  Data Link Layer • Service: Reliable transfer of frames over a link. • Functions: Synchronization, error control, flow control.  Network Layer • Service: Moves packets inside the network. • Functions: Routing, addressing, switching, congestion control.  Transport Layer • Service: Controls delivery of data between hosts. • Functions: Connection establishment/termination, error control, flow control.  Application Layer • Service: Handles details of application programs. • Functions: Everything is application specific.

Protocols in Different Layers

Layers responsibility:  link layer, (data-link layer or network interface layer) – Includes device driver in operating system and the corresponding network interface card in computer. – Handle all hardware details of physically interfacing with cable (or whatever type of media is being used).  network layer (internet layer) – Handles movement of packets around the network. Routing of packets, for example, takes place here. • IP (Internet Protocol), ICMP (Internet Control Message Protocol), and IGMP (Internet Group Management Protocol) provide the network layer in the TCP /IP protocol suite.  transport layer – Provides a flow of data between two hosts, for the application layer above. In the TCP /IP protocol suite there are two vastly different transport protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).  application layer – Handles the details of the particular application. There are many common TCP /IP applications that almost every implementation provides (e.g. Telnet for remote login, FTP- File Transfer Protocol, SMTP-Simple Mail Transfer protocol for electronic mail, SNMPSimple Network Management Protocol, and many more).

3. Discuss the four sources of packet delay in the Internet. Internet’s four sources of delay packet: 1. processing:  Check bit errors.  Determine output link (routing table lookup).  Policies etc. 2. queuing  Time waiting at output link for transmission  Depends on congestion level of router and queue size.

3. Transmission delay:  R=link bandwidth (bps)  L=packet length (bits)  time to send bits into link = L/R 4. Propagation delay:  d = length of physical link  s = propagation speed in medium (~2x108 m/sec)  propagation delay = d/s Nodal delay:

d nodal = d proc + d queue + d trans + d prop
 dproc = processing delay  Usually small though depending on the processor, a few microsecs?  dqueue = queuing delay  depends on the congestion level  dtrans = transmission delay  = L/R, significant for low-speed links  dprop = propagation delay  a few microsecs to hundreds of msecs. 4. Unlike TCP, UDP does not provide reliable delivery services. Discuss THREE (3) reasons why UDP is still being used to support network applications.

UDP Unreliable Not ordered. Lightweight Datagram

TCP Reliable Ordered Heavyweight Streaming

Deciding which transport protocol to use can be the hardest part of developing TCP/IP Network-based applications. The general rule of thumb is to use TCP

unless your specific application calls for bandwidth sensitivity or congestion control. UDP should be used in the following situations: when writing applications that require the capability to broadcast data to multiple devices (IP Multicast however, is much less bandwidth-intensive); when writing real-time multimedia applications that can afford to drop packets when congestion occurs; or for extremely small transmissions that require acknowledgment only.

5. Your office colleagues, who are using the office’s 100Mbps local area network (LAN) that connects to the Internet via a 45Mbps broadband access link, complain to you that their Internet access are frustratingly slow. Based on your understanding of the Internet technology, DESCRIBE and JUSTIFY at least TWO (2) possibilities why the situation happen and propose your solution(s) to overcome the problem. Do it Math Local area networks are built using Ethernet switches and a Category 5 wire connecting each port of a switch to each computer. If a switch has 16 ports, and each port is operating at 100Mbps, then the switch would have to support 1.6Gbps (100Mbps x 16 = 1600Mbps) for it to be “non-blocking”2. Happily, modern Ethernet switches are fully non-blocking. One could easily conclude that sending 1.5Gbps (15 ports at 100Mbps each) to a single 100Mbps port would be a huge issue, but surprisingly it is not. This is because, although each computer can send data at the 100Mbps rate, they don’t send very much data! For example, consider what happens when you download a 1MB file over a 100Mbps network: 1MB file = 1,048,576 x 8 bits = 8,388,608 bit file 100Mbps = 1/100M = 0.00000001 seconds per bit 8388608 x 0.000000001 = 0.08388608 Thus, it will take only 83.8 thousands of a second to download your file (it actually takes much longer because of computer disk operations and other factors). The point is that you are not using the network at all for most of the time, leaving time for others to use it. The sharing of an uplink from your workgroup switch, like the sharing of your WAN connection, is possible because of the bursty nature of most data sources and the statistical nature of the network usage. As long as there is not too much data, all is well. one might conclude it would be a bad idea to send an 8Mbps video stream from one port to every other port of an Ethernet switch. That would require the source port to provide 120Mbps (15 x 8Mbps), well in excess of a 100Mbps port’s capacity, right? Wouldn’t this more than saturate a 100M uplink? Wouldn’t all

mission-critical applications slow to a crawl? Not when sending well-regulated video and when multicasting techniques are employed.

Multicasting to the Rescue
While conventional packet data normally is sent from one source to one destination, multicast traffic is sent from one source to multiple destinations but without using more bandwidth. With multicast, the source delivers only one packet stream to the switch (for example, at exactly 5Mbps), and the switch replicates the packets and delivers them to anyone connected to that switch who requests them. In this local Ethernet switch environment, it is rather pointless to worry about bandwidth when everything is happening at wireline speed. Modern Ethernet switches replicate multicast packets locally without using any additional uplink bandwidth. As a result, sending 5Mbps to every user will have the same network load as sending 5Mbps to one user. But if one Ethernet switch has 16 ports, and one port is connected to the router and 15 ports are connected to users who each wish to view the 5Mbps video, wouldn’t it require 75Mbps (15 x 5Mbps), dangerously close to maximum uplink capacity? The answer is no, because there is only one stream coming from the video source and it is delivered via multicast.

Bursts and Priority
In our discussion, a 1MB file is transferred in about 83 milliseconds. It is important to understand that the intended nature of the Local Area Network is to allow everything to happen as quickly as possible. If you send a 1MB file, the network will attempt to use all of the bandwidth to complete the transfer. If you have 10Mbps Ethernet, the network will try to send your file at 10Mbps for as long as it takes; if you have 100Mbps Ethernet, the network will try to use 100Mbps for as long as it takes. In other words, you are “betting” that your file will be done before someone else needs the network3. With this in mind, you can see why giving one network user priority over another can become complex. If one user can send data at 100Mbps on a 100Mbps network, and if he has priority over everyone else, that priority user could lock out everyone else each time he uses the network! However, if a device such as an MPEG encoder were given top priority, it could never use more than the rate at which it was running. For example, if an encoder unit were sending video at 5Mbps, it would use exactly 5% of the 100Mbps Ethernet connection at all times. It could never use more because the video is a well-regulated continuous stream that does not burst, unlike conventional web, email, file transfers and other traffic.

Exactly 95% of the Ethernet port would simply be unused. To the extent the video data were to leave the Ethernet switch via an uplink port (perhaps destined to a router), it will use exactly 5Mbps, never more. If that uplink were 100Mbps, 95% is available for other traffic; if that link were Gigabit Ethernet, exactly 99.5% remains available for other traffic. Using our previous example, if a 5Mbps MPEG video stream were present, a file transfer that might otherwise require 83 milliseconds would now require 88 milliseconds—not much of a difference

6.

TCP Congestion control.

1. What is meant by network congestion? Network congestion is the situation in which an increase in data transmissions results in a proportionately smaller increase, or even a reduction, in throughput. Throughput is the amount of data that passes through the network per unit of time, such as the number of packets per second. Packets are the fundamental unit of data transmission on the Internet and all other TCP/IP (transmission control protocol/Internet protocol) networks, including most LANs (local area networks). Congestion results from applications sending more data than the network devices (e.g., routers and switches) can accommodate, thus causing the buffers on such devices to fill up and possibly overflow. A buffer is a portion of a device's memory that is set aside as a temporary holding place for data that is being sent to or received from another device. This can result in delayed or lost packets, thus causing applications to retransmit the data, thereby adding more traffic and further increasing the congestion.

2.

Describe how congestion is controlled in the Internet? Supply fairness with a cost of increased state, but provide no inherent incentive structure for best-effort flows to use end-to-end congestion control.

 Per-flow packet scheduling

 Incentives for end-to-end congestion control Give a concrete incentive to end-users, developers, and protocol designers to use end-to-end congestion control for best-effort traffic.  Pricing mechanism Result in a risky gamble that network providers will provide additional

bandwidth and deploy effective pricing structures fast enough to keep up the growth in unresponsive best-effort traffic in the Internet.  Per-flow scheduling Provide fairness at router point. Encourage flows to make sure their queue in the congested router never goes empty.  FCFS scheduling More efficient to implement, Reduces the tail of delay distribution and Allows bursty transmitted in a bursty way instead of having packets “spread out” and be delayed by scheduler.

 Other scheduling algorithms Such as differential treatment or preferential dropping of unresponsive flows, relaxed variants of per-flow scheduling, differential dropping for flows using disproportionate bandwidth, Class Based Queueing, stochastic Fair Queueingand min-max fairness restriction.  Pricing mechanism State required for this would be too complex

3. Explain how does a TCP sender perceive network congestion? • • • • loss event = timeout or 3 duplicate acks TCP sender reduces rate (CongWin) after loss event Here, binary feedbacks indicate “loss events” or “no loss event” Binary feedbacks can indicate others

4. State and briefly explain TWO (2) important mechanisms of TCP congestion control. 1st Mechanism: Slow Start  when connection begins, CongWin = 1 MSS • • Example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps

 available bandwidth may be >> MSS/RTT • desirable to quickly ramp up to respectable rate

 When connection begins, increase rate exponentially fast until first loss event (the end of slow start).  When connection begins, increase rate exponentially until first loss event: • • • double CongWin every RTT done by incrementing CongWin for every ACK received This is Multiplicative-Increase (MI)

Initial rate is slow but ramps up exponentially fast. 2nd Mechanism: AIMD in Congestion Avoidance Additive increase: increase CongWin by 1 MSS every RTT if no loss events  Increase CongWin by 1/CongWin on each ACK. Multiplicative decrease: cut CongWin in half after loss event.
c o n g e s tio n w in d o w 2 4 K b y te s

1 6 K b y te s

8 K b y te s

tim e

Long-lived TCP connection

General AIMD  Increase CongWin by α MSS in each RTT if no loss events • • For TCP, α = 1 Usually α is small

 Decrease CongWin by β*CongWin MSS if a loss event is detected • • For TCP, β=0.5 Usually β is small

5. Fill in the blanks with appropriate answers (Hints: Use these keywords: threshold, congestion window, MSS, timeout, triple duplicate ACK).  When a triple duplicate ACK occurs, Threshold is set to CongWin/2 and CongestionWindow is set to Threshold.  When time out occurs, Threshold is set to CongestionWindow/2 and CongWindow is set to 1 MSS.

1. Specify the TCP sender action(s) for each of the events TCP sender events Data received from applications Actions create, send segment, create TCP segment with sequence number nextseqnum start timer for segment nextseqnum pass segment to IP nextseqnum = nextseqnum + length(data) Timeout retransmit segment, timer timeout for segment with sequence number y retransmit segment with sequence number y . compue new timeout interval for segment y restart timer for sequence number y ACK received ACK processing. ACK received, with ACK field value of y. if (y > sendbase) cumulative ACK of all data up to y cancel all timers for segments with sequence numbers <y sendbase = y If sender receives 3 ACKs for the same data a duplicate ACK for already ACKed segment. increment number of duplicate ACKs received for y if (number of duplicate ACKS received for y == 3)

2. Study the following figure and answer the following questions:

1. Define and describe “duplicate ACK”. Duplicate ACK (DUP ACK) is ACK send by TCP to other end telling that a  segment might have been lost and telling it the value of next expected  sequence number. 

2.

What are ACKx, ACKy and ACKz? How many duplicate ACKs are there in the above figure?

Ackx= acknowledgement for packet1 Acky= acknowledgement for packet1 Ackz= acknowledgement for packet1

Duplicate acknowledgement

Duplicate ACKs are generated by packet loss or packet disorder. TCP cannot determine whether duplicate ACK is generated by packet loss or packet disorder. But TCP assumes that 3 successive duplicate ACKs are caused by packet loss.

3. Describe the behavior of a TCP sender if: 1. .. the timeout value is too short? Choosing good timeout value is important to achieve good TCP performance – Too small yields excess traffic too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss 2. .. the timeout value is too long? Too large yields low utilization

Describe how TCP sender and receiver establish “connection” before 5. TCP Congestion control To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs: 1. The active open is performed by the client sending a SYN to the server. 2. In response, the server replies with a SYN-ACK. 3. Finally the client sends an ACK back to the server. At this point, both the client and server have received an acknowledgment of the connection. 6. Given the maximum segment size is 1kB and the round trip time is 150 milliseconds, calculate the TCP sending rate when connection begins. Show your work.

loop (forever) { switch (event) Event_A: create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) Event_B: retransmit not-yet-acknowledged segment with smallest sequence number start timer Event_C: if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { Action_X }

7. The above pseudo-code presents a simplified description of a TCP sender. Examine the pseudo-code and state the following: Event_A: data received from application  Create a segment with next sequential # seq # is byte-stream number of first data byte in segment.  start timer if not already running (think of timer as for oldest unacked segment).  expiration interval: timeout(n)

Event_B: Time out  retransmit segment that caused timeout

 Restart timer.

Event_C: ACK received  if acknowledges previously unacked segments – – Update what is known to be acked. Start timer if there are outstanding segments.

Action_X: _____________________________________________ Action_X is generally known as ____________________________

8. Compare and contrast the features TCP Vegas, TCP Selective Acknowledgement (TCP SACK) and TCP Reno. TCP Reno, TCP SACK and TCP Vegas are loss based schemes, in that they consider packet loss as congestion indication.

TCP Reno: Uses fast retransmit and fast recovery to avoid timeouts. Thus it helps it recover successfully from a single packet loss. However if multiple packets are lost in a window, TCP Reno generally goes into a timeout because it considers each loss to be a separate congestion indication, and will cut it's ssthresh in half for each loss. TCP SACK: Refines TCP NewReno., Allows a bitmask field to acknowledge individual lost packets. Thus SACK need not retransmit the entire window on packet loss, but only the lost packets. SACK also has cumulative ACKs, which it falls back for correctness in case selective ACKs are lost. TCP Vegas: Is an accumulation-based scheme that uses queueing delay measurements to detect congestion. Vegas additively increases it's window size until a certain small queueing delay is reached and decreases additively if the queueing delay crosses some threshold

9. Justify the need of the following mechanisms in TCP: 1. Slow Start :
The role of the 'slow start' algorithm allows a connection to quickly 'grow' into 'free' bandwidth whilst paying close attention to any possible problems that a connection may face. By implementing a variable called the congestion window (cwnd) we can effectively determine the amount of data that is permitted by the sender on the network at any instance. By implementing slow start, we push data onto the network at a rate such that as much of the network bandwidth is utilised as possible without negative consequences to other users on the network. •

The goal of the slow start mechanism is to detect and avoid congestion as a connection begins or after a timeout
o

Slow start threshold (sshtresh) set to half of cwnd when congestion is detected

o o

Slow start is active if cwnd ? ssthresh Initially, cwnd = 1 segment

2. Additive Increase Multiplicative Decrease (AIMD) : The additive increase/multiplicative-decrease (AIMD) algorithm is a feedback control algorithm and used in TCP Congestion Avoidance. Basically, AIMD represents a linear growth of the congestion window, combined to an exponential reduction when a congestion takes place. The approach taken is to increase the transmission rate (window size), probing for usable bandwidth, until loss occurs. The policy of additive increase basically says to increase the congestion window by 1 MSS (Maximum segment size) every RTT until a loss is detected. When loss is detected, the policy is changed to be one of multiplicative decrease which is to cut the congestion window in half after loss. A loss event is generally described to be either a timeout or the event of receiving 3 duplicate ACKs. Also related to TCP congestion control is the slow start mechanism.

3. Fast retransmit : An enhancement to TCP that reduces the time a sender waits before retransmitting a lost segment. A TCP sender uses timers to recognize lost segments. If an acknowledgement is not received for a particular segment with a specified time (a function of the estimated Round-trip delay time), the sender will assume the segment was lost in the network, and will retransmit the segment. The fast retransmit enhancement works as follows: if a TCP sender receives three duplicate acknowledgements with the same acknowledge number (that is, a total of four acknowledgements with the same acknowledgement number), the sender can be reasonably confident that the segment with the next higher sequence number was dropped, and will not arrive out of order. The sender will then retransmit the packet that was presumed dropped before waiting for its timeout.

4. Fast recovery : After fast retransmit sends what appears to be the missing segment, congestion avoidance, but not slow start is performed. This is the fast recovery algorithm. It is an improvement that allows high throughput under moderate congestion, especially for large windows.
• • • •

Receiver send immediate duplicate ACKs for each segment of out-of-order data received Sender takes corrective action, incuding re-transmission of lost data When 3 duplicate ACKs ( 4 in all ) are received, sender retransmits the lost segment without waiting for timer to expire Fast recovery governs the re-transmission of new data until nonduplicate ACKs are received.

5. Duplicate Acknowledgements (dupACK) : Duplicate ACK (DUP ACK) is ACK send by TCP to other end telling that a segment might have been lost and telling it the value of next expected sequence number. The idea is to delay the third and subsequent duplicate acknowledgements for some time, during which the packet may reach receiver wireless host due to local link level retransmissions. In case of packet losses due to corruptions on wireless links, delayed dupack scheme may avoid unnecessary invocation of congestion control mechanisms at the sender. We expect that this scheme may improve performance of TCP over wireless links.

6. Delayed ACK : Delayed ACKs reduce the number of packets sent on the network. An ACK is only sent when either of the following occurs: - No ACK was sent for the previously received segment. - No segment arrives within 200 milliseconds (the default), after receiving a segment. An ACK is normally sent for every other received segment, unless the delayed ACK timer expires.

10. Find out which TCP variant used in ONE of the popular operating systems (e.g. Windows XP or Apple Macintosh’s OS X or Linux). You must provide/attach the necessary reference to accompany your answer to this question (e.g. hyperlinks, journal/conference articles).

11. State whether you AGREE or DISAGREE with these statements AND justify your answers. 1. The size of the TCP RcvWindow never changes throughout the duration of the connection. DISAGREE because RcvWindow is used to give the sender an idea of how much free buffer space is available at the receiver. Thus, as the amount of unacknowledged TCP data varies the RcvWindow also changes.
In other words, RcvWindow indicates the amount of spare room in the buffer (which is dynamic in nature because the spare room changes over time)

2. Suppose host A is sending a large file to host B over a TCP connection. If the sequence number for a segment of this connection is m, then the sequence number for the subsequent segment will necessarily be m+1. DISAGREE, because TCP sequence number count bytes in the byte stream rather than packets.
If u bytes of data are sent at connection m, than the subsequent segment will have a sequence number of m + u.

3. The TCP segment has a field in its header for RcvWindow.
AGREE, because RcvWindow indicates the number of bytes that a receiver is wiling to accept.

4. Suppose that the last SampleRTT in a TCP connection is equal to 1 sec. Then Timeout for the connection will necessarily be set to a value >= 1 sec.
DISAGREE, because TimeoutInterval should be greater than or equal (> =) to EstimatedRTT, but not necessarily with SampleRTT.

5. Suppose host A sends host B one segment with sequence number 38 and 4 bytes of data. Then in this same segment the acknowledgement number is necessarily 42.
DISAGREE, because Host A’s sending acknowledgement indicates the sequence number of the next byte Host A expects to receive from Host B. On successfully receiving Host A’s packet, Host B will send acknowledgement of 38 + 4 = 42, which is the sequence number of the next byte the receiver is expecting.

6. Suppose that host A wants to send data over TCP to host B, and host B wants to send data to host A over TCP. Two separate TCP connections one for each direction - are needed. 7. The MSS is the maximum size of a TCP segment including headers. DISAGREE, because to point out that the name “maximum segment size” is in fact misleading. The value actually refers to the maximum amount of data that a segment can hold—it does not include the TCP headers. So if the MSS is 100, the actual maximum segment size could be 120 (for a regular TCP header) or larger (if the segment includes TCP options). 8. In TCP, the acknowledgement number that a host puts in a segment is the sequence number of the next byte the host is expecting from the sender. 9. When an in-order segment with expected sequence number arrive and one other segment has ACK pending, the receiver immediately sends duplicate ACK, indicating seq. # of next expected byte DISAGREE, because Immediately TCP Receiver sends single cumulative ACK, ACKing both in-order segments. 10. If sender receives 3 ACKs for the same data, it supposes that segment before ACKed data was lost. DISAGREE, because If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: 11. At the end of a TCP connection, server receives FIN segment (from client), then replies with ACK. Server then closes connection and sends FIN segment. DISAGREE, because a 3-way handshake is used to terminate the connection, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK. This is perhaps the most common method.

12. When TCP CongWin is above Threshold, sender is in slow-start phase, window grows linearly. DISAGREE, because when CongWin is above Threshold, sender is in

congestion-avoidance phase, window grows linearly.