Possibile problem regarding newreno

[Zoltan Richard Turanyi <[e-mail]>]

Hi all!

I have a problem regarding the newreno algorithm as described in
draft-ietf-tcpimpl-cong-control-00.

In section 3.3 the additional step C to the fast retransmit/recovery 
states

    C.  A non-duplicate ACK that does not cover send_high, followed by 3
        duplicate ACKs should not reduce ssthresh or cwnd but SHOULD
        trigger a retransmission.  A non-duplicate ACK that does not
        cover send_high SHOULD NOT cause any adjustment in cwnd.

But when we receive a partial non-duplicate ack it will increase
the value of snd.una (the bottom of our window) and without changing
cwnd it will open the window, though the number of packets in the
network is OK.
In my understanding we should decrease cwnd to prevent the unnecessary
opening of the window.

An example:

Suppose we have a window of 32 packets and two packets are dropped from
one window 20 packets from each other (say packet #10 and #30).

When we receive the dupacks snd.una is 10 and snd.nxt is 42.
Then we retransmit packet #10, halve cwnd to 16 packets and
start deflating it, as duplicate acks come in.
We save snd.nxt (42) to send_high. When we receive
16 dupacks we also start transmitting packets as cwnd is 32 again
and cwnd + snd.una is over snd.nxt. After receiving 32 dupacks
we get a non-duplicate ack for the retransmitted #10 packet. cwnd is
48 packets now and cwnd + snd.una is 58.
The non-duplicate ack will not cover send_high (42) as packet #30 is
also missing, it will signal the need for packet #30.
Thus we do not modify cwnd, but set snd.una to 30 thus raising
snd.una + cwnd to 78, dumping 20 packets into the network, though 
we are not entitled to do so as the number of packets in the network
is the correct value 16.

Instead we should decrease cwnd in a way that snd.una + cwnd remains
at the same level.

Comments?

Zoltán Richárd Turányi
Ericsson TrafficLab
[e-mail]