From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dong Fang <yp.fangdong@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: some questions of tcp congestion window
Date: Thu, 08 Aug 2013 06:13:09 -0700 [thread overview]
Message-ID: <1375967589.4004.89.camel@edumazet-glaptop> (raw)
In-Reply-To: <5203F2D1.3030104@gmail.com>
On Thu, 2013-08-08 at 15:34 -0400, Dong Fang wrote:
> On 08/08/2013 03:26 PM, Dong Fang wrote:
> > hi, all
> >
> > I'am reading the tcp/ip network source code(kernel 3.10), i was
> > fogged by the congestion window. so, i want to confirm something
> > about it:
> >
> > Note: sack is disable. and A is sender, B is receiver.
> >
> > 1. at time t, the number of packets in flight is 100. like this:
> > u, u+1, u+2, ..., u+99
> > and suppose u is lost and all other packets are not. so bwtween
> > t:t+RTT we would have retransmitted u and received 99 dupack.
> > all of this dupack's ack == u, right?
> >
> > when A recieved 3 dupack, it changed to TCP_CA_Recovery state.
> > in this state, the congestion window won't grow any more.
> > then, A retransmit U packet. after that, if A receive a new ack,
> > acked all the packets in flight, so the sock state is changed
> > to TCP_CA_Open. right?
> >
> > 2. at time t, the number of packets in flight is 100, like this:
> > u, u+1, u+2, ..., u+99
> > and suppose u and u+5 is lost and all other packets are not.
> > between t:t+RTT, we should have retransmitted u and received 99
> > dupack, all of this dupack's ack == u, right?
> >
> > when A recieved 3 dupack, it changed to Recovery state, then
> > retransmit U packet, after that, if A receive a new ack,
> > this ack is only acked for u+5, at this time, current sshresh =
> > cwnd/2 + 5(the first 5 packets was acked), but cwnd > sshresh.
> > so A won't send any packets to B, and B won't send any ack to
> > A too, because B have beed send 99 dupack and 1 new ack, it
> > have done its work, right? the only way to let B send ack to
> > A is, the retransmit timeout of u+5 packet.
> >
> > when A was retransmit u+5 packet to B, then B send packet ack
> > for u+100 to A, this time, the A's cwnd == sshresh << 1, enter
> > CA progress, right?
> can anybody help me? :)
I suggest you download packetdrill and build a test ;)
prev parent reply other threads:[~2013-08-08 13:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 19:26 some questions of tcp congestion window Dong Fang
2013-08-08 19:34 ` Dong Fang
2013-08-08 13:13 ` Eric Dumazet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1375967589.4004.89.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=yp.fangdong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox