Subject: [Softwires] Feedback on draft-templin-mtuassurance-01.txt

From: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 20:20:06 -0300

Fred,

I read your draft draft-templin-mtuassurance-01 . Here some issues 
that, at least for me, need some clarification:

High-order bit: After reading the whole draft, what I understand is 
that you want to create some sort of PMTUD to be implemented at 
tunnel endpoints, completely independent of the current PMTUD. 
However, I didn't get to this point until reading the whole document. 
I'd probably make this clear in the Introduction (and maybe the abstract, too).

* In the abstract, the draft says:
    IP-in-IP tunnels present a Maximum Transmission Unit (MTU) to layer 3
    via static prearrangements and/or dynamic MTU determination based on
    layer 2 ICMP messages

The numbers you use for the layers confuse me. For example "Layer 2 
ICMP messages" makes me think of something like "link layer ICMP" 
which does not make sense. There are other instances of this. For 
example, in the Introduction you talk about "Layer 2 network-based 
fragmentation", which sounds confusing to me. In Section 2 you talk 
about "the layer 2 IP headers of tunneled packets". Unless these are 
all conventions that are assumed in the reader from, let's say, the 
softwire problem statement draft, it is confusing.

* Section 3, "Problems with Path-MTU Discovery"
If you implement PMTU for the tunnel, when you receive an ICMP 
message at the tunnel, you'd like to signal the sending system (the 
one transferring information over the tunnel) so that it reduces the 
size of the packets it sends. Unfortunately, only the original IP 
header plus the first 64 bits of the packet that elicited the error 
message are required to be included in the payload of the ICMP error 
message. Thus, the information included in the ICMP payload may not 
be enough to signal which of the endpoint behind the tunnel should be 
signaled about the "frag needed" error condition. RFC 1812 states 
that "the ICMP payload SHOULD include as much information from the 
orginal packet as possible", though. But I'm not sure how many 
implementations actually honor RFC 1812.

* Section 4.4. The draft says:
"The reassembly must occur
    after layer 2 IP reassembly (and prior to layer 3 delivery), since it
    is possible that the segments may have also incurred fragmentation
    along the path.

I assume that the tunnel will set the DF bit in the packets it sends. 
Thus, by saying "layer 2" reassembly you are assuming that there are 
systems that, even when the DF bit is set, may fragment IP datagrams. Right?

* Section 4.5. The draft says "packet splicing".
I'm not sure what this term means. Unless it's well known in the 
"tunneling" literature, you should probably clarify it.

* Section 4.6
Here you talk about out-of-order packets. But it's not clear to me 
why an MTU assurance mechanism would have to deal with that.

* Section 4.7. The draft says "in-of-band"
Shouldn't it be "in-band"?

* Section 4.9. The draft says "path MTU"
I'd write it as "Path-MTU"

* Section 4.9. The draft says "path MTU reductions, e.g, due to route 
fluctuations, have occurred."
s/reduction/ , s/have/has". (A probe can only check for *one* 
reduction... you never know if the Path-MTU decreased many times, in 
different steps... but well... it's a detail).

* Section 4.10. The draft says "maximum receive unit (MRU)"
Where is this term defined?

Just my two cents.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 May 2006 11:22:12 -0700

Fernando,

Thanks for taking the time to comment; please see below

> I'd probably make this clear in the Introduction (and maybe the
abstract, too).

Your read of the entire document is correct, and agree that
it could be made more clear in the abstact and introduction.

> softwire problem statement draft, it is confusing.

Hmm; I see the point and will try to come up with a way to clarify.
The solution document avoids this layer-3/layer-2 nomenclature for
the most part, so I'll try to follow that same example.

> signaled about the "frag needed" error condition.

Right; so, any tunnel MTU assurance solution should try to
avoid sending tunneled packets that could generate ICMP packet
too big messages that should be signaled back to the sending
system.

Note that it may not always be possible to avoid ICMP packet too
bigs, which means that in some cases the sending system might not
be notified of an MTU restriction for the first oversized packet
it sends. But, the tunnel encapsulator should discover the MTU
restriction and be able to inform the sending system for subsequent
oversized packets.

Maybe there is an additional requirement needed here?     

> RFC 1812 states 

My personal opinion is that the solution should assume the
worst-case of 64 bits and make a best-effort to avoid sending
tunneled packets that might elicit ICMP packet too bigs. 

> systems that, even when the DF bit is set, may fragment IP datagrams.
Right?

It could be that the tunnel will decide to *not* set the DF bit
in the packets it sends. Setting or not setting the DF bit would
be an implementation decision that has tradeoffs to be analyzed
under both alternatives. For implementations that set the DF bit,
I have heard that there are systems that can fragment IP datagrams
even when the DF bit is set but I don't have any first-hand data
on this.

> "tunneling" literature, you should probably clarify it.

OK - I'll try to clarify this.

> why an MTU assurance mechanism would have to deal with that.

This relates to the reassembly algorithm and reassembly buffer
management. IPv4 and IPv6 fragmentation/reassembly have a
means for accommodating out-of-order arrival of fragments,
but it could be that the solution would use a reassembly
mechanism that does not resemble those. In any case, the
reassembly mechanism is required to accommodate out-of-order
delivery whether it looks like IPv4/6 reassembly or something
else altogether different. 

