Revision history [back]

Quick answer to your question is: there are both Slow Start and Congestion Avoidance in your trace. Let's dig into this somewhat deeper.

1) Slow Start. Think of it as of ruleset, not a form. Yes, sometimes it looks like "nice and shiny" exponential growth graph (if a link is of LFN type). In your case it doesn't because your link is not LFN-like. Slow start just says: "for every ACKed full MSS increase cwnd by one". Nothing more.

Look at screenshot from your trace:

Launch caclulator app and follow. I'll start not from very beginning to skip some application chatter and to focus on bulk transfer itself. Packet 135. ACK N 56461. Before it we have Bytes in flight = 67680 = 47 full MSS. I suspect this is cwnd limit. So, packet 135. ACK N 56461. It ACKed 56461 - 53581 = 2880 Bytes or 2 full MSS. Sender's reaction is - releasing 4 full MSS packets into network. Looks familiar? :) BIF after packet N135 and 4 MSS sending became 70560 or 49 full MSS. Packet 140. ACK N 59341. Acked 59341 - 56461 = 2880 Bytes. Again 2 full MSS. What does the sender? Correct, it releases 4 full MSS. BIF becomes 73440 or 51 full MSS.

Main point is - this is what slow start is. Why doesn't it look like exponential? Because ACK's are coming not in bulk manner, but evenly paced. Every ACK comes separately with 20ms interval. That's It!

2) Slow start phase continues up to the point where packet loss and retransmissions occur. After that the sender switches into Congestion Avoidance mode. It can be clearly seen on the next graph:

Congestion avoidance pattern is very consistent. It somewhat looks like CUBIC as Christian said before.

3) Your additional questions.

what causing problem to have so many DUP ACK starting on packet #345

This isn't a problem. Remember. One of the packets was lost in transit. But remember, you have a lot of other out-of-sequence packets in flight when you do Fast retransmission. Every one of these out-of-sequence packets will be causing a receiver to issue DUP ack. The more data in flight you have - the more DUP ACKs you'll see in case of packet loss.

how to know if some packet is Fast Retransmssion or it's retransmited because of RTO

This is tough. You don't know current RTO because it's internal to sender. You can guess it (to some degree!) if you spot current RTT. DIfferent Congestion Avoidance algorithms calculate it differently. If you have received 3 DUP ACKs and almost instantly see a retransmission - probably it is Fast retransmission.

Back to Packet 446. Your suspicion is correct. This is probably not Fast retransmission. Why? Because packet N 348 had the same SEQ, and this one actually WAS Fast retransmission - it's been issued almost instantly after 3 DUP ACKs. Highly probably it was lost again and resent after some timeout. TCP dissector marks it as "Fast" incorrectly, because it sees DUP ACK before it and doesn't take into account there already has been one Fast retransmit to these.

Very interesting trace!

Regards, Vlad

Quick answer to your question is: there are both Slow Start and Congestion Avoidance in your trace. Let's dig into this somewhat deeper.

1) Slow Start. Think of it as of ruleset, ruleset, not a form. form. Yes, sometimes it looks like "nice and shiny" exponential growth graph (if a link is of LFN type). In your case it doesn't because your link is not LFN-like. Slow start just says: "for "for every ACKed full MSS increase cwnd by one". one". Nothing more.

Look at screenshot from your trace:

Launch caclulator app and follow. follow.

I'll start not from very beginning to skip some application chatter and to focus on bulk transfer itself. Packet 135. 135. ACK N 56461. Before it we have Bytes in flight = 67680 = 47 full MSS. I suspect this is cwnd limit. So, packet 135. ACK N 56461. It ACKed 56461 - 53581 = 2880 Bytes or 2 full MSS. Sender's reaction is - releasing 4 full MSS packets into network. Looks familiar? :) BIF after packet N135 and 4 MSS sending became 70560 or 49 full MSS. Packet 140. 140. ACK N 59341. Acked 59341 - 56461 = 2880 Bytes. Again 2 full MSS. What does the sender? Correct, it releases 4 full MSS. BIF becomes 73440 or 51 full MSS.

Main point is - this is what slow start is. is. Why doesn't it look like exponential? Because ACK's are coming not in bulk manner, but evenly paced. paced. Every ACK comes separately with 20ms interval. interval between them. That's It!

2) Slow start phase continues up to the point where packet loss losses and retransmissions occur. After that the sender switches into Congestion Avoidance mode. It can be clearly seen on the next graph:

Congestion avoidance pattern is very consistent. It somewhat looks like CUBIC as Christian said before.

3) Your additional questions.

what causing problem to have so many DUP ACK starting on packet #345

This isn't a problem. Remember. One of the (or more) packets was (were) lost in transit. But remember, consider the fact you have a lot lot of other out-of-sequence packets in flight when you do send Fast retransmission. Every one of these out-of-sequence packets (which are already flying somewhere in the network) will be causing a receiver to issue one more DUP ack. The more data in flight you have had before Fast Retransmission - the more identical DUP ACKs you'll see in case of packet loss.

how to know if some packet is Fast Retransmssion or it's retransmited because of RTO

This is tough. You don't know current RTO because it's internal to sender. You can guess it (to some degree!) if you spot current RTT. DIfferent Congestion Avoidance algorithms calculate it differently. If you have received 3 DUP ACKs and almost instantly see a retransmission - probably it is Fast retransmission.

Back to Packet 446. Your suspicion is correct. This is probably not Fast retransmission. Why? Because packet N 348 N348 had the same SEQ, and this one actually WAS Fast retransmission - it's been issued almost instantly after 3 DUP ACKs. Highly probably it was lost again and resent after some timeout. TCP dissector marks it as "Fast" incorrectly, because it sees DUP ACK before it and doesn't take into account there already one Fast retransmission has been one Fast retransmit to these.issued to these before.

Very interesting trace!

Regards, Vlad

Quick answer to your question is: there are both Slow Start and Congestion Avoidance in your trace. Let's dig into this somewhat deeper.

1) Slow Start. Think of it as of ruleset, not a form. Yes, sometimes it looks like "nice and shiny" exponential growth graph (if a link is of LFN type). In your case it doesn't because your link is not LFN-like. Slow start just says: "for every ACKed full MSS increase cwnd by oneone full MSS". Nothing more.

Look at screenshot from your trace:

Launch caclulator app and follow.

I'll start not from very beginning to skip some application chatter and to focus on bulk transfer itself. Packet 135. ACK N 56461. Before it we have Bytes in flight = 67680 = 47 full MSS. I suspect this is cwnd limit. So, packet 135. ACK N 56461. It ACKed 56461 - 53581 = 2880 Bytes or 2 full MSS. Sender's reaction is - releasing 4 full MSS packets into network. Looks familiar? :) BIF after packet N135 and 4 MSS sending became 70560 or 49 full MSS. Packet 140. ACK N 59341. Acked 59341 - 56461 = 2880 Bytes. Again 2 full MSS. What does the sender? Correct, it releases 4 full MSS. BIF becomes 73440 or 51 full MSS.

Main point is - this is what slow start is. Why doesn't it look like exponential? Because ACK's are coming not in bulk manner, but evenly paced. Every ACK comes separately with 20ms interval between them. That's It!

2) Slow start phase continues up to the point where packet losses and retransmissions occur. After that the sender switches into Congestion Avoidance mode. It can be clearly seen on the next graph:

Congestion avoidance pattern is very consistent. It somewhat looks like CUBIC as Christian said before.

3) Your additional questions.

what causing problem to have so many DUP ACK starting on packet #345

This isn't a problem. One (or more) packets was (were) lost in transit. But consider the fact you have a lot of other out-of-sequence packets in flight when you send Fast retransmission. Every one of these out-of-sequence packets (which are already flying somewhere in the network) will be causing a receiver to issue one more DUP ack. The more data in flight you had before Fast Retransmission - the more identical DUP ACKs you'll see in case of packet loss.

how to know if some packet is Fast Retransmssion or it's retransmited because of RTO

This is tough. You don't know current RTO because it's internal to sender. You can guess it (to some degree!) if you spot current RTT. DIfferent Congestion Avoidance algorithms calculate it differently. If you have received 3 DUP ACKs and almost instantly see a retransmission - probably it is Fast retransmission.

Back to Packet 446. Your suspicion is correct. This is probably not Fast retransmission. Why? Because packet N348 had the same SEQ, and this one actually WAS Fast retransmission - it's been issued almost instantly after 3 DUP ACKs. Highly probably it was lost again and resent after some timeout. TCP dissector marks it as "Fast" incorrectly, because it sees DUP ACK before it and doesn't take into account there already one Fast retransmission has been issued to these before.

Very interesting trace!

Regards, Vlad

Quick answer to your question is: there are both Slow Start and Congestion Avoidance in your trace. Let's dig into this somewhat deeper.

1) Slow Start. Think of it as of ruleset, not a form. Yes, sometimes it looks like "nice and shiny" exponential growth graph (if a link is of LFN type). In your case it doesn't because your link is not LFN-like. Slow start just says: "for every ACKed full MSS increase cwnd by one full MSS". Nothing more.

Look at screenshot from your trace:

Launch caclulator calculator app and follow.

I'll start not from very beginning to skip some application chatter and to focus on bulk transfer itself. Packet 135. ACK N 56461. Before it we have Bytes in flight = 67680 = 47 full MSS. I suspect this is cwnd limit. So, packet 135. ACK N 56461. It ACKed 56461 - 53581 = 2880 Bytes or 2 full MSS. Sender's reaction is - releasing 4 full MSS packets into network. Looks familiar? :) BIF after packet N135 and 4 MSS sending became 70560 or 49 full MSS. Packet 140. ACK N 59341. Acked 59341 - 56461 = 2880 Bytes. Again 2 full MSS. What does the sender? Correct, it releases 4 full MSS. BIF becomes 73440 or 51 full MSS.

