Subject: Re: The IPv4 Internet MTU

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Oct 2007 13:56:46 +0200

MTU's are real bastard. Especially for UDP applications that rarely has
built in any support for handling MTU discovery if the ICMP doesn't
work. Which it clearly do not do. The worst is that each
application/protocol needs to support MTU handling by itself.

At least for TCP we at least have a solution that can be gradually
deployed in RFC 4821 "Packetization Layer Path MTU Discovery" that
doesn't rely on ICMP. Simply getting this implemented in a majority of
the TCP stacks would be really good.

However, I think we need to strive towards getting applications in line
and support MTU discovery. It is silly for high-bit rate applications to
send all these small packet instead of at least descent sized packets
when possible.

Rémi Denis-Courmont skrev:

> Maybe Fred was hinting that Teredo could have defined its
> 
> fragmentation layer between UDP and IPv6. But while this would
> 
> work-around on-path fragmentation it would bring a naughty congestion
> 
> control issue - one simply cannot send 40 datagrams of 1500 bytes each
> 
> with no pacing. And we don't want to have to do congestion control,
> 
> right?
>

Exactly, and you also need to define a reliability mechanism so you can
retransmit fragments that got lost so that you don't get the packets to
experience only (1-packet_loss_probability)^40 chance of getting through.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Oct 2007 09:51:19 +1300

> send all these small packet instead of at least descent sized packets

So, is there any scope for a generic UDP echo process that would allow
PMTUD without ICMP messages? It's probably easier to get a port open
in firewalls for that than to reverse the trend of ICMP filtering, as
long as the echo process has adequate DoS resistance.

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Oct 2007 09:52:05 -0700

Brian,

> long as the echo process has adequate DoS resistance.

I would hope that we could at least ping. Or, is that
off the table as well?

Fred
[email-masked]

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 11 Oct 2007 22:28:52 +0300

Hello,

Le Thursday 11 October 2007 22:20:35 Brian E Carpenter, vous avez écrit :
> On 2007-10-12 05:52, Templin, Fred L wrote:
> > Brian,
> >
> If you mean ICMP echo that seems to be blocked in many places.

By design, ICMP echo requests can't go *in* through NATs anyway, so this is a 
moot point within this *TEREDO* thread..

Of course, UDP echo would work, but I am a bit concerned as to its 
applicability to potentially short-lived UDP flows, as can happen with 
TEREDO... ?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Oct 2007 12:52:27 -0700

Brian,

> If you mean ICMP echo that seems to be blocked in many places.

That doesn't sound so great. About the UDP echo port,
in one of my earlier (unpublished) essays I talked about
setting up a "sprite-mtu" service port. Maybe I should go
back and look at that again.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Oct 2007 13:13:04 -0700

> applicability to potentially short-lived UDP flows, as can happen with 

Short UDP flows should still be OK, but may need to
institute pacing until coordination with the TFE can
be done. If the flow is so short-lived that there is
no time to perform the coordination, then it is simply
"out of sight - out of mind" - right?

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Oct 2007 10:26:09 +1300

> "out of sight - out of mind" - right?

A sender could always cache the most recently discovered PMTU
to a given destination. That would be enough for repeated
short UDP flows to the same destination. As for isolated
short UDP flows, they just need to use the Internet minimum
MTU (576 or 1280) - there's no other possible solution.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Oct 2007 08:20:35 +1300

Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Oct 2007 15:32:01 -0700

Brian,

> MTU (576 or 1280) - there's no other possible solution.

Minimum MTU for IPv4 is only 68 bytes; minimum EMTU_R
is the one that is 576 - right?

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Thu, 11 Oct 2007 17:01:20 -0700

> is the one that is 576 - right?

I forget the exact terminology, but Brian is talking about the  
biggest packet one can send and be guaranteed it will not be  
fragmented.  The is 576 bytes for IPv4 and 1280 bytes for IPv6.

I think of it as the biggest smallest packet one can send :-)

Bob

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Oct 2007 18:46:34 +0200

On 10-okt-2007, at 22:51, Brian E Carpenter wrote:

>> MTU's are real bastard.

:-)

