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

[Robin Whittle <rw@firstpr.com.au>]

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 rrg-request@psg.com 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