[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Sprite & IPTM while PMTU probing is in progress
- To: Routing Research Group list <rrg@psg.com>
- Subject: [RRG] Sprite & IPTM while PMTU probing is in progress
- From: Robin Whittle <rw@firstpr.com.au>
- Date: Wed, 28 Nov 2007 13:09:04 +1100
- Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>
- Organization: First Principles
- User-agent: Thunderbird 2.0.0.9 (Windows/20071031)
Hi Fred,
Here is a diagrammatic explanation of how IPTM would works, and a
question about how Sprite would work. I haven't been able to
understand your ID clearly enough to answer this myself.
http://tools.ietf.org/html/draft-templin-inetmtu-06
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
IPTM only sends a PTB message to the SH after it has reliably
ascertained the PMTU to the ETR - and then only when the SH sends it
a packet which is of a length which would exceed that PMTU, once it
was encapsulated. Until then (with the first such "long" packet,
and with any others which arrive while the ITR is probing) "long"
outer packets are fragmented, whether or not the inner packet has
its DF flag set, to be reassembled at the ETR before decapsulation.
A "long" inner packet is one which, once encapsulated, would exceed
the ITR's current best estimate of the PMTU. This would initially
be a default such as 1280 bytes. If this default value is above the
minimum for the protocol, eg. 576 for IPv4, then this value of PMTU
to the "core" of the net must be available to every ITR and ETR and
would be part of the specification of the ITR-ETR scheme.
(Did you mean "1280" instead of "1500" in:
"For IPv6, the minimum EMTU_R is 1500 bytes ..."
http://psg.com/lists/rrg/2007/msg00623.html ?)
The default value would be replaced by a higher value once the probe
process was complete. The pattern would be something like this,
assuming the SH's initial idea of PMTU to the Destination Host was
1500. I will assume an ENCAPS overhead of 20 bytes (as with IPv4
Ivip, though other ITR-ETR schemes have higher overheads) and that
all ITRs and ETRs are located so they have an MTU of at least 1280
from the DFZ.
Inner ITR action on SH's idea DH gets
packet outer packet of PMTU
length following encapsul- to DH
ation of inner packet
1500
200 Send outer packet - 1500 The packet
the length is less than
1280.
1500 Fragment packet and 1500 The packet
commence probing (Less efficient
and more error-
prone tunnel with
2 packets instead
of 1, but this is
only for a few
seconds, I hope.)
1500 Fragment packet and 1500 The packet
continue probing
... etc.
Probing complete:
PMTU to ETR decided
to be 1460.
1400 Send outer packet - 1500 The packet
the length is <= 1460.
(This length would not
necessarily be sent - it
is just to show that the
ITR will now send longer
packets without frag-
mentation than before.)
1500 Drop the packet and send
the SH a PTB message
with value 1440. 1440 Nothing, but the
ITR is usually
close to the SH,
and it doesn't
take long for...
1440 Send the outer packet - 1440 The packet
the length is <= 1460 (Now the tunnel
is handling
optimal length
packets.)
This pattern would continue unless the ITR, with periodic probing,
decides that the PMTU is less than 1460 (it might do this quickly if
it got a PTB message from a router in a new, more MTU-challenged,
path to the ETR), and if the SH sends a packet which would be too
big for the new lower value of PMTU. Then the ITR would send
another another PTB message to the SH, with a lower value than 1440.
Alternatively, occasional probing by the ITR might discover a higher
value of PMTU to this ETR, and the SH could discover this increase
by trying its luck with a larger packet - and either having it
accepted, or rejected with a PTB containing the new higher value,
minus 20.
Sprite, as I understand it for IPv4 ...
(Fred, the "Section 5.5.x" numbers in Figure 2 should be "5.6.x"
except for 5.5.6, which should be 5.6.5. Other references
in the ID to "5.5.4" etc. may also need correction.)
... actually, I don't understand it clearly enough to describe it.
I think Sprite will fragment outer packets, as does IPTM,
irrespective of the DF flag of the inner packet. The criteria for
which IPv4 outer packets are fragmentable is complex (5.6.4).
I am not sure how Sprite handles "large" outer packets while it is
probing. Does it fragment them as IPTM does? Or does it do the
following, which is the same as what it does for a "long" packet
once the PMTU has been reliably ascertained:
(5.6.5) "... admits the packet but also sends a PTB message ..."
It seems strange to me to send the packet (unfragmented, I assume)
while also sending back a PTB message to the sending host. Wouldn't
this cause needless traffic and/or confusing signals to the SH if
the outer packet does in fact arrive at the ETR and therefore the
inner packet is delivered to the destination host?
Here I will assume IPv4 only, with 1280 bytes for the default PMTU
for every ETR the ITR has not yet probed. I will also assume an
encapsulation overhead of 20, although this would typically be
higher for Sprite and non-Ivip ITR-ETR schemes.
If the ITR sends a PTB message to the SH when the first packet (or
multiple packets) length exceeds the default PMTU value and then,
after probing, decides the PMTU is 1480, then I am concerned that
the SH would get contradictory values in these PTB messages.
At first the SH would be told to send packets no longer than (1280 -
20 = 1260) and later, it would be told to send packets no longer
than (1480 - 20 = 1460).
But if the SH took notice of the first PTB message, it probably
wouldn't send any longer packets which would trigger the second.
So, if my understanding of Sprite is correct, the SH would
experience something like this:
Inner ITR action on SH's idea DH gets
packet outer packet of PMTU
length following encapsul- to DH
ation of inner packet
1500
200 Send outer packet - 1500 The packet
the length is less than
1280.
1500 Send packet and Probably nothing
commence probing - however, if the
Send PTB with value packet was a little
1260 1260 shorter, such as
1440, then it may
arrive at the ETR
in one piece,
despite the SH
being told it was
too big.
SH breaks the message
into smaller packets
and retries:
1260 Send packet and 1260 The packet
continue probing
... etc.
Probing complete:
PMTU to ETR decided
to be 1460.
1260 Send outer packet - 1260 The packet
the length is <= 1460.
1260 SH would probably keep The packet -
sending packets of but more and
length <= 1260. Unless shorter
the SH was pushy, it packets than
would never discover the the ITR-ETR
PMTU it could use was tunnel can
in fact 1440. handle.
- 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