Hi, Masataka,
On 6/15/2012 5:01 AM, Masataka Ohta wrote:
Joe Touch wrote:
Hi,
Hi,
But, then,
>> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination
address/protocol triple.
makes most, if not all, IPv4 hosts non compliant if MSL=2min.
This is already noted throughout this document, however there is little
impact to such non-compliance if datagrams don't persist that long.
So, the question to be asked is how long datagrams persist.
As you now say MSL may be smaller than 2min, the draft is
useless to promote implementers implement rate limiting.
If you can't define hard value of MSL, implementors can
assume anything.
MSL is not defined on a network unless it is enforced throughout the
network. The only MSL that matters is how long segments persist between
a pair of endpoints, which is why the draft states the requirement this way.
This was discussed at length in the WG and led to the language used
throughout this document.
The section you quote above later already states:
Because there is no strict definition of the MSL, reassembly hazards
exist regardless of the IPv4 ID reuse interval or the reassembly
timeout. As a result:
...
Perhaps we should change "is no strict definition" to "can be no strict
definition"?
Worse, without hard value of MSL, it is a meaningless
requirement. Note that MSL=2min derived from RFC793 breaks
150Mbps TCP.
It breaks at 6.4 Mbps for 1500 byte packets, as is already noted in the doc.
With practically very low probability.
"Breaks" means 'breaks the requirement'. The probability of doing this
for 1500-byte packets at 6.4 Mbps is 100%.
If you mean "and this causes problems", it generally doesn't because:
a) most packets aren't fragmented
and
b) fragments aren't reordered over the full 120-second delay
The problem is that you can't know the max fragment delay variability on
a path.
The proper solution, IMHO, to the ID uniqueness is to request
a destination host drop fragments from a source host after
it receives tens (or hundreds) of packets with different IDs
from the same source host.
That doesn't help ID uniqueness; it helps avoid fragmentation
overload.
It does help ID uniqueness, because fragments with accidental
matches are quickly discarded.
FWIW, such issues were discussed at length in the INTAREA WG when this
doc was developed.
I appreciate that the draft is terse not including so lengthy
discussions in the WG.
However, at the same time, don't expect me to read all the log
of the discussions in the WG, especially because you and
the discussions misunderstand the problem as:
That doesn't help ID uniqueness; it helps avoid fragmentation
overload.
That does help ID uniqueness.
Again this was discussed in the WG and the conclusion of the group was
that it did not help. The document does not include the full text of the
discussions of the WG, nor does it include all alternatives that were
not selected.
If you can point to a specific thing we need to include, please let us know.
Joe