TCP sobre redes sem fio
Computação Móvel
MAC5743/MAC330
Crhistian Noriega
[email protected]
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações do TCP
Conclusões
2/84
Introdução
TCP é o protocolo de transporte mais empregado na
Internet e redes fixas
As redes sem fio vêm sendo mais polulares, e
precisam de accesso a serviços nas redes fixas
(confiabilidade, etc)
A redes sem fio afrontam diferentes problemas que
as redes fixas
O emprego direito do TCP sobre redes sem fio tem
problemas pelo fato que elas são diferentes à redes
fixas
3/84
Introdução
Mobilidade do Terminal
Altos ERB
Lantência no medio elevada
Interferencia/Desconexões
Meio físico não confiável
Manter a compatibilidade apesar da diferença entre
meios de comunicação
4/84
Introdução
Protocolo IP (IPv4, IPv6)
 Os pacotes podem ser entregados fora de ordem
 Os pacotes podem ficar perdidos
 Os pacotes podem ser duplicados
Arquitetura TCP/IP nas redes sem fio
 TCP confiabilidade
5/84
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações doTCP
Conclusões
6/84
TCP (Transmission Control
Protocol)
Orientado à conexão
Ponto a ponto (end-to-end)
Confiabilidade
Full duplex
Handshake
Finalização controlada
7/84
TCP (Transmission Control
Protocol)
Implementa mecanismos de controle da
Congestão
O protocolo supõe que a maior pérdida de
pacotes se deve à congestão da rede
Confibilidade mediante retransmissões
Semântica end-to-end


Confirmações (ACK) enviadas pelo receptor da
correta recepção dos pacotes do transmissor
ACK somente são enviadas depois de ser recebido
o pacote
8/84
Janela deslizante
O mecanismo da janela deslizante
 receiver’s advertised window (rwnd) – determinado
pela capacidade do receptor
 congestion window (cwnd) – determinado pelo
transmissor baseado no estado da rede
Janela de congestão
Definida por cwnd medida em bytes
9/84
Confirmações ACK
Dados armazenados no buffer do Transmissor e
Receptor
Metodo da janela deslizante
A cada pacote transmitido é incorporado um número
de seqüência, para manter o ordem dos pacotes
O ACK transmitido pelo receptor do pacote X é o
número do próximo segmento que o receptor espera
receber (X+1)
ACK contem o número mais alto do pacote recebido
em seqüência
ACK contem o tamanho do buffer do receptor
10/84
ACKs acumulativos
Um novo ACK é gerado somente ao receber um
pacote em seqüência
33
34
34
35
36
35
36
37
i
11/84
ACKs duplicados
Um AC duplicado (DUPACK) é gerado quando:
 Um pacote chegar fora de ordem
 Um pacote fica perdido
34
36
36
36
12/84
Cabeçalho TCP
13/84
RTT - Round Trip Time
Tempo gasto entre a transmissão de um segmento e
o recebimento do respectivo ACK



Sua medida deve ser adaptativa
Determina o ciclo da Janela de Congestionamento
do TCP (cwnd)
Serve de base para o cálculo do RTO -
Retransmission Timeout
14/84
RTO - Retransmission Timeout
Tempo máximo de espera de confirmação de um
segmento, antes da sua retransmissão

Calculado em função da média e variação de RTT

Se o ACK não chegar antes que RTO expire, o segmento
é retransmitido, o valor de RTO é dobrado e o contador
reiniciado (“Timer Backoff”)
 Baixo RTO: Retransmissões desnecessárias
 Alto RTO: Baixo aproveitamento da rede
SRTT(i+1) = (1-α) * SRTT(i) + α * RTT(i+1)
RTO = β * SRTT
RTO=RTT + 4*desvio
15/84
Slow-Start
No inicio de uma transmissão é preciso que o TCP teste as
condições da rede em lugar de transmitir normalmente
 No inicio da transferência
 Reparar perdas de pacotes (timeouts)
