Subject: [RRG] PMTUD, Sprite & IPTM; Outer src-addr = sending host's addr

From: Robin Whittle <[email-masked]>
Date: Fri, 23 Nov 2007 18:26:23 +1100

Hi Iljitsch,

I am responding to what you wrote in "Re: [RRG] Inviting people to
join the RRG" http://psg.com/lists/rrg/2007/msg00575.html.

>> http://www.firstpr.com.au/ip/ivip/pmtud-frag/
>
> I only scanned this quickly (it's a bit long...),

I aim for something which, when read fully just once, is reasonably
complete and understandable.  The Ivip ID is pretty long too:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-00

but I think this level of explanation and detail is needed for any
ITR-ETR scheme.  It is the other IDs which are too short!

> but it looks like a complex scheme in the same vain as Fred's MTU
> proposals.

Fred's latest revision of Sprite:

  http://tools.ietf.org/html/draft-templin-inetmtu-06

contains some changes which address the criticisms I made here:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/#sprite_critique

When I get a chance I will revise my critique accordingly.

One change is that it would be allowable to assume an MTU_R of up to
1280 on IPv4, which would be better than having to assume something
much lower, such as 576.  This reduces the number of instances in
which the proposed protocol needs to be activated - as long as there
is a rule about ITR and ETR placement to suit the assumed limit.

Sprite is an attempt to make a generalised protocol for many
situations while my IPTM (ITR Probes Tunnel MTU) on the above page
is purely designed for an ITR-ETR system.  Ideally, perhaps, as you
suggest, the single generalised protocol approach would be best, but
I think such a generalised protocol needs to be crafted so it can
meet the specific lightweight, flexible, requirements which I think
are important in an ITR-ETR system.

Most of my approach could be used for one of the other ITR-ETR
schemes, in which the traffic packet is tunneled with the outer
header's source address being that of the ITR.  However, my proposal
is primarily intended for Ivip in which the outer header's source
address is that of the original sending host.

It would be quite a twist of Sprite or some other generalised PMTUD
proposal to have this as an option, but I have several reasons for
believing this latter, unconventional, approach is superior for an
ITR-ETR scheme.

Firstly, I think "Outer header source address = sending host's
address" is the only practical way ETRs can enforce (on the packets
they decapsulate and forward to receiving hosts) the ISP's filtering
which tries to prevent spoofed source addresses in the ISP's network.

   http://www1.ietf.org/mail-archive/web/ram/current/msg01691.html
   http://www1.ietf.org/mail-archive/web/ram/current/msg01697.html
   http://www1.ietf.org/mail-archive/web/ram/current/msg01705.html

Secondly, I think this approach lends itself to support for
Traceroute, with relatively simple modifications to the Traceroute
software.

There may also be some other reasons for preferring this.

The reason links to a separate issue of why I believe all traffic to
an ITR-ETR mapped address should go through an ITR and the correct
ETR.  Only the ITRs - not the local routing system of an ISP in
which a packet originates, and in which the destination host might
be located - are responsive to the mapping database, which I think
should solely be in control of the forwarding of packets.

This leads to the concept of the ETR not being able to rely on the
local routing system forwarding packets with the raw destination
address to the final destination - local routers should forward
those packets to an ITR.  Therefore, I think the ETR needs some
locally determined arrangement of a direct link, or a tunneled,
method of forwarding packets towards, or to, the receiving host (or
end-user network router).  I think all this is very different from
from the way the proponents of the other ITR-ETR schemes think.

I will maintain my separate IPTM proposal as either a specific
approach to be used only in an ITR-ETR scheme in general (Ivip in
particular) or as an outcome to which a generalised approach such as
Sprite might aspire when used by an ITR-ETR scheme.

You wrote:

> In my opinion, that's not the best way to handle this.
> First of all, operators need to make sure that they use decent
> MTUs after tunneling so that hosts that send 1500-byte packets
> won't get in trouble or lead to much, if any, MTU discovery.

