ConventionalProgrammer's questions

O tempo de transmissão pode ser definido, conforme Wikipédia , como (para um sinal digital):

"O tempo desde o primeiro bit até o último bit de uma mensagem sair do nó transmissor."

Pensando em sinais digitais, o tempo de transmissão corresponde à duração total de todo o pacote. Os dados são enviados para o fio a partir do buffer de envio. A quantidade de tempo que os bits individuais de um pacote devem esperar na fila de envio (buffer) é outro tipo de atraso chamado atraso de fila , portanto, estou excluindo-o por enquanto.

Minha pergunta é a seguinte: de que exatamente o tempo de transmissão é função? Por exemplo, podemos dizer que o atraso de propagação é função de uma fração da velocidade da luz e da distância entre os nós conectados, o atraso de processamento é função da velocidade de processamento das CPUs, FPGAs etc. o tempo parece ser vagamente definido em termos dessas relações funcionais.

Como o tempo de fila é um tipo separado de atraso, devemos pensar que os dados que serão enviados para a rede já ultrapassaram o tempo de fila, portanto, o único trabalho a fazer é enviar os dados para a rede. A pergunta que faço também assume a forma: "Que razões físicas impedem que os dados sejam enviados imediatamente para a rede?".

Claro, parece que não pode ser colocado no fio imediatamente e não é nada intuitivo, mas por quê? É a distância do local físico do buffer de envio até a extremidade inicial do fio? É algum tipo de limitação que os protocolos PHY são capazes de impor através de diferentes mecanismos de limitação (por exemplo, consulte: "...Muitos adaptadores Ethernet e portas de switch suportam múltiplas velocidades usando negociação automática para definir a velocidade e duplex para os melhores valores suportado por ambos os dispositivos conectados.") ? Se sim, quais são esses mecanismos no nível do hardware? É a taxa de amostragem do relógio do nó? Qual(is) deles provavelmente teria o maior impacto no tempo de transmissão?

Eu sei que nem todos os protocolos PHY são capazes de lidar com altas velocidades de transmissão (por exemplo, Comer, DE (2008). Computer Networks and Internets 5th Edition: "As interfaces seriais assíncronas comumente suportarão velocidades de transmissão de bits de até 230,4 kbit/s.") . Pelo que entendi, há uma limitação causada pelo cabeamento e pela própria camada física; no entanto, presumo que a resposta esteja em uma combinação das propriedades do nó de envio e da interface de conexão física na NIC.

A propósito, por favor, não me diga que é uma função do tamanho do pacote e da taxa de bits, pois eventualmente se resume a dizer que "O período é alto, mas por quê? Porque a frequência é baixa!", o que não tem sentido.

Posso ter ignorado algumas fontes que podem fornecer informações sobre isso, porém, não consegui encontrar nenhuma.

Citando da Wikipédia:

"Quando ambos os endpoints suportam ECN, eles marcam seus pacotes com ECT(0) ou ECT(1). Os roteadores tratam os codepoints ECT(0) e ECT(1) como equivalentes. Se o pacote atravessa uma fila de gerenciamento de fila ativa (AQM) ( por exemplo, uma fila que usa detecção precoce aleatória (RED)) que está enfrentando congestionamento e o roteador correspondente suporta ECN, ele pode alterar o ponto de código para CE em vez de descartar o pacote. Este ato é conhecido como "marcação" e sua finalidade é informar o terminal receptor sobre congestionamento iminente. No terminal receptor, essa indicação de congestionamento é tratada pelo protocolo da camada superior (protocolo da camada de transporte) e precisa ser ecoada de volta ao nó transmissor para sinalizá-lo para reduzir sua taxa de transmissão. . "

Portanto, o mecanismo de feedback de congestionamento é realizado na camada de transporte (TCP) através do recebimento de segmentos de envio final com o sinalizador ECE definido como 1. Minha pergunta é: por que o roteador que primeiro experimenta o congestionamento não envia, por exemplo, um ICMP mensagem imediatamente de volta ao remetente (eu sei que o ICMP não tem uma opção de congestionamento, no entanto, não pode ser simplesmente implementado?) para que o remetente possa reduzir sua janela de congestionamento mais cedo? Por que esperar até que os datagramas cheguem ao destinatário? O que acontece se os segmentos chegarem à extremidade receptora por tempo suficiente para causar uma transmissão intermitente por parte do remetente, levando a um bufferbloat (que pode ter sido evitado por uma notificação antecipada), de modo que outras conexões no roteador experimentem alta latência e até mesmo instabilidade? se for por um curto período de tempo?

Pode ser que o efeito benéfico disso na rede não valha o esforço e a razão pela qual a extremidade receptora é aquela que faz o eco do congestionamento pode ser porque o roteador não se dá ao trabalho de preparar mensagens de controle em um ambiente em que muitas conexões são regulamentadas. No entanto, não consigo encontrar nenhuma fonte sobre este assunto.

Além disso, pensei primeiro que talvez o pacote precise passar por todos os nós de roteamento para deixar claro os nós que estão passando pelo congestionamento, no entanto, não há uma opção de informação que mantenha rastros de nós individuais em nenhum quadro, datagrama, e campos de cabeçalho de segmento. Outra razão pela qual pensei que os segmentos chegam à extremidade receptora para enviar feedback de congestionamento em vez de serem enviados diretamente pelo roteador é manter o controle de congestionamento na camada de transporte (especificamente TCP), mas a camada de Internet (por exemplo, IPv4) também suporta informações de congestionamento via um campo ECN de 2 bits, o que me faz questionar esse motivo. Não tenho certeza se meus raciocínios fazem sentido prático.