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.
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 ... (more)
We need more information to be able to help you. It's better to share actual trace, not screenshot. And also please tell the next: capture point location, network environment details, software used to generate traffic.
Packet_vlad I've changed the question in which I added actual trace in the link. This is done for the purpose of traffic analyzing and it's upload of a file to the Dropbox cloud, so I'am the sender and Dropbox is a receiver. I use WiFi internet. Also, now when you have actual trace, can you tell me what causing problem to have so many DUP ACK starting on packet #345 and how to know if some packet is Fast Retransmssion or it's retransmited because of RTO (this situation is on packet #446-it's say Fast Retranssmition but I'm not sure about it)
Well, your trace is not the easiest... I recommend to start with this traces here: https://sharkfesteurope.wireshark.org...
and then go back to your trace. But Keep in mind, that Win7/8 mostly uses CTCP and Linux and Win10 mostly uses Cubic I guess.
It can be clearly seen, that the packet loss has an impact to the performace, due to congestion avoidance mode is entered.