I think it may be reasonable to insist on something like "Every ITR
and ETR must be on a link with at least an XXX MTU to the core of
the Net", but XXX needs to be below 1500 for a variety of reasons -
although I have only a rough understanding of the various situations
where it is currently lower.  Encapsulation in DSL links is one.
GRE or some other tunneling is another, for instance as some parts
of some networks use this continually, or perhaps to handle outages.
 Bill Herrin gave a good example of this:

  http://psg.com/lists/rrg/2007/msg00348.html

As far as I know, we can't reasonably insist that any operator
provide an MTU above 1500.  Even if, for some reason (and I
understand this is not the case, due to typical limitations of
100Mbps Ethernet gear) the "core" of the Internet had a greater than
1500 byte MTU, I don't think we could insist that ITRs and ETRs be
located in places with an MTU >= (1500 + worst case ITR-ETR
tunneling overhead), since we need ETRs to be deep in ISP networks,
and we need ITRs to be almost anywhere.  For instance, I think that
in quite a few circumstances it would be best to have the ITR
function (a caching ITRC function) in the sending host.

So I think we do need a scheme such as Sprite or IPTM, rather than
what I understand you suggest - insisting on larger than 1500 MTUs
in most of the Net, so hosts can carry on sending 1500 byte packets
which do not fragment, even when tunneled.

> Second, tunnel endpoints should simply implement two sides of
> path MTU discovery: they should discover the maximum packets they
> can successfully send to the other endpoint, and they should set
> their own inbound MTU to that value minus the size of the header
> that's added. This is simple enough that it's possible to get it
> right and doesn't add much overhead.

This is what Fred's and my approaches are trying to achieve.

However, when sending the first packet to an ETR, there is no time
for the ITR to muck around testing the PMTU limit before sending the
packet.  So I suggest sending it if it is shorter than some assumed
limit (eg. 1280) and fragmenting it if it is longer - irrespective
of whether its do not fragment bit is set.  Later, if more such
packets need to be sent, the ITR and ETR can work on determining the
real PMTU.  I do this with probe packets, rather than traffic packets.

I think Fred's approach and mine have a lot in common, but he is
trying to make a generalised protocol for many other scenarios
beyond ITR-ETR schemes.

 - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 23 Nov 2007 14:35:37 +0100

> the Net", but XXX needs to be below 1500 for a variety of reasons

No.

We're doing something new here, which gives us the opportunity to get  
rid of at least SOME old crap. If you want to run a *TR, get gear that  
can handle 1600 byte packets. Period.

> Encapsulation in DSL links is one.

Oh really?

#sh int atm0.1
ATM0.1 is up, line protocol is up
   Hardware is PQUICC_SAR (with Alcatel ADSL Module)
   Interface is unnumbered. Using address of Ethernet0 (82.192.90.25)
   MTU 4470 bytes, BW 800 Kbit, DLY 80 usec,
      reliability 255/255, txload 1/255, rxload 1/255
   Encapsulation ATM
   54222372 packets input, 11781520984 bytes
   54403498 packets output, 16978237812 bytes
   0 OAM cells input, 0 OAM cells output
   AAL5 CRC errors : 0
   AAL5 Oversized SDUs : 0
   Last clearing of "show interface" counters never
#ping
Protocol [ip]:
Target IP address: 82.192.91.254
Repeat count [5]:
Datagram size [100]: 4000
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]: yes
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 4000-byte ICMP Echos to 82.192.91.254, timeout is 2 seconds:
Packet sent with the DF bit set
Reply data will be validated
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/73/76 ms

> GRE or some other tunneling is another

No. GRE, like any other *-in-IP mechanism, adds some extra bytes, but  
if you start with something big enough you can add a good number of  
GRE headers before you end up below 1500 bytes.

