Resumo

  • Um agente intermediário de ST-II podia confirmar CONNECT, aprovar um identificador local e tentar reservar recursos antes da consulta ao aplicativo de destino.
  • O ACCEPT do destino era um evento separado e devolvia a FlowSpec efetivamente acumulada no ramo, que podia ser menor que o pedido inicial.
  • Em um fluxo com vários destinos, a origem precisava fechar cada resposta e compatibilizar os parâmetros; o estado aceito não comprovava entrega de dados nem experiência do usuário.

A rede preparava o caminho sem falar pelo destino

Publicada em outubro de 1990, a RFC 1190 especificou o Experimental Internet Stream Protocol Version 2, ST-II. Era um experimento de uso limitado, não um Internet Standard. Os registros do RFC Editor e do IETF Datatracker fixam sua substituição pela RFC 1819, sem provar adoção geral ou uma sessão real.

O stream de ST-II era uma árvore simplex. Uma origem enviava para um ou mais targets; cada agent intermediário mantinha rota, estado e informação de recursos. A aplicação só mandaria dados depois do setup. Em vez de decidir tudo a cada pacote, o protocolo preparava a árvore e deixava um identificador curto acionar o encaminhamento posterior.

Esse trabalho antecipado era legítimo, mas limitado. O agente sabia sobre seu próximo salto, sua rede e seu estado. Não controlava a vontade do processo distante. A topologia não conferia mandato.

O pedido carregava margem para mudar

A FlowSpec continha valores Desired e Limits. Os primeiros expressavam a qualidade desejada; os segundos, a fronteira mínima que os agentes seguintes não podiam reduzir. Quando um ramo entregava menos banda, mais atraso ou um tamanho menor de PDU, o agente atualizava Desired antes de propagar CONNECT, desde que ainda respeitasse Limits.

Os recursos não eram apenas capacidade do link. A lista incluía informação de forwarding, processamento do switch, buffers, banda e identificadores multicast. A RFC não definiu um alocador universal para redes subjacentes e reconheceu que nenhuma rede conhecida oferecia reserva de todo esse conjunto.

Logo, pedido, limite, alocação local e valor acumulado são registros diferentes. Um compromisso operacional precisa indicar qual resource manager decidiu, para qual target e ramo, com qual duração e possibilidade de preemption.

HID-APPROVE fechava uma pergunta estreita

Ao receber CONNECT, um agente intermediário respondia rapidamente com ACK, HID-REJECT ou HID-APPROVE. O HID era o Hop Identifier proposto para encaminhar dados com baixo custo. Aprovar o HID dizia que aquela relação local conseguia usar o atalho.

Ainda faltava descobrir se o restante da rota era satisfatório, se os recursos distantes existiam e se o aplicativo de destino desejava participar. Transformar a resposta do vizinho em aceite remoto apagaria exatamente a divisão de responsabilidade que o protocolo desenhou.

O Name global do stream, a TargetList de cada ramo, o HID local e o SAP do aplicativo também não eram intercambiáveis. Nenhum autenticava uma pessoa ou autorizava uma decisão comercial.

O aplicativo via o que restou da proposta

No target, o host agent concluía a negociação do identificador e apresentava Name, FlowSpec, Options, Group e seletor local ao processo indicado. O aplicativo podia aceitar, recusar ou reduzir a qualidade desejada.

Só depois disso surgia ACCEPT ou REFUSE. A resposta trazia uma nova referência ligada ao CONNECT original. No caminho de volta, cada agent validava a relação, confirmava o recebimento para o vizinho e propagava um novo ACCEPT em direção à origem.

O trajeto de retorno preservava o dono de cada decisão. Routing escolhia o ramo; o gestor local alocava; vizinhos acordavam o handle; o target consentia; a origem avaliava se as condições retornadas ainda serviam. Um componente não herdava a competência do seguinte.

Cada target devolvia sua própria condição

Uma árvore com vários targets produzia várias respostas. A origem recebia ACCEPT, REFUSE ou erro individualmente e conhecia a FlowSpec daquele caminho. O setup só terminava depois de todas as respostas e negociações.

Os resultados podiam não combinar. Um caminho aceitava PDUs maiores em ritmo menor; outro, menores em ritmo maior. A origem podia remover um target, encerrar tudo ou criar outro stream. Depois do acordo, CHANGE liberava recursos que ficaram acima do parâmetro comum.

Esse detalhe impede uma conclusão sedutora: um target aceito não torna toda a árvore aceita. O conjunto exige a decisão explícita da origem sobre quais folhas e parâmetros sobreviveram.

O sim continuava revogável pelo mundo físico

O ACCEPT precisava subir de modo confiável. Se o ACK anterior não chegasse depois das tentativas, o agente substituía o sinal por REFUSE à origem e DISCONNECT ao target. Recursos também podiam ser tomados por stream de maior precedência. NOTIFY carregava uma garantia reduzida; um CHANGE mal sucedido podia deixar uma transformação parcial.

A própria RFC dizia que ST não oferecia serviços de segurança. O protocolo não autenticava o operador, não autorizava cobrança e não demonstrava que o consentimento pertencia a um principal institucional. Muito menos provava que pacotes chegaram, voz foi ouvida ou vídeo foi exibido.

A experiência retirou o HID, mas manteve a volta do ACCEPT

A RFC 1819, documentada também pelo RFC Editor e pelo Datatracker, revisou o experimento em 1995 como ST2+. A nota do IESG afirmou que nenhuma versão era ou estava em consideração para ser Internet Standard.

ST2+ manteve CONNECT, a consulta ao local resource manager, a decisão do target e o ACCEPT de retorno. Removeu os HIDs porque a complexidade prejudicava interoperabilidade. Também acabou com implementações por subset: permissão para implementar menos não demonstrava que os peers tinham capacidade comum.

O identificador aprovado em 1990 desapareceu, enquanto o consentimento do destino permaneceu. A mudança prova por que formato, interoperabilidade, reserva e autoridade não devem caber na mesma coluna.

A RFC 1077 já tratava banda rápida como um problema maior que o meio físico. Depois, RFC 1633 e RFC 2212 definiram outras superfícies de reserva e serviço garantido. Servem como contraste, não como prova de linhagem direta, implantação ou resultado.

Fontes