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

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

Fernando,

Thanks for taking the time to comment; please see below
for responses: 

> 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).

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

> * 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.

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.

> * 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.

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 
> 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.

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. 

> * 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?

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.

> * 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.

OK - I'll try to clarify this.

> * 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.

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. 

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

Yep; will fix.

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

OK.

> * 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).

Good point; will fix.

> * Section 4.10. The draft says "maximum receive unit (MRU)"
> 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
fred.l.templin at boeing.com

Just my two cents.

Kindest regards,

--
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






_______________________________________________
Softwires mailing list
Softwires at ietf.org
https://www1.ietf.org/mailman/listinfo/softwires