In TCP recovery state, problem of computing the pipe(amount of data in flight).

[hiren panchasara]

On 03/08/16 at 10:29P, Yongmin Cho wrote:
> On Mon, Feb 29, 2016 at 09:54:53AM -0800, hiren panchasara wrote:
> > On 02/29/16 at 05:40P, Yongmin Cho wrote:
> > > Thanks very much for the quick reply.
> > > 
> > > I'm sorry, I didn't make patch file.
> > > First, I wanted to discuss my opinion is right.
> > > 
> > > Let me give you example, please check this.
> > > 
> > > <- ACK (cumack = 1,  sack[3-4], sack[6-7], sack[9-10])
> > > * here segment/byte 2, 5, and 8 are missing.
> > > <- ACK (cumack = 1, sack[12-13], sack[15-16], sack[18-19])
> > > * here segment/bytes 11, 14 and 17 are also reported missing.
> > > <- ACK (cumack = 1, sack[18-19], sack[21-24], sack[27, 28])
> > > * here segment/bytes 20 and 25, 26 are missing. (triggered fast
> > > retransmission)
> > > <- ACK.....(cumack = 1, sack[21-24], sack[27, 28], sack[32, 33])
> > > <- ACK.....(cumack = 1, sack[34-35], sack[37, 40], sack[42, 44])
> > > <- ACK.....(cumack = 1, sack[34-35], sack[37, 40], sack[42, 45])
> > > <- ACKs.....(many duplication acks, and new sacked blocks)
> > > 
> > > In the fast recovery phase, the pipe is caculated like below, If the
> > > net.inet.tcp.rfc6675_pipe is turned on.
> > > pipe = snd_max - snd_una + sack_bytes_rexmit(1 MSS size) -
> > > sacked_bytes(10 = 34-35, 37-40, 42-45 tcp_sack.c:390)
> > > One segment is sended(sack_bytes_rexmit), when triggered fast
> > > retransmission.
> > > Because the snd_cwnd was set 1 mss size. (tcp_input.c:2609)
> > > In the fast recovery phase, The sender can send data,
> > > If this condition is right(awnd < tp->snd_ssthresh tcp_input.c:2568).
> > > When in the network, It still has many in flight packets,
> > > snd_max and snd_una will not be changed, and sack_bytes_rexmit is one MSS 
> > > size, and sacked_bytes is caculated by last ACK that has three SACK
> > > blocks(34-35, 37-40, 42-45).
> > > So, sometimes(In my test environment) the awnd(pipe) value can't go
> > > down less than the snd_ssthresh, while receiving each ACKs
> > > in fast recovery phase.
> > > You know, If the awnd value can't go down less than the snd_ssthresh,
> > > The sender can't send data that is included snd_holes.
> > > 
> > > So, I think, the sacked_bytes should be caculated by all of sacked
> > > blocks that is greater than snd_una, like below.
> > > pipe = snd_max - snd_una + sack_bytes_rexmit - sacked_bytes(3-4, 6-7,
> > > 9-10, 12-13, 15-16, 18-19, 21-24, 27-28, ...).
> > > 
> > > But on current implementation, the sacked_bytes is caculated by three(or four)
> > > sacked blocks that is in last ACK, like below.
> > > pipe = snd_max - snd_una + sack_bytes_rexmit - sacked_bytes(34-35,
> > > 37-40, 42-45 -> sacked blocks of last ACK).
> > > 
> > > My opinion may not be right. Just I want to check implementation of
> > > computing pipe.
> > 
> > Your opinion seems correct to me. If you can create a patch based on
> > this, that'd be great. As I cannot spend time on this until next week.
> > 
> > Cheers,
> > Hiren
> 
> I've created a patch based on this issue.
> 
> You know, The sack_blocks array in tcp_sack_doack function(tcp_sack.c)
> have only 3 or 4 sacked blocks.
> But We need to know all the data that has been sacked.
> The snd_holes queue(in tcp_cb structure) is updated every time we get
> an ACK with sack blocks.
> So, the snd_holes queue know all of hole information.
> And, We can get the sacked_bytes from the snd_holes.
> So, I calculated the sacked_bytes every time when updating the
> snd_holes.
> I've tested this patch in my test environment, And I think, this
> implementation is working well.
> 
> Please check this patch. any feedback will be welcome.

Looks good on the first glance. I'll test this and update you.
Great work!

Cheers,
Hiren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-transport/attachments/20160307/43a8f044/attachment.sig>