>> Especially for UDP applications that rarely has
>> work.

Are we talking about IPv4 here? In that case, path MTU discovery is  
pretty much impossible because the applications would have to receive  
the ICMP messages and adjust their behavior = every UDP app needs to  
implement PMTUD itself.

With IPv6 the IP layer takes care of all of this but obviously if  
there are no ICMP messages it won't work. However...

>> doesn't rely on ICMP.

I don't see any reason why the IPv6 IP layer wouldn't be able to do  
RFC 4821.

>> and support MTU discovery.

No way. Application developers don't run networks, they tend to get  
this stuff wrong and then you'll forever supporting applications with  
broken network behavior that won't be upgraded for a decade.

>> It is silly for high-bit rate applications to

> PMTUD without ICMP messages?

That's what RFC 4821 does by trying different packet sizes and seeing  
which gets through.

For IPv4, an obvious method would be to send packets with DF=0 and  
hear from the other side how big the fragments are but that's not  
possible with IPv4.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 11:52:57 +0200

> I think of it as the biggest smallest packet one can send :-)

Please note that the former and the latter are not the same thing. In  
IPv4, fragmentation is always an option unless you set the DF bit.  
That doesn't mean it's a good idea to set the DF bit because  
fragmentation is less than desireable, because the alternative is  
worse: the packet is dropped. You ONLY get to set the DF bit if you  
have a mechanism in place that can recover from the drops and resend  
smaller packets. As far as I know, this is universally not the case  
for IPv4 UDP applications so those should NEVER set the DF bit.

68 is not the minimum MTU for IPv4, it's a throw-away observation in  
RFC 791 that having an MTU even smaller than 68 is unworkable. In  
practice, the smallest MTU that I've seen in IPv4 is 296 (see work by  
Van Jacobsen) and for a long time, 576 was the largest univesally  
supported packet size on the IPv4 internet. But this was so long ago  
that it doesn't mean much anymore today. There are basically two  
types of UDP protocols: the old / low volume ones such as the DNS,  
where a 512 / 576 limit is explicitly or implicitly understood, and  
the newer / higher volume ones such as A/V streaming that will  
usually work just fine at sizes between 1300 and 1400 bytes.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Oct 2007 13:52:27 +0200

> the ICMP messages and adjust their behavior = every UDP app needs to

Yes IPv4, but I don't know if things are better in the IPv6 world. What
you write about requiring each app to do it itself is basically the
state of things today as I understand them. However, you should even
forget to use ICMP for it. It can be used as a hint for your process.
But the only reliable way of determining MTU is to probe how big packets
the network will deliver with DF bit set. And this obviously doesn't
work unless you have a feedback and can ACK which packets that was
delivered so that one can know if a particular size successfully was
delivered.

> 
> With IPv6 the IP layer takes care of all of this but obviously if there
> are no ICMP messages it won't work. However...
> 
> I don't see any reason why the IPv6 IP layer wouldn't be able to do RFC
> 4821.
> 
> No way. Application developers don't run networks, they tend to get this
> stuff wrong and then you'll forever supporting applications with broken
> network behavior that won't be upgraded for a decade.

Well, then we stop using UDP. Protocols built on top of UDP needs to
take care of this as ICMP clearly does not work. There is also the whole
thing that most applications need to deliver the data that suits the MTU
that is present. For RTP/UDP application this adaptation needs to happen
in the media codecs that deliver data to the lower layers to enable the
utilization of different MTUs.

Any protocol/application implementation capable of utilizing larger MTUs
needs to have support for utilizing the MTU that actually is present.

> That's what RFC 4821 does by trying different packet sizes and seeing which gets through.
> 
> For IPv4, an obvious method would be to send packets with DF=0 and hear from the other side how big the fragments are but that's not possible with IPv4.
> 

Yes, that would probably work. The question is how we get a feedback
channel that works.

Cheers

Magnus Westerlund

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Oct 2007 06:00:23 -0700

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Thursday, October 11, 2007 9:47 AM
> To: Brian E Carpenter
> Cc: IPv6 Operations
> Subject: Re: The IPv4 Internet MTU
> 

