[RRG] SEAL & IPTM: differing goals

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

Hi Fred,

There are no-doubt mistakes in my attempt to understand your goals
and broader assumptions with SEAL - so please correct them.

I will write a separate message on how IPTM could be improved to
handle IPv4 DF=0 packets.

The note below * discusses the possibility of IPTM ITRs sending DF=1
traffic packets encapsulated as DF=0.

 - Robin


The SEAL Internet Draft is:

  http://tools.ietf.org/html/draft-templin-seal

I was reading version 08 from yesterday, but now it is version 10.
The Diff1 comparisons show only low-level differences in techniques
between the two - not differences in what I think are assumptions
and goals.


A terse description of my new IPTM (ITR Probes Tunnel MTU) proposal
with follow-up discussions is here:

  http://psg.com/lists/rrg/2008/msg01191.html  RW
  http://psg.com/lists/rrg/2008/msg01197.html  BH
  http://psg.com/lists/rrg/2008/msg01199.html  RW

The full description is here:

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


Differing scopes
----------------

SEAL is a general purpose protocol for application to many tunneling
situations, one of which is ITR --> ETR tunnels in map-encap
schemes, such as LISP, APT, Ivip or TRRP.  (It isn't compatible with
Ivip's use of outer source address = Sending Host's (SH's) address,
but I am still keen to learn from it and assist its development.)

SEAL is intended to work with many other tunneling systems,
including long-lasting 2-way tunnels.  Map-encap ITR --> ETR tunnels
are transient and one-way.

SEAL is intended to be a single protocol, used by others.

IPTM (and its subsidiary RPD2 PMTUD probing protocol) is intended
primarily for Ivip, but I want to develop it in a way that it could
be adapted to other map-encap schemes, or be used with suitable
adaptations for other purposes, perhaps including SEAL.

IPTM is not a standalone protocol.  It is an approach which should
work well for Ivip, and from which some or a lot will (ideally) be
adaptable to other scenarios.


Other than its potentially broader applications, IPTM is intended
solely for the challenging task of an ITR (most particularly in an
Ivip system) getting packets to an ETR, including when the ITR
initially has no information at all about where this ETR is, or what
the Real PMTU to this ETR is.  IPTM should also adapt to changes in
the Real PMTU.

As part of this, the ITR is assumed to receive packets from the
Sending Host (SH).  Perhaps that SH is itself a tunneling device,
with the real communication occurring from some other host, and the
destination address of the traffic packet is really the end-point of
some tunnel, not the destination host of the underlying
communication.  Either way, the ITR is assumed to be able to get
PTBs to the SH, and if the SH is doing any kind of tunneling, it is
assumed to be doing its own PMTU management of whatever it sends to
the DH.


Differing goals
---------------

Ignoring IPv4 DF=0 packets for the moment (I am writing a separate
message on this) the goals of IPTM are:

  1 - Send all traffic packets with the minimal necessary
      encapsulation overhead into the tunnel, to the ETR,
      so that the vast majority of them never encounter any
      PMTU limits.

*       As currently described, IPTM sends IPv4-in-IPv4 packets
        to the ETR with DF=1.  (I didn't specify this - just assumed
        it.)

        Maybe it would be desirable to send them with DF=0, to
        enable them to be fragmented by any router in the tunnel
        which has an MTU which is lower than the ITR expects -
        that is lower than LPME.

        That would increase robustness, since as currently defined
        if the packets were DF=1, the ITR would get no PTB.  The
        router's PTB would be sent to the SH, which would not
        recognise it.  With fragmentation, the packets have a good
        chance of arriving, whereas without this, they would be
        dropped and it would be up to the application (such as
        with RFC 4812 Packetization Layer PMTUD) to figure out
        something was wrong - or to wait for the ITR's occasional
        explorative RPD2 probing to find that the Real PMTU was
        lower than LPME.

        I will think about this more.  I suspect it would be
        more trouble than it is worth - but maybe not.


  2 - Send PTBs to the RFC 1191 compliant SH (as all are assumed
      to be) in a way which reliably reduces the size of the SH's
      outgoing packets for this ETR, such that very soon, they
      are of a size which once encapsulated, fits within the
      Real PMTU of the tunnel.  Ideally, this size fits exactly
      within the Real PMTU, so the system works with maximum
      efficiency.

      This involves not sending any PTBs with an unnecessarily low
      value of MTU, since RFC 1191 hosts will not try to send
      packets longer than that value for 10 minutes.


  3 - Discovery of the Real PMTU is done by using traffic packets
      encapsulated in a different manner - RPD2 - from the normal
      encapsulation (for Ivip, 20 byte IP-in-IP with outer source
      address = that of the SH).  RPD2 produces a packet of the same
      length as usual, but also involves 2 or 3 smaller packets
      as well (these numbers are not fixed in stone) which accompany
      the main packet.


  4 - Apart from occasional explorative use of RPD2 for packet
      lengths shorter than LPME, or longer than UPME (and apart
      from Synthetic Probes with RPD2, as discussed below for
      PMTUD with DF=0 packets), the RPD2 probing technique is only
      used for traffic packets whose length falls within the Zone of
      Uncertainty between LPME and UPME.  (See a separate message
      for how I plan to use Synthetic Probe packets with RPD2
      in order to probe the PMTU to an ETR when there are no
      longer DF=1 packets being sent, only longer DF=0 packets.)


  5 - This main use (not the occasional explorative use) of RPD2
      always (apart from in extreme cases of random packet loss)
      results in the ITR learning something reliable about the Real
      PMTU, and so adjusting LPME up or UPME down.


  6 - For IPv6 and IPv4 DF=1 packets, the overall outcome is that
      the ITR will quickly discover good upper and lower estimates
      for the Real PMTU to the ETR, and cause the SH to send packets
      which once encapsulated by the normal techniques, will be sent
      along the tunnel without any PMTU limits and without any
      fragmentation or segmentation (special in-tunnel techniques
      for breaking the traffic packet into smaller pieces at the ITR
      and  reassembling it at the ETR).


  7 - Therefore, IPTM is intended to quickly adjust each SH's
      RFC 1191 notion of PMTU to each of its Destination Hosts
      for which the ITR encapsulated packets longer than ~1200
      bytes, to the optimal value for efficient operation.
      (AFAIK, SHs which send DF=0 packets are not able to receive
      any instructions from the network regarding packet size.)


  8 - IPTM does not embody any assumptions about the prevalence of
      ~1500 byte MTUs, or of 9000 byte MTUs.  So it should be able
      to adapt seamlessly to all future MTU sizes without any
      trade-offs or configuration changes.  There is, however, an
      assumption that all ITRs and ETRs can send packets of a
      certain size - say 1200 bytes - without any PMTU problems.

      I am very happy about this, because I had thought there
      needed to be some ugly assumptions and config changes as
      the world transitions from primarily 1500 byte MTU systems to
      primarily 9000 byte MTU systems.


Reading up to 4.2.4 (08 to 10 changes are all from 4.2.6 onwards) I
get the strong impression that SEAL's goals are rather different.

The goals seems to be something like this:

  1 - SEAL does not assume or require anything like IPTM's
      assumption of at least a ~1200 byte PMTU clear path from
      any ITR to any ETR.  (ITE to any ETE for SEAL, since the
      proposal is for many settings beyond map-encap.)


  2 - SEAL seems to assume that the ITE could be getting packets
      which have already been wrapped in one or more layers of
      encapsulation - that is they are tunnel packets, and the
      ITE sees the outer header, without knowing how many layers
      of encapsulation there are.

      IPTM copes fine with this too.


  3 - SEAL assumes it cannot send PTBs to the original SH
      of the original packet which is encapsulated to form
      the whole traffic packet it handles.

      This is true of IPTM too.  IPTM assumes the ITR can send
      PTBs to what the ITR regards as the SH, which in this case
      is the last encapsulator - and expect that device, whatever
      it is, it to reduce its packet lengths accordingly.

      If this assumption is not true, then my view is that that
      SH is expecting too much of the Network (including the ITR,
      which it has no direct knowledge of or relationship with)
      in putting out packets which are in fact unsuitable for
      efficient carriage to the DH, whilst ignoring PTBs sent to
      it.

      I think it would be worse than useless for the Network to
      go to special trouble to carry the packets of such SHs.
      Maybe this is one of SEAL's goals.

      I think those SHs need to change their PTB-ignoring ways!

      (I think the Network shouldn't go to any special trouble to
      increase the reliability of long DF=0 packets either.
      Does SEAL go to any such extra trouble?)


  4 - SEAL seems to assume that the initial SH is putting out
      packets of ~1500 bytes and that by various layers of
      encapsulation since then, the total packet size of the
      traffic packet the ITE needs to handle has grown to
      some larger value, such as between 1520 and somewhat below
      2048 bytes.


  5 - SEAL seems to assume that the ITE has no prospect of
      altering the size of these 1500 byte packets which have
      been bloated by encapsulation to be potentially too large
      to fit through the smallest MTU of the routers in the
      tunnel to the ETE.


  6 - SEAL allows for there being multiple other layers of
      encapsulation in the tunnel to the ETE.


  7 - Therefore, SEAL attempts to handle packets up to
      ~2048 bytes in size, and to get them by hook or by
      crook, to the ETE, despite there being MTU limits
      in the tunnel which are well below 1500 bytes.


Differing mechanisms
--------------------

The mechanisms within IPTM (including RPD2) are very different from
those within SEAL.  I don't clearly understand SEAL's, in part
because I am still trying to understand SEAL's goals and in part
because I find it hard to construct a systematic view of SEAL's
algorithm for handling packets of different sizes.


Discussion
----------

Initially I assumed that SEAL (and before that SPRITE-MTU) had goals
pretty close enough to my own at the time.

My October 2008 approach to IPTM was a much messier conception than
now, focussing on trying to handle ~1500 byte packets via tunnels
through ISP and end-user networks and the DFZ in which we may have a
PMTU to the ETR of:

  1500 - map-encap ENCAPS - other unseen ENCAPS overheads

or we may now, and increasingly later, have:

  9000 - map-encap ENCAPS - other unseen ENCAPS overheads

while we have now, and increasingly later, hosts which want to send
~9000 byte packets.

Now I see the goals of these two proposals as very different.  I
don't think SEAL in its current state would be anywhere near as
suitable for a map-encap system as IPTM.

I wonder whether SEAL could be adapted or something like it could be
created to be a general-purpose protocol, useful outside map-encap,
and which embodies the relatively open-ended approach of IPTM -
which I am really happy doesn't involve any hard assumptions about
prevalent MTUs, except for assuming ~1200 clear path to the tunnel
end-point.


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