tcp_mtu_probe implementation details

tcp_mtu_probe implementation details

[Anatoly Sivov]

Hi all,

Looking on TCP implementation in Linux I see that there are some things
that I don't understand in tcp_mtu_probe() implementation.
Could someone clear them for me or share the link to Linux PMTUD
documentation, please?
The first thing I don't understand is tp->snd_cwnd < 11 in
if (!icsk->icsk_mtup.enabled ||
             icsk->icsk_mtup.probe_size ||
             inet_csk(sk)->icsk_ca_state != TCP_CA_Open ||
             tp->snd_cwnd < 11 ||
             tp->rx_opt.num_sacks || tp->rx_opt.dsack)
                 return -1;
What is magic number "11" here?
The other question is about size_needed variable.
It is assigned to value probe_size + (tp->reordering + 1) * tp->mss_cache
And that is not clear for me.
What is this "(tp->reordering + 1) * tp->mss_cache" addition?

Thanks.

Re: tcp_mtu_probe implementation details

[Vijay Subramanian]

> The other question is about size_needed variable.
> It is assigned to value probe_size + (tp->reordering + 1) * tp->mss_cache
> And that is not clear for me.
> What is this "(tp->reordering + 1) * tp->mss_cache" addition?
>

I think the idea is that you want enough bytes in the write_queue so
that even if the probe is lost, the sender will get an ack even if
there is reordering in the network. Without sufficient bytes, the
probe will not be sent. This is what I make of the code but I could be
wrong.

Regards,
Vijay

Re: tcp_mtu_probe implementation details

[Anatoly Sivov]

Hello Vijay,

Thank you for your response.

>> The other question is about size_needed variable.
>> It is assigned to value probe_size + (tp->reordering + 1) *  
>> tp->mss_cache
>> And that is not clear for me.
>> What is this "(tp->reordering + 1) * tp->mss_cache" addition?
>>
>
> I think the idea is that you want enough bytes in the write_queue so
> that even if the probe is lost, the sender will get an ack even if
> there is reordering in the network. Without sufficient bytes, the
> probe will not be sent. This is what I make of the code but I could be
> wrong.

I believe, I found the explanation of this addition in RFC 4821:
   "TCP Fast Retransmit is not robust unless there are
    sufficient segments following a probe; that is, the sender SHOULD
    have enough data queued and sufficient receiver window to send the
    probe plus at least Tcprexmtthresh [RFC2760] additional segments."

However, I'm still confused with magic number 11 in "tp->snd_cwnd < 11"  
check.

Thanks.

Re: tcp_mtu_probe implementation details

[John Heffner]

TCP doesn't operate as well with a small window, and below some point
there isn't really a justification for increasing the MTU size.  11 is
something of a magic number, but here's the reasoning:

A cwnd of 11 pre-probe will result in a cwnd of 6 after a successful
probe.  (By the time the probe succeeds, cwnd will have been increased
to 12, then doubling MSS will halve cwnd to 6.)  A window size smaller
than this makes TCP more vulnerable to double loss events and
increases the likeliness of timeouts.

  -John


2011/12/21 Anatoly Sivov <mm05@mail.ru>:
> Hello Vijay,
>
> Thank you for your response.
>
>
>>> The other question is about size_needed variable.
>>> It is assigned to value probe_size + (tp->reordering + 1) * tp->mss_cache
>>> And that is not clear for me.
>>> What is this "(tp->reordering + 1) * tp->mss_cache" addition?
>>>
>>
>> I think the idea is that you want enough bytes in the write_queue so
>> that even if the probe is lost, the sender will get an ack even if
>> there is reordering in the network. Without sufficient bytes, the
>> probe will not be sent. This is what I make of the code but I could be
>> wrong.
>
>
> I believe, I found the explanation of this addition in RFC 4821:
>  "TCP Fast Retransmit is not robust unless there are
>   sufficient segments following a probe; that is, the sender SHOULD
>   have enough data queued and sufficient receiver window to send the
>   probe plus at least Tcprexmtthresh [RFC2760] additional segments."
>
> However, I'm still confused with magic number 11 in "tp->snd_cwnd < 11"
> check.
>
> Thanks.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tcp_mtu_probe implementation details

[Anatoly Sivov]

Hello John,

Thanks for clarifications.

> A cwnd of 11 pre-probe will result in a cwnd of 6 after a successful
> probe.  (By the time the probe succeeds, cwnd will have been increased
> to 12, then doubling MSS will halve cwnd to 6.)  A window size smaller
> than this makes TCP more vulnerable to double loss events and
> increases the likeliness of timeouts.

Perhaps, it's worth of being mentioned in comment inside of tcp_mtu_probe.