Thanks Ole. Imagine a usecase where I am getting IP packets on my graph node. I encapsulate them into an outer IP and send them out. So let's say in my example, I get IP1 and IP2. IP1 is max mtu size and IP2 is a shorter one. Perhaps they themselves are part of a fragmented flow. I now encapsulate IP1 with an outer IP for tunneling. This topples the mtu size and I send it out ip4-lookup, and in my for loop I operate on IP2 also and encapsulate it in outer IP and send it again to ip4-lookup. This triggers my usecase that I described earlier. You can imagine that effectively I have managed to reorder the original IP flow (now the inner IP packet) towards the final receiver which is never good for eg. end to end TCP flows.
Regards -Prashant On Wed, Nov 14, 2018 at 3:03 PM Ole Troan <otr...@employees.org> wrote: > > Prashant, > > > I have a usecase where I have two IP Datagrams, let's call them IP1, > > IP2. Each contains UDP Payload. > > IP1 size is bigger than mtu. > > IP2 size is lesser than mtu. > > > > I ship these both one after the other in that order to ip4-lookup. > > > > IP1 gets fragmented, as expected, to IP1.1 and IP1.2 and the fragments > > are shipped out. > > IP2 does not get fragmented and gets shipped out. > > > > However I see that the final destination UDP receiver gets UDP payload > > of IP2 packet first, then it gets the UDP payload of IP1 packet. > > It seems that VPP has sent out the IP2 packet out first and then the > > fragments of IP1. > > > > Is this an expected behaviour ? I do intuitively understand that > > fragmentation must be involving further graph nodes to traverse and > > thus the fragments are sent out later for IP1. > > It’s certainly expected. > But is it an optimal outcome, probably not. > Not sure how to fix that, unless we want to insert the fragments back into > the same frame we’re processing. > And of course in UDP an application must deal with re-ordering anyway... > > The recommended solution is: > https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-02 > > And not meaning to be cheeky, but seriously. Do not send fragments. > > Best regards, > Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11245): https://lists.fd.io/g/vpp-dev/message/11245 Mute This Topic: https://lists.fd.io/mt/28133898/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
