I reviewed the draft and don’t support WG adoption. Main reason as stated by others is the minimal gain from super jumbo greater then 9000 bytes is supported today of which most router / switch vendors for example Cisco supports maximum 9216 MTU and Juniper supports 16000 MTU. Most all hosts Windows, MAC and Linux support up to 9216 MTU.
Servers for 5G MEC Multi Access Edge Compute on the wireless RAN Radio network X-Haul are now closer to the user’s 100G connected servers for network slice services being instantiated at ultra low latency microseconds as well as MSDC (Massively Scalable Data Centers) 100G connected servers and ultra low latency all using super Jumbo set to 9000+ MTU. Keeping in mind that MPLS, IPSEC, NVO overlays must be taken into account, the super jumbo server MTU must be less then the network underlay or overlay MTU so let’s say set to a maximum maximum of 9116 for Cisco for now being the lowest common denominator in a network with Cisco and Juniper routers. At this time Transport networks with OTNGN DWDM packet or TDM over IP/MPLS a single wavelength can be 400G and now soon to be 800G standard per wavelength. At the current network speeds on the core and transport side given the higher bandwidths we are still at super jumbo which > 9000 and no vendor is close to 64k - 65535 which is the maximum super jumbo size. Jumbo grams RFC 2675 as discussed in the draft is > 64k to 4.2B. We are well off from a network technology point of view coming anywhere close to use of Jumbo grams RFC 2675. Until we get close to the maximum MTU of Super Jumbo and we still feel we need larger buffers for better performance would this draft be even remotely a possibility. Also the big issue here is if you do the math you do get tremendous gains in throughout and performance from 1500 byte to jumbo to then super jumbo up to 9216. The performance gains are not there to even go to the maximum of super jumbo 64k which has not happened and more then likely will never happen. However the cost of extra buffers on server NIC and router hardware proves that the performance gains are nominal and it’s not worth the investment by router and server vendors to ever support more then what is supported today which is 9216 on servers and what Cisco supports today. So bottom line is RFC 2675 would never come to fruition and should really be deprecated or made obsolete. I believe this was discussed on 6MAN. Kind Regards Gyan On Sat, Jul 2, 2022 at 11:12 AM Bob Hinden <[email protected]> wrote: > Hi, > > I agree with the other comments that this shouldn’t be adopted at this > point. > > Another point is that what I understand this is proposing would appear to > have non-trivial effect on current transport protocols, as it will add > delay to create the “parcels”. I don’t see this issue discussed in the > draft, other than pointing to some other perhaps similar work. > > Bob > > > > On Jul 1, 2022, at 5:17 PM, Tommy Pauly <tpauly= > [email protected]> wrote: > > > > I agree with the points being raised by Tom and Joel. I don’t think this > is something intarea should adopt at this point. If there’s going to be > further discussion on this, I’d want to see more explanation of who would > intend to support and deploy this solution to the problem. > > > > If this is a matter of sending fewer packets over a particular link of > the network, the use of a proxy or tunnel between hosts may equally well > solve the problem without needing to make changes at this layer. > > > > Thanks, > > Tommy > > > >> On Jul 1, 2022, at 5:06 PM, Tom Herbert <[email protected]> wrote: > >> > >> At this point, I don't see IP parcels as being a significant benefit to > host performance which, as I understand it, is the primary motivation. > While it's an interesting idea, I don't support adoption. > >> > >> A recent patch to the Linux kernel allows for GSO/GRO segments greater > than 64K, using RFC2675 Jumbograms to reassemble so those limitations which > were discussed on the list have been addressed in implementation. There is > a nice writeup in https://lwn.net/Articles/884104/. > >> > >> As Joel mentions moving any sort of reassembly into network devices is > complex and problematic. For instance, if a middebox is trying to perform > reassembly of packets for a flow not addressed to it, it's implicitly > requiring that all packets of the flow that go through the device perform > reassembly which is contrary to the end-to-end model. Also, if reassembly > requires buffering of messages then that creates a memory requirement on > middleboxes; hosts are in a better position to do reassembly since they are > only providing the service for themselves as opposed to some number of > devices behind a middlebox. > >> > >> Tom > >> > >> > >> > >> > >> On Wed, Jun 22, 2022 at 12:25 PM Juan Carlos Zuniga (juzuniga) > <[email protected]> wrote: > >> Dear IntArea WG, > >> > >> > >> > >> We are starting a 2-week call for adoption of the IP-Parcels draft: > >> > >> https://www.ietf.org/archive/id/draft-templin-intarea-parcels-10.html > >> > >> > >> > >> The document has been discussed for some time and it has received > multiple comments. > >> > >> > >> > >> If you have an opinion on whether this document should be adopted by > the IntArea WG please indicate it on the list by the end of Wednesday July > 6th. > >> > >> > >> > >> Thanks, > >> > >> > >> > >> Juan-Carlos & Wassim > >> > >> (IntArea WG chairs) > >> > >> > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/int-area > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
