I think pretty much anything would need that wouldn't it?
- Stewart
On 30/01/2019 18:29, Templin (US), Fred L wrote:
Hi Stewart,
Sounds like that would require some sort of encapsulation protocol and
low-level code in the kernel or hardware to strip the UDP headers, right?
Fred
*From:*Stewart Bryant [mailto:[email protected]]
*Sent:* Wednesday, January 30, 2019 10:15 AM
*To:* Templin (US), Fred L <[email protected]>; Fred Baker
<[email protected]>; Tom Herbert <[email protected]>
*Cc:* int-area <[email protected]>
*Subject:* Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
Hi Fred
I had something quite simple in mind:
Fragment the IP packet just as you do today and send each fragment as
opaque data in a simple 8 byte basic UDP payload with port set to IP.
Set the source port based on a hash of the 5 tuple. Then resemble the
IP just like you always would.
- Stewart
On 30/01/2019 16:55, Templin (US), Fred L wrote:
Hi Stewart,
>> It we really need to fragment a packet, it would be better to
stick the fragments inside a common UDP/IP(no frag) shim.
I agree. Two different approaches for UDP fragmentation that avoid
IP fragmentation
are currently under consideration:
https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
Thanks - Fred
*From:*Int-area [mailto:[email protected]] *On Behalf Of
*Stewart Bryant
*Sent:* Wednesday, January 30, 2019 6:14 AM
*To:* Fred Baker <[email protected]>
<mailto:[email protected]>; Tom Herbert
<[email protected]> <mailto:[email protected]>
*Cc:* int-area <[email protected]> <mailto:[email protected]>
*Subject:* Re: [Int-area] Comments on
draft-ietf-intarea-frag-fragile-06
On 29/01/2019 23:37, Fred Baker wrote:
Section 4.5:
"IP fragmentation causes problems for some routers that support
Equal
Cost Multipath (ECMP). Many routers that support ECMP execute the
algorithm described in Section 4.4 in order to perform flow based
forwarding;
As far as I know, routers that hash fields in the IP header to select a
en ECMP next hop do so because all packets in a flow will hash the same way
(modulo the issues with the transport port number), not because they are doing
per-flow forwarding. The do so explicitly to avoid having to maintain per-flow
state and yet make all fragments of a message follow the same path.
I agree with Fred. ECMP is normally done to distribute the load
over the available next hops on a best effort basis. Originally it
was done per packet, but that gave problems with out of order
packet delivery, so the routers moved to doing it based on the
five tuple described in this draft. It is a stateless best effort
ECMP process with no regard to specific flows and the path for any
five tuple may move arbitrarily if routing changes its mind on the
ECMP set.
Fragmented packets are really bad news in networks that need ECMP.
There is not enough entropy in the SA/DA/Protocol triplet and
anything else results in misorder. But if ECMP is not done this
overloads the default path.
MPLS is also stateless but there are more options, although the
most common is to look past BoS to the five tuple, however some
"features" make mistakes and look at a non-existent five tuple
despite hints in the packet that thus is a bad idea.
therefore, the exhibit they same problematic behaviors
described in Section 4.4. In IPv6, the flow label may alternatively
used as input to the algorithm as opposed to parsing the transport
layer of packets to discern port numbers. The flow label should be
consistently set for a packets of flow including fragments, such
that
a device does not need to parse packets beyond the IP header for the
purposes of ECMP."
Add to section 7.3:
"Routers SHOULD use IPv6 flow label for ECMP routing as described in
[RFC6438]."
If we want to migrate to the FL then we really need to state that
the FL MUST be set by the sender. Without, that we are never going
to wean routers off looking at the five tuple, if indeed we ever
succeed in doing that.
It we really need to fragment a packet, it would be better to
stick the fragments inside a common UDP/IP(no frag) shim. Then the
forwarders could carry on just as they are. We would never get
misorder and we would not be faced with the impossible problem of
changing the Internet core forwarding behaviour to a single
consistent model.
- Stewart
_______________________________________________
Int-area mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/int-area
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
Sun Tzu
_______________________________________________
Int-area mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