A taxa de pacotes inseridos dever ser a mesma que ACK
recebidos
Inicialmente a janela de congestão
cwnd = 1 MSS (Maximun segment size)
Incrementa o tamanho da janela por 1 MSS por cada ACK
recebido
cwnd = cwnd + 1 MSS
O algoritmo termina quando o tamanho da janela for igual a
slow-start threshold (ssthresh)
cwnd<= ssthresh
16/84
Slow-Start
A janela de congestão cresce exponencialmente
durante o slow-start por RTT
17/84
Congestion avoidance
Em cada ACK cwnd é incrementado em MSS2/cwnd
pacotes
Assim cwnd é incrementada linearmente
Se cwnd> ssthresh
18/84
Controle da congestão
Ao detectar um pacote perdido o transmissor supõe
que foi devido à congestão na rede
Ao detectar perda de pacotes cwnd é reduzida
drasticamente
É reduzido o fluxo de dados na rede por RTT
A perda de pacotes por:



Timeouts
ACK consecutivos
Mensagens ICMC
19/84
Controle da congestão –
Timeout
O tamanho da janela de congestão é reduzida a
1MSS (cwnd=1 MSS)
O slow-start threshold é reduzido a metade da janela
de congestão antes da congestão (ssthresh=cwnd/2)
ssthresh = max( min(cwnd,rwnd)/2 , 2 MSS)
Algoritmo de Karn, ambiguedade dos time-out,
cresce exponencialmente, back-off (suficiente tempo
aos ACK)
Slow-Start é iniciado
20/84
Controle da congestão – Fast
Retransmit
Acontece com múltiplos DUPACK (>=3)


Acontece quando um pacote é perdido, mas os
seguintes alcançaram ao Receptor
Não existe a necessidade de slow-start
Fast Recovery é iniciado
21/84
Controle da congestão – Fast
Recovery
O valor de ssthresh é:
ssthresh = max( min(cwnd,rwnd)/2 , 2 MSS)
Retransmite o pacote perdido
cwnd = ssthresh + MSS * número de DUPACKs
Quando chegar novos ACK cwnd=ssthresh
Inicia congestion avoidance
22/84
Controle da congestão – Fast
Recovery
23/84
Estados do TCP
24/84
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações do TCP
Conclusões
25/84
TCP sobre redes sem fio
Erros de pacotes podem causar Fast restransmit,
frente a perda de ACK ou pacotes
Fast restransmit resulta em:
 Retransmissão de pacotes perdidos
 Redução da janela de congestão
Redução da janela de congestão é desnecessária
devido a erros na entrega de pacotes
Seria necessário transmitir a mesma taxa de
transferência
26/84
TCP sobre redes sem fio
Se fossem produzidas desconexões por longos
períodos de tempo, podem acontecer perdas de
pacotes da janela de congestão
Timeouts executam slow-start
Slow-start reduz a janela de congestão a 1 MSS, e
por tanto a taxa de transferência
Tempos de latência longos podem produzir erros no
calculo do RTO, e timeout
27/84
TCP sobre redes sem fio
O TCP não pode distinguir entre perda de pacotes
devido a problemas de congestionamento e
problemas de transmissão
Desnecessária redução da janela de congestão e por
enquanto baixa taxa de transferência
28/84
Considerações
Evitar a execução errada do mecanismo de controle
da congestão
Evitar o problema de time-outs consecutivos
Deve ser confiável altos BER
Poder manipular os hand-offs eficientemente
Poder manipular desconexões longas e freqüentes
Considerar a largura de banda limitada e escassa
energia do host móvel
Usar tamanhos de pacotes dinâmicos dependendo
da largura de banda disponível para o MH
Manter a semântica end-to-end do TCP
No possível manter a compatibilidade
29/84
Abordagens do TCP nas redes
sem fio
Soluções por divisão da conexão
Soluções na camada de enlace
Soluções Cross-Layer
Soluções por modificação do TCP
30/84
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações do TCP
Conclusões
31/84
Divisão da Conexão
A conexão ponto a ponto (end-to-end) do TCP é
dividida em um enlace fixo e outro sem fio, isto
permite ter maior grau de liberdade na otimização do
TCP
Podem ser necessárias mais divisões
A conexão entre o FH e MH vai através da BS
FH-MH = FH-BS + BS-MH
32/84
Divisão da Conexão
Controle de fluxo, erro, tamanho dos pacotes,
timeouts podem ser independentes nas duas partes
da conexão
Exemplos:
 I-TCP, M-TCP
FH
BS
MH
33/84
M-TCP
A arquitetura



MH Mobile host
MSS Mobile Support Station
SH Supervisor host
 SH-TCP cliente
 M-TCP cliente
Custo de hand-off baixo O(√n)
Complexidade do SH
34/84
M-TCP
35/84
M-TCP
Mantém a semântica TCP end-to-end
Manipular os problemas apresentados por longas
desconexões o freqüentes desconexões
Adapta dinamicamente a largura de banda largura de
banda fixa baseado nas mudanças de necessidades
de outros MH (QoS)
SH executa:
 Administração da largura de banda
 Recuperação de erros locais (FEC)
 Fornece seguimento do MH
36/84
O cliente SH-TCP
Quando um pacote chegar ao SH-TCP do transmissor
TCP, este passa o pacote ao M-TCP, mas a diferença
do I-TCP não envia ACK
Envia o ACK quando o MH faz
O protocolo “afoga” ao transmissor
O objetivo do SH-TCP é manter a janela de congestão
no transmissor fechada frente a desconexões do MH
37/84
O cliente SH-TCP
Envia ACK para os k‘-1 bytes da maneira normal mas
o ultimo byte não é confirmado
Ao MH desconectar depois de reconhecer os k' bytes,
o SH-TCP envia um ACK para o k' byte ao
transmissor, este ACK ajusta a janela a zero
FH modo persistente
SH-TCP que a sua vez envia um ACK ao transmissor
re-abrindo a janela do transmissor, a partir do byte
k'+1
k’-1
k’
k’+1 …
38/84
O cliente M-TCP
Na rede sem fio o objetivo é fazer uma recuperação
rápida de perdas devidas a desconexões
Desconexão: congela todos os tempos do M-TCP
Conexão restabelecida: o M-TCP do MH envia um
ACK especial ao M-TCP do SH que contem o numero
da seqüência do mais alto byte recebido
Não fluxo de ACK: SH-TCP modo persistente
transmissor
39/84
O cliente M-TCP
Time-out: em lugar de retransmitir o pacote, o M-TCP
é posto no modo persistente
 Soluções na camada de enlace (FEC)
 No modo persistente, o M-TCP pode enviar
pacotes persistentes ao MH cada período de
tempo
Pelo fato que o MH tem largura de banda fixa
Back-off são evitados
40/84
M-TCP hand-off
No hand-off pode ser controlando mantendo a janela
do transmissor em zero pelo SH-TCP no antigo SH,
Quando terminar o hand-off o SH-TCP no novo SH
pode incrementar o tamanho da janela
retransmitindo a máxima velocidade
Nenhum pacote é perdido pelo mecanismo de
confirmação do ultimo byte
41/84
M-TCP
A semântica ponto a ponto do TCP é mantida
A eficiência da conexão TCP não é diminuída devido
a desconexões
Time-outs consecutivos são evitados
Complexidade dos SH
Dificuldade com a confirmação do ultimo byte
Supõe que cada tem MH tem uma largura de banda
fixa (mudanças drásticas?)
42/84
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações do TCP
Conclusões
43/84
Protocolos na Camada de
Enlace
Pretendem fazer a camada de enlace sem fio
semelhante à camada das redes fixas, para
protocolos superiores
44/84
Protocolos na Camada de
Enlace
Empregam mecanismo Forward Error Correction
(FEC)
Correção local
FEC produz sobre cargo inclusive se não acontecer
erros
Retransmissão de pacotes na camada de enlace, só
em erros
Confiabilidade na camada de enlace
Ocultar características das redes sem fio à camada de
transporte
Exemplos: Snoop, AIRMAIL, WTCP
45/84
Snoop
Arquitetura FH-BS-MH
 Modulo Snoop
