Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt

["Templin, Fred L" <[e-mail]>]

Hi Julien,

> -----Original Message-----
> From: Julien Laganier [mailto:[e-mail]]
> Sent: Thursday, May 31, 2012 3:17 PM
> To: Templin, Fred L
> Cc: [e-mail]; Joe Touch; Brian Haberman
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> 05.txt
> 
> Hi Fred,
> 
> With WG Co-chair hat on,
> 
> Changing MSL to Maximum Datagram Lifetime is a minor and almost
> editorial change that I recommend we make since the use of MSL and
> possible reference to RFC793 could implicitly restrict the scope of
> the document to TCP, which is not the case -- this doc applies to IP
> irrespective of the transport protocol in use.

>From Section 3.3.2 of RFC1122:

  "If the reassembly timeout is set too high, buffer
   resources in the receiving host will be tied up too long,
   and the MSL (Maximum Segment Lifetime) [TCP:1] will be
   larger than necessary.  The MSL controls the maximum rate
   at which fragmented datagrams can be sent using distinct
   values of the 16-bit Ident field; a larger MSL lowers the
   maximum rate.  The TCP specification [TCP:1] arbitrarily
   assumes a value of 2 minutes for MSL.  This sets an upper
   limit on a reasonable reassembly timeout value."

This clearly shows that the value 120 for reassembly timeout
came from the TCP MSL specification, and does not take other
transport protocols into account. For historical correctness,
the 'ipv4-id-update' document should therefore continue to
cite "MSL" but should identify RFC793 (and not RFC791) as
the reference.

> As to the other change about the reassembly timeout, I agree with Joe
> that this is out-of-scope of this document in its current form, and I
> do not think it is appropriate to use a document as a vehicle for
> changes that are out-of-scope. Furthermore, this document as been in
> the hands of the Intarea WG for a fair amount of time during which the
> consensus has been that no changes should be made to the core IP
> specifications unless something is broken. Your proposal to include
> considerations on reassembly timeouts does not seem to fix something
> that is broken in IP and as such is against the consensus of that WG.
> With both these in mind I recommend against it.

Based on recent discussions on the v6ops list regarding
tunneling protocols that perform IPv4 fragmentation, I had
an obligation to ask for a more favorable reassembly timeout.
Others who were involved in those discussions have had fair
opportunity to comment have not done so. I therefore withdraw
the request. 

> That being said it is up to our AD and the IESG to consider your IETF
> Last Call comments as well as my recommendation on a disposition.

Please forward the above comments for their consideration
also.

Thanks - Fred
[e-mail]

> Regards,
> 
> --julien
> 
> On Thu, May 31, 2012 at 1:34 PM, Joe Touch <[e-mail]> wrote:
> > Hi, Fred,
> >
> >
> > On 5/31/2012 12:13 PM, Templin, Fred L wrote:
> >>
> >> Hi Joe,
> >
> > ...
> >
> >> As you know, the bar for documents that would update
> >> bedrock specifications such as RFC791 and RFC1122 is
> >> set very high indeed. That your document has made it
> >> to this level of maturation is a tribute to your many
> >> years of concerted effort, which would best be amortized
> >> if this useful addition can also be applied.
> >
> >
> > As you note, this doc has taken a lot to get to its current state.
> >
> > Nothing should be added that isn't core to its purpose AND agreed by the
> > community. Your proposed change doesn't meet either criteria - your only
> > reason for adding it is to get a "free ride", and I don't think that's
> an
> > appropriate suggestion for *any* doc.
> >
> >
> >>>>> - reducing the timeout is not current practice AFAIK
> >>>>>        so we'd be adding a new recommendation, rather
> >>>>>        than even documenting existing practice
> >>>>>
> >>>>> - my conclusion, based on "keep it simple", is to not include this
> >>>>> recommendation in this document
> >>>>
> >>>>
> >>>> Let me ask, do you know of any implementations that have
> >>>> ever benefitted from keeping the fragments of an incomplete
> >>>> reassembly for longer than 60sec? (Linux for example only
> >>>> waits 30sec before discarding fragments.)
> >>>
> >>>
> >>> I don't, but that's a discussion that should happen - as you note
> below
> >>> - involving those on a different list as well, for a different reason.
> >>> Linux does a lot of things that are not standard, but that alone is
> not
> >>> necessarily a reason to document it as best practice - e.g., why are
> you
> >>> not suggesting 30 sec?
> >>
> >>
> >> 60sec is consistent with both RFC1122 and RFC2460.
> >
> >
> > RFC2460 isn't relevant to the reassembly requirements of IPv4; if it
> were,
> > it would be 120 seconds, or would have updated RFC1122 itself.
> >
> > ...
> >
> >> If you want to call it MSL you need to cite RFC793. If
> >> you want to change all occurrences of MSL to something
> >> else, then you could get away with citing only RFC1122.
> >> My preference would be to keep it as MSL and cite RFC793.
> >
> >
> > It's only MSL in that one place in this doc, but it's intended to refer
> to
> > maximum datagram lifetime since this doc has no other reference to
> transport
> > protocols.
> >
> > Joe
> >
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area