FreeRTOS-TCP congestion RFC

Kernel
1

I am looking fo rthe congestion control schema that FREERtoS-TCP supprt.
What is the RFC that the TCP stack support?
ECN, SACK, DCTCP. WS . TS

2

Hello @neemanavi

You wrote:

I am looking for the congestion control schema that FreeRTOS+TCP support.
What is the RFC that the TCP stack support?
ECN, DCTCP. SACK, WS . TS

If I may ask, why this interest? Are you planning to use FreeRTOS+TCP? Or are you using it and experience problems with TCP congestion?

  • Explicit Congestion Notification (ECN)
    Data Center TCP (DCTCP)
    Not implemented

  • Selective acknowledgment (SACK)
    Implemented

  • WebSocket (WS)
    is a higher protocol and can be realised by using the TCP-sockets. T think that WS can be very interesting for embedded projects.

  • Time stamps (TS)
    were implemented in earlier releases, but it was rarely used. We removed it for the sake of simplicity and security. Also, it depended on hardware features that are not always present.

  • Smoothed Round Trip Time (SRTT)
    was chosen to calculate proper time-outs. The acknowledgement timer is ignored in case of a fast-retransmission.

  • The Nagle algorithm
    is not implemented because most applications want zero-wait delivery of packets. And if it is desired, Nagle can also be realised at a higher level.

Each TCP socket has 3 queues for transmission:

    xPriorityQueue; /* Priority queue: segments which must be sent immediately */
    xTxQueue;       /* Transmit queue: segments queued for transmission */
    xWaitQueue;     /* Waiting queue:  outstanding segments */

FreeRTOS+TCP has a powerful socket option that determines the maximum WIN (sliding window) size in both directions, as well as the size of the TCP buffers associated with the socket. The option is called FREERTOS_SO_WIN_PROPERTIES. For fast reliable connections, it may be profitable to use a large WIN. In case of a connection with a limited quality, it is best to use a WIN of 1 or 2 MSS only.

/* Declare an xWinProperties structure. */
WinProperties_t  xWinProps;

xWinProps.lTxBufSize = 4 * ipconfigTCP_MSS; /* Unit: bytes */
xWinProps.lTxWinSize = 2;                   /* Unit: MSS */
xWinProps.lRxBufSize = 4 * ipconfigTCP_MSS; /* Unit: bytes */
xWinProps.lRxWinSize = 2;                   /* Unit: MSS */

FreeRTOS_setsockopt( xSocket,
                     0,
                     FREERTOS_SO_WIN_PROPERTIES,
                     ( void * ) &xWinProps,
                     sizeof( xWinProps ) );

In this example, the buffers are larger than the WIN, which is very good.

“Emergency break”: when a segment has been sent 4 times without being acknowledged, the library will decide to use a smaller WIN, at most 2 times MSS. See MAX_TRANSMIT_COUNT_USING_LARGE_WINDOW in FreeRTOS_TCP_WIN.c

In the old days, some ISP’s would offer a very limited capacity. For me that was ideal because I could test the IP-stack in a realistic way: packets were delayed and some would get dropped in either direction, at random.

Today I have broadband internet and when there are “congestion problems”, they have mostly to do with the configuration of WIN sizes and buffers.

1 Like
3

Hello
Thanks for your thourogh answer .
We are planing to use FreeRToS+TCP package. We want to run it as a user space process in our linux SoC.
As for WS - I was refering to window-scale option defined by RFC 7323.
I will be happy to consult you about our Architecture and how it can be ported to FreeRToS+TCP.
BR
Avi N

4

As for WS - I was referring to window-scale option defined by RFC 7323.

Sorry yes, the window-scale option is recognised and the library will also advertise a WS option when needed.

5

What about

newReno [RFC 6582]

and Cubic [RFC 8312]

Algorithms ?

6

We chose to use SRTT as described in rfc6298, and no newReno or Cubic.

7

Hello
Regarding the 3 queues you mentioned can u please elaborate:
PriorityQ - I guess this is used fo urgent segements?
Tx Q - is it used fo new and ReTx segements?
WaitQ - what are oustanding segements?

8

When you send out TCP data, the segment will be added to xTxQueue first.

When a packet has timed out, it will move to the xPriorityQueue because it must be resend immediately, either because the timer expired, or because it is a fast retransmit.

When a segment has been sent, it will wait for an ACK while sitting in the xWaitQueue.

So normally, only xTxQueue and xWaitQueue will be used, and xPriorityQueue will always be empty.