Main point is - this is what slow start is. Why doesn't it look like exponential? Because ACK's are coming not in bulk manner, but evenly paced. Every ACK comes separately with 20ms interval between them. That's It!

2) Slow start phase continues up to the point where packet losses and retransmissions occur. After that the sender switches into Congestion Avoidance mode. It can be clearly seen on the next graph:

Congestion avoidance pattern is very consistent. It somewhat looks like CUBIC as Christian said before.

3) Your additional questions.

what causing problem to have so many DUP ACK starting on packet #345

This isn't a problem. One (or more) packets was (were) lost in transit. But consider the fact you have a lot of other out-of-sequence packets in flight when you send Fast retransmission. Every one of these out-of-sequence packets (which are already flying somewhere in the network) will be causing a receiver to issue one more DUP ack. The more data in flight you had before Fast Retransmission - the more identical DUP ACKs you'll see in case of packet loss.

how to know if some packet is Fast Retransmssion or it's retransmited because of RTO

This is tough. You don't know current RTO because it's internal to sender. You can guess it (to some degree!) if you spot current RTT. DIfferent Congestion Avoidance algorithms calculate it differently. If you have received 3 DUP ACKs and almost instantly see a retransmission - probably it is Fast retransmission.

Back to Packet 446. Your suspicion is correct. This is probably not Fast retransmission. Why? Because packet N348 had the same SEQ, and this one actually WAS Fast retransmission - it's been issued almost instantly after 3 DUP ACKs. Highly probably it was lost again and resent after some timeout. TCP dissector marks it as "Fast" incorrectly, because it sees DUP ACK before it and doesn't take into account there already one Fast retransmission has been issued to these before.

Very interesting trace!

Regards, Vlad

Quick answer to your question is: there are both Slow Start and Congestion Avoidance in your trace. Let's dig into this somewhat deeper.

1) Slow Start. Think of it as of ruleset, not a form. Yes, sometimes it looks like "nice and shiny" exponential growth graph (if a link is of LFN type). In your case it doesn't because your link is not LFN-like. Slow start just says: "for every ACKed full MSS increase cwnd by one full MSS". Nothing more.

Look at screenshot from your trace:

Launch calculator app and follow.

I'll start not from very beginning to skip some application chatter and to focus on bulk transfer itself. itself.

Packet 135. ACK N 56461. Before it we have Bytes in flight = 67680 = 47 full MSS. I suspect this is cwnd limit. limit.

So, packet 135. ACK N 56461. It ACKed 56461 - 53581 = 2880 Bytes or 2 full MSS. Sender's reaction is - releasing 4 full MSS packets into network. Looks familiar? :) BIF after packet N135 and 4 MSS sending became 70560 or 49 full MSS. MSS.

Packet 140. ACK N 59341. Acked 59341 - 56461 = 2880 Bytes. Again 2 full MSS. What does the sender? Correct, it releases 4 full MSS. BIF becomes 73440 or 51 full MSS.

Main point is - this is what slow start Slow Start is. Why doesn't it look like exponential? Because ACK's are coming not in bulk manner, but evenly paced. Every ACK comes separately with 20ms interval between them. That's It!

2) Slow start phase continues up to the point where packet losses and retransmissions occur. After that the sender switches into Congestion Avoidance mode. It can be clearly seen on the next graph:

Congestion avoidance pattern is very consistent. It somewhat looks like CUBIC as Christian said before.

3) Your additional questions.

what causing problem to have so many DUP ACK starting on packet #345

This isn't a problem. One (or more) packets was (were) lost in transit. But consider the fact you have a lot of other out-of-sequence packets in flight when you send Fast retransmission. Every one of these out-of-sequence packets (which are already flying somewhere in the network) will be causing a receiver to issue one more DUP ack. The more data in flight you had before Fast Retransmission - the more identical DUP ACKs you'll see in case of packet loss.

how to know if some packet is Fast Retransmssion or it's retransmited because of RTO

This is tough. You don't know current RTO because it's internal to sender. You can guess it (to some degree!) if you spot current RTT. DIfferent Congestion Avoidance algorithms calculate it differently. If you have received 3 DUP ACKs and almost instantly see a retransmission - probably it is Fast retransmission.

Back to Packet 446. Your suspicion is correct. This is probably not Fast retransmission. Why? Because packet N348 had the same SEQ, and this one actually WAS Fast retransmission - it's been issued almost instantly after 3 DUP ACKs. Highly probably it was lost again and resent after some timeout. TCP dissector marks it as "Fast" incorrectly, because it sees DUP ACK before it and doesn't take into account there already one Fast retransmission has been issued to these before.

Very interesting trace!

Regards, Vlad