> Shouldn't it be "in-band"?

Yep; will fix.

> I'd write it as "Path-MTU"

OK.

> different steps... but well... it's a detail).

Good point; will fix.

> Where is this term defined?

I believe RFC1122 might be an appropriate reference here,
but RFC1122 calls it "Effective MTU to receive (EMTU_R)".
I'll add a citation.

Thanks - Fred
[email-masked]

Just my two cents.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 May 2006 08:42:02 -0300

At 15:22 26/05/2006, Templin, Fred L wrote:

Fred,

You'll find my responses inline....

>it could be made more clear in the abstact and introduction.

Yeah. The document is not lengthy, anyway. But I would appreciate to 
get the big picture at the beginning on the document.

>the most part, so I'll try to follow that same example.

After reading the document a few times, I get the idea. But layer 
numbers is so OSI-speak, the text confusing, where it needn't be.

>Maybe there is an additional requirement needed here?

One one hand, I would that part of the stuff I posted above to the 
section  "Problems with Path-MTU Discovery".

Then thinking out loud, I'm thinking about this:
The tunnel would have an assured MTU. This MTU would be the Path-MTU 
(minor the bytes needed for the tunnelling mechanism, of course) 
between the two endpoints of the tunnel.

Now, let's say that one host tries to send a datagram that is larger 
than the "virtual MTU" of the tunnel. In that case, the tunnel should 
not even bother in tunnelling the datagram. The tunnel should simple 
send an ICMP "frag needed" to the sending system, advertising the 
"virtual MTU" of the tunnel.

Now let's say that a host sends a datagram that is *smaller* than the 
"virtual MTU" of the tunnel, but, because of a change in the route 
that packets follow, at some point it is impossible to forward the 
resulting datagram (i.e., tunneling overhead + original datagram). 
The router in question would send an ICMP "frag needed". The tunnel 
endpoint would receive it, and would update the "virtual MTU" of the 
tunnel accordingly. Now, if the payload of the ICMP error message 
contains enough information to identify the host that had sent that 
encapsulated datagram, then that host would be signalled of the 
condition by means of an ICMP "frag needed" generated by the tunnel endpoint.
If the ICMP error message didn't contain that much information, then, 
no problem, anyway: The tunnel endpoint updated its "virtual MTU", 
anyway. So when the host tries to, say, retransmit that datagram that 
never got to destination, the tunnel endpoint (which we assume is 
"close" to that host) will send the host an ICMP "frag needed", and 
the sending host would end up updating its assummed Path-MTU.

Just thinking out loud....

(Kinda "recursive PMTUD"... isn't it? ;-) )

>tunneled packets that might elicit ICMP packet too bigs.

Agreed.

> > "The reassembly must occur after layer 2 IP reassembly
> > (and prior to layer 3 delivery), since it

I have heard of the same thing. Actually, I recall hearing that they 
fragment the datagram, but also send an ICMP "frag needed".

However, given all the known problems of fragmentations, I'd try to avoid it.

>else altogether different.

Not sure what you mean by "something else altogether different"....

>but RFC1122 calls it "Effective MTU to receive (EMTU_R)".

Okay. My point was basically that it wasn't clear what the term 
referred to. I would probably include a definition within the draft.

Kindest regards,

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 May 2006 13:06:03 -0700

Fernando,

Agree with pretty much everything you said. About the case when
the "virtual MTU" of the tunnel is invalidated due to a route
change, some implementations might try to finesse that scenario
by not setting the DF bit in the tunneled packets and sending
probe packets periodically to see if the tunnel is fragmenting.
That way, the period during which fragmentation could occur is
kept small and the encapsulator would never be caught in the
ambiguous situation of what to do with a "fragmentation needed"
ICMP that can't be translated and forwarded back to the source.
(The alternative, of course, is to set the DF bit on every
tunneled packet and allow the sender to timeout and retransmit
if the virtual MTU changes.) 

About the "something else altogether" comment, I was meaning
to imply that the segmentation/reassembly procedure  that
occurs between the tunnel encapsulator and decapsualtor need
not be the same as the IPv4/6 specifications for fragmentation
and reassembly.

I guess the real question in my mind is whether this wg is
interested in looking into this area in more detail. IMHO,
some form of tunnel MTU assurance is necessary from a
robustness and efficiency standpoint. If tunnels are to be
used on a wide scale, then it seems like their performance
characteristics should approach as closely as possible to
those of a non-tunneled scenario. So, where should the work
be done if not here?

Fred

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Saturday, May 27, 2006 4:42 AM
To: Templin, Fred L; [email-masked]
Subject: RE: Feedback on draft-templin-mtuassurance-01.txt

Fred,

condition by means of an ICMP "frag needed" generated by the tunnel
endpoint.

Agreed.

> > systems that, even when the DF bit is set, may fragment IP
datagrams.

However, given all the known problems of fragmentations, I'd try to
avoid it.

Kindest regards,