* discrepancy in ip(7) wrt. IP DF flag for UDP sockets
@ 2011-09-19 12:19 Benjamin Poirier
[not found] ` <20110919121940.GA19942-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Poirier @ 2011-09-19 12:19 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Hi,
I noticed what appears to be a discrepancy between the ip(7) man page
and the kernel code with regards to the IP DF flag for UDP sockets.
The man page says that "The don't-fragment flag is set on all outgoing
datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
sockets. This is quickly disproved by doing:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
firing up netcat and looking at a few outgoing udp packets in wireshark
(they don't have the DF flag set).
1) in the words of `man 7 ip`:
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket.
When enabled, Linux will perform Path MTU Discovery as defined
in RFC 1191 on this socket. The don't-fragment flag is set on
all outgoing datagrams. The system-wide default is controlled
by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
sockets, and disabled on all others.
This is the text present in the latest version of the online manpages,
http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
2) in net/ipv4/af_inet.c:inet_create():
if (ipv4_config.no_pmtu_disc)
inet->pmtudisc = IP_PMTUDISC_DONT;
else
inet->pmtudisc = IP_PMTUDISC_WANT;
and pmtudisc is left alone from there on for UDP sockets.
What should be adjusted, the man page or the code?
Thanks,
-Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <20110919121940.GA19942-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
@ 2011-09-19 13:03 ` Neil Horman
[not found] ` <20110919130313.GA27819-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Neil Horman @ 2011-09-19 13:03 UTC (permalink / raw)
To: Benjamin Poirier
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> Hi,
>
> I noticed what appears to be a discrepancy between the ip(7) man page
> and the kernel code with regards to the IP DF flag for UDP sockets.
>
> The man page says that "The don't-fragment flag is set on all outgoing
> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> sockets. This is quickly disproved by doing:
> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> firing up netcat and looking at a few outgoing udp packets in wireshark
> (they don't have the DF flag set).
>
> 1) in the words of `man 7 ip`:
> IP_MTU_DISCOVER (since Linux 2.2)
> Set or receive the Path MTU Discovery setting for a socket.
> When enabled, Linux will perform Path MTU Discovery as defined
> in RFC 1191 on this socket. The don't-fragment flag is set on
> all outgoing datagrams. The system-wide default is controlled
> by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
> sockets, and disabled on all others.
>
> This is the text present in the latest version of the online manpages,
> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
>
> 2) in net/ipv4/af_inet.c:inet_create():
> if (ipv4_config.no_pmtu_disc)
> inet->pmtudisc = IP_PMTUDISC_DONT;
> else
> inet->pmtudisc = IP_PMTUDISC_WANT;
>
> and pmtudisc is left alone from there on for UDP sockets.
>
> What should be adjusted, the man page or the code?
>
The man page is wrong I think
By my read, the code:
1) Affects UDP and TCP the same way (which makes sense to me)
2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
means the stack should be free to fragment a frame as it sees fit according to
the MTU metric of the route its traversing, hence the cleared DF bit in the
fraem.
RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
default value at creation shouldn't apply as well.
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <20110919130313.GA27819-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
@ 2011-09-20 6:14 ` Michael Kerrisk
[not found] ` <CAKgNAkgWRdkxgTXNnMi4PVGGsOd-8EHF1siBrk-Bj=rnYenVmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Michael Kerrisk @ 2011-09-20 6:14 UTC (permalink / raw)
To: Neil Horman
Cc: Benjamin Poirier, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Hello Benjamin, Neil,
On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
>> Hi,
>>
>> I noticed what appears to be a discrepancy between the ip(7) man page
>> and the kernel code with regards to the IP DF flag for UDP sockets.
>>
>> The man page says that "The don't-fragment flag is set on all outgoing
>> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
>> sockets. This is quickly disproved by doing:
>> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
>> firing up netcat and looking at a few outgoing udp packets in wireshark
>> (they don't have the DF flag set).
Could you describe the required change in terms of how the man page
text should look--i.e., rewrite the passage as you think it should
look?
Thanks,
Michael
>> 1) in the words of `man 7 ip`:
>> IP_MTU_DISCOVER (since Linux 2.2)
>> Set or receive the Path MTU Discovery setting for a socket.
>> When enabled, Linux will perform Path MTU Discovery as defined
>> in RFC 1191 on this socket. The don't-fragment flag is set on
>> all outgoing datagrams. The system-wide default is controlled
>> by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
>> sockets, and disabled on all others.
>>
>> This is the text present in the latest version of the online manpages,
>> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
>>
>> 2) in net/ipv4/af_inet.c:inet_create():
>> if (ipv4_config.no_pmtu_disc)
>> inet->pmtudisc = IP_PMTUDISC_DONT;
>> else
>> inet->pmtudisc = IP_PMTUDISC_WANT;
>>
>> and pmtudisc is left alone from there on for UDP sockets.
>>
>> What should be adjusted, the man page or the code?
>>
> The man page is wrong I think
>
> By my read, the code:
> 1) Affects UDP and TCP the same way (which makes sense to me)
>
> 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> means the stack should be free to fragment a frame as it sees fit according to
> the MTU metric of the route its traversing, hence the cleared DF bit in the
> fraem.
>
> RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> default value at creation shouldn't apply as well.
> Neil
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <CAKgNAkgWRdkxgTXNnMi4PVGGsOd-8EHF1siBrk-Bj=rnYenVmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-09-20 13:29 ` Benjamin Poirier
[not found] ` <20110920132954.GA23041-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Poirier @ 2011-09-20 13:29 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Neil Horman, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
On 11-09-20 08:14, Michael Kerrisk wrote:
> Hello Benjamin, Neil,
>
> On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> > On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> >> Hi,
> >>
> >> I noticed what appears to be a discrepancy between the ip(7) man page
> >> and the kernel code with regards to the IP DF flag for UDP sockets.
> >>
> >> The man page says that "The don't-fragment flag is set on all outgoing
> >> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> >> sockets. This is quickly disproved by doing:
> >> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> >> firing up netcat and looking at a few outgoing udp packets in wireshark
> >> (they don't have the DF flag set).
>
> Could you describe the required change in terms of how the man page
> text should look--i.e., rewrite the passage as you think it should
> look?
How about changing it to:
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket. When
enabled, the don't-fragment flag is set on all outgoing packets.
Linux will perform Path MTU Discovery as defined in RFC 1191 on
SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
user's responsibility to packetize the data in MTU sized chunks
and to do the retransmits if necessary. The kernel will reject
(with EMSGSIZE) datagrams that are bigger than the known path
MTU. The system-wide default is controlled by the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.
Path MTU discovery flags Meaning
[...]
There are some differences between _DO and _WANT that are glossed over
in this description, but I suppose there's only so much detail you can
put in...
Thanks,
-Ben
>
> Thanks,
>
> Michael
>
>
> >> 1) in the words of `man 7 ip`:
> >> IP_MTU_DISCOVER (since Linux 2.2)
> >> Set or receive the Path MTU Discovery setting for a socket.
> >> When enabled, Linux will perform Path MTU Discovery as defined
> >> in RFC 1191 on this socket. The don't-fragment flag is set on
> >> all outgoing datagrams. The system-wide default is controlled
> >> by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
> >> sockets, and disabled on all others.
> >>
> >> This is the text present in the latest version of the online manpages,
> >> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
> >>
> >> 2) in net/ipv4/af_inet.c:inet_create():
> >> if (ipv4_config.no_pmtu_disc)
> >> inet->pmtudisc = IP_PMTUDISC_DONT;
> >> else
> >> inet->pmtudisc = IP_PMTUDISC_WANT;
> >>
> >> and pmtudisc is left alone from there on for UDP sockets.
> >>
> >> What should be adjusted, the man page or the code?
> >>
> > The man page is wrong I think
> >
> > By my read, the code:
> > 1) Affects UDP and TCP the same way (which makes sense to me)
> >
> > 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> > means the stack should be free to fragment a frame as it sees fit according to
> > the MTU metric of the route its traversing, hence the cleared DF bit in the
> > fraem.
> >
> > RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> > set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> > offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> > default value at creation shouldn't apply as well.
> > Neil
> >
> >
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <20110920132954.GA23041-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
@ 2011-09-20 13:38 ` Neil Horman
[not found] ` <20110920133837.GA16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Neil Horman @ 2011-09-20 13:38 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Michael Kerrisk, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
> On 11-09-20 08:14, Michael Kerrisk wrote:
> > Hello Benjamin, Neil,
> >
> > On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> > > On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> > >> Hi,
> > >>
> > >> I noticed what appears to be a discrepancy between the ip(7) man page
> > >> and the kernel code with regards to the IP DF flag for UDP sockets.
> > >>
> > >> The man page says that "The don't-fragment flag is set on all outgoing
> > >> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> > >> sockets. This is quickly disproved by doing:
> > >> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> > >> firing up netcat and looking at a few outgoing udp packets in wireshark
> > >> (they don't have the DF flag set).
> >
> > Could you describe the required change in terms of how the man page
> > text should look--i.e., rewrite the passage as you think it should
> > look?
>
> How about changing it to:
> IP_MTU_DISCOVER (since Linux 2.2)
> Set or receive the Path MTU Discovery setting for a socket. When
> enabled, the don't-fragment flag is set on all outgoing packets.
> Linux will perform Path MTU Discovery as defined in RFC 1191 on
> SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
> user's responsibility to packetize the data in MTU sized chunks
> and to do the retransmits if necessary. The kernel will reject
> (with EMSGSIZE) datagrams that are bigger than the known path
> MTU. The system-wide default is controlled by the
> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>
> Path MTU discovery flags Meaning
> [...]
>
> There are some differences between _DO and _WANT that are glossed over
> in this description, but I suppose there's only so much detail you can
> put in...
>
> Thanks,
> -Ben
>
Yeah, I think thats close, but its only the users responsibility to package
datagrams in mtu sized chunks if they force the dont fragment bit on. If they
go wtih the default, the stack will fragment a datagram is it sees fit according
to the mtu of the path it traverses
Neil
> >
> > Thanks,
> >
> > Michael
> >
> >
> > >> 1) in the words of `man 7 ip`:
> > >> IP_MTU_DISCOVER (since Linux 2.2)
> > >> Set or receive the Path MTU Discovery setting for a socket.
> > >> When enabled, Linux will perform Path MTU Discovery as defined
> > >> in RFC 1191 on this socket. The don't-fragment flag is set on
> > >> all outgoing datagrams. The system-wide default is controlled
> > >> by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
> > >> sockets, and disabled on all others.
> > >>
> > >> This is the text present in the latest version of the online manpages,
> > >> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
> > >>
> > >> 2) in net/ipv4/af_inet.c:inet_create():
> > >> if (ipv4_config.no_pmtu_disc)
> > >> inet->pmtudisc = IP_PMTUDISC_DONT;
> > >> else
> > >> inet->pmtudisc = IP_PMTUDISC_WANT;
> > >>
> > >> and pmtudisc is left alone from there on for UDP sockets.
> > >>
> > >> What should be adjusted, the man page or the code?
> > >>
> > > The man page is wrong I think
> > >
> > > By my read, the code:
> > > 1) Affects UDP and TCP the same way (which makes sense to me)
> > >
> > > 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> > > means the stack should be free to fragment a frame as it sees fit according to
> > > the MTU metric of the route its traversing, hence the cleared DF bit in the
> > > fraem.
> > >
> > > RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> > > set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> > > offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> > > default value at creation shouldn't apply as well.
> > > Neil
> > >
> > >
> >
> >
> >
> > --
> > Michael Kerrisk
> > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> > Author of "The Linux Programming Interface"; http://man7.org/tlpi/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <20110920133837.GA16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
@ 2011-09-20 14:12 ` Benjamin Poirier
[not found] ` <20110920141234.GA23164-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Poirier @ 2011-09-20 14:12 UTC (permalink / raw)
To: Neil Horman
Cc: Michael Kerrisk, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
On 11-09-20 09:38, Neil Horman wrote:
> On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
> > On 11-09-20 08:14, Michael Kerrisk wrote:
> > > Hello Benjamin, Neil,
> > >
[snip]
> > >
> > > Could you describe the required change in terms of how the man page
> > > text should look--i.e., rewrite the passage as you think it should
> > > look?
> >
> > How about changing it to:
> > IP_MTU_DISCOVER (since Linux 2.2)
> > Set or receive the Path MTU Discovery setting for a socket. When
> > enabled, the don't-fragment flag is set on all outgoing packets.
> > Linux will perform Path MTU Discovery as defined in RFC 1191 on
> > SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
> > user's responsibility to packetize the data in MTU sized chunks
> > and to do the retransmits if necessary. The kernel will reject
> > (with EMSGSIZE) datagrams that are bigger than the known path
> > MTU. The system-wide default is controlled by the
> > /proc/sys/net/ipv4/ip_no_pmtu_disc file.
> >
> > Path MTU discovery flags Meaning
> > [...]
> >
> > There are some differences between _DO and _WANT that are glossed over
> > in this description, but I suppose there's only so much detail you can
> > put in...
> >
> > Thanks,
> > -Ben
> >
> Yeah, I think thats close, but its only the users responsibility to package
> datagrams in mtu sized chunks if they force the dont fragment bit on. If they
> go wtih the default, the stack will fragment a datagram is it sees fit according
> to the mtu of the path it traverses
Exactly. To get into this level of detail, I think we have to mention
the option value, not just enabled/disabled. Let's try like this:
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket. When
enabled, Linux will perform Path MTU Discovery as defined in RFC
1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets,
IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
outgoing packets. It is the user's responsibility to packetize
the data in MTU sized chunks and to do the retransmits if
necessary. The kernel will reject (with EMSGSIZE) datagrams
that are bigger than the known path MTU. IP_PMTUDISC_WANT will
fragment a datagram if needed according to the path MTU or will
set the don't-fragment flag otherwise.
The system-wide default can be toggled between IP_PMTUDISC_WANT
and IP_PMTUDISC_DONT by writting to the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <20110920141234.GA23164-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
@ 2011-09-20 14:31 ` Neil Horman
[not found] ` <20110920143109.GB16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Neil Horman @ 2011-09-20 14:31 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Michael Kerrisk, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
On Tue, Sep 20, 2011 at 10:12:34AM -0400, Benjamin Poirier wrote:
> On 11-09-20 09:38, Neil Horman wrote:
> > On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
> > > On 11-09-20 08:14, Michael Kerrisk wrote:
> > > > Hello Benjamin, Neil,
> > > >
> [snip]
> > > >
> > > > Could you describe the required change in terms of how the man page
> > > > text should look--i.e., rewrite the passage as you think it should
> > > > look?
> > >
> > > How about changing it to:
> > > IP_MTU_DISCOVER (since Linux 2.2)
> > > Set or receive the Path MTU Discovery setting for a socket. When
> > > enabled, the don't-fragment flag is set on all outgoing packets.
> > > Linux will perform Path MTU Discovery as defined in RFC 1191 on
> > > SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
> > > user's responsibility to packetize the data in MTU sized chunks
> > > and to do the retransmits if necessary. The kernel will reject
> > > (with EMSGSIZE) datagrams that are bigger than the known path
> > > MTU. The system-wide default is controlled by the
> > > /proc/sys/net/ipv4/ip_no_pmtu_disc file.
> > >
> > > Path MTU discovery flags Meaning
> > > [...]
> > >
> > > There are some differences between _DO and _WANT that are glossed over
> > > in this description, but I suppose there's only so much detail you can
> > > put in...
> > >
> > > Thanks,
> > > -Ben
> > >
> > Yeah, I think thats close, but its only the users responsibility to package
> > datagrams in mtu sized chunks if they force the dont fragment bit on. If they
> > go wtih the default, the stack will fragment a datagram is it sees fit according
> > to the mtu of the path it traverses
>
> Exactly. To get into this level of detail, I think we have to mention
> the option value, not just enabled/disabled. Let's try like this:
>
> IP_MTU_DISCOVER (since Linux 2.2)
> Set or receive the Path MTU Discovery setting for a socket. When
> enabled, Linux will perform Path MTU Discovery as defined in RFC
> 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets,
> IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
> outgoing packets. It is the user's responsibility to packetize
> the data in MTU sized chunks and to do the retransmits if
> necessary. The kernel will reject (with EMSGSIZE) datagrams
> that are bigger than the known path MTU. IP_PMTUDISC_WANT will
> fragment a datagram if needed according to the path MTU or will
> set the don't-fragment flag otherwise.
>
> The system-wide default can be toggled between IP_PMTUDISC_WANT
> and IP_PMTUDISC_DONT by writting to the
> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>
Yes, that sounds good to me. Thanks for doing this!
Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <20110920143109.GB16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
@ 2011-09-22 4:15 ` Michael Kerrisk
[not found] ` <CAKgNAkiSrGdXd2e1dpcC0fPmARRwkMrUvB8vCJ7eQ8SYsCuuUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Michael Kerrisk @ 2011-09-22 4:15 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Neil Horman, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Ben, Neil,
On Tue, Sep 20, 2011 at 4:31 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> On Tue, Sep 20, 2011 at 10:12:34AM -0400, Benjamin Poirier wrote:
>> On 11-09-20 09:38, Neil Horman wrote:
>> > On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
>> > > On 11-09-20 08:14, Michael Kerrisk wrote:
>> > > > Hello Benjamin, Neil,
>> > > >
>> [snip]
>> > > >
>> > > > Could you describe the required change in terms of how the man page
>> > > > text should look--i.e., rewrite the passage as you think it should
>> > > > look?
>> > >
>> > > How about changing it to:
>> > > IP_MTU_DISCOVER (since Linux 2.2)
>> > > Set or receive the Path MTU Discovery setting for a socket. When
>> > > enabled, the don't-fragment flag is set on all outgoing packets.
>> > > Linux will perform Path MTU Discovery as defined in RFC 1191 on
>> > > SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
>> > > user's responsibility to packetize the data in MTU sized chunks
>> > > and to do the retransmits if necessary. The kernel will reject
>> > > (with EMSGSIZE) datagrams that are bigger than the known path
>> > > MTU. The system-wide default is controlled by the
>> > > /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>> > >
>> > > Path MTU discovery flags Meaning
>> > > [...]
>> > >
>> > > There are some differences between _DO and _WANT that are glossed over
>> > > in this description, but I suppose there's only so much detail you can
>> > > put in...
>> > >
>> > > Thanks,
>> > > -Ben
>> > >
>> > Yeah, I think thats close, but its only the users responsibility to package
>> > datagrams in mtu sized chunks if they force the dont fragment bit on. If they
>> > go wtih the default, the stack will fragment a datagram is it sees fit according
>> > to the mtu of the path it traverses
>>
>> Exactly. To get into this level of detail, I think we have to mention
>> the option value, not just enabled/disabled. Let's try like this:
>>
>> IP_MTU_DISCOVER (since Linux 2.2)
>> Set or receive the Path MTU Discovery setting for a socket. When
>> enabled, Linux will perform Path MTU Discovery as defined in RFC
>> 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets,
>> IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
>> outgoing packets. It is the user's responsibility to packetize
>> the data in MTU sized chunks and to do the retransmits if
>> necessary. The kernel will reject (with EMSGSIZE) datagrams
>> that are bigger than the known path MTU. IP_PMTUDISC_WANT will
>> fragment a datagram if needed according to the path MTU or will
>> set the don't-fragment flag otherwise.
>>
>> The system-wide default can be toggled between IP_PMTUDISC_WANT
>> and IP_PMTUDISC_DONT by writting to the
>> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>>
> Yes, that sounds good to me. Thanks for doing this!
> Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
applied that change for man-pages-3.34.
Ben, I added one small piece ti the description of
/proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
the entire text below. Perhaps you could take a quick scan, to make
sure that the changed text is consistent with the whole piece.
Thanks,
Michael
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a
socket. When enabled, Linux will perform Path MTU Dis-
covery as defined in RFC 1191 on SOCK_STREAM sockets.
For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the
don't-fragment flag to be set on all outgoing packets.
The don't-fragment flag is set on all outgoing data-
grams. It is the user's responsibility to packetize the
data in MTU-sized chunks and to do the retransmits if
necessary. The kernel will reject (with EMSGSIZE) data-
grams that are bigger than the known path MTU.
IP_PMTUDISC_WANT will fragment a datagram if needed
according to the path MTU, or will set the don't-frag-
ment flag otherwise.
The system-wide default can be toggled between IP_PMTUD-
ISC_WANT and IP_PMTUDISC_DONT by writing (respectively,
zero and nonzero values) to the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.
Path MTU discovery flags Meaning
IP_PMTUDISC_WANT Use per-route settings.
IP_PMTUDISC_DONT Never do Path MTU Discovery.
IP_PMTUDISC_DO Always do Path MTU Discovery.
IP_PMTUDISC_PROBE Set DF but ignore Path MTU.
When PMTU discovery is enabled, the kernel automatically
keeps track of the path MTU per destination host. When
it is connected to a specific peer with connect(2), the
currently known path MTU can be retrieved conveniently
using the IP_MTU socket option (e.g., after an EMSGSIZE
error occurred). The path MTU may change over time.
For connectionless sockets with many destinations, the
new MTU for a given destination can also be accessed
using the error queue (see IP_RECVERR). A new error
will be queued for every incoming MTU update.
While MTU discovery is in progress, initial packets from
datagram sockets may be dropped. Applications using UDP
should be aware of this and not take it into account for
their packet retransmit strategy.
To bootstrap the path MTU discovery process on uncon-
nected sockets, it is possible to start with a big data-
gram size (up to 64K-headers bytes long) and let it
shrink by updates of the path MTU.
To get an initial estimate of the path MTU, connect a
datagram socket to the destination address using con-
nect(2) and retrieve the MTU by calling getsockopt(2)
with the IP_MTU option.
It is possible to implement RFC 4821 MTU probing with
SOCK_DGRAM or SOCK_RAW sockets by setting a value of
IP_PMTUDISC_PROBE (available since Linux 2.6.22). This
is also particularly useful for diagnostic tools such as
tracepath(8) that wish to deliberately send probe pack-
ets larger than the observed Path MTU.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <CAKgNAkiSrGdXd2e1dpcC0fPmARRwkMrUvB8vCJ7eQ8SYsCuuUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-09-22 10:48 ` Neil Horman
2011-09-22 12:44 ` Benjamin Poirier
1 sibling, 0 replies; 11+ messages in thread
From: Neil Horman @ 2011-09-22 10:48 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Benjamin Poirier, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
On Thu, Sep 22, 2011 at 06:15:53AM +0200, Michael Kerrisk wrote:
> Ben, Neil,
>
> On Tue, Sep 20, 2011 at 4:31 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> > On Tue, Sep 20, 2011 at 10:12:34AM -0400, Benjamin Poirier wrote:
> >> On 11-09-20 09:38, Neil Horman wrote:
> >> > On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
> >> > > On 11-09-20 08:14, Michael Kerrisk wrote:
> >> > > > Hello Benjamin, Neil,
> >> > > >
> >> [snip]
> >> > > >
> >> > > > Could you describe the required change in terms of how the man page
> >> > > > text should look--i.e., rewrite the passage as you think it should
> >> > > > look?
> >> > >
> >> > > How about changing it to:
> >> > > IP_MTU_DISCOVER (since Linux 2.2)
> >> > > Set or receive the Path MTU Discovery setting for a socket. When
> >> > > enabled, the don't-fragment flag is set on all outgoing packets.
> >> > > Linux will perform Path MTU Discovery as defined in RFC 1191 on
> >> > > SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
> >> > > user's responsibility to packetize the data in MTU sized chunks
> >> > > and to do the retransmits if necessary. The kernel will reject
> >> > > (with EMSGSIZE) datagrams that are bigger than the known path
> >> > > MTU. The system-wide default is controlled by the
> >> > > /proc/sys/net/ipv4/ip_no_pmtu_disc file.
> >> > >
> >> > > Path MTU discovery flags Meaning
> >> > > [...]
> >> > >
> >> > > There are some differences between _DO and _WANT that are glossed over
> >> > > in this description, but I suppose there's only so much detail you can
> >> > > put in...
> >> > >
> >> > > Thanks,
> >> > > -Ben
> >> > >
> >> > Yeah, I think thats close, but its only the users responsibility to package
> >> > datagrams in mtu sized chunks if they force the dont fragment bit on. If they
> >> > go wtih the default, the stack will fragment a datagram is it sees fit according
> >> > to the mtu of the path it traverses
> >>
> >> Exactly. To get into this level of detail, I think we have to mention
> >> the option value, not just enabled/disabled. Let's try like this:
> >>
> >> IP_MTU_DISCOVER (since Linux 2.2)
> >> Set or receive the Path MTU Discovery setting for a socket. When
> >> enabled, Linux will perform Path MTU Discovery as defined in RFC
> >> 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets,
> >> IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
> >> outgoing packets. It is the user's responsibility to packetize
> >> the data in MTU sized chunks and to do the retransmits if
> >> necessary. The kernel will reject (with EMSGSIZE) datagrams
> >> that are bigger than the known path MTU. IP_PMTUDISC_WANT will
> >> fragment a datagram if needed according to the path MTU or will
> >> set the don't-fragment flag otherwise.
> >>
> >> The system-wide default can be toggled between IP_PMTUDISC_WANT
> >> and IP_PMTUDISC_DONT by writting to the
> >> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
> >>
> > Yes, that sounds good to me. Thanks for doing this!
> > Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
>
> Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
> applied that change for man-pages-3.34.
>
> Ben, I added one small piece ti the description of
> /proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
> the entire text below. Perhaps you could take a quick scan, to make
> sure that the changed text is consistent with the whole piece.
>
This looks good to me. A minor nit in the chunk you added thoguh. Calling the
MTU discovery value 'flags' suggests they can be or-together, or somehow
otherwise combined, which is non-sensical. It may be better to use the term
values rather than flags.
Other than that
Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Thanks!
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
[not found] ` <CAKgNAkiSrGdXd2e1dpcC0fPmARRwkMrUvB8vCJ7eQ8SYsCuuUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-22 10:48 ` Neil Horman
@ 2011-09-22 12:44 ` Benjamin Poirier
2011-09-23 5:27 ` Michael Kerrisk
1 sibling, 1 reply; 11+ messages in thread
From: Benjamin Poirier @ 2011-09-22 12:44 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Neil Horman, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
On 11-09-22 06:15, Michael Kerrisk wrote:
> Ben, Neil,
>
[snip]
>
> Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
> applied that change for man-pages-3.34.
>
> Ben, I added one small piece ti the description of
> /proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
> the entire text below. Perhaps you could take a quick scan, to make
> sure that the changed text is consistent with the whole piece.
>
> Thanks,
>
> Michael
>
> IP_MTU_DISCOVER (since Linux 2.2)
> Set or receive the Path MTU Discovery setting for a
> socket. When enabled, Linux will perform Path MTU Dis-
> covery as defined in RFC 1191 on SOCK_STREAM sockets.
Oops, seems like there's a repetition that crept in here. I'd keep only
the first of those two sentences:
> For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the
> don't-fragment flag to be set on all outgoing packets.
> The don't-fragment flag is set on all outgoing data-
> grams. It is the user's responsibility to packetize the
> data in MTU-sized chunks and to do the retransmits if
> necessary. The kernel will reject (with EMSGSIZE) data-
> grams that are bigger than the known path MTU.
> IP_PMTUDISC_WANT will fragment a datagram if needed
> according to the path MTU, or will set the don't-frag-
> ment flag otherwise.
>
> The system-wide default can be toggled between IP_PMTUD-
> ISC_WANT and IP_PMTUDISC_DONT by writing (respectively,
> zero and nonzero values) to the
> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
I think it's a welcome clarification. Is is normal that IP_PMTUDISC_WANT
gets hyphenated?
>
> Path MTU discovery flags Meaning
I agree with what Neil said about "flags" here. setsockopt(2) calls
these "option values".
Other than that, LGTM
Acked-by: Benjamin Poirier <benjamin.poirier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks Michael,
-Ben
> IP_PMTUDISC_WANT Use per-route settings.
> IP_PMTUDISC_DONT Never do Path MTU Discovery.
> IP_PMTUDISC_DO Always do Path MTU Discovery.
> IP_PMTUDISC_PROBE Set DF but ignore Path MTU.
>
> When PMTU discovery is enabled, the kernel automatically
> keeps track of the path MTU per destination host. When
> it is connected to a specific peer with connect(2), the
> currently known path MTU can be retrieved conveniently
> using the IP_MTU socket option (e.g., after an EMSGSIZE
> error occurred). The path MTU may change over time.
> For connectionless sockets with many destinations, the
> new MTU for a given destination can also be accessed
> using the error queue (see IP_RECVERR). A new error
> will be queued for every incoming MTU update.
>
> While MTU discovery is in progress, initial packets from
> datagram sockets may be dropped. Applications using UDP
> should be aware of this and not take it into account for
> their packet retransmit strategy.
>
> To bootstrap the path MTU discovery process on uncon-
> nected sockets, it is possible to start with a big data-
> gram size (up to 64K-headers bytes long) and let it
> shrink by updates of the path MTU.
>
> To get an initial estimate of the path MTU, connect a
> datagram socket to the destination address using con-
> nect(2) and retrieve the MTU by calling getsockopt(2)
> with the IP_MTU option.
>
> It is possible to implement RFC 4821 MTU probing with
> SOCK_DGRAM or SOCK_RAW sockets by setting a value of
> IP_PMTUDISC_PROBE (available since Linux 2.6.22). This
> is also particularly useful for diagnostic tools such as
> tracepath(8) that wish to deliberately send probe pack-
> ets larger than the observed Path MTU.
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
2011-09-22 12:44 ` Benjamin Poirier
@ 2011-09-23 5:27 ` Michael Kerrisk
0 siblings, 0 replies; 11+ messages in thread
From: Michael Kerrisk @ 2011-09-23 5:27 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Neil Horman, linux-man, netdev
HI Ben, Neil,
On Thu, Sep 22, 2011 at 2:44 PM, Benjamin Poirier
<benjamin.poirier@gmail.com> wrote:
> On 11-09-22 06:15, Michael Kerrisk wrote:
>> Ben, Neil,
>>
> [snip]
>>
>> Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
>> applied that change for man-pages-3.34.
>>
>> Ben, I added one small piece ti the description of
>> /proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
>> the entire text below. Perhaps you could take a quick scan, to make
>> sure that the changed text is consistent with the whole piece.
>>
>> Thanks,
>>
>> Michael
>>
>> IP_MTU_DISCOVER (since Linux 2.2)
>> Set or receive the Path MTU Discovery setting for a
>> socket. When enabled, Linux will perform Path MTU Dis-
>> covery as defined in RFC 1191 on SOCK_STREAM sockets.
>
> Oops, seems like there's a repetition that crept in here. I'd keep only
> the first of those two sentences:
>> For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the
>> don't-fragment flag to be set on all outgoing packets.
>> The don't-fragment flag is set on all outgoing data-
>> grams.
Thanks for catching that! The second of the above sentences is now gone.
>> It is the user's responsibility to packetize the
>> data in MTU-sized chunks and to do the retransmits if
>> necessary. The kernel will reject (with EMSGSIZE) data-
>> grams that are bigger than the known path MTU.
>> IP_PMTUDISC_WANT will fragment a datagram if needed
>> according to the path MTU, or will set the don't-frag-
>> ment flag otherwise.
>>
>> The system-wide default can be toggled between IP_PMTUD-
>> ISC_WANT and IP_PMTUDISC_DONT by writing (respectively,
>> zero and nonzero values) to the
>> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>
> I think it's a welcome clarification. Is is normal that IP_PMTUDISC_WANT
> gets hyphenated?
That's just an artifact of groff formatting. One can prevent it, but
then the text justification of some lines starts to look very weird.
>> Path MTU discovery flags Meaning
>
> I agree with what Neil said about "flags" here. setsockopt(2) calls
> these "option values".
Changed this to just "value".
> Other than that, LGTM
> Acked-by: Benjamin Poirier <benjamin.poirier@gmail.com>
>
> Thanks Michael,
> -Ben
You're welcome. Thanks for taking the time to write the text and check my work.
Cheers,
Michael
>> IP_PMTUDISC_WANT Use per-route settings.
>> IP_PMTUDISC_DONT Never do Path MTU Discovery.
>> IP_PMTUDISC_DO Always do Path MTU Discovery.
>> IP_PMTUDISC_PROBE Set DF but ignore Path MTU.
>>
>> When PMTU discovery is enabled, the kernel automatically
>> keeps track of the path MTU per destination host. When
>> it is connected to a specific peer with connect(2), the
>> currently known path MTU can be retrieved conveniently
>> using the IP_MTU socket option (e.g., after an EMSGSIZE
>> error occurred). The path MTU may change over time.
>> For connectionless sockets with many destinations, the
>> new MTU for a given destination can also be accessed
>> using the error queue (see IP_RECVERR). A new error
>> will be queued for every incoming MTU update.
>>
>> While MTU discovery is in progress, initial packets from
>> datagram sockets may be dropped. Applications using UDP
>> should be aware of this and not take it into account for
>> their packet retransmit strategy.
>>
>> To bootstrap the path MTU discovery process on uncon-
>> nected sockets, it is possible to start with a big data-
>> gram size (up to 64K-headers bytes long) and let it
>> shrink by updates of the path MTU.
>>
>> To get an initial estimate of the path MTU, connect a
>> datagram socket to the destination address using con-
>> nect(2) and retrieve the MTU by calling getsockopt(2)
>> with the IP_MTU option.
>>
>> It is possible to implement RFC 4821 MTU probing with
>> SOCK_DGRAM or SOCK_RAW sockets by setting a value of
>> IP_PMTUDISC_PROBE (available since Linux 2.6.22). This
>> is also particularly useful for diagnostic tools such as
>> tracepath(8) that wish to deliberately send probe pack-
>> ets larger than the observed Path MTU.
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-09-23 5:27 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-19 12:19 discrepancy in ip(7) wrt. IP DF flag for UDP sockets Benjamin Poirier
[not found] ` <20110919121940.GA19942-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
2011-09-19 13:03 ` Neil Horman
[not found] ` <20110919130313.GA27819-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2011-09-20 6:14 ` Michael Kerrisk
[not found] ` <CAKgNAkgWRdkxgTXNnMi4PVGGsOd-8EHF1siBrk-Bj=rnYenVmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-20 13:29 ` Benjamin Poirier
[not found] ` <20110920132954.GA23041-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
2011-09-20 13:38 ` Neil Horman
[not found] ` <20110920133837.GA16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2011-09-20 14:12 ` Benjamin Poirier
[not found] ` <20110920141234.GA23164-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
2011-09-20 14:31 ` Neil Horman
[not found] ` <20110920143109.GB16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2011-09-22 4:15 ` Michael Kerrisk
[not found] ` <CAKgNAkiSrGdXd2e1dpcC0fPmARRwkMrUvB8vCJ7eQ8SYsCuuUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-22 10:48 ` Neil Horman
2011-09-22 12:44 ` Benjamin Poirier
2011-09-23 5:27 ` Michael Kerrisk
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.