Double :-) :-)
 
> hear from the other side how big the fragments are but that's not  

Have been there, and won't go there again. Size of fragments
usually indicates size of links in the path - but not always!

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Oct 2007 06:06:35 -0700

> Sent: Friday, October 12, 2007 2:53 AM
> To: [email-masked]
> Cc: IPv6 Operations

> usually work just fine at sizes between 1300 and 1400 bytes.

The BCP for this is RFC3819, Section 2. It essentially says
that slow links should set an MTU that is "small, but not
too small". It gives an example number of 256b, but leaves
it up to the reader to decide just how small "too small" is.
Main takeaway for me is that if the path MTU is 576 or smaller,
just drop everything bigger than 576 and set DF=0 in the others.

Fred

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 16:23:15 +0200

> state of things today as I understand them.

No, the state of things today for UDP is that no PMTUD happens. This  
is suboptimal, but I'm not sure if there is a reasonable way to do  
better.

> delivered so that one can know if a particular size successfully was

And, more importantly, you can adjust your packet sizes as required.  
This isn't something all UDP applications can do. The IP layer can do  
it for them by sending out fragments but although this is normal  
behavior for IPv6 if there are "too big" messages, I have never seen  
IPv4 do this.

> Well, then we stop using UDP.

:-)

Maybe the notion of implementing protocols such as RTP in the  
application isn't such a smart one after all.

> Protocols built on top of UDP needs to
> take care of this as ICMP clearly does not work.

ICMP isn't the issue. The issue is that any kind of PMTUD in  
applications is just a very bad idea.

>> hear from the other side how big the fragments are but that's not  

(That last IPv4 should be an IPv6.)

> Yes, that would probably work. The question is how we get a feedback

It has to be in-band because the out-of-band method (ICMP) is  
filtered in a small but significant number of all cases.  
Unfortunately, UDP doesn't support options and inserting IPv6 option  
headers or IPv4 options will almost certainly trigger the same  
filtering that makes using ICMP problematic. So the only choice would  
be adding something to the next higher protocol on top of UDP.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 18:36:12 +0200

On 12-okt-2007, at 17:13, Rémi Després wrote:

> 2. Since IPv6 MTU is fixed, why would IPv6 ICMP be useful at all as  
> far as  MTU is concerned ?

The IPv6 MTU isn't fixed, it just has a 1280 byte minimum. Nearly all  
IPv6 hosts use larger packets and perform path MTU discovery,  
resulting in even worse black holes than with IPv6 if the ICMP  
messages are filtered because in IPv6 you can't clear the DF bit  
because there isn't one.

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Oct 2007 10:02:32 -0700

On Oct 12, 2007, at 07:23, Iljitsch van Beijnum wrote:
> Unfortunately, UDP doesn't support options and inserting IPv6  
> option headers or IPv4 options will almost certainly trigger the  
> same filtering that makes using ICMP problematic. So the only  
> choice would be adding something to the next higher protocol on top  
> of UDP.

I'd hate to be repetitive and boring, but I'm shocked-- SHOCKED! I  
say-- to learn that stateful packet filtering is the root cause of so  
many problems for application transport.

I have a radical proposal: how about we tell the stateful packet  
filter users that it's their own damned fault if their filters break  
their favorite applications, and that they can either fix their  
broken filters or they can turn them off?  Since *when* has it been  
our job to reengineer the whole world because some idiot can't read  
the RFC series?

PMTUD for IPv4/UDP could work just fine through NAT if the state  
matching and translation code isn't totally broken.  The problem we  
are discussing here is in the wetware of the coders who write the NAT  
and stateful packet filter implementations.  It's their problem if  
applications don't work because their filters don't pass ICMP through  
for corresponding UDP state-- *not* ours.

Let's concentrate on the problems that belong to us.  That's what I say.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Doug Barton <[email-masked]>
Date: Fri, 12 Oct 2007 12:01:51 -0700 (PDT)

On Fri, 12 Oct 2007, james woodyatt wrote:

> I have a radical proposal: how about we tell the stateful packet filter users 
> that it's their own damned fault if their filters break their favorite 
> applications, and that they can either fix their broken filters or they can 
> turn them off?

