[arch-d] On the (f)utility of prescriptive architecture

["Brian Trammell (IETF)" <[e-mail]>]

Hi Stewart, all,

I’ll leave the question of the appropriateness or this side meeting announcement to the side, but I did want to respond to the notion that the IAB should have some top-down master plan for the Internet, and that the lack of such is evidence that the IAB is not properly tracking changes in the Internet itself.

Architectural guidance from the IAB has admittedly been somewhat meta: 5218, 6709, and 8170 on how protocols themselves emerge and evolve in a multi-protocol, multi-implementor, multi-operator environment; 6973, 7754, and 7624 on privacy, access control, and confidentiality concerns of protocols up the stack; 8546 and 8558 on the implications additional confidentiality on the wire has on transport design and operations, and so on. Each of these efforts has been in parallel to related efforts in the IETF (I would argue that the design and deployment of QUIC, for instance, is influenced, in some cases deeply, by all of the cited RFCs).

True, there is no overarching prescriptive “architecture for the Internet”, because IMO developing such a thing would be a colossal waste of time. In the absence of a lever with which to impose architectural will, in the best case the broad and diverse community that builds and runs the Internet would look at such a thing, maybe read the abstract, say “yeah that’s nice” then go back to the business of keeping things running. What is more useful is descriptive architecture in the small: looking at the way things are and drawing insights toward evolutionary change; the RFCs cited above are all examples of this sort of thing.

Most of the problems the long history of IP replacements (including the ones I’ve worked on, and continue to work on) over the years have identified aren’t really technical, or at least are not technical in tractably addressable ways (the speed of light and the fact that all operations one can do in a network have strictly nonnegative latency are problems as old and hard as the non existence of perpetual motion machines). Rather, they are issues of inter organizational relationships and business models: rethinking inter domain routing or end to end QoS require an alignment of incentives that seldom emerges organically in a multi operator network. If you’d like the IAB to address these authoritatively, you can talk to your friendly local NomCom about appointing some economists, but it’s not clear to me that that’s the best business for the IAB to be in.

Cheers, Brian

Sent from my iPhone

> On 21 Mar 2020, at 12:11, Stewart Bryant <[e-mail]> wrote:
> 
> ...and also when the IAB fails to drive the changes needed in the Internet to support the evolving applications requirements or to properly track the changes in the Internet itself.
> 
> I did kind of think that the IAB would have had a 10 to 20 year evolution plan front and centre of its thinking, but I have never seen any evidence that it regards that to be one of its core responsibilities.
> 
> I also thought that the IAB ought to be an enabler of this thought process by encouraging input form others, but rather than that it seems to be a tightly closed community.
> 
> ... just saying.
> 
> - Stewart
> 
> 
>> On 20 Mar 2020, at 23:15, Tony Li <[e-mail]> wrote:
>> 
>> 
>> And I hate to see the IAB stomp on discussions.
>> 
>> T
>> 
>> 
>>>> On Mar 20, 2020, at 4:09 PM, Melinda Shore <[e-mail]> wrote:
>>> 
>>> On 3/20/20 3:03 PM, Stephen Farrell wrote:
>>>> AFAIK this is basically an initiative driven by one or
>>>> a small set of vendors. It is not an IAB activity and
>>>> this list is. ISTM somewhat cheeky to cast this as if
>>>> it were sort-of "official" by sending ICS invites to
>>>> this list and suggesting this list be used for follow
>>>> ups. I'm saying that as an individual and have not
>>>> asked other IAB folks what they think, but again
>>>> speaking personally, I'd be much happier if people
>>>> and organisations had a bit more style.
>>> 
>>> That was close to my reaction, as well.
>>> 
>>> Melinda
>>> 
>>> -- 
>>> Melinda Shore
>>> [e-mail]
>>> 
>>> Software longa, hardware brevis
>>> 
>>> _______________________________________________
>>> Architecture-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
>> _______________________________________________
>> Architecture-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss