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

[Joe Touch <[e-mail]>]

On 5/31/2012 10:47 AM, Templin, Fred L wrote:
> Hi Joe,
>
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Thursday, May 31, 2012 9:59 AM
>> To: Templin, Fred L
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
>> 05.txt
...
>> That would change things by a factor of 2.
...
> A 2X performance increase is not insignificant. And,
> there seemed to be some interest for the use of IPv4
> fragmentation for IPv4-over-IPv* tunnels.

Perhaps for other uses - as you note - but not to the discussions that 
are the focus of this draft. Which is why, IMO, it should be the focus 
of a different 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?

>> If others disagree, they should speak up.
>
> This has implications for IPv4-over-IPv* tunnels,
> which have been discussed on the v6ops list recently.

Perhaps, but only as a factor of 2 improvement, and you're raising a 
change that is new.

Again, since this is for a different motivation and because it's not 
documenting existing widespread practice, this seems appropriate for a 
separate document.

>> ...
>>>>>> Also, in the document's introduction, it says:
>>>>>>
>>>>>>     "In IPv4, the Identification (ID) field is a 16-bit value that is
>>>>>>     unique for every datagram for a given source address, destination
>>>>>>     address, and protocol, such that it does not repeat within the
>>>>>>     Maximum Segment Lifetime (MSL) [RFC791][RFC1122]."
>>>>>>
>>>>> Isn't the correct reference for MSL actually RFC793?
>>>>
>>>> Yes; that should read "maximum datagram lifetime" as per RFC 791. I can
>>>> fix that in AUTH48. Thanks,
>>>
>>> Maximum datagram lifetime per RFC791 doesn't talk about
>>> the 120sec that your document discusses; Maximum Segment
>>> Lifetime per RFC793 is the one that talks about 120sec.
>>> If you want to talk about 120sec and MSL, you need to
>>> cite RFC793 instead of RFC791.
>>
>> Segments aren't datagrams. RFC793 talks about segment lifetimes. RFC1122
>> is the only one that talks about datagram lifetimes, relating the
>> lifetime described in 791 to 120 seconds.
>>
>> I.e., the references are correct, but the term should be "maximum
>> datagram lifetime", not "maximum segment lifetime". There is certainly a
>> historical note that the 120 seconds in RFC1122 is likely related to
>> RFC793, but that's conjecture - 1122 Sec 3.3.2 states that the lifetime
>> should be between 60 and 120 seconds, and recommends 120 seconds without
>> reference to 793.
>
> That's not how I read the discussion beginning at the
> bottom of P. 57 of RFC1122. In my read, that text clearly
> points to the 120sec as being derived from the TCP MSL
> specification.

The top of page 58 refers to TCP MSL (page 57 does not). And even if it 
refers to 793 as one component in the derivation of the recommendation 
in 1122, it is still 1122 that should be cited, not 793, IMO.

JOe