What you really mean is that there is some ethernet stuff in the  
middle that doesn't support jumboframes. Since as good as all gigabit  
ethernet equipment supports jumboframes these days in practice, this  
means that someone is being too cheap to upgrade their stuff to  
gigabit ethernet and/or doesn't want to go through the trouble of  
manually setting the MTU. I don't find this sufficient reason to  
cripple our efforts.

(Sitting behind a link with an IPv6 PMTUD black hole doesn't help me  
being tolerant here.)

Note that these days pretty much all TCP stacks set the DF bit and a  
very significant number of sites filters ICMP too big messages. That  
means that if you're behind a < 1500 MTU link you WILL have a LOT of  
trouble unless you work around that by clearing the DF bit or adjust  
the TCP MSS option, both of which are easy to do in a local gateway  
but much harder in the core of the network.

> provide an MTU above 1500.

Not all operators or even any operator, just the ones that want to run  
*TRs.

> For instance, I think that

Well, if you do that you have to use good security mechanisms because  
that way you're sure that ITRs are in the hands of bad people. If you  
only have them under the control of ISPs the security mechanisms can  
be much simpler because if your ISP is out to get you, they'll get you  
without subverting an ITR anyway.

>> that's added.

> This is what Fred's and my approaches are trying to achieve.

Doesn't look that way to me...

> of whether its do not fragment bit is set.

That is a really bad solution, because this guarantees a good amount  
of fragmenting. With IPv4, this is rather problematic because of the  
small ID space. It also costs you lots of CPU and could even allow for  
CPU exhaustion attacks.

A few lost packets here or there because of PMTUD aren't the end of  
the world; just keep things simple.

> Later, if more such

Even more overhead...

---

From: Robin Whittle <[email-masked]>
Date: Sat, 24 Nov 2007 13:56:56 +1100

Hi Iljitsch,

I respond to what you wrote about MTUs, jumboframes and ITR-ETR
placement in a separate message to follow.

You wrote, initially quoting me:

>>> path MTU discovery: they should discover the maximum packets
>>> they can successfully send to the other endpoint, and they
>>> should set their own inbound MTU to that value minus the size of
>>> the header that's added.
>

OK - I missed the part: "they  should set their own inbound MTU to
that value ...".

An ITR can't set its inbound MTU to the lowest value of any ETR it
might need to send packets to.  My IPTM proposal:

is different from what you wrote.  So is Fred's, I think.  My page
above contains a complete description of what I think is the
problem, and the best solution.  I would really appreciate you or
anyone else writing a detailed critique of this.

>> However, when sending the first packet to an ETR, there is no
>> time for the ITR to muck around testing the PMTU limit before
>> sending the packet.  So I suggest sending it if it is shorter
>> than some assumed limit (eg. 1280) and fragmenting it if it is
>> longer - irrespective of whether its do not fragment bit is set.
>
> That is a really bad solution, because this guarantees a good
> amount of fragmenting.

As I point out in my proposal, fragmentation is only performed for
those initial long packets in a potential stream to an ETR which the
ITR hasn't sent packets to recently.  I think it is better to do
this than to drop the packet, sending back a Packet To Big message
to the sending host with a too low (assumed, not tested) PMTU value
 - which would screw up that host's attempt to find the MTU of the
path to the destination.  The final PMTU is likely to be pretty
close to 1500 once the ITR has probed the ETR.

> With IPv4, this is rather problematic because of the small
> ID space.

This is only likely to be for a handful of packets, though I suppose
one could construct a worst-case scenario of a sudden burst of long
packets which would need to be fragmented until the ITR could figure
out the true MTU.

I haven't looked closely at the fragmentation reassembly problems of
IPv4.  Can you point to some references?

> It also costs you lots of CPU and could even allow for CPU
> exhaustion attacks.

