[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] SEAL & IPTM: differing goals
- To: Routing Research Group <firstname.lastname@example.org>
- Subject: [RRG] SEAL & IPTM: differing goals
- From: Robin Whittle <email@example.com>
- Date: Tue, 22 Apr 2008 12:45:40 +1000
- Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>
- Organization: First Principles
- User-agent: Thunderbird 18.104.22.168 (Windows/20080213)
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.
The SEAL Internet Draft is:
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
A terse description of my new IPTM (ITR Probes Tunnel MTU) proposal
with follow-up discussions is here:
The full description is here:
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
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
* As currently described, IPTM sends IPv4-in-IPv4 packets
to the ETR with DF=1. (I didn't specify this - just assumed
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
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
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
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.
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.
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
to unsubscribe send a message to firstname.lastname@example.org 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