Por que o tamanho da MTU para quadros Ethernet foi calculado como 1500 bytes?

Existe algum cálculo específico que foi feito para chegar a esse número e quais foram os fatores que foram levados em consideração para esse cálculo.

A resposta está na minuta-ietf-isis-ext-eth-01 , seções 3-5. A Ethernet usa os mesmos dois bytes de maneiras diferentes nos encapsulamentos Ethernet II (DIX) e 802.3:

• Ethernet II usa os dois primeiros bytes após o endereço mac de origem Ethernet para um Tipo
• O 802.3 usa esses mesmos dois bytes para um campo Comprimento .

Estou incluindo um diagrama anotado abaixo de cada tipo de quadro, que mostra exatamente onde estão os bytes conflitantes no cabeçalho Ethernet:

• O RFC 894 (comumente conhecido como quadros Ethernet II) usa esses bytes para Tipo

     +----+----+------+------+-----+
     | DA | SA | Type | Data | FCS |
     +----+----+------+------+-----+
               ^^^^^^^^
  
     DA      Destination MAC Address (6 bytes)
     SA      Source MAC Address      (6 bytes)
     Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
     Data    Protocol Data           (46 - 1500 bytes)
     FCS     Frame Checksum          (4 bytes)
  

• O IEEE 802.3 com 802.2 LLC / SNAP (usado pela Spanning-Tree, ISIS) usa esses bytes para Comprimento

     +----+----+------+------+-----+
     | DA | SA | Len  | Data | FCS |
     +----+----+------+------+-----+
               ^^^^^^^^
  
     DA      Destination MAC Address (6 bytes)
     SA      Source MAC Address      (6 bytes)
     Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
     Data    Protocol Data           (46 - 1500 bytes)
     FCS     Frame Checksum          (4 bytes)
  

Os encapsulamentos Ethernet II e 802.3 devem poder existir no mesmo link. Se o IEEE permitisse que as cargas Ethernet passassem de 1536 bytes (0x600 hex), seria impossível distinguir quadros 802.3 LLC ou SNAP grandes dos quadros Ethernet II; Os valores do tipo Ethernet começam em 0x600 hex.

EDITAR:

Estou incluindo um link para cópias em pdf das especificações da Ethernet Versão 1 e da Ethernet 2 , caso alguém esteja interessado ...

No outro extremo do intervalo - 1500 bytes, havia dois fatores que levaram à introdução desse limite. Primeiro, se os pacotes forem muito longos, eles introduzirão atrasos extras em outro tráfego usando o cabo Ethernet. O outro fator foi um dispositivo de segurança incorporado nos primeiros transceptores de cabos compartilhados. Este dispositivo de segurança era um sistema anti-balbuciar.Se o dispositivo conectado a um transceptor desenvolver uma falha e começar a transmitir continuamente, ele efetivamente impedirá qualquer outro tráfego de usar esse segmento de cabo Ethernet. Para proteger isso, os primeiros transceptores foram projetados para desligar automaticamente se a transmissão exceder cerca de 1,25 milissegundos. Isso equivale a um conteúdo de dados de pouco mais de 1500 bytes. No entanto, como o transceptor usava um temporizador analógico simples para desligar a transmissão se fosse detectado um murmúrio, o limite de 1500 foi selecionado como uma aproximação segura ao tamanho máximo de dados que não acionaria o dispositivo de segurança.

Fonte: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

Quando a Ethernet foi originalmente desenvolvida como um meio ou barramento compartilhado com 10Base5 e 10Base2, colisões de quadros eram frequentes e esperadas como parte do design. Compare isso até hoje, quando quase tudo é alternado com domínios de colisão separados e executando full-duplex, onde ninguém espera ver colisões.

O mecanismo para compartilhar o "éter" empregava o CMSA / CD (Acesso Múltiplo à Portadora / Detecção de Colisão)

Sentido de portadora significava que uma estação que deseja transmitir deve ouvir o fio - sentir o sinal da portadora - para garantir que ninguém mais estivesse falando, pois era o acesso múltiplo nesse meio. Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time. Quanto mais bytes forem transmitidos em um quadro, mais todas as outras estações deverão esperar até que a transmissão seja concluída. Em outras palavras, rajadas mais curtas ou MTU menor significavam que outras estações tinham mais oportunidade de transmitir e uma participação mais justa. Quanto mais lenta a taxa do meio de transmissão (10 Mb / s), as estações teriam atrasos mais longos na transmissão à medida que o MTU aumenta (se permitido exceder 1500).

Uma questão corolária interessante seria por que o tamanho mínimo de quadro de 64 bytes? Os quadros foram transmitidos em "slots" de 512 bits e foram necessários 51.2us para propagação do sinal de ida e volta no meio. Uma estação precisa não apenas ouvir quando começar a falar detectando o IFG (intervalo entre quadros de 96 bits), mas também ouvir colisões com outros quadros. A detecção de colisão assume um atraso máximo de propagação e dobra isso (para ser seguro), para que não perca uma transmissão iniciando na mesma hora da outra extremidade do fio ou um reflexo de sinal de sua própria transmissão quando alguém se esquece do resistor de terminação no extremidades do cabo. A estação não deve concluir o envio de seus dados antes de detectar uma colisão; portanto, esperar 512 bits ou 64 bytes garante isso.

Originalmente, máx. carga útil foi definida como 1500 bytes no 802.3. A Ethernet v2 suporta um comprimento de quadro de> = 1536 e é isso que as implementações de IP usam. Atualmente, a maioria dos fornecedores de classe de operadora suporta cerca de 9000 bytes ("jumbo-frames"). Como 1500 bytes é o padrão que todas as implementações de Ethernet devem suportar, é o que normalmente é definido como padrão em todas as interfaces.

O quadro ethernet mínimo é baseado no Ethernet Slot Time, que é de 512 bits (64 bytes) para 10M ethernet. Depois de subtrair 18 bytes para o cabeçalho Ethernet e o CRC, você obtém 46 bytes de carga útil.

O tempo do slot Ethernet foi especificado para que o CSMA / CD funcionasse corretamente. É preciso ter certeza de que o tamanho mínimo do quadro não exceda o maior comprimento possível de cabo; se fizesse a detecção determinista de colisão seria impossível. Após a detecção de colisão no comprimento máximo do cabo, você precisa do sinal de detecção de colisão para retornar ao remetente.