Não é executado nenhum protocolo de transporte
46/84
O protocolo Snoop
O agente snoop contem um cache que mantém os
pacotes do FH não confirmados pelo MH
Retransmissão baseada em DUPACKs do MH
DUPACKs não são propagados ao FH, evitando os
mecanismos do controle da congestão e slow-start
Armazena em cache os pacotes recebidos e enviados
ao processamento normal
Matem um track de ACK enviados pelo MH
Se o pacote for perdido retransmite o pacote, a
retransmissão tem prioridade sobre a transmissão
47/84
Pacotes do FH
Um novo pacote TCP normal chega na seqüência
correta: enviado ao MH e inserido no cache
Um pacote fora de ordem que já foi inserido no
cache previamente, é mantido o número de pacote
em seqüência mais alto confirmado:
 Se o número de seqüência do pacote é maior
 O pacote é enviado ao MH
 Se o número de seqüência do pacote é menor
 O pacote já foi recebido pelo MH,
 Descartar ou
 Perda do ACK original
48/84
Pacotes do FH
Um pacote fora de seqüência que não foi inserido no
cache previamente: marcado para retransmissão do
FH, esto reflete congestão da rede fixa
Mantém um contador do número de retransmissões
do pacote, o qual é reiniciado quando chegar o
pacote novamente do FH
49/84
Processamento dos ACKs
ACK novo: limpeza do cache
ACK duplicados (DUPACK),
 O pacote que não esta no cache snoop ou foi
marcado para ser retransmitido: retransmissão
pelo FH
 O pacote fica em cache neste caso o pacote
perdido é retransmitido imediatamente a maior
prioridade
 Mantém um track do número de retransmissões
Calcula o número de DUPACKs que o receptor espera
receber, o número de pacotes enviados desde o
ultimo erro
50/84
Fluxo
51/84
Processamento dos ACKs
52/84
Processamento dos ACKs
Pacotes desde o MH
A BS gera Selective ACK (SACK) que são processados
no MH
53/84
Snoop hand-off
O hand-off esta baseado no multicast
As BS vizinhas recebem os pacotes destinados ao
MH, construir seus cache snoop
Este esquema tem a vantagem de efetuar o hand-off
em corto tempo entanto o FH pode continuar
enviando pacotes ao MH sem apresentar retardo
54/84
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações do TCP
Conclusões
55/84
Cross-Layer
Quebram o principio de camadas do ISO/OSI
permitindo interdependência
Desenho de protocolos cruzados de diferentes
camadas
Abordagem interessante
Poucas soluções são disponíveis
A camada de transporte e enlace deveriam ser
conjuntamente tomadas em consideração
Exemplos:
 ILC-TCP, ATCP, LLE-TCP
56/84
ILC-TCP
Interlayer Collaboration Protocol
Melhorar o desempenho das redes sem fio,
freqüentes e longas desconexões, mobilidade
Introduz State Manager(SM) paralelo as camadas,
TCP, IP, Link/Physical, para obter informação
relacionada a cada camada
Obtém informação se for necessário de outras
camadas
TCP
IP
LL/PHY
State
Manager
(SM)
57/84
ILC-TCP
Neste modelo a camada física de enlace e a camada
IP periodicamente notificam seu estado ao state
manager (SM), configurável
 LINK_ONLY
 LINK_IP
A camada LL/PHY informa ao SM essencialmente
sobre o estado do enlace (hand-off)
 LINK_OK
 LINK_NOT_OK
A camada IP envia informação sobre a conectividade
ao nível da camada de rede (foi registrado em algum
agente estrangeiro), alcançabilidade
 IP_OK
 IP_NOT_OK
58/84
ILC-TCP
Baseado nesta informação SM pode propor congelar
(freezer) ou executar o TCP normalmente
(PROCCED_NORMALLY, FREEZE, RESTORE)