Yes, but I think it is better than dropping longish packets just
because we assume some too low PMTU of 1280 or whatever, when in
fact, within a second or two, the ITR will probably be able to
establish that the real PMTU is 1500 or somewhat less.  Then the ITR
can switch over to dropping packets (and sending a Packet Too Big
message with the correct PMTU value the sending host should assume)
 which need to go to that ETR when they are longer than this value
after encapsulation.

I am just repeating what is on my web page.  This encapsulation,
PMTUD and fragmentation stuff is really difficult.  I would really
appreciate detailed critiques of Fred's and my proposals - rather
than critiques based on too quick a read of what we wrote.

> A few lost packets here or there because of PMTUD aren't the end
> of the world; just keep things simple.

I agree to some extent.  While I don't think it acceptable that an
ITR should generally drop all first packets to an ETR, since they
are typically short DNS, TCP open or some other initial packet -
which would delay for seconds the establishment of a communication -
I guess it would be a different class of packets we are discussing here.

They would be the first substantial data carrying packets in the
flow, since the earlier, shorter ones would have been ignored by
Sprite or IPTM.

Still, we can predict that there will be such large packets early on
in many communications.  Simply dropping them doesn't seem right to
me.  Dropping them with a too-low PMTU value being sent to the
sending host would screw up that host's later packets, making them
shorter than they really need to be.  I think fragmenting them at
first is the best approach.

>> Later, if more such packets need to be sent, the ITR and ETR can
>> work on determining the real PMTU.  I do this with probe packets,
>> rather than traffic packets.
>
> Even more overhead...

Yes.  However I can't see a way of probing the PMTU in any other
way.  ICMP can't be relied upon, and if I tried to use only traffic
packets, I would have to risk those packets not arriving.  Instead,
IPTM fragments the traffic packets and sends its own probe packets.
 This means there is no fancy overhead in traffic packets - they are
not intended to be used for PMTUD at all.

  - Robin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 Nov 2007 23:10:22 +0100

On 24 nov 2007, at 3:56, Robin Whittle wrote:

> might need to send packets to.

Hm, you're right: in a point-to-point tunnel this is trivial, but in a  
point-to-multipoint tunnel the MTU will be different for different  
destinations. This complicates matters, but I would still like to  
stick to the basic principle that the MTU the tunnel presents to  
encapsulated packets is a simple reflection of the path MTU discovered  
through the sending of tunneled packets.

> anyone else writing a detailed critique of this.

I'm sorry, but I'm not prepared to do that at this time. I've been  
discussing tunnel MTU issues for some time recently, and my conclusion  
is that you either need to have a rather involved scheme that is  
supported on both ends (hard for existing tunneling mechanisms but  
doable for something new) or it's necessary to reject a good number of  
seemingly reasonable use cases to keep things workable. There doesn't  
seem to be much useful middle ground here.

If you like, I can send you copies of the ~ 200 message exchange  
between a number of people that led up to Fred's sprite MTU proposal.

>>> So I suggest sending it if it is shorter

> ITR hasn't sent packets to recently.

Obviously this would be a fraction of all packets under normal  
circumstances, but it would still mean that routine packets (i.e.,  
1500-byte ones) would be fragmented, which I don't like.

> packets which would need to be fragmented until the ITR could figure

Right. So you'd probably have to be prepared to deal with this even  
though it wouldn't be an issue in practice most of the time.

> IPv4.  Can you point to some references?

I don't have any references, but in short, the issue is that you have  
a 16 bit ID space with a reassembly timeout of something like a few  
minutes. This means you can only send 65536 packets during that "few  
minute" window or you'll incorrectly reassemble fragments from  
different packets if you lose a fragment. This is especially  
problematic if the fragmented packets belong to a tunnel because in  
that case the IP source/dest addresses are always the same.

> establish that the real PMTU is 1500 or somewhat less.

Who said anything about preemptively dropping packets? Just send 1500- 
byte packets + an outer header with DF set and you'll get a "too big".  
After that, you know the path MTU and you can in turn send too bigs to  
the source of the original packets.