While I'm as sympathetic as the next guy to a good net.purist rant, if we 
want to find real solutions (where real is defined as useful for actual 
users) we need to look at the real problems.

99.9% of home users who go to Fry's and buy a Netgear/Linksys/D-Link
or whatever "home router" don't have any idea what stateful packet 
filtering, PMTUD, or a lot of other things mean, and they shouldn't have 
to. It's unfortunate that PMTUD is broken on most of the IPv4 internet, 
but if we're going to do better with IPv6 we have to play the hand we've 
been dealt.

Doug

-- 

 	If you're never wrong, you're not trying hard enough

---

From: Doug Barton <[email-masked]>
Date: Fri, 12 Oct 2007 12:06:58 -0700 (PDT)

On Fri, 12 Oct 2007, Iljitsch van Beijnum wrote:

> There are basically two types of UDP protocols: the old / low volume ones 
> such as the DNS, where a 512 / 576 limit is explicitly or implicitly 
> understood,

And of course this assumption is no longer valid in the EDNS0 world where 
UDP packets can be as large as 6k.

Speaking of bad stateful firewalls, we've had enormous problems deploying 
EDNS0 in the wild due to firewalls that assume anything larger than 512 
can't possibly be a DNS packet, so they drop them. And lest you think this 
is low end stuff, Cisco's PIX was one of the most common AND worst 
offenders till they finally created an update for it. Now all we have to 
do is go around to every single site that's having problems with larger 
packets and convince them to upgrade.

and so it goes,

Doug

--

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Oct 2007 13:25:33 -0700

On Oct 12, 2007, at 12:01, Doug Barton wrote:
>> filter users that it's their own damned fault if their filters  
>> break their favorite applications, and that they can either fix  
>> their broken filters or they can turn them off?
>
> While I'm as sympathetic as the next guy to a good net.purist rant,  
> if we want to find real solutions (where real is defined as useful  
> for actual users) we need to look at the real problems.
>
> filtering, PMTUD, or a lot of other things mean, and they shouldn't  
> have to. It's unfortunate that PMTUD is broken on most of the IPv4  
> internet, but if we're going to do better with IPv6 we have to play  
> the hand we've been dealt.

I admire your appreciation for the virtues of pragmatism, but  
respectfully, sir, I think my point was that we, the IETF, haven't  
been dealt into this hand.

PMTUD is broken on most of the IPv4 internet for the same reason it's  
currently broken on most of the IPv6 internet: stateful packet  
filters that don't properly admit ICMP errors corresponding to their  
underlying IP flows.  The best we can do as engineers in the business  
of setting standards is to document what behaviors in stateful packet  
filters are known to break which application protocols, and recommend  
that equipment vendors and network operators choose to deploy  
networks that comply as much as possible with the proposed  
standards.  If people don't want to do that, and they insist on  
deploying network equipment that is engineered deliberately for  
failure, then I don't see how writing another RFC will help undo  
their basic malfunction.

It is not a good idea for IETF to reinvent yet another way to pass  
around traffic control messages that will be filtered improperly by  
badly coded stateful packet filters with the result that applications  
will be mysteriously broken in new and exciting ways for naïve users  
without the technical ability to repair them.  We already have a  
method for passing such messages around today.  It's called ICMP.  It  
works perfectly well when filters are absent or they are present and  
coded properly.  It could be made to work just as well in IPv4/NAT  
and filtered IPv6 as it does today in unfiltered IPv6.  If we invent  
another mechanism, then we will just be inviting the filter coders  
(hello? that's me!) to screw up our new mechanism just as badly as  
they screwed up our old one.  Don't think they won't try.  They're  
pretty resourceful when it comes to breaking the Internet.  Some of  
them (hi!) make a living doing it.

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 12 Oct 2007 23:36:00 +0200

Hi,

james woodyatt <[email-masked]> writes:

> [ snipped things i agree with ]
>

IMHO, the local issues can be solved ... locally, i.e. in home and
corporate networks.

Problems in the core are the real issue here: it's unbearable that
people from ISP or having some power on devices in the core implement
stupid filtering or deploy devices that simply do not work.

Let's correct that with AWARENESS.

What about simply:

1) pointing the finger at the people that do that: among the operator
   community, their reactivity (or lack of) will (slowly) create some
   feedback. For ISP, end users will simply know that things do not work
   smoothly with A and then select B. I don't know for peering.
