— Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 3, 2021, at 10:06 AM, Templin (US), Fred L <fred.l.temp...@boeing.com> > wrote: > > Joe, I was going to let this slide but this is the most words you have spoken > to > me in a single message in many years.
Sorry - my day job keeps me quite busy…. > What AERO/OMNI enable is lossless and > adaptive packet sizing to determine the best-performing size for a given flow > *even if that size exceeds the path MTU*. I think this honors the past works > that > you seem to hold as sacred – both from yourself and from others. > > What more do you want? As a mechanism, nothing. But that mechanism has to be widely deployed and arguably available at multiple layers. I wish we had an approach that didn’t have the same kind of notion of MTU as IP, but rather more like Ethernet, as I noted before - which would obviate the need for frag/reassembly except at the uppermost app layer. Joe > > Fred > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] > Sent: Friday, December 03, 2021 7:33 AM > To: Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> > Cc: Dino Farinacci <farina...@gmail.com <mailto:farina...@gmail.com>>; > int-area@ietf.org <mailto:int-area@ietf.org>; Dirk Trossen > <dirk.trossen=40huawei....@dmarc.ietf.org > <mailto:dirk.trossen=40huawei....@dmarc.ietf.org>> > Subject: Re: Side meeting follow-up: What exact features do we want from the > Internet? > > Fred, > > Having a mechanism that *can* be used at any layer to address fragmentation > isn’t the same as solving the MTU issue. > > Issues that complicate this are: > - not all layers employ that mechanism or any other > - too many ‘layers’ peek into payload contents for message dispatch (of one > sort or another) > - which means that if the fragmentation doesn’t copy enough of > the payload, that dispatch breaks > (lack of transport port numbers for IP frags, lack of HTTP > headers for web message frags, etc.) > > So whether it’s because solution are incomplete or not widely adopted, or > both, it’s not solved. > > Joe > > — > Joe Touch, temporal epistemologist > www.strayalpha.com <http://www.strayalpha.com/> > > > On Dec 3, 2021, at 6:37 AM, Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> wrote: > > Joe, yes MTU was hard – very hard – but it is now solved. > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] > Sent: Thursday, December 02, 2021 5:21 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> > Cc: Dino Farinacci <farina...@gmail.com <mailto:farina...@gmail.com>>; > int-area@ietf.org <mailto:int-area@ietf.org>; Dirk Trossen > <dirk.trossen=40huawei....@dmarc.ietf.org > <mailto:dirk.trossen=40huawei....@dmarc.ietf.org>> > Subject: Re: Side meeting follow-up: What exact features do we want from the > Internet? > > All waists, like all layers except those that touch the physical (e.g., MAC > protocols) are relative. > > It’s a lot like the ‘end’ in E2E. It was thought to imply “that which can be > kicked”, but it’s really “that which *I* can kick”. > > Once you accept this relativity, everything else just works - including the > reason why OSI got it completely wrong - layers are not uniquely defined by > functions/capabilities. That’s the reason why MTU is so hard - everyone wants > it to be ‘fixed’ at a single layer, but it can’t be. > > — > Joe Touch, temporal epistemologist > www.strayalpha.com <http://www.strayalpha.com/> > > > > On Dec 2, 2021, at 2:22 PM, Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> wrote: > > Depends on what you consider to be the “waist”; the adaptation layer is below > the > IP “waist” and (again) is missing from your diagram. > > From: Dino Farinacci [mailto:farina...@gmail.com > <mailto:farina...@gmail.com>] > Sent: Thursday, December 02, 2021 2:18 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> > Cc: Stewart Bryant <stewart.bry...@gmail.com > <mailto:stewart.bry...@gmail.com>>; int-area@ietf.org > <mailto:int-area@ietf.org>; Dirk Trossen > <dirk.trossen=40huawei....@dmarc.ietf.org > <mailto:dirk.trossen=40huawei....@dmarc.ietf.org>> > Subject: Re: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? > > > > You missed the point maybe. Common functions should be performed at the waist > so applications don’t have to duplicate functionality. > > Dino > > > > > On Dec 2, 2021, at 2:08 PM, Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> wrote: > > > Your diagram is missing a critical layer – the adaptation layer. > > From: Int-area [mailto:int-area-boun...@ietf.org > <mailto:int-area-boun...@ietf.org>] On Behalf Of Dino Farinacci > Sent: Thursday, December 02, 2021 1:05 PM > To: Stewart Bryant <stewart.bry...@gmail.com > <mailto:stewart.bry...@gmail.com>> > Cc: int-area@ietf.org <mailto:int-area@ietf.org>; Dirk Trossen > <dirk.trossen=40huawei....@dmarc.ietf.org > <mailto:dirk.trossen=40huawei....@dmarc.ietf.org>> > Subject: Re: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? > > The key question that I would ask Dino is whether these need to be addressed > at the network layer? > > Yes, because of this architectural principle: > > <image002.png> > > > > > > > > > > > On 1 Dec 2021, at 22:18, Dino Farinacci <farina...@gmail.com > <mailto:farina...@gmail.com>> wrote: > > Here's my single feature request the network layer should provide: > > (1) I want to be connected ALL THE TIME, I want my computer to use all its > links, either cabled or radio, ALL THE TIME. > > It can do this by treating these as independent links with different > addresses and bind them in the application or through some OS service. > > Its too much complexity for the app. The app is talking to one place and > shouldn't know where it is. Hence the network layer should do this. > > > > > > > > > > > (2) I do not want to turn on and off wifi to get my device/computer to > connect when it is currently not connected. The network layer should do all > this for me. > > Is that a network layer problem or an OS problem? > > Yes, its a network layer problem. The OS is just an implmentation of a > network stack. > > > > > > > > > > > (3) I want it easy for people to find me (my IP address), so I don't want > multiple addresses from the user level. I want one device ID, EID, host > address, whatever you want to call it. I want you to "ping <dino's-computer>". > > It is important that people can find you/your device, but I am not convinced > they need to find you by historic IP address. > > I used this example (at the network layer) due to the audience of the list. > What I really want to know is Stewart's crypto wallet address because I want > to send you a donation. That is addressing at a specific app level. > > > > > > “Pinging” Dino’s computer does not have to happen directly at the network > layer to find out that it is alive. To test > > Right but if I want to debug where my crypto transaction is going (I want it > to go from my computer to your computer) then I have to go down a level (to > the network layer), that is as an engineer (not high-level user) to determine > an issue or understand performance. > > > > > > *a* path to Dino’s computer sure you need the address that that path responds > to, but I am not convinced that it is simpler if the address on that network > is the same as the address on all of the other networks to which it is > attached. > > There is one network. You are one human being with 2 names. I can call you > Stewart or Mr Bryant. It doesn't matter you will respond but wouldn't it be > better if I called you "my-friend" and packets can go to either Steward or Mr > Bryant? > > I can tell you could react that this is a stretch, but you get what I'm > trying to get across. The physical connection should not matter to the app. > And don't forget the physical connection goes up and down, it gets fast and > slow, it gets address (i.e. locator) changes. That should be damped out from > the app. > > > > > > > > Yes, I want host multi-homing and mobility. And I want it to work seamlessly. > > > Yes, I agree but I am not convinced we need to solve this by adding the > complexity in L3 and hence through out the whole of the Internet rather than > further up the protocol stack. > > You always have to add something to get something. And what you add can be > simple. Just have to make choices very very carefully. > > Dino > > > > > > > Stewart > > > > > > > > Speaking as a user, > Dino > > > > > > On Dec 1, 2021, at 12:52 AM, Dirk Trossen > <dirk.trossen=40huawei....@dmarc.ietf.org > <mailto:dirk.trossen=40huawei....@dmarc.ietf.org>> wrote: > > Dear all, > > Many thanks for those participating in the side meeting on Internet > addressing during the IETF 112 week. As suggested during the meeting, we want > to take various points of discussion during the meeting onto the mailing list > to continue discussion here on possible ways forward. > > Specifically, we wanted to come back on the issue that a larger architectural > discussion may be needed, a point that we make towards the end of the GA > draft (https://datatracker.ietf.org/doc/draft-jia-intarea-internet- > <https://datatracker.ietf.org/doc/draft-jia-intarea-internet->addressing-gap-analysis/), > but which was also core to Dirk K’s main point that only such architecture > discussion may lead to possibly needed changes to addressing. We will be > looking into such possibly larger discussion along different possible avenues. > > For our discussion here on the INT area list, we found Dino’s related > suggestion particularly useful in that we may need a discussion on what we > (as users) may want from a network. We feel that our current GA draft may > contribute to this question by observing that the many extensions to Internet > addressing that we have gathered so far may be seen as an expression of a > desired feature that those proposing the extension may want to see from the > network. Hence, in addition to positioning those extensions as identified > gaps to Internet addressing, we may want to formulate those extensions as > desired features towards an extended Internet system, not just addressing; > this can be done through suitably extending the GA draft with another section. > > Why is this useful? We think that such view provides an observational input > into the question that Dino suggests to answer, which in turn links to the > larger architectural discussion that Dirk K suggests to have. While the > overall architectural discussion may (and likely will) touch on more than > ‘just’ addressing, we as a community may contribute to the discussion by > rationalizing the work that has been done in this space. > > We would like to solicit thoughts on this proposed way forward as concrete > steps for the community here on the list. Also, anybody wanting to provide > concrete input and contribution to this proposed revision of the draft is > more than welcome. > > Best, > > Dirk > (on behalf of the co-authors) > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org <mailto:Int-area@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area > <https://www.ietf.org/mailman/listinfo/int-area> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org <mailto:Int-area@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area > <https://www.ietf.org/mailman/listinfo/int-area> > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org <mailto:Int-area@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area > <https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
