Short version: "Jumbograms" are not the same as "jumboframes".
Discussion of SEAL's support for packets longer
than 1500 bytes and up to 64k bytes - these are
"jumboframes".
Questions about how SEAL detects the PMTU being
too short for the currently sent packets - it
appears to be based on detecting fragmented packets
for IPv4, and by using ICMP PTBs for IPv6. If so
why not use ICMP PTBs for IPv4 too?
When would SEAL segmentation be used? I would
have thought it is never desirable to have
ITRs, ITEs or any intermediate router fragmenting /
segmenting packets into two or more smaller packets
on an ongoing basis. Surely the sending host
should be sent a PTB to cause it to send packets
which, once encapsulated, will fit within the
actual PMTU of the ITR/ITE path to the ETR/ETE.
Hi Fred,
I read the current ID:
http://tools.ietf.org/html/draft-templin-intarea-seal-08
I used the term "jumboframe" to denote IPv4 or IPv6 packets which are
up to about 9kbytes long, as opposed to the conventional length of
~1500 bytes.
Your current ID and your previous mailing list message used the term
"jumbogram", which is IPv6 only and refers to packets of 65,575 bytes
or more (up to 4 gigabytes) - and which have a "Jumbo Payload" option
header.
My IPTM approach needs to be written up more clearly. As far as I
know, it is the only thing which attempts anything similar to SEAL -
although it is purely for use within Ivip, and assumes that the outer
source address of ordinarily tunneled packets is that of the sending
host, not the ITR.
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
IPTM doesn't have any particular upper limit for packet length, other
than that imposed by the 16 bit length fields in the IPv4 and IPv6
headers. Any such packet longer than 1500 bytes is properly
referred to as a "jumboframe". IPTM is not intended to support
"jumbograms".
I think your SEAL proposal is supposed to work with the same - IPv4
and IPv6 packets with normal headers and lengths up to 65,575 bytes.
If so, then I think "jumbogram" is not the correct term to describe
SEAL's capabilities.
Assuming that you do aim to handle both IPv4 and IPv6 packets up to
65,575 bytes, then here is my understanding of how SEAL-SR does it.
There is new text on page 15: "The ITE can alternatively ...".
Before this text is guidance on how the ITE can set an MTU value on
the input of the tunnel to 1500 bytes or greater, or significantly
lower, such as to 576 bytes for for IPv4 and 1280 bytes for IPv6. It
is not very clear how such decisions should be made. The new text
provides a third option:
The ITE can alternatively set an indefinite MTU on the tunnel
virtual interface such that all inner IP packets are admitted into
the interface without regard to size. For ITEs that host
applications, this option must be carefully coordinated with
protocol stack upper layers, since some upper layer protocols
(e.g., TCP) derive their packet sizing parameters from the MTU of
the underlying interface and as such may select too large an
initial size. This is not a problem for upper layers that use
conservative initial estimates, e.g., when mechanisms such as
Packetization Layer Path MTU Discovery [RFC4821] are used.
I understand this as meaning that the ITE (AKA ITR in other CES
architectures) will accept any size packet initially, but may later
change the limit to a lower value and send PTBs to the sending host
(assuming the SH is sending IPv6 packets or IPv4 packets with DF=1).
As far as I know, no applications use RFC 4821. Can you cite any
which do? RFC 4821 involves different applications sharing
information via the operating system about their experience with
packet lengths sent to a particular destination host. This sounds
complex to implement and text - and I guess there is little
motivation for early adoptors amongst application writers if few
other apps do it.
Also, the "ITE which hosts applications" is confusing, since in
RANGER, the ITE is a router. Maybe you mean apps inside the router
which use TCP.
My overall understanding is that if the ITE adopts this indefinite
MTU, and adjusts it downwards if any packets are too big for the PMTU
to the ETR, then you can cope with IPv4 and IPv6 packets up to 65,575
bytes. If so, then this paragraph of my critique no longer applies:
RANGER uses its own tunneling and PMTUD management protocol:
SEAL. ...
However I think the ID should be amended to avoid reference to
"jumbograms".
As best I understand it, SEAL sends all its encapsulated traffic
packets from the ITE to ETE (ITR to ETR) with:
IPv4 DF=0
IPv6 with a Fragmentation header
I understand the purpose with IPv4 DF=0 is so if the packets are too
long for the PMTU to the ETE, that they will be fragmented and the
ETE will therefore receive at least some of the fragments, and so
report this to the ITE (4.4.5.1.2). This is how SEAL works to detect
PMTU problems in the tunnel - rather than relying on RFC 1191 ICMP
PTB packets generated by routers between the ITE an ETE, at least for
IPv4.
In IPTM (for both IPv4 and IPv6) I send a pair of packets, one short
and one long, (perhaps a few copies of the short one, to improve
robustness) for any traffic packet which is longer than the ITR has
previously successfully sent to the ETR. The ETR responds to the
shorter one, and tells the ITR if the long one didn't arrive. (Also,
the ETR will reply to the ITR if only the long one arrives.) These
are DF=1 packets for IPv4 and ordinary (implicitly DF=1) packets for
IPv6.
I think it is bad to send DF=0 packets into the DFZ and expect the
routers to dutifully fragment them if they are too long - though I
know this should not happen frequently with SEAL, since it is just
part of detecting the PMTU.
Do DFZ routers handle IPv6 packets with the Fragmentation Header just
as fast as those without?
With IPv6, does SEAL detect its encapsulated packets being too long
for the ITE to ETE PMTU by relying on ICMP PTB messages from the
limiting router in the ITE to ETE path? (AFAIK, IPv6 packets are
never fragmented by ordinary routers.) If so, then why not do the
same with IPv4 packets?
Assuming the above-mentioned approaches enable each SEAL ITE to
discover the actual PMTU to a given ETE (and to probe occasionally to
see if the value has increased), and assuming it uses this to send
PTB packets to the SH in order that subsequently emitted packets will
be of the right size, once encapsulated, to not exceed this PMTU,
then what is the purpose of the SEAL segmentation system?
Actually, it is trickier. The one SH may be sending to multiple
destination hosts (DHs) all of which are for one or more EID
prefixes for which the ITE is currently tunneling to a given ETE.
Then the ITE needs to send the SH a separate PTB for each too-long
packet it sends to each such DH. Also, there may be multiple such
SHs using this ITE whose packets will be tunneled to this ETE.
If the SH sends a really long IPv4 DF=0 packet, the ITE will use
ordinary IPv4 fragmentation to turn it into multiple shorter fragment
packets, before SEAL processing. (I think, come the Revolution, that
DF=0 packets longer than some value like 1450 bytes or similar should
be *dropped* - applications are expecting too much of the Network to
fragment and carry the fragments of their excessively long packets.
Applications have had since 1991 - RFC 1191 - to change their
free-loading ways.)
Under what circumstances would SEAL segmentation be used?
IPTM does not do any such thing, except for the rare dual-packet
protocol which is used for probing PMTUD to the ETR.
I would have thought it highly undesirable to allow SHs to keep
sending packets which the ITE, ITR or whatever should have to turn
into two or more packets just to get to the ETR.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