2) referencing the brands that have devices that do that (i.e. bad
   implementations): the market will do the rest.

Let me be first: one of my ISP in France provides native IPv6 for their
ADSL service (they are the only one here, AFAIK). Basically, the
connectivity from the client's router to the LNS is provided either by
France Telecom or 9/Cegetel. When it's 9/Cegetel, you get an asymmetric
MTU: IPv6 packets larger than 1473 bytes sent by peers are just dropped
when they come back. Annoying to say the least ...

I have spent hours with people of my provider debugging that issue
(before switching to their SDSL service) and we get to the conclusion
that it was associated with the way IPv6 traffic encapsulation was done
by the devices in 9/Cegetel network. From what i get (_NO_ certainty on
that one), the issue is related to the L2TP implementation of HUAWEI
devices in 9/Cegetel network. I have put someone of my ISP in Bcc, he
might provide more specific feedback (or correct me).

Let's start referencing the faulty devices/networks/admins, this might
lead somewhere ... like having PMTUD working on the IPv6 internet. Note
that i don't think v6ops is the best place to do that.

a+

ps: in parallel, just like another client of my ISP (in Bcc), i
implemented TCP MSS clamping for IPv6 traffic for Linux but this is just
a workaround (IKE traffic obviously still get killed, for instance).

---

From: Gert Doering <[email-masked]>
Date: Sat, 13 Oct 2007 13:47:03 +0200

Hi,

> many problems for application transport.

Actually the problem has nothing to do with stateful packet filtering
(except where the firewall doesn't get it right), but much more with

  - stupid admins "ICMP is so evil, we must forbid it"
  - broken IP mangling devices, like load balancers or NATs, that cannot 
    correctly handle incoming ICMP packet-too-big packets.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  122119

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Sat, 13 Oct 2007 13:51:20 +0200

Hi,

> I would hope that we could at least ping. Or, is that

As long as security "experts" go around and tell people "you must switch off
ping to your servers, because that's a security hole" -> off the table.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Oct 2007 08:18:02 +1300

...
> Yes, that would probably work. The question is how we get a feedback

And that's exactly where I'm suggesting a UDP echo process on its
own port, which has a much better chance of being allowed by firewalls
than ICMP.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 13 Oct 2007 19:02:56 +0200

On 12-okt-2007, at 23:36, Arnaud Ebalard wrote:

> IPv6 packets larger than 1473 bytes sent by peers are just dropped

A good way to work around that is by having your router advertise an  
IPv6 MTU of that size. Your hosts will then automatically reduce  
their packet sizes and advertise a reduced TCP MSS option.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 13 Oct 2007 18:56:03 +0200

> their broken filters or they can turn them off?

We can't; they'd filter the message.  :-)

> are discussing here is in the wetware of the coders who write the  
> NAT and stateful packet filter implementations.  It's their problem  
> if applications don't work because their filters don't pass ICMP  
> through for corresponding UDP state-- *not* ours.

Good rant.

At some point, when people insist on breaking stuff, you have to stop  
glueing them back together.

What I find utterly infuriating about the whole PMTUD issue is that  
people still set the DF bit and then proceed to filter the too big  
messages. You can do either if you like, just not both at the same time.

That said, the problem is so widespread that it makes sense to work  
around it. Also, the IETF is at fault for adopting such a fragile  
protocol. Setting the DF bit on 1 in 10 packets would give almost  
identical results when everything works but only cause some slowdown  
when they don't. You can't build a protocol that completely fails if  
a third party not under your control doesn't do what you expect them  
to do.

I really like what we came up with in shim6: the signalling and data  
packets all share the same protocol number. So people either filter  
all shim6 packets, in which case they won't be able to run shim6 but  
there are no other ill effects, or they let the shim6 packets through  
and it works.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 13 Oct 2007 18:58:15 +0200