Yes, this allows for PMTUD black holes, but those are subject to the  
"so don't do that and the problem goes away" doctrine. ISPs generally  
get this, unlike enterprise people and ignorant consumers who can't  
live without their firewalls.

> first is the best approach.

If we mandate that *TRs support 1500-byte user traffic without  
fragmentation this wouldn't be any issue in practice.

> not intended to be used for PMTUD at all.

I REALLY don't like this: generating singalling traffic when there is  
no data traffic is a very bad precedent. However, we probably need to  
probe for reachability in some way or another, if we can do the MTU  
stuff along with that i may be tolerable.

Iljitsch

---

From: Robin Whittle <[email-masked]>
Date: Mon, 26 Nov 2007 00:49:28 +1100

Hi Iljitsch,

Thanks for your response and offer of the correspondence leading to
Fred's proposal - I won't read that just now.

Hopefully some other folks can scrutinise Fred's proposal and mine:

ITR-ETR schemes are fresh, and definitely need some kind of PMTUD
system, so it should be fine to build in special functions at both ends.

Thanks for your account of the fragmentation reassembly problems of
IPv4.

> I don't have any references, but in short, the issue is that you
> have a 16 bit ID space with a reassembly timeout of something
> like a few minutes. This means you can only send 65536 packets
> during that "few minute" window or you'll incorrectly reassemble
> fragments from different packets if you lose a fragment. This is
> especially problematic if the fragmented packets belong to a
> tunnel because in that case the IP source/dest addresses are
> always the same.

In a fresh system such as an ITR-ETR scheme, perhaps a workaround
for this would be to set the maximum reassembly time at the ETR to
something very much shorter, such as 1, 2 or 3 seconds?

That could be a pain where the ETR is an additional function in a
server or router with a pre-existing TCP/IP stack.  Then it would
probably not be possible to shorten the time just for the ITR to ETR
packets.

>> Yes, but I think it is better than dropping longish packets
>> just because we assume some too low PMTU of 1280 or whatever,
>> when in fact, within a second or two, the ITR will probably be
>> able to establish that the real PMTU is 1500 or somewhat less.
> 
> Who said anything about preemptively dropping packets? Just send 
> 1500-byte packets + an outer header with DF set and you'll get a
> "too big". After that, you know the path MTU and you can in turn
> send too bigs to the source of the original packets.

OK - here's the Devil's Advocate view:

Firstly, the ITR can't be sure it will get a Packet Too Big (PTB)
message - that could be dropped.

Secondly, there could be another lower MTU limit beyond whatever
sent the first PTB message.

Your algorithm, as I understand it, does not involve the ITR
fragmenting any packets.  All the ITR can do when it gets the PTB
message is send a PTB back to the sending host.  This really slows
things down, since the sending host has to create another shorter
packet and the whole process repeats itself.

With my IPTM approach, as long as the ITR doesn't yet have a
reliable estimate of the PMTU to the ETR (which it takes a few
seconds to establish with an explicit probe protocol, not using
traffic packets, and not relying on PTB messages), it fragments any
packet which is longer (after encapsulation) than the default PMTU,
which I suggest be something like 1280 bytes.  This only persists
for a few seconds while the probing takes place.  After that, the
ITR has a good idea of the PMTU and then sends a PTB to the sending
host when it next gets a packet which would exceed this, once
encapsulated.

In my scheme, when the sending host does get an PTB message, it gets
it nearly instantly from the (typically) nearby ITR, rather than
from the ITR in your scheme with a long delay due to the long path
the encapsulated traffic packet took from the ITR to some router in
the tunnel and the delay of the PTB returning to the ITR.  Maybe you
don't think much of this in Europe or the USA, but from Australia
these delays are significant.

The round trip to your Netherlands based mailserver 83.149.65.1 is
162ms from my web server in San Francisco, and 343ms from a
well-connected (ISP, not via DSL) server in Australia.

