[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA++eYdsG5Jw15BNqLv6AE3LivhsDpHNjRxvx3T3qZF248z6fRQ@mail.gmail.com>
Date: Thu, 4 Jun 2015 18:19:00 +0200
From: Kenneth Klette Jonassen <kennetkl@....uio.no>
To: Yuchung Cheng <ycheng@...gle.com>
Cc: Kenneth Klette Jonassen <kennetkl@....uio.no>,
netdev <netdev@...r.kernel.org>,
David Hayes <davihay@....uio.no>,
Andreas Petlund <apetlund@...ula.no>,
Dave Taht <dave.taht@...il.com>
Subject: Re: [RFC PATCH net-next] tcp: add CDG congestion control
> why not just call tcp_init_cwnd_reduction()?
I deferred considering the ECN implications of doing so. The code to
start PRR was based on tcp_enter_cwr()/tcp_init_cwnd_reduction(), save
that both of these functions ensure a call to tcp_ecn_queue_cwr().
The upcoming patch set instead exports tcp_enter_cwr() and calls it,
which sets CWR on ECN-capable connections.
Consider CDG at the sender-side. The RFC 3168 Errata says that a
receiver should:
"First, reset ECE because of CWR
Second, set ECE because of CE"
Thus, in "good networks", setting CWR on a CDG backoff should not
affect ECN signalling – we still get ECE from the receiver.
It is conceivable that fringe scenarios of ECN in the forward path and
losses in the ACK path creates a situation where CDG's backoff could
inhibit some ECN signals from the receiver. That is, setting CWR will
inhibit the signalling reliability of standard ECN in TCP. But we are
arguably still in good faith since we have reduced the congestion
window by some beta.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists