Thanks for the reply. I will try to create a patch based on this. Thanks. 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
_______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport To unsubscribe, send any mail to "[email protected]"