Hand-off, IP_NOT_OK, LINK_NOT_OK:
FREEZE
LINK_OK, Timeout :
PROCCED_NORMALLY
LINK_OK e IP_OK:
RESTORE
Se recuperar LINK_OK e IP_OK o estado da conexão
voltou ao normal e se o TCP foi congelado e registrado
seu estado, executar RESTORE
59/84
ILC-TCP
O desempenho do protocolo depende da rapidez em
que o State Manager (SM) obtém a informação das
mudanças nos enlaces e na rede
É um verdadeiro protocolo end-to-end e não precisa
a colaboração de entidades intermediárias com
estações base
Adiciona uma camada na pilha de protocolos
60/84
LLE-TCP
Link Layer ARQ Exploitation TCP
Automatic Repeat Request
Aponta a reutilizar o esquema ARQ, no TCP sobre
redes 802.11 camadas MAC e física
Para a entrega sucedida de um pacote TCP o
transmissor deveria esperar por uma confirmação
ARQ na camada MAC então passa o ACK do pacote
TCP
O ACK do pacote é só um pacote ordinário desde o
ponto de vista da camada de enlace
O protocolo propõe a introdução de uma entidade à
pilha de protocolos. O agente ARQ snoop
61/84
LLE-TCP
O protocolo pretende considerar a informação do
esquema ARQ na camada MAC para reconhecimento
dos pacotes entregados na camada de transporte
Quando um pacote foi entregue na camada de enlace
o ACK do TCP pode ser gerado localmente e não ser
enviado pelo receptor
62/84
LLE-TCP o agente
A camada de enlace:
 PACK_DELIVERED indica a correta entrega de um
pacote, gerado ao receber uma trama ACK na
camada de enlace como uma indicação que o
pacote foi entregue
 PACK_UNDELIVERED que indica que a camada de
enlace não pode entregar o pacote
A camada de transporte:
 No lado do transmissor armazena a informação
relevante do pacote (buffer do agente)
 No lado do receptor, os ACKs do TCP são
descartados
63/84
LLE-TCP o agente
Depois de uma entrega sucedida pela camada MAC
(PACK_DELIVERED) o agente gera um pacote ACK
TCP
Incrementa a complexidade
do transmissor
Realmente não é end-to-end
64/84
LLE-TCP
65/84
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações do TCP
Conclusões
66/84
Modificações no TCP
Pretendem empregar o bom conhecido mecanismo
do TCP sobre ambientes sem fio
São protocolos end-to-end devido a que mantêm a
semântica do TCP
O transmissor TCP tenta resolver a perda de pacotes
fazendo modificações ao TCP base
Somente mudam alguns mecanismos do TCP
(geração de ACKs), complexidade BS, sobrecarga nos
pacotes
Não existe a necessidade de trocar o TCP da BS
Exemplos: TSP-SC, SACK, METP
67/84
SACK
Selective ACK (RFC 2018)
O receptor informa ao transmissor sobre os pacotes
recebidos ou fora de ordem
O transmissor somente retransmite os pacotes
requisitados
Permite recuperação de múltiplos pacotes por RTT
Tanto o transmissor como o receptor devem permitir
a funcionalidade
68/84
SACK geração dos blocos
O SACK emprega bytes do cabeçalho nos pacotes
TCP, chamados opções SACK
SACK-Permited option: ativar o protocolo SACK
enviados em pacotes SYN do TCP no estabelecimento
da conexão
SACK-Option format: Nestes bytes se informa ao
transmissor de blocos de dados contíguos que foram
recebidos; cada bloco de dados contíguos é definido
dois inteiros sem signo de 32 bits


Left Edge of Block - LEB: primeiro numero de seqüência do
bloco
Right Edge of Block - REB: ultimo número na seqüência do
bloco
69/84
SACK geração dos blocos
Cada bloco representa bytes de dados recebidos que
são contíguos e isolados, e dizer os bytes LEB-1 e
REB não foram recebidos
70/84
SACK geração dos blocos
O primeiro bloco deveria especificar o bloco de
dados que contem o pacote que inicio o ACK
As opções SACK deveriam ser enchidos por blocos
repetindo os mais recentes que não são subconjuntos
Depois do primeiro bloco podem ser listado em
ordem aleatório
Bloco 1
Bloco 2
Ultimo Bloco
71/84
SACK interpretação
O transmissor possui uma fila de pacotes que foram
transmitidos mas ainda não confirmados em ordem de
seqüência, esta é a fila de retransmissão. Cada pacote
na fila de retransmissão tem um bit sacked
Depois de acontecer um time-out todos os pacotes
deveriam ser retransmitidos sem importar se o sacked
bit esta ativo
Cada vez que um pacote novo chegar é obrigado a criar
um SACK contendo o pacote novo, ante á perda de
ACK o transmissor pode reconstruir o estado do
receptor, baseado neste bloco
É preciso que o SACK reporte o bloco que contem o
ultimo pacote recebido
Os blocos redundantes do SACK incrementa a robustez
do protocolo
72/84
TCP Santa Cruz
TCP-SC, pretende melhorar o desempenho do TCP
(New Reno), no controle de congestão
Controle de congestão baseado em retardos relativos
 Tempo entre pacotes enviados pelo transmissor (S)
 Tempo entre pacotes recebidos pelo receptor (R)
