TCP acceleration notes

All say BBR Than CUBIC, but CUBIC What is the difference ？ Look at the figure below to understand CUBIC Why not resist packet loss ：

CUBIC Unconditionally after packet loss MD, After that, a new ssthresh Start at AI,CUBIC It is believed that packet loss must be caused by congestion buffer overflow Caused by the . In fact, not necessarily .

25 Gbps * 50us link ,5% Packet loss rate , Throughput drops to 300 Mbps, The reason is as shown in the figure above , The longer the link , The more serious the problem .

How do you optimize it ？

The conventional idea is to lose packets without dropping windows or reduce windows , But not to the core . The core is not to drop the window after packet loss , contrary , Packet loss window reduction and packet conservation are necessary strategies in any case ( Van Jacobsen conservation rate ： As long as there is only one copy of each packet on the network , There will be no congestion collapse ), The core of the problem lies in the recovery of packet loss , Should have been undo But there was no undo.

As long as it is random non congestion packet loss , Should be implemented completely undo action .

How to determine non congestion packet loss ？

Here is a 10 Line code scheme , Not complicated but effective . Change tcp_cubic.c, rename cc name by cubic2, modify pkts_acked/set_state Callback ：

//  increase  currRTT,minRTT  Field , Bubble tracking  minRTT, Real time updates  currRTT.
static void bictcp_acked(struct sock *sk, const struct ack_sample *sample)
{
    
        const struct tcp_sock *tp = tcp_sk(sk);
        struct bictcp *ca = inet_csk_ca(sk);
        struct inet_connection_sock *icsk = inet_csk(sk);

        u32 delay;

        /* Some calls are for duplicates without timetamps */
        if (sample->rtt_us < 0)
                return;

        if (icsk->icsk_ca_state < TCP_CA_Recovery)
                ca->currRTT = sample->rtt_us;
        ca->minRTT = min(ca->minRTT, sample->rtt_us);
        /* Discard delay samples right after fast recovery */
        ...
}

static void bictcp_state(struct sock *sk, u8 new_state)
{
    
        struct tcp_sock *tp = tcp_sk(sk);
        struct bictcp *ca = inet_csk_ca(sk);

        if (new_state == TCP_CA_Loss) {
    
                bictcp_reset(inet_csk_ca(sk));
                bictcp_hystart_reset(sk);
        }
        if (new_state == TCP_CA_Open) {
    
// int gamma = 3;
// module_param(gamma, int, 0644);
// MODULE_PARM_DESC(gamma, "gamma");
                if (ca->currRTT < gamma*ca->minRTT) {
    
                        tp->snd_cwnd =  max(tp->snd_cwnd, tp->prior_cwnd);
                        tp->snd_ssthresh = tp->prior_ssthresh;
                        tp->snd_cwnd_stamp = tcp_jiffies32;
                        tp->undo_marker = 0;
                        tp->rack.advanced = 1;
                } else {
    
                        printk("un-undo %d to %d min:%d curr:%d srtt:%d\n",
                                tp->snd_cwnd,
                                tp->prior_cwnd,
                                ca->minRTT,
                                ca->currRTT,
                                tp->srtt_us);
                }
        }
}

I only record Open and Disorder In state currRTT, In fact, I already have a way to Recovery Accurate state measurement RTT, But for a day tip, They are not linked together .

The code means , In case of packet loss, if currRTT There's nothing like minRTT Too much ( In the code is 5 times , Adjustable , If minRTT Ben is very small ,gamma Obviously not so big ,2 sufficient ), It is determined as random packet loss , All undo.

to the end currRTT,minRTT,srtt_us What relationship should be maintained before it is determined as random packet loss , It's complicated , It can also be simple and rough , We should adjust the parameters according to the actual effect , As for links AQM QoS Strategy , Can only guess .

BBR With actual measurements maxbw, minrtt To guide the pacing rate, cwnd Calculation ,CUBIC It can also be used minRTT,currRTT,srtt_us, Half way jitter, etc undo. In a word, we should make full use of the measured information to inspire future actions .

as for minRTT Is it accurate , One line of code is definitely imprecise , In case the route reconverges, it is necessary to retest . You can't learn completely BBR, Then it becomes BBR 了 , The simplest way is to make the whole situation bubble .

Probably 10 Line code , Complete a heuristic undo. Look at the effect ：

[  4]  0.0-100.7 sec  3.16 GBytes   270 Mbits/sec  # cubic
[  5]  0.0-101.0 sec  49.1 GBytes  4.18 Gbits/sec  # cubic2
[SUM]  0.0-101.0 sec  52.3 GBytes  4.45 Gbits/sec

Retransmission rate ：

cubic  bytes_sent:3565663872  bytes_retrans:177562484    Retransmission / transmission ：0.0497
cubic2 bytes_sent:55514372396 bytes_retrans:2773832160   Retransmission / transmission ：0.0499

Not because undo Cause radical packet loss and increase retransmission rate , Relatively accurate , There is no retransmission rate for throughput .

Finally, let's look at most scenarios BBR Than CUBIC The core reason for better throughput , In fact, that is BBR Of undo well done .BBR Hold on to your strength 10 rounds Internal maxbw Reuse , And directly after the packet loss recovery undo It's time to maxbw and prior cwnd, That's why it works .

go back to CUBIC, Combined with the small ones of the previous day tips, Such as half range jitter measurement ,Recovery state RTT To measure accurately , It can also judge random non congestion packet loss more accurately , But that's it for today .

It still hasn't rained after waiting for several days , This year, the rain belt has stayed in South China for too long , So I missed the appointment of Jiangnan plum rainy season , In the past, the South China dragon boat water was followed by the plum rain season in the south of the Yangtze River , Then North China , The northeast . This year the rain belt will not go away in South China . The weather is not too complicated , Wait till it rains . Simple notes .

Zhejiang Wenzhou leather shoes wet , It's not fat when it's raining .