O princípio de ponta a ponta pode ser formalizado?

No final dos anos 90, quando eu estava na faculdade, o jornal

JH Saltzer; DP Reed; DD Clark: Argumentos de ponta a ponta no design do sistema . ACM Trans. Comput. Syst. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

era praticamente uma leitura obrigatória em todas as classes de sistemas operacionais em todas as universidades e ainda parece ser um dos princípios orientadores principais subjacentes ao design da internet. (Veja, por exemplo: J Kempf, R. Austein (eds), e o IAB, " O surgimento do meio e o futuro de ponta a ponta: reflexões sobre a evolução da arquitetura da Internet ", RFC 3724, março de 2004. )

O princípio de ponta a ponta afirma (Saltzer et al., 1984):

[Se] a função em questão pode ser completa e corretamente implementada somente com o conhecimento e a ajuda do aplicativo nos pontos finais do sistema de comunicação, ..., fornecendo essa função questionada como um recurso do próprio sistema de comunicação não é possível. possível. [Embora] algumas vezes uma versão incompleta da função fornecida pelo sistema de comunicação possa ser útil como um aprimoramento de desempenho.

Ou mais brevemente (do resumo):

O argumento de ponta a ponta sugere que funções colocadas em níveis baixos de um sistema podem ser redundantes ou de pouco valor quando comparadas com o custo de fornecê-las nesse nível baixo.

Mas tive pouco sucesso ao aplicar o princípio de ponta a ponta em minha própria experiência (que é na arquitetura de computadores, não na arquitetura da Internet). Como o princípio é declarado como um "poema" (ou seja, em prosa inglesa com vários termos que não são matematicamente definidos), é muito fácil enganar-se ao pensar que "a função em questão pode ser completa e corretamente implementada apenas com o conhecimento e a ajuda do aplicativo ". Mas qual é "a função em questão", muito menos "o conhecimento e a ajuda" de um aplicativo?

Exemplo: As redes on-chip (diferente da Internet) não têm permissão para descartar pacotes, mas têm um buffer bastante limitado; portanto, é necessário ter uma maneira de evitar ou recuperar-se de um conflito. Por outro lado, o aplicativo também precisa se tornar livre de impasse, certo? Portanto, posso pensar que devo tornar o caso comum (sem conflito) rápido e desativar a prevenção de conflitos no aplicativo. Isso é, de fato, o que tentamos em Alewife e Fugu (Mackenzie, et al., Explorando a entrega em dois casos para mensagens com proteção rápida , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. Ou a dissertação de John Kubiatowicz.) "Funcionou" (interrompendo a interconexão do processador quando os buffers foram preenchidos e o SO aumentado com o buffer do software), mas não vi ninguém na academia ou na indústria (incluindo qualquer um de nós que éramos autores desse Papel HPCA), tentando replicar a ideia. Portanto, aparentemente, a prevenção de conflitos em uma rede não é a mesma "função em questão" que a prevenção de conflitos no nível do aplicativo, ou o princípio de ponta a ponta está errado.

É possível transformar o princípio de ponta a ponta de um "poema" em um teorema? Ou pelo menos, pode ser afirmado em termos compreensíveis para um arquiteto de computador?

Acredito que possa haver duas deficiências na sua aplicação do princípio de ponta a ponta (e2e):

Primeiro, no sentido de aplicá-lo ao desempenho. O princípio de ponta a ponta é um princípio de design que garante ortogonalidade, composição, regularidade, uma ou todas as arquiteturas, fornece primitivas etc. Esses princípios foram descritos em livros relacionados. O desempenho não é um deles. De fato, Clark et al. Sugerem que estrita de ponta a ponta pode resultar em pior desempenho, por isso a utiliza, como uma exceção a esse princípio.

Então, se você ainda deseja formalizar:

"O argumento de ponta a ponta apela aos requisitos da aplicação e fornece uma justificativa para mover a função para cima em um sistema em camadas", assim você precisará de requisitos formalizados da aplicação e de um sistema em camadas formalizado. Aqui está uma tentativa que pode ajudar a dar um passo adiante:

Digamos que você tenha requisitos da Camada (i) (Camada (0) é para o conjunto de aplicativos que você espera suportar agora ou no futuro, a camada de aplicativo) e interfaces firmes Interface (i, i + 1) e Interface (i + 1 , i) (da Camada i a i + 1 não pressupõe a existência de camadas cruzadas aqui, fácil de alterar e exige disso) e funções Função (i, j) (Camada i, Índice de função j, assume parte dos dados da função para simplificar)

Entrada: Requisitos da camada (0) (como dissemos que precisam ser formalizados)

Saída: tudo o resto

Saída END-TO-END é uma Saída tal que: Para cada L, Camada (L) cumpre seus requisitos apenas pelas funções Função (L, j) (isto é, funções dentro da camada) e Interface (L, L + 1), Interface (L + 1, L)

Para cada Camada L e Função (L, F), não existe um conjunto de Funções S na saída, de modo que Função (L, F) = S (= significa saída equivalente e efeitos colaterais)

Portanto, chegando à segunda falha possível para a aplicação específica do princípio e2e (e se eu estiver lendo corretamente o que está sendo tentado), pode-se afirmar que ele não segue o princípio e2e, pelo contrário. Você faz com que seus chips forneçam "alguma solução de impasse" e você possui uma interface incomum e específica para desencadear (interromper) mais ajuda das camadas superiores. Esta é sem dúvida uma abordagem de camada cruzada e não de ponta a ponta. Em outras palavras, você tem uma Função (1, x) que não está cumprindo sua tarefa completa e corretamente com as Interfaces definidas - se desejar usar o rascunho da formalização fornecido acima (que, é claro, é apenas um começo útil para estender a resposta completa à sua pergunta) mas provavelmente não por si só).