So my approach shouldn't involve significant delay in packets,
whereas yours does significantly delay the first "long" packet.

If there is a second shorter MTU limit, the packet which hits that
will be delayed similarly as well.  These packets would be lost if
the PTB message didn't get back to the ITR.

Also, in Ivip, traffic packets from the ITR to the ETR sent with the
sending host as the outer source address, not the ITR's address.
(So any PTB message would go to the sending host, which would ignore
it, since the destination address is of the ETR, not of the
destination host.)

In Ivip, an ITR couldn't use traffic packets as probes for PMTU to
the ETR - at least in a system which relied on PTB messages.  Using
traffic packets as probes would require some special signalling to
the ETR, in another packet or in a more complex header of the
tunneled packet, to tell the ETR to send an acknowledgement to the
ITR.  I think this complexifies the encapsulation system - so I use
a completely separate probe protocol, between the ITR and the ETR,
which has nothing to do with traffic packets.  I would rather add
probe packets to the total system load than have the lost effort,
delayed delivery and additional complications of using traffic
packets as probes.

With synthetic probes, the ITR can push its luck as far as it likes
with larger packets until one size doesn't generate
acknowledgements.  This is a very robust way of determining PMTU,
without relying on PTB packets - though of course the ITR would use
any which it received.

If you can only use traffic packets to probe the PMTU, you are
restricted to the lengths which result from their length and the
encapsulation overhead.

My approach is:

   While PMTU to the ETR is being established:

      Fragment traffic packets which (after encapsulation) are
      longer than the default PMTU - even if the DF flag is set,
      since this is only within the tunnel.  This gets the data
      through, in most cases.  Reassembly is in the ETR, so the
      destination host gets one packet.

   Once this has occurred, probe the PMTU to the ETR with a specific
   protocol and artificial probe packets - not with traffic packets.

   Then the ITR can send a reliable PTB message to the source, in
   the likely event that it gets another packet which is too long
   to fit in the tunnel, once encapsulated.

   The result is that all packets are delivered, except the first
   one for which the ITR sends back a PTB message.  Then the sending
   host has been reliably informed of the entire PMTU situation and
   adjusts subsequent packets accordingly.  There is no recursing
   of your algorithm, with delayed delivery in each instance, as
   would be required if there was first a 1450 MTU limit and then
   further along the tunnel a 1400 limit (unrealistic examples).

If the ETR simply forwards packets to the destination host, and
there are PMTU limits between the ETR and the destination host,
these are dealt with by the sending host, not the ETR or ITR.  If
the ETR tunnels to the destination host, then that tunnel mechanism
needs to handle the MTU problems - such as by using Sprite.

The task of my scheme is purely related to the tunnel between one
ITR and one ETR.  The same ETR could have multiple destination
hosts, each with their own MTU limits.

> Yes, this allows for PMTUD black holes, but those are subject to
> the "so don't do that and the problem goes away" doctrine. ISPs
> generally get this, unlike enterprise people and ignorant
> consumers who can't live without their firewalls.

I think an ITR-ETR should minimising the degradation of
communication as much as possible.  I don't think we should let the
ITR-ETR scheme frequently drop packets - otherwise end-users will
quickly discover that this new class of address space sucks.

>> Still, we can predict that there will be such large packets
>> early on in many communications.  Simply dropping them doesn't
>> seem right to me.  Dropping them with a too-low PMTU value
>> being sent to the sending host would screw up that host's later
>> packets, making them shorter than they really need to be.  I
>> think fragmenting them at first is the best approach.
> 

But then we wouldn't be able to put ITRs and ETRs in all the places
they need to be.  The whole system would be much more restricted in
scope and would not be deployed as widely or as flexibly.

