Consider this code in tcp_output.c and tcp_input.c

[hiren panchasara]

On 05/12/16 at 05:50P, Randall Stewart via freebsd-transport wrote:
> All:
> 
> Here are a couple blocks of code from input/output
> ************************************
> tcp_input.c:
> 
>        /*
>          * Segment received on connection.
>          * Reset idle time and keep-alive timer.
>          * XXX: This should be done after segment
>          * validation to ignore broken/spoofed segs.
>          */
>         tp->t_rcvtime = ticks;
> 
> tcp_output.c:
> 
>        /*
>          * Determine length of data that should be transmitted,
>          * and flags that will be used.
>          * If there is some data or critical controls (SYN, RST)
>          * to send, then transmit; otherwise, investigate further.
>          */
>         idle = (tp->t_flags & TF_LASTIDLE) || (tp->snd_max == tp->snd_una);
>         if (idle && ticks - tp->t_rcvtime >= tp->t_rxtcur)
>                 cc_after_idle(tp);
> 
> **************************************
> 
> Now this works just fine if you are the sender of the data.. i.e. we go idle, and then 
> you call send(?) to the peer.
> 
> However what happens if say you are a CDN?
> 
> Your client goes idle, its gotten everything.. for some period of time, maybe its playing out
> its play-buffer or what ever..
> 
> Then it sends in a request, "please send me a large block of data??
> 
> You then start to stream out your 2Meg block of data?.
> 
> Since you received a request at tp->t_rcvtime to send you a big block of data
> the timestamp is current.
> 
> So you blast out 2Meg using your old cwnd/ssthresh and send a nice line-rate
> burst? which of course hits tail drops and other fun :-)
> 
> I believe we need to have something like:
> ***************************
> if ((tp->snd_max == tp->and_una) && ((ticks - tp->t_rcvtime) >= tp->t_rxtcur))) {
>      cc_after_idle(tp)
> }
> tp->t_rcvtime = ticks;
> ***********************************
> added so we catch both sides of the equation..

Great catch! I always thought we were covered on both sides but clearly
thats not the case.

BTW, we are very conservative in after idle case on our CC side which I
tried to fix: https://reviews.freebsd.org/D5124 (which got abandoned for
other things but you get the idea...)

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/20160512/f1b936a8/attachment.sig>