Ole, > Now, all this said... I understand the temptation of the solution and while I think it is likely a bad idea, and likely undeployable, nothing would stop you from trying it out in VPP if you like. There is some code that assumes the TCP header follows a 20 byte IP header, but that could easily dealt with for a prototype. I think I'd like to see where the industry would be going with this before favouring any upstreaming of such a change though.
Regarding the VPP modification I thought that you said: "Not impossible to change the IP4 VPP path, although it would require fixing all code that finds the L4 header. But I think you would end up in horrific deployment issues..." ;) BTW, good points from you. Thanks Soheil On Fri, Jun 30, 2017 at 1:12 PM, Ole Troan <otr...@employees.org> wrote: > Dear Soheil, > > > We are in the design phase and investigating different platforms to see > which one might be used in our scenario. Here, I don't wannna discuss the > characteristics of a software router solution we all already know that! But > simply one of the key properties of a software solution like VPP should be > the flexibility that it brings up to the table, which in this case it > doesn't. > > > > Encapsulation techniques won't work in our scenario, because NFVs might > be third party solutions which expect generally IPv4 packets as their > input. So any change like encapsulation causes problem for them. > > > > Regarding the dynamic header insertion (in this case IP-option) and > standardization, actually as you know there are already standards defining > the structure like the old one: RFC 781. Recently there are effort from > facebook, Barefoot and other guys out there for extending the concept of > Packet-telemetry using all these available (if we can still say this word!) > options. > > No, RFC781 does not indicate support for header insertion (if all RFCs > could be that brief! ;-)). > There is no support in the IP architecture for inserting neither IP4 or > IP6 options/extension headers by intermediate nodes in the network. There > are _proposals_ for doing that, but those do not have consensus as of now. > > The main issues with header insertion (non-exhaustive list) are: > - fundamentally breaks PMTUD > - leads to source host receiving ICMP errors on parts of the packet it > knows nothing about > - breaks AH > > It might be possible to do this in constrained environments, although the > IETF argument is always that "packets leak". > A proposal to do this does have to say something about the three issues > above at least. > > > The key idea is that when you own the network, you need to have > mechanisms to to measurements and why not doing it in dataplane in high > speed/low cost compared to control plane. > > > > So would you please confirm (or anyone who knows about the future plan > of VPP) that VPP won't support header option (which already is defined for > Ipv4 and other ones) or dynamic packet header sizes if you will. > > I idly tried this in scapy, but couldn't very much replying apart from my > first-hop router. ;-) > > p = sr1(IP(dst="8.8.8.8", options=IPOption())/ICMP()) > > Now, all this said... I understand the temptation of the solution and > while I think it is likely a bad idea, and likely undeployable, nothing > would stop you from trying it out in VPP if you like. There is some code > that assumes the TCP header follows a 20 byte IP header, but that could > easily dealt with for a prototype. I think I'd like to see where the > industry would be going with this before favouring any upstreaming of such > a change though. > > Also note, that NIC offloading features are unlikely to work. Any feature > like the classifier, which uses vector instructions on fixed offsets in > packets will not be easily reworked and that the extra header size might > lead to the header bleeding into another cache line and this will have > performance consequences. > > Best regards, > Ole > > > > >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
