Re: The IPv4 Internet MTU

[Magnus Westerlund <magnus.westerlund@ericsson.com>]

Iljitsch van Beijnum skrev:
> On 12-okt-2007, at 13:52, Magnus Westerlund wrote:
> 
> 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.

> 
>> 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.
> 
> 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.

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.

> 
>>> 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.
> 
> :-)
> 
> Maybe the notion of implementing protocols such as RTP in the
> 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.

> 
>> 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.

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

> 
>>> 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.
> 
> (That last IPv4 should be an IPv6.)
> 
>> Yes, that would probably work. The question is how we get a feedback
>> channel that works.
> 
> 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

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------