>>>> Later, if more such packets need to be sent, the ITR and
>>>> ETR can work on determining the real PMTU.  I do this with
>>>> probe packets, rather than traffic packets.
> 
>>> Even more overhead...
> 
>> Yes.  However I can't see a way of probing the PMTU in any
>> other way.  ICMP can't be relied upon, and if I tried to use
>> only traffic packets, I would have to risk those packets not
>> arriving.  Instead, IPTM fragments the traffic packets and
>> sends its own probe packets. This means there is no fancy
>> overhead in traffic packets - they are not intended to be used
>> for PMTUD at all.
> 
> I REALLY don't like this: generating singalling traffic when
> there is no data traffic is a very bad precedent. However, we
> probably need to probe for reachability in some way or another,
> if we can do the MTU stuff along with that i may be tolerable.

In my proposal, and I think in Fred's, there are no probe packets
unless the ITR perceives that there is likely to be further longer
packets to handle.  So yes, there would be one or more large probe
packets.  ITRs might evolve some smarts about what length probe
packets to try, perhaps based on comparing notes with nearby ITRs
who have tunneled to this ETR recently, or by some downloaded
"cheatsheet" suggesting good lengths to try, for each of the BPG
prefixes in which ETRs have been found.

Also, an ITR might be happy with getting a response from an ETR to a
relatively long probe packet and leave it at that - rather than send
another somewhat longer packet, and wait a few seconds before
deciding that was too long.  That would lead to longer delays before
it could inform the sending host with a PTB message, prolonging the
time in which the ITR needs to fragment longer traffic packets.

This might lead to a generalised minor underestimate for PMTUs, in
addition to the overhead imposed by tunneling.  However, that might
be preferable to spending a few seconds pushing larger and larger
probe packets at the ETR until one size is perceived as never
generating a response.

Some of these matters are also discussed in the other thread "MTU,
jumboframes, ITR & ETR placement, ITR function in hosts" - please
see my next message.

 - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Nov 2007 12:54:23 -0800

Having been away from e-mail and just now going through
this detailed discussion, here are just a few related
thoughts:

- the ITR has no control over the pathMTU; all it can know
  a priori is the EMTU_R of each ETR. For IPv6, the minimum
  EMTU_R is 1500 bytes (see: RFC2460 and RFC4213) and for
  IPv4 the minimum EMTU_R is only 576 bytes (see: RFC1122).
  If there is a specification that says (sic) "all RFC(foo)
  compliant ETRs MUST configure an EMTU_R of at least X bytes
  (with X larger than the minimum) then the ITR can assume
  the larger size; otherwise, it can't.

- due to the fragment misassociation/reassembly issues
  mentioned by Iljitsch (and discussed in detail in RFC4963)
  excessive outer fragmentation for the encapsulated packets
  the ITR admits into the tunnel should be avoided, since the
  ETR will have to reassemble these. And again, the ITR cannot
  assume an EMTU_R for the ETR that is larger than the minumums
  listed above unless there is a spec that says that the ETR
  must configure the larger EMTU_R.

- the ITR might not be able to return a "packet too big"
  to the original source if it receives a PTB from a router
  inside of the tunnel, since the router might not return
  enough of the original packet in the ICMP message. Because
  of this, the ITR should send an explicit probe to the ETR
  in parallel with a data message that is larger than some
  previously probed size, since the ITR will get explicit
  feedback from the ETR if the probe succeeds.

- the worst case is for paths with fast links that configure
  small MTUs. In that case, the ITR and ETR need to engage in
  a soft state synchronization protocol to mitigate fragment
  misassociation/reassembly issues.

Fred
[email-masked]   

> -----Original Message-----
> From: Robin Whittle [mailto:[email-masked]] 
> Sent: Sunday, November 25, 2007 5:49 AM
> To: Routing Research Group list
> Cc: Iljitsch van Beijnum
> Subject: Re: [RRG] PMTUD, Sprite & IPTM; Outer src-addr = 
> sending host's addr
> 
> Hi Iljitsch,
>