Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 3:21 PM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Hi Tom, > > > > No, this is not a transparent proxy; I should know – I “invented” them > (see US Patent 5,781,550). > > > > No, these middlebox/proxy devices only kick into gear if a packet is > explicitly addressed to > > themselves; but, that is at the adaptation layer, and not necessarily at > the IP layer. > Fred, Your terminology is confusing to me. When a source host sends a packet with an IP parcel, what is the IP destination address that the source host put into the packet sent on the network? Is it the destination host, or the address of some intermediate node that will perform reassembly and then forward the reassembled packet to the destination via some sort of routing header or encapsulation? Tom > > Fred > > > > > > *From:* Tom Herbert [mailto:t...@herbertland.com] > *Sent:* Tuesday, July 12, 2022 12:42 PM > *To:* Templin (US), Fred L > *Cc:* Joel Halpern ; int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > > > > On Tue, Jul 12, 2022 at 9:59 AM Templin (US), Fred L < > fred.l.temp...@boeing.com> wrote: > > Joel, it also bears mention that today’s link MTUs cap out at about 9KB > because that > > is the maximum size that is well-supported by link-layer CRC-32 checks – > links with > > larger MTUs have been considered in the past (e.g., the HiPPI you > mentioned earlier) > > but one of the reasons they do not predominate today is due to the > diminished link > > layer integrity check considerations. IP parcels change the game because > they may > > include multiple upper layer integrity checks per packet instead of a > single integrity > > check. This means that parcel-capable links with MTUs as large as 64KB (or > even > > larger still) become possible, which opens the possibility for new > innovation. > > > > About middleboxes reassembling parcels, it might help if you try not to > think of them > > as routers but instead think of them as “proxys” that are performing a > function in the > > network on behalf of a host. That sort of thing happens all the time with > proxys today; > > indeed, even this email I am sending right now will be forwarded by a > proxy. > > > > Fred, > > > > At best this would be considered a transparent proxy. The host is not > sending packets to the proxy, it's that the proxy is intercepting them. > IMO, transparent proxies have been the bane of the Internet. They are > invasive in protocol layers that the network is not supposed to be > concerned with, and host developers spend much more time trying to work > around the constraints and problems with these devices than rejoicing > their existence. > > > > Tom > > > > > > Fred > > > > *From:* Joel Halpern [mailto:j...@joelhalpern.com] > *Sent:* Tuesday, July 12, 2022 9:43 AM > *To:* Templin (US), Fred L > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > > There are no "parcel-capable links" You are trying to invent them. You > are allowed to invent them. > > But in the absence of a physical link that can actually handle parcels > natively, I do not see any benefit in handling parcels (if needed at all) > anywhere except the hosts. > > At this point the chairs know my opinion. I will leave it to them to > conclude this adoption call and make the rough consensus decision. > > Yours, > > Joel > > On 7/12/2022 12:38 PM, Templin (US), Fred L wrote: > > Joel, > > > > The path for an IP parcel traverses parcel-capable links. Some of those > links might > > be physical links (most likely links nearest the source and links nearest > the destination) > > while others might be virtual (most likely links in between). Only > forwarding nodes on > > those kinds of virtual links would deal with parcel packaging and > repackaging, and > > there would be very few of those. Routers that connect physical > parcel-capable links > > would either forward the parcel if it is not too big or drop it and return > a PTB otherwise. > > This is very much intarea territory. > > > > Fred > > > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com > ] > *Sent:* Tuesday, July 12, 2022 9:20 AM > *To:* Templin (US), Fre
Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 9:59 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Joel, it also bears mention that today’s link MTUs cap out at about 9KB > because that > > is the maximum size that is well-supported by link-layer CRC-32 checks – > links with > > larger MTUs have been considered in the past (e.g., the HiPPI you > mentioned earlier) > > but one of the reasons they do not predominate today is due to the > diminished link > > layer integrity check considerations. IP parcels change the game because > they may > > include multiple upper layer integrity checks per packet instead of a > single integrity > > check. This means that parcel-capable links with MTUs as large as 64KB (or > even > > larger still) become possible, which opens the possibility for new > innovation. > > > > About middleboxes reassembling parcels, it might help if you try not to > think of them > > as routers but instead think of them as “proxys” that are performing a > function in the > > network on behalf of a host. That sort of thing happens all the time with > proxys today; > > indeed, even this email I am sending right now will be forwarded by a > proxy. > Fred, At best this would be considered a transparent proxy. The host is not sending packets to the proxy, it's that the proxy is intercepting them. IMO, transparent proxies have been the bane of the Internet. They are invasive in protocol layers that the network is not supposed to be concerned with, and host developers spend much more time trying to work around the constraints and problems with these devices than rejoicing their existence. Tom > > Fred > > > > *From:* Joel Halpern [mailto:j...@joelhalpern.com] > *Sent:* Tuesday, July 12, 2022 9:43 AM > *To:* Templin (US), Fred L > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > > There are no "parcel-capable links" You are trying to invent them. You > are allowed to invent them. > > But in the absence of a physical link that can actually handle parcels > natively, I do not see any benefit in handling parcels (if needed at all) > anywhere except the hosts. > > At this point the chairs know my opinion. I will leave it to them to > conclude this adoption call and make the rough consensus decision. > > Yours, > > Joel > > On 7/12/2022 12:38 PM, Templin (US), Fred L wrote: > > Joel, > > > > The path for an IP parcel traverses parcel-capable links. Some of those > links might > > be physical links (most likely links nearest the source and links nearest > the destination) > > while others might be virtual (most likely links in between). Only > forwarding nodes on > > those kinds of virtual links would deal with parcel packaging and > repackaging, and > > there would be very few of those. Routers that connect physical > parcel-capable links > > would either forward the parcel if it is not too big or drop it and return > a PTB otherwise. > > This is very much intarea territory. > > > > Fred > > > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com > ] > *Sent:* Tuesday, July 12, 2022 9:20 AM > *To:* Templin (US), Fred L > > *Cc:* int-area@ietf.org > *Subject:* [EXTERNAL] Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > If you document it purely as a host-to-host tunnel / shim, then it is not > even clear you need an RFC. intarea does not own all tunnels or overlays. > > But that is not what you currently have documented. You ahve documented a > mechanism wherein some routers are expected to break up parcels, and some > routers are hoped to reassemble parcels. That is what I object to. > > Yours, > > Joel > > On 7/12/2022 12:02 PM, Templin (US), Fred L wrote: > > Joel, the “shim” you are referring to is IPv6 encapsulation per RFC2473. > It forms an > > adaptation layer below IP as the network layer and above IP as the data > link layer. > > IP-in-IPv6-in-IP in other words. That seems like intarea. > > > > Fred > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com > ] > *Sent:* Tuesday, July 12, 2022 8:52 AM > *To:* Templin (US), Fred L > > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > If there are no links that can handle parcels bigger than 64K, then as a > step one deploy it o
