Trabalhos Relacionados
3.2.6 Multi-caminhos com SDN
❏ (SANDRI et al., 2015) propõe o uso do MPTCP junto com a Arquitetura SDN. O MPTCP é uma aplicação usada para dividir um Ćuxo TCP em múltiplos subĆuxos TCP, sendo que todo o processo de encaminhamento de tráfego ocorre por apenas uma conexão TCP. Cada subĆuxo terá seu próprio mecanismo de controle e pode passar por caminhos completamente diferentes de outros subĆuxos. Na abordagem proposta pelos autores, um controlador SDN será usado para garantir que os subĆu- xos gerados pelo MPTCP sempre passem por caminhos disjuntos, com isso o tráfego gerado pelo MPTCP usará de forma mais eĄciente a banda da rede e o tráfego não será tão afetado em caso de falhas de interfaces nos dispositivos de encaminha- mento. É feito uma comparação usando o MPTCP, com múltiplos caminhos, e o TCP padrão, onde este irá usar apenas um único caminho para transmitir o tráfego. A partir dos resultados obtidos pelos autores, é possível perceber que o MPTCP tem resultados bem superiores em comparação com o TCP, caso o MPTCP real- mente tenha seus subĆuxos passando por caminhos diferentes. Entretanto, existem alguns problemas relativos, principalmente, à natureza do MPTCP, que limita-se ao protocolo TCP. Além disso, embora derive um Ćuxo TCP em subĆuxos TCP, é uma abordagem centrada no host, pois será necessário que todos os hosts tenham o MPTCP instalado. Embora o artigo usado como referência use um controlador para deĄnir caminhos disjuntos, o host precisa deĄnir à priori quantos subĆuxos
56 Capítulo 3. Trabalhos Relacionados
serão usados pelo MPTCP, pois caso gere mais subĆuxos do que número de cami- nhos disjuntos, o MPTCP vai prejudicar a rede, pois gerará mais overhead na rede e, consequentemente, reduzirá a largura de banda livre, aumentando o gasto em processamento. O artigo propõe a idéia de que caso o MPTCP requisite um novo caminho e a rede não possa disponibilizar mais caminhos disjuntos, o controlador irá descartar essa requisição, mas mesmo assim gerará um overhead entre o dispo- sitivo OpenFlow e o controlador para cada requisição. A nossa proposta difere do trabalho apresentado em (SANDRI et al., 2015) por ser independente de protocolo, suportando o tratamento de multicaminhos para todos os Ćuxos que utilizam a rede OpenFlow, sem que haja a necessidade de alteração na pilha de protocolos dos hosts. Além disso, a deĄnição dos caminhos a serem utilizados é automaticamente obtida pelo módulo multicaminhos, MP-Routing, através de informações precisas sobre o Plano de Dados, obtidas pelo módulo de monitoramento, SDNMon.
❏ (JINYAO et al., 2015) propõe um framework, chamado de HiQoS, para prover en- caminhamento de dados sobre múltiplos caminhos usando a Arquitetura SDN. O
framework possui dois componentes principais: o de serviços diferenciados e o de
roteamento em multiplos caminhos. O primeiro componente será responsável por classiĄcar o tráfego das aplicações de acordo com o uso estimado de largura de banda, onde os tráfegos podem ser classiĄcados em: vídeo com alto uso de banda, vídeo/audio com baixo atraso e um Ćuxo de dados como serviços de melhor esforço. Já o módulo de roteamento irá consultar os dispositivos periodicamente para coletar algumas estatísticas, neste caso a largura de banda de cada Ąla das interfaces, e a partir dessa métrica coletada irá veriĄcar qual a Ąla menos utilizada para aplicar o novo Ćuxo no dispositivo. O fato de escolher sempre a Ąla com menor largura de banda ajuda a balancear a carga e aumentar a eĄciência da rede, como mos- trado no artigo. Diferentemente da nossa proposta, a escolha do melhor caminho em (JINYAO et al., 2015) baseia-se na divisão em nível de Ćuxo, ou seja, um Ćuxo é encaminhado pelo mesmo caminho até o seu término, não havendo a divisão de um mesmo Ćuxo em múltiplos subĆuxos.
3.2.7 QUIC
O QUIC é um protocolo proposto pela Google no ano de 2012, construído em cima do protocolo UDP, e que possui como objetivo principal reduzir o tempo de acesso a uma página Web. O QUIC tem funcionalidades semelhantes ao protocolo TCP, tais como um serviço orientado à conexão, um controle de congestionamento, e também semelhantes ao protocolo Transport Layer Security (TLS)/Secure Socket Layer (SSL), como a criptograĄa e a autenticação dos dados transmitidos. Além disso, permite que uma conexão possua muitas streams de dados, através de uma multiplexação de streams, possibilitando que
3.2. Multi-Caminhos 57
cada stream tenha o seu próprio tráfego e um sistema de controle.
O trabalho proposto em (CARLUCCI; CICCO; MASCOLO, 2015) faz uma descrição do QUIC e o compara com a implementação Cubic (HA; RHEE; XU, 2008) do TCP, rea- lizando experimentos em diferentes condições de rede e utilizando o protocolo HTTP/1.1. No Ąnal dos testes, os autores mencionam que o QUIC pode ser realmente melhor que o TCP em determinadas situações. O trabalho também menciona que o QUIC tem um suporte nativo à multi-caminhos, em decorrência do campo Connection ID em seu cabe- çalho. No protocolo TCP, uma conexão é identiĄcada pela seguinte tupla: [IP de origem, IP de destino, Porta de Origem e Porta de Destino], entretanto, quando um dispositivo move-se para uma outra rede, ou o Network Address Translation (NAT) do roteador é al- terado, por exemplo, os endereços IPs ou as Portas podem ser modiĄcadas, inviabilizando a conexão. Isso não acontece no QUIC, pois como a identiĄcação da conexão ocorre atra- vés do campo Connection ID, os endereços da camada de rede ou as portas da aplicação podem ser alteradas sem afetar a conexão, e isto, indiretamente, garante que um mesmo Ćuxo pode passar por diferentes caminhos durante sua transmissão.
No futuro, o QUIC poderia implementar um mecanismo de multi-caminhos, onde diferentes streams podem passar por diferentes caminhos, a partir da observação da ca- racterística de cada tráfego ou da rede, por exemplo. Isso poderia contribuir para um melhor balanceamento da rede, utilizar de forma mais eĄcientes os recursos disponíveis, entre outras vantagens do uso de multi-caminhos, como descrito na Seção 2.3.
59