Timestamp agregados nos ACK que registram o
tempo de chegada dos pacotes Melhorar o calculo do
RTT
TCP Santa Cruz implementa SACK
73/84
TCP Santa Cruz
Câmbio no retardo direto do pacote j com respeito a i
Se a soma dos retardos relativos num período de
tempo é 0 significa que nenhuma congestão ou saída
de pacotes da rede apresentou-se
74/84
TCP Santa Cruz
nti : número total de pacotes na rede no tempo ti
Nop: ponto de operação, número de pacotes
desejados na rede
MWi-1: é a conta adicional de pacotes introduzida
sobre a janela anterior Wi-1
Pkts : tempo médio de entrega de um pacote
75/84
TCP Santa Cruz
Uma vez calculado o valor de MWi-1 é agregado ao
número de pacotes existentes previamente na rede
nti se o resultado nt ficar:
 menor do que Nop - delta a janela é incrementada,
rede sub utilizada
 acima do Nop+ delta a janela é reduzida, acima do
desejado
 delta fracção de um pacote
No TCP-SC é feito os ajustes na janela de
transmissão baseado no retardo da rede e não nos
ACKs
76/84
TCP Santa Cruz - SACK
TCP-SC implementa recuperação de pacotes SACK
Conceito de granularidade
Vetor de bits
Incrementa a complexidade do transmissor
Modifica o TCP
77/84
EBSN
Explicit Bad State Notification
Foi proposto o envio de uma notificação especial
(EBSN) que provocaria o cancelamento do time-out
em lugar de executar os algoritmos slow-start e
controle da congestão
Modificações menores no transmissor TCP
78/84
ELN
Explicit Loss Notification
Pretende fazer clara os problemas apresentados nas
redes sem fio
A BS monitora o fluxo de pacotes em ambos sentidos
Quando DUPACKs são recebidos do MH, a BS ajusta
os bits necessários segundo uma mensagem ELN no
cabeçalho do ACK TCP, enviado ao transmissor
O transmissor (com algumas modificações) pode
decidir como atingir frente a mensagem (controle de
congestão, etc)
O esquema ELN, não incorpora retransmissão local
79/84
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
O TCP
Os problemas do TCP nas redes sem fio
Protocolos por Divisão da Conexão
Protocolos na Camada de Enlace
Protocolos Cross-Layer
Modificações do TCP
Conclusões
80/84
Comparações
81/84
Comparações
82/84
Conclusões
A principal vantagem dos protocolos na camada de
enlace são que eles mantêm a semântica end-to-end
do TCP

Dificuldade com o manejo de desconexões e hand-off
Os protocolos que implementam o modelo da divisão
da conexão garantem a compatibilidade com redes
fixas existentes, ocultam os problemas nas rede sem
fio dos FH, além disso eles podem manipular
desconexões eficientemente

Podem não garantir a semântica end-to-end do TCP
83/84
Conclusões
Os protocolos TCP-SC, SACK e EBSN são protocolos
end-to-end, mas para conseguir isto,

Precisam de modificações no TCP do FH, portanto não
podem garantir compatibilidade
Os protocolos Cross-Layer tem bom desempenho nas
redes sem fio, mas eles podem não garantir
compatibilidade incrementado novas camadas à pilha
de protocolos
84/84