Value of congestion window (cwnd) when loss is detected

[hiren panchasara]

On 09/03/15 at 09:13P, Lawrence Stewart wrote:
> On 09/03/15 10:54, hiren panchasara wrote:
> > 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.
> 
> You want to read up about window inflation during fast recovery in RFC
> 5681 followed by 3782, and then consult Stevens vol 2 to understand how
> variables are used for different purposes depending on connection state
> and which code path was taken (something I greatly dislike and would
> love to change one day).

Thanks Lawrence for the pointers. From what I could see in the code (as
I pointed above in original email) as soon as we get 3rd dup ack in
tcp_do_segment() insdie 'else if (tp->t_dupacks == tcprexmtthresh)' we
check if we could do SACK with 'if (tp->t_flags & TF_SACK_PERMIT)' and
we set 'tp->snd_cwnd = tp->t_maxseg;' before calling tcp_output().

And I've seen this behavior on many situations. So wanted to confirm if
others are also seeing this. FWIW, I am using cubic cc. But as far as
I can see, snd_cwnd setting for FreeBSD is outside of any cc algos'
scope. i.e. We override whatever is being set.

I'll do the necessary readings.

Cheers,
Hiren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20150903/c47d70ed/attachment.bin>