From: "Vincent, Pradeep" <pradeepv@amazon•com>
To: Andi Kleen <andi@firstfloor•org>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>
Subject: Re: UDP Fragmentation and DF bit..
Date: Thu, 27 May 2010 14:58:07 -0700 [thread overview]
Message-ID: <C82438FF.170E9%pradeepv@amazon.com> (raw)
In-Reply-To: <87bpc11xyw.fsf@basil.nowhere.org>
Thanks Andi.
> 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.
Example Setup: One part of the network supports MTU-big and another part of
the network supports MTU-small. The NIC interfaces are configured with MTU
corresponding to the part of the network they are connected to.
When a host in MTU-big part of the network sends a packet to a host in
MTU-small part of the network, the router bordering these two sections of
the network sends ICMP messages to the host in MTU-big section of the
network to enable PMTU discovery.
Everything works great for TCP. UDP's PMTU discovery seems to be available
for some datagram sizes ( size < MTU-big) but not otherwise.
>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.
Is there a reason kernel can't learn the PMTU using ICMP messages generated
due to large size fragments with DF=1 ?
>But if the app supports pmtu discovery it's better
> to not use fragments in the first place.
Absolutely.
Thanks,
- Pradeep Vincent
On 5/27/10 2:43 AM, "Andi Kleen" <andi@firstfloor•org> wrote:
> "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.
> --
> 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
>
prev parent reply other threads:[~2010-05-27 21:58 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
2010-05-27 21:58 ` Vincent, Pradeep [this message]
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=C82438FF.170E9%pradeepv@amazon.com \
--to=pradeepv@amazon$(echo .)com \
--cc=andi@firstfloor$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox