Lines Matching full:fast
330 retransmissions into SYN, fast-retransmits, timeout retransmits, etc.
337 TCPFastOpenActiveFail: Fast Open attempts (SYN/data) failed because
367 TCP Fast Open
415 TCP Fast Path
418 packet, one is fast path, another is slow path. The comment in kernel
421 It is split into a fast path and a slow path. The fast path is
432 - Data is sent in both directions. The fast path only supports pure senders
437 Kernel will try to use fast path unless any of the above conditions
443 try to enable fast path immediately when the connection comes into the
445 will disable the fast path at first, and try to enable it after kernel
451 kernel handles it in the fast path, TcpExtTCPHPAcks will increase 1,
458 and this packet is handled in the fast path, TcpExtTCPHPHits will
570 The TCP protocol has two retransmission mechanisms: SACK and fast
572 the kernel TCP stack would use SACK, or kernel would use fast
574 the fast recovery is defined in `RFC6582`_, which is also called
607 The reorder packet is detected by fast recovery. It would only be used
608 if SACK is disabled. The fast recovery algorithm detects recorder by
911 TCP Fast Open description
913 TCP Fast Open is a technology which allows data transfer before the
914 3-way handshake complete. Please refer the `TCP Fast Open wiki`_ for a
917 .. _TCP Fast Open wiki: https://en.wikipedia.org/wiki/TCP_Fast_Open
928 This counter indicates that the TCP stack initiated a TCP Fast Open,
934 fast open after the handshake.
938 This counter indicates how many times the TCP stack accepts the fast
943 This counter indicates how many times the TCP stack rejects the fast
949 When the pending fast open request number is larger than
950 fastopenq->max_qlen, the TCP stack will reject the fast open request
1211 TCP window scale option is not used, kernel will try to enable fast
1214 fast path at first, and try to enable it after kerenl receives
1228 reply an ACK, when kernel handled this ACK, the fast path was not
1232 and received another ACK from the server, in this time, the fast path is
1233 enabled, and the ACK was qualified for fast path, so it was handled by
1234 the fast path, so this ACK was counted into TcpExtTCPHPAcks.
1236 In the first nstat output of server side, fast path was not enabled,
1239 In the second nstat output of server side, the fast path was enabled,
1240 and the packet received from client qualified for fast path, so it