I am failing to understand the reason behind this behavior. What should the congestion window (snd_cwnd) be set to when we hit loss? It seems that we set it to 1 segment right now. https://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?revision=286227&view=markup#l2531
I also see that in the simulations I did. Sender side pcap can be found at: https://people.freebsd.org/~hiren/pcaps/single_packet_loss.pcap Trying to send 50kb of data from freebsd 10.2 server to freebsd client. Initial cwnd is 10 so we blast out 10 packets but 1 packet gets dropped: seq 2897:4345. We get 3 dupacks and we retransmit it. But as soon as we detect this loss, we reduce cwnd to 1 segment. In fact, we could've used data in SACK to see how much we could send on the n/w, imo. 3rd dup ack (which triggered the retransmit) looks like this: IP 192.168.11.10.41674 > 192.168.10.10.http: Flags [.], ack 2897, win 12579, options [nop,nop,TS val 4236220288 ecr 3905376863,nop,nop,sack 1 {4345:10137}], length 0 And the retransmit: IP 192.168.10.10.http > 192.168.11.10.41674: Flags [.], seq 2897:4345, ack 172, win 12579, options [nop,nop,TS val 3905376894 ecr 4236220288], length 1448 At this point in time, sender knows that it has sent 23169 bytes (last packet server sent was seq 21721:23169) and received ack for 10137 bytes minus a missing packet = 8689 bytes. i.e. 6 packets. So, there is at least that much room on n/w at that point in time. We can go conservative and halve that. i.e. 3 packets. That is still better than going down to 1 packet. Is there something basic I am missing here? Any insights would be helpful. Cheers, Hiren
pgpfGgfyAKnFL.pgp
Description: PGP signature