On 12-okt-2007, at 21:06, Doug Barton wrote:

>> There are basically two types of UDP protocols: the old / low  
>> volume ones such as the DNS, where a 512 / 576 limit is explicitly  
>> or implicitly understood,

> And of course this assumption is no longer valid in the EDNS0 world  
> where UDP packets can be as large as 6k.

I should do some checking to see how many implementations advertise  
an EDNS0 size larger than 1500 and set the DF bit.

A while back there was at least one root server that set the DF bit  
which causes breakage with an MTU lower than 450 bytes because  
obviously they don't retry with smaller packets when a "too big" is  
returned.

---

From: [email-masked] (Arnaud Ebalard)
Date: Sun, 14 Oct 2007 14:33:11 +0200

Hi,

> their packet sizes and advertise a reduced TCP MSS option.

I prefer MSS clamping, because it provides the same final result, but
does not make the communications inside my site undergo a reduced MTU. 

It also allows me to configure it only at a single location (edge
router) instead of doing it on a bunch of devices.

On my specific case, the MTU being asymmetric, i even get the benefit of
1500 bytes MTU for outgoing traffic.

Don't get me wrong, i *hate* mangling packets but it's IMHO a cleaner
workaround in that specific case.

a+

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 14 Oct 2007 19:38:53 +0200

> does not make the communications inside my site undergo a reduced MTU.

Right. Rewriting the MSS is an ugly hack, though.

> router) instead of doing it on a bunch of devices.

You only have to let routers that send router advertisement include a  
smaller MTU, no need to adjust settings on hosts.

---

From: [email-masked] (Arnaud Ebalard)
Date: Sun, 14 Oct 2007 22:27:02 +0200

Hi,

> smaller MTU, no need to adjust settings on hosts.

You misunderstood me. Obviously i do not need to adjust settings on my
hosts, i don't know where you read that in my previous emails. My point
was that given the number of subnets I have, this means a lot of
configuration on my routers. 

BTW, please consider gigabit links carrying jumbo frames and compare the
*real* drawbacks of your "solution" with those of MSS clamping (note
again that I'm for E2E). In the end, you will probably come to the
conclusion that setting the MTU of the link to a suboptimal value just
for dealing with a problem in my ISP's network is a worst hack than MSS
clamping ...

a+

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Oct 2007 16:25:02 +0200

Iljitsch van Beijnum skrev:
> No, the state of things today for UDP is that no PMTUD happens. This is
> suboptimal, but I'm not sure if there is a reasonable way to do better.

There are cases one can do better at least if one thinks about it when
defining the protocol that works on top of UDP.

> This isn't something all UDP applications can do. The IP layer can do it
> for them by sending out fragments but although this is normal behavior
> for IPv6 if there are "too big" messages, I have never seen IPv4 do this.

Sure, there applications that have this issue. However, the big question
for them in that case. Why are they using UDP as transport layer instead
of something that handle that limitation better.

> application isn't such a smart one after all.

The reality is that RTP is normally implemented in the application code.
It has both up and downsides. The downside is that there is a lot of
implementations, not all necessary well done and correct. The advantage
is that they at least has the potential to be well integrated with what
happens at lower layer. But, in most cases a good library implementation
of RTP/RTCP is needed.

> applications is just a very bad idea.

Well, for UDP it is hard to know where the network protocol ends and the
application starts.

> It has to be in-band because the out-of-band method (ICMP) is filtered
> in a small but significant number of all cases. Unfortunately, UDP
> doesn't support options and inserting IPv6 option headers or IPv4
> options will almost certainly trigger the same filtering that makes
> using ICMP problematic. So the only choice would be adding something to
> the next higher protocol on top of UDP.
> 

Which means that the UDP protocol needs to be designed with PMTUD in
mind. Probably to get this to work there needs to be a fragmentation and
reassembly mechanism at the UDP layer for the application message
themselves. As usually you very soon have reinvented the wheel, excuse
me, I mean TCP or SCTP.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Oct 2007 16:25:02 +0200

Cheers

Magnus Westerlund