[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] RE: Critique of Sprite-MTU: PMTUD, fragmentation etc.
Robin,
I will address the points from the critique on your
webpage below:
> 1. The ITR needs to create state for every "tunnel" - and
> a "tunnel" is created by a single packet being sent to a
> single ETR. This packet could be very short, as might all
> subsequent packets - such as for VoIP, DNS or other protocols,
> and so would never actually need any intervention on the part
> of the ITR regarding PMTU, PMTUD or fragmentation. Creation
> of this state - and the consequent need to manage it and
> eventually delete it - seems to be an onerous and unnecessary
> burden on ITRs for just one traffic packet. Creation of this
> state, and management of it, would probably involve (in a
> traditional router) considerable effort by the router's
> central CPU, rather than straightforward effort by the FIB
> processors/hardware.
There may be wording in the draft that led you to conclude
that there are absolutes, and if so I would be happy to fix
it in the next draft version. But, there is nothing wrong
with an implementation that initially operates in "legacy mode"
with minimal soft state and then shifts over to sprite-mtu mode
when it becomes evident that a tunnel is seeing non-negligible
use. Moreover, soft state is required for any approach that
would aspire to larger MTUs than the minimums cited for the
legacy mode of operation. Finally, the degree of effort for
managing soft state depends somewhat on the location of the
ITR; ITRs that are located closer to the edge of the network
might have less trouble managing the soft state than those
located nearer to the core.
> 2. Continuation of mandatory sprite communications for probing
> PMTU seems to be an onerous and unnecessary burden on ITRs
> which handle only one packet, or only a few, or only packets
> which are so short as to not require any special management of
> PMTU, fragmentation etc. Sprite communications are supposed to
> continue as long as the traffic is flowing in the tunnel, and
> one interpretation of that is that the sprite communications
> should begin with the first traffic packet. So a single packet
> would trigger the generation of state in the ITR and the ETR,
> with multiple packets flowing back and forth, until the ITR
> decided that there was no need to continue - some time after
> the one and only traffic packet arrived.
The draft doesn't currently say this, but there is no need
for the continuous sprite exchanges once there is evidence
that the path MTU is larger than the minimums (1280+ENCAPS
for IPv6/*/IP and 576 for IPv4/*/IP), since the purpose for
the continuous sprite exchanges is to mitigate fragmentation
related misassociations at high data rates. This can be
addressed in the next draft version.
> 3. Under certain common circumstances, in particular the
> first traffic packet which is longer than a certain length,
> the ITR would send back an ICMP Packet Too Big (PTB) message
> to the sending host, even though it sends the resultant
> encapsulated packet. This would mean (for IPv4) that the
> first attempt by the sending host to send a packet longer
> than about (576 minus encapsulation overhead) bytes would
> result in the sending host reducing its estimation of the
> Path MTU to the destination host - to an unrealistically
> low value. Meanwhile, the ITR is required to send the packet,
> with DF=1, to the ETR, where it may well arrive and be
> forwarded to the destination host. So the sending host has
> contradictory signals from the outside world. It is likely
> to get the PTB message first, and so send the same packet as
> multiple fragments. Meanwhile, the receiving host responds
> to the first packet and sends a response (actually, not all
> packets are part of protocols which would generate a response),
> which may arrive before, during or after the sending host
> emits the fragmented form of its initial packet. There is
> great potential for confusion at the sending host, especially
> with RFC4821
It seems reasonable to expect that the initial packets over
a tunnel (e.g., TCP SYN, TCP ACK, etc) will be small enough
that the TNE would not need to generate a PTB back to the
original source. (Isolated large packets would typically be
sent with DF=0 for IPv4, or as 1280byte or smaller fragments
for IPv6.) Moreover, RFC4821 implementations will take care
to not expose packets of an unprobed size to loss due to an
MTU restriction such that for those implementations the most
likely packets to trigger a PTB from the TFE are the probe
packets themselves.
There is evidence in RFC4821 that the sending host would
not be confused by the contradictory information of both
a probe confirmation and a PTB response for the same probe
packet. In Section 2:
"The isolated loss of a probe packet (with or without an
ICMP Packet Too Big message) is treated as an indication
of an MTU limit"
and:
"Packetization Layer PMTUD (PLPMTUD) introduces some
flexibility in the implementation of classical Path
MTU Discovery. It can be configured to perform just
ICMP black hole recovery to increase the robustness of
classical Path MTU Discovery, or at the other extreme,
all ICMP processing can be disabled and PLPMTUD can
completely replace classical Path MTU Discovery."
and:
"In the limiting case, all ICMP PTB messages might be
unconditionally ignored, and PLPMTUD can be used as
the sole method to discover the Path MTU."
Also, in Section 7.6.2:
"If an ICMP PTB message is received matching the probe
packet, then search_high and eff_pmtu MAY be set from
the MTU value indicated in the message. Note that the
ICMP message may be received either before or after the
protocol loss indication."
Fred
fred.l.templin@boeing.com
> -----Original Message-----
> From: Robin Whittle [mailto:rw@firstpr.com.au]
> Sent: Tuesday, October 30, 2007 2:08 AM
> To: Routing Research Group list; Templin, Fred L
> Subject: Critique of Sprite-MTU: PMTUD, fragmentation etc.
>
> I have a revised critique of Fred Templin's proposal:
>
> http://tools.ietf.org/html/draft-templin-inetmtu-05
>
> at my IPTM (ITR Probes Tunnel MTU) page:
>
> http://www.firstpr.com.au/ip/ivip/pmtud-frag/#sprite_critique
>
> The three elements of the critique apply to the use of Sprite-MTU in
> an ITR-ETR system (at least for IPv4). The third element may be
> applicable to the many other uses which Sprite-MTU is intended to
> help with.
>
> In brief (please read the full critique before responding), they are:
>
> 1 - The ITR has to set up state even when a single short
> (too short to be a problem for MTU limits) packet is
> tunneled to an ETR.
>
> 2 - The ITR and ETR have to continually engage in Sprite-MTU
> communications as long as packets are tunneled to the ETR -
> and this should arguably start with the first packet.
>
> Both these place a huge load on the ITR, for just a single packet -
> which doesn't even need any MTU management. My proposal avoids such
> overheads, by being triggered only by longer packets.
>
> 3 - The initial response of the ITR to a longer packet is to
> send back a Packet To Big message to the sending host and
> to tunnel the packet. The sending host will then resend
> the packet (and probably subsequent packets) in multiple
> small fragments - but the original packet may arrive at
> the destination host and be acknowledged. This contradictory
> response is likely to cause trouble for sending hosts,
> including those implementing RFC 4821, as well as being a
> source of extra packets, confusion etc.
>
>
> This tunneling, MTU, fragmentation, PMTUD stuff is really challenging.
>
> So far, Fred's proposal and my own IPTM (ITR Probes Tunnel MTU) are
> the only two which are applicable to the ITR-ETR schemes we are
> discussing on this list.
>
> I would really appreciate some critical assessment of IPTM, and
> likewise some confirmation or otherwise of my critique of Sprite-MTU.
>
> - 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