Erblichs wrote:
John Heffner,
Interesting..
A few Short comments.. Possible fixes in #1, #4, #5, and #6.
1) Does your 26 Mbps flow rate in section 2, almost imply that
a connection should be multiplexed so that each sub connection
has a bps rate of 26Mbps to remove this issue in IPv4 if
fragmentation is an issue?
The problem occurs independently of flows. It only depends on src,dst
address pair.
2) How does xmit of say a 9k jumbo segments effect this?
Wasn't their work into accepting 9k size segments a few
years back?
Using 9k frames instead of 1500 as in the examples scale the rate at
which the problem can occur up by a factor of six.
3) Does the use of say a 3/4 multiplier for the actual transmit
size decrease the linklyhood of a fragment? Could we have tacked
an additional header that caused the fragmentation, that this
would fix?
There are many ways fragments can be created, not just from an extra
tunnel header. For example, it's natural to want to send
disk-block-sized datagrams. If the block size is >PMTU, then you end up
fragmenting.
4) If a fragment does occur and out-of-order segments are
seen should a algor like the fast-xmit used be implimented
to drop the partial set of recv'd fragments. TCP will force the
entire set to be rexmit'ed, right?
What you're describing is like what Linux does now. It works pretty
well under most realistic conditions. Aside from some theoretical
corner cases, a couple practical issues:
1) The sender has no way of knowing that the receiver is implementing this.
2) NATs.
5) Some datagrams being delivered to a system are comprised
of distinct objects which if modified are detected.
- compressed files.
I assume that the distinct items being created is not in the
scope of this memo, but decrease the chance of a TCP checksum
being accepted at a higher layer.
However, if the above is true, would it be wise on some object
types to do a non-lossy compression before xmit knowing that the
expand would detect any abnormalities????
You could... Cryptographic hashes would be better yet.
6) It sounds like some type of SACK ack that states
fragmented segment dropped, redo your path MTU and decrease
segment size; is NEEDED.
When MTU discovery is working, and the DF bit is not ignored, it should
be adequate.
Thanks,
-John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
