From: Andi Kleen <andi@firstfloor.org>
To: "Vincent\, Pradeep" <pradeepv@amazon.com>
Cc: "netdev\@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: UDP Fragmentation and DF bit..
Date: Thu, 27 May 2010 11:43:35 +0200 [thread overview]
Message-ID: <87bpc11xyw.fsf@basil.nowhere.org> (raw)
In-Reply-To: <C8231CDB.16FC5%pradeepv@amazon.com> (Pradeep Vincent's message of "Wed\, 26 May 2010 18\:45\:47 -0700")
"Vincent, Pradeep" <pradeepv@amazon.com> writes:
> OMan 7 ip¹ declares that ³The system-wide default is controlled by the
> ip_no_pmtu_disc sysctl for SOCK_STREAM sockets, and disabled on all
> others.² which led me to think ODF¹ bit will not be set for UDP packets.
> But..
One should add ip.7 is not really a spec, just documentation
how things were quite a few years ago. It unfortunately
does often not get updated when things change.
>
> In a network environment where MTU-big and MTU-small co-exist (and have
> router¹s fragmentation turned off in favor of PMTU discovery), UDP packets
> that are > MTU-small and < MTU-big find the PMTU effectively but UDP
> packets
I don't understand your mtu-small/big concept. PMTU is per IP and per
flow. So there's only always a single PMTU, not small and big.
Or do you refer to a single IP NAT situation where a single IP
shares different MTUs?
> Is there a reason ODF¹ bit cannot be set on fragmented packets on UDP
> transmission ? I couldn¹t find anything in RFC for IP protocol that
> prohibited DF bit on fragmented packets. Did I miss
> something here ?
> Would it be reasonable if PMTU discovery is performed (DF bit set +
> appropriate icmp logic) even for locally fragmented packets ? I think
> this
DF=1 on fragments would mean the application has to do pmtu discovery
even with fragments for the case when the kernel does not know
the path mtu yet. But if the app supports pmtu discovery it's better
to not use fragments in the first place.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-05-27 9:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 1:45 UDP Fragmentation and DF bit Vincent, Pradeep
2010-05-27 9:43 ` Andi Kleen [this message]
2010-05-27 21:58 ` Vincent, Pradeep
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bpc11xyw.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=netdev@vger.kernel.org \
--cc=pradeepv@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.