Hi Tom and Joe, > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Thursday, May 26, 2016 11:52 AM > To: Templin, Fred L <[email protected]> > Cc: Joe Touch <[email protected]>; [email protected] > Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > > On Thu, May 26, 2016 at 11:35 AM, Templin, Fred L > <[email protected]> wrote: > > Hi Joe and Tom, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Thursday, May 26, 2016 11:26 AM > >> To: Tom Herbert <[email protected]> > >> Cc: Templin, Fred L <[email protected]>; [email protected] > >> Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > >> > >> > >> > >> On 5/26/2016 11:22 AM, Tom Herbert wrote: > >> > On Thu, May 26, 2016 at 10:56 AM, Joe Touch <[email protected]> wrote: > >> >> > >> >> On 5/26/2016 10:52 AM, Tom Herbert wrote: > >> >>> On Thu, May 26, 2016 at 10:41 AM, Joe Touch <[email protected]> wrote: > >> >>>> Here's the problem: > >> >>>> > >> >>>> The first 4 bits are either part of the GUE header or IPv4 or IPv6. > >> >>>> > >> >>>> In the diagrams in draft-ietf-nvo3-gue and RFC791 they're indicated > >> >>>> in the > >> >>>> following bit order: 0,1,2,3 > >> >>>> > >> >>>> In GUE, these are 0,0,x,x > >> >>>> > >> >>>> In IPv4, these are 0,0,1,0 > >> >>>> > >> >>>> In IPv6, these are 0,1,1,0 > >> >>>> > >> >>> IPv4 is 0,1,0,0. > >> >> Not LSB to MSB, which is how both GUE and RFC791 define the header: > >> >> > >> > >From RFC791: > >> > > >> > "Whenever an octet represents a numeric quantity the left most bit in > >> > the diagram is the high order or most significant bit. That is, the > >> > bit > >> > labeled 0 is the most significant bit." > >> Arrgh. > >> > >> Yup. OK, so the reason this would work is only because we no longer use > >> IP versions 0..3. > >> > >> Got it. > > > > I for one like it, and I am using it in my AERO implementation. As Joe > > points out > > however it does not account for fragmentation, identification etc. But, as > > long > > as you use it in a carefully controlled environment it should be OK. > > > > Can we have this added back to the GUE spec? > > > Since it technically defines a new version of GUE and other than the > two bit version number there is nothing else in common with GUEv0 > format, I would say this should be a new spec (I need to go back and > see if I wrote it up this in a draft). > > Fred, do you have any objective data showing the benefits? I think we > need something tangible to justify complexity (i.e. burning 25% of the > GUE version number space ;-) )
I want to use it over low-end wireless data links such as for aviation. In that domain, it is common to see links with 1Mbps or less bandwidth. So, any extra encapsulation is expensive. I can dampen this to some extent using techniques such as lzo message compression, but still the four bytes would contribute to eating scarce available bandwidth. Thanks - Fred > Thanks, > Tom > > > Thanks - Fred > > > >> > >> Joe > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
