Host A is sending data to host B over a full duplex
link. A and B are using the sliding window
protocol for flow control. The send and receive
window sizes are 5 packets each. Data packets
(sent only from A to B) are all 1000 bytes long
and the transmission time for such a packet is
50 ps. Acknowledgment packets (sent only from
B to A) are very small and require negligible
transmission time. The propagation delay over
the link is 200 trrs. What is the maximum
achievable throughput in this communication?
This question was asked in gate my question. I have calculated it, but what is the meaning of word 'maximum'? The calculation was just for throughput. How would one calculate minimum throughput?
I think maximum means assuming no packets loss and therefore no retries. Also, no additional transmission time above the 50ms. Basically, given the above transmission time and propagation delay, how many bytes can be sent and acknowledged per sec?
My intuition is to figure out how long it takes to send 5 packets to fill up the window with the propagation delay added. Then add the time for the acknowledgement for the first packet to arrive at the sender. That's your basic window send and acknowledgement time because as soon as the acknowledgement arrives the window will slide forward by one packet.
Since the window is 5 packets and each packet is 1,000 bytes then the maximum throughput should be 5,000 bytes / the time you calculated for the above cycle.
Related
TCP fast recovery algorithm is described as follows(from TCP illustrated vol. 1). What I can't understand is in step 1, why there's a CWD window inflation by three times the segment size?
When the third duplicate ACK is received, set ssthresh to one-half the current congestion window, cwnd. Retransmit the missing segment.
Set cwnd to ssthresh plus 3 times the segment size.
Each time another duplicate ACK arrives, increment cwnd by the segment size and transmit a packet (if allowed by the new value of
cwnd).
When the next ACK arrives that acknowledges new data, set cwnd to ssthresh. This should be the ACK of the retransmission from step 1,
one round-trip time after the retransmission. Additionally, this ACK
should acknowledge all the intermediate segments sent between the lost
packet and the receipt of the first duplicate ACK. This step is
congestion avoidance, since we're slowing down to one-half the rate we
were at when the packet was lost.
From [RFC 2001][1]
When the third duplicate ACK in a row is received, set ssthresh
to one-half the current congestion window, cwnd, but no less
than two segments. Retransmit the missing segment. Set cwnd to
ssthresh plus 3 times the segment size. This inflates the
congestion window by the number of segments that have left the
network and which the other end has cached
So, when you receive 3 duplicate ACKs in a row you cut cwnd to half and perform a fast retransmit, from now on you're trying to not just idle while waiting for the next new ACK (1 RTT at best). Once you enter fast recovery, you send new data with
cwnd= original cwnd + # of duplicate ACKs received
until either you receive the ACK you were waiting for or the timer for that ACK expires.
Basically, that "+3" takes account for those 3 acks received that made you enter fast recovery in the first place so that you transmit a number of new bytes equal to the lost bytes + the ones that got to the receiver but were discarded.
[1]: https://www.rfc-editor.org/rfc/rfc2001
In TCP, packet loss can be detected in two ways: timeout and three ACKs (for one certain packet, ie. the loss packet).
Assume that timeout has not been reached yet, what happens to the congestion window if a packet loss happens during the slow start stage? Will the congestion window still increase by 1 when receiving the first duplicated ACK?
For example, at the view of the sender, initially the window size is 3:
[1 2 3]
Packet 1 and its ACK (the ACK for packet 1) are sent and received. Therefore the window size increases by 1, ie. to 4:
[2 3 4 5]
Packet 2 is sent but it's lost. Then when packet 3 is sent successfully, a duplicated ACK (still for packet 1) arrives, what is the window size at this point?
1) If the window size could increase due to receiving of this first duplicated ACK (note that the sender doesn't know packet loss now because there is only one duplicated ACK and timeout has not been reached yet), it should be:
[2 3 4 5 6]
2) Otherwise, perhaps because ACK for packet 1 has been received already (because packet 1 is sent successfully), the window size may remain 4:
[2 3 4 5]
Which one is true for TCP?
Many thanks!
Firstly , window size is set depending on the flow control .
Generally it is 4096 bytes or 8192 bytes and it may change.
So your window size does not depend on the congestion parameters or lost packets.
Now at the very beginning , one packet is sent ( 1 MSS size packet ). If ack for the first packet is received successfully , then it will increase the rate of packets being sent . It will double the size for every acknowledgement. So the congestion window grows exponentially. At certain point , due to congestion it figures out the loss due to timeout or duplicate ACK received. If it receives duplicate ACk , then it will half the congestion windows size and then increases the congwin by adding 1. It increases linearly. If loss is due to timeout then , it will set conwin to 1 and does perform slow start algorithm . In case duplicate ack received it runs fast recovery algorithm .
Slow start stage is where the rate at which packets are sent into transmission like grows exponentially, and after figuring out congestion due to loss event , it half's the congestion window value and increased linearly . Now it will be in congestion avoidance stage.
Although this might be off topic at StackOverflow, I still believe this is an important and interesting issue. I post the answer I find here:
A similar (actually almost the same) question:
Does TCP increase its congestion window when Dup Acks arrive?
Answer:
https://www.rfc-editor.org/rfc/rfc5681#section-3.2
In more detail:
On the first and second duplicate ACKs received at a sender ... the
TCP sender MUST NOT change cwnd to reflect these two segments
For each additional duplicate ACK received (after the third),
cwnd MUST be incremented by SMSS.
Consider a long flow being transmitted in 1 kB packets by a transport protocol that (only) uses AIMD to control the window size. Initially, the window size is 10 kB. Every time the window opens to 20 kB, the last packet in the window is dropped, which is detected exactly after one round-trip time, and re transmitted. How many packets are sent up to and including the first packet that is dropped?
The answer is 165 packets 10+11+12+13+14+15+16+17+18+19+20=165 as
Window will add one pkt each time till it gets a massage of dropping a pkt.
This question is on a test review and I'm not really sure of the answer.
TCP packets are being sent from a client to a server. The MMS is equal to 1460 bytes, and each TCP packet is sent with the maximum capacity. How many TCP packets can be sent before the sequence number field in the TCP header will wrap around?
How much time in seconds will this take on a 1 Mbit/s link?
How much time in seconds will this take on a 1Gbit/s link?
Is there some sort of formula used to figure this out?
Thanks!
Each TCP segments contains 1460 bytes, and sequence number in TCP header is 4 bytes=32 bits so there need to be send 2^32 bytes (because sequence number measure bytes and not bits) in order to sequence number field to wrap around.
In order to calculate the delay you need to consider:
Transmission time - time it takes to push the packet's bits onto the link.
Propagation time - time for a signal to reach its destination.
Processing delay - time routers take to process the packets header.
Queuing delay - time the packet spends in routing queues.
In your questions the transmission time is 1 Mbit/s and 1Gbit/s, and I assume the other delays are 0; so the time it will take to send 2^32 bytes= 8*2^32 bits on:
1 Mbit/s link:
8*2^32 / 10^6 = 34359 seconds
1Gbit/s link:
8*2^32 / 10^9 = 34 seconds
Hope this help you
suppose i have a 4MBits network and i want to calculate the data throughput, this is considering the max transfer rate minus overhead from ethernet/IP/TCP headers.
Reading on the web i found out that the MSS ( maximum segment size) of a TCP segment is 576 - 20 - 20, these last two being TCP and IP headers overhead, resulting in a 93% of data, meaning i will be only using 93% of my 4MBits link to transfer data. Now where's the link ayer overhead? Shouldn't it be added as well? If im not wrong an ethernet header is around 46 bytes so the final sum would be 576 - 20 - 20 - 46 = 490, resulting in an 85% data throughput, but am i doing something wrong?
Just work bottom up. Regular ethernet frames (no jumbo frames, no vlan tagging) are 1542 bytes in total and can have a payload of 1500 bytes. An Ipv4 header without options is 20 bytes and a TCP header without options also 20 bytes. So you end up with 1460 bytes possible payload of a 1542 byte link-layer frame. So your efficiency is 1460/1542=0.9468223086900129, resulting in a maximum throughput of 3.7872892347600517Mbps.
Notice however this will usually be lower. This is the theoretical maximum rate for a continuous stream you can get on a full duplex link, after the TCP session is established and when you're the only user of that link. Also note that as soon as you're sending at a slightly higher rate for some time your link will get congested, you will see drops and your actual TCP throughput might drop significantly because of slow-start.
If the link is wireless (802.11) the calculation becomes a lot more complex because of RTS/CTS mechanisms, but it's about /2 for only one active user and that's without incorporating loss, which is unrealistic.
In general, the protocol can impact network throughput and much more than simply the packet overhead. You mention that you want to measure throughput on an Ethernet/IP/TCP network but the impact of packet overhead of those protocols is NOT the only thing to consider. TCP is a connection-oriented protocol and uses ACK's to signal if a packet has been received or not. user1777914 missed the mark about ACK's but was on to something - they do not take up any more SPACE but they can DELAY the transmission of packets. As latency increases the overall network throughput can decrease based on how often the application or hosting OS expects a response.
W. Richard Stevens has written an AMAZING book on TCP/IP. Here is an except that explains theoretical TCP performance, what impacts it and how it is calculated.
There too is the Nagle algorithm helps with latency but if disabled can slow down throughput.