Políticas de Fila

As políticas de fila podem ser compostas por uma única fila única, tratando a ordem de transmissão pacote-a-pacote e de descarte de pacotes enfileirados quando a capacidade de ar- mazenamento esgota, ou uma política de múltiplas filas, separando as classes de QoS em filas com tratamento distintos. O tratamento destas filas é definido por uma disciplina de escalona- mento de tráfego. As duas disciplinas de serviço adotadas neste trabalho, de modo a viabilizar a baixa complexidade dos escalonadores de tráfego propostos foram a Round Robin (RR) e a Priority Scheduling(PrioSched).

Referência: Drop Tail Fila Única

A disciplina de enfileiramento mais simples é a FIFO. Assim como a disciplina de descartes de menor complexidade é aquela na qual os pacotes que na sua chegada encontram o buffer de enfileiramento cheio são descartados. Como referência, utiliza-se a composição destas discipli- nas em uma única política de fila, a qual denominaremos apenas por Drop Tail. Utilizaremos esta referência para o ganho alcançado pelas propostas estudadas neste trabalho, já que este é o tratamento mais básico que se pode ter em um sistema de comutação de pacotes amplamente utilizado na prática.

Porém, para que seja possível comparar esta política de escalonamento de tráfego com as demais políticas propostas, compostas por duas filas, sem prejuízos causados por descartes originados pela desigualdade no tamanho dos buffers empregados, determinou-se o tamanho dos buffersexperimentalmente de forma a sobredimensionar a sua capacidade para que descartes

não ocorressem.

Premissas para a Divisão dos fluxos

As aplicações TCP reagem ao congestionamento e às perdas em uma rede de três formas distintas: através da alteração do tamanho de suas janelas (congestionamento e de recepção), de processos rápidos de retransmissão de pacotes ou da retransmissão destes após o timeout (PAXSON; ALLMAN, 2000). Para conexões curtas, o que implica em pequenas janelas de congestionamento, a perda é normalmente detectada após o timeout e, provavelmente, após a finalização da transmissão de todos os dados. Como resultado disto, temos que a retransmissão após o timeout, para conexões curtas, não é muito eficaz na redução do tráfego global de uma rede e em sua estabilização.

Quando é utilizada uma fila única, há desigualdade na disputa entre fluxos longos e curtos na ocupação desta. Os fluxos longos, em fase de controle de congestionamento, alcançam maiores janelas de transmissão implicando, assim, na transmissão de dados em longas rajadas de pacotes e consequente ocupação de maiores porções do buffer. Dado que este recurso é limitado, o esgotamento do buffer acarreta em descartes que oneram em maior proporção o desempenho de fluxos curtos, que alcançam pequenas janelas de transmissão.

A separação de fluxos longos e curtos em duas filas distintas, além de aumentar a equidade na disputa na ocupação do buffer entre estas classes, pode proporcionar economia deste recurso. Resultados em (PSOUNIS et al., 2005) indicam que a somatória do tamanhos dos buffers ne- cessários para a classe de fluxos longos e para a classe de fluxos curtos é menor que o tamanho necessário quando se utiliza um único buffer compartilhado.

Running Number 2 Class (RuN2C)

O mecanismo de diferenciação RuN2C é um escalonador de tráfego TCP/IP que processa duas classes de prioridades. Nele, os pacotes são classificados como baixa ou alta prioridade de acordo com o número de bytes transmitidos numa sessão TCP. Os pacotes pertencentes a cada uma dessas classes são lotados em um fila FIFO. Após isso, utiliza-se uma disciplina de escalo- namento para transmissão destes pacotes. Na proposta original do RuN2C (AVRACHENKOV; BROWN; NYBERG, 2004), a disciplina de escalonamento utilizada é a PrioSched. No entanto, também se experimenta neste trabalho a disciplina RR.

A diferenciação dos pacotes pelo RuN2C é realizada sem manutenção de estados das co- nexões TCP ativas. Quando uma conexão é estabelecida, um número de sequência inicial, ISN

3.1 Objeto de Estudo: Diferenciadores de Fluxo 55

(Initial Sequence Number), de 32 bits é gerado de maneira aleatória. A cada pacote transmitido é somado a este ISN o número de Bytes transferidos. Isto possibilita a diferenciação dos fluxos ativos no roteador, através deste campo do cabeçalho TCP, apenas com o controle da geração destes números iniciais nas máquinas fontes de tráfego e da comparação deles com um limiar nos roteadores.

Após a transferência do primeiro pacote um número de sequência inicial é incrementado de um número máximo de bytes igual ao MSS (Maximum Segment Size) da rede. Para um MSS igual a 1460 bytes, temos que, aproximadamente os 10 bits menos significativos, log₂(MSS = 1460) ≈ 10, do número de sequência seriam utilizados logo no primeiro pacote. Assim, estes bits poderiam ser utilizados, sem prejuízos ao limiar, para geração de um ISN. No entanto, 10 bits gerariam apenas 1024 possíveis ISNs, não provendo aleatoriedade suficiente a estes núme- ros, possibilitando problemas de segurança, tais como IP spoofing para sequestro de conexões e sessão hijacking (SUN et al., 2007).

Desta forma, a divisão do número de sequência é feita de acordo com a Figura 3.2. Utilizam- se além dos 10 bits menos significativos, os 10 bits mais significativos, campo R, para a geração dos ISN, totalizando em 220 ≈ 1 milhão de possíveis números iniciais.

Figura 3.2: Padrão do número de sequência utilizado pelo RuN2C

A geração dos ISNs se dá através de uma função específica no kernel dos sistemas operacio- nais. Desta forma, para que o Run2C funcione adequadamente é necessário que uma adaptação na geração destes números de sequência iniciais seja realizada. Esta adaptação deve-se dar pelo menos na máquina que envia os arquivos. Para os experimentos, optamos pela alteração nas duas máquinas. Como mostrado, requisito para que o mecanismo Run2C funcione adequada- mente é a geração dos 32 bits dos números de sequência inicial na forma: 20 bits, os 10 bits mais e os 10 bits menos significativos são gerados de maneira aleatória possibilitando um total de 1 milhão de ISNs e os 12 bits restantes devem ser iniciados com zero quando uma conexão TCP é estabelecida. Para isto, alteraram-se as funções do kernel Linux responsável pela geração destes ISNs aplicando-se ao final da função de geração existente uma máscara sobre o número

gerado pelo algoritmo. Ela mantém os 20 bits necessários aleatórios e zera os demais. O arquivo alterado foi o Random.c, localizado dentro do kernel em linux<versão>/drivers/char/.

O parâmetro de ajuste do RuN2C é o limiar de separação, TH. O mecanismo segrega as conexões que transmitirem um número de bytes superior a este limiar a fila de fluxos longos. Assim, o limiar deve ser escolhido de forma que os fluxos curtos se beneficiem do mecanismo de diferenciação, todavia, mantendo-se baixa a carga de alta prioridade para que fluxos longos não sejam prejudicados demasiadamente. A determinação desse limiar será discutida no Capítulo 4, com base em uma análise experimental.

Random Assorter of Flow LEngths (RAFLE)

A dependência de alterações na implementação dos protocolos básicos da Internet (TCP/IP) para que uma política de diferenciação de fluxos funcione adequadamente é um ponto complexo na implantação desta em ambientes em operação. Assim, mecanismos de diferenciação de fluxos que consigam realizar a isolação de fluxos através de informações do tráfego passante em um roteador, sem que o grau de complexidade dos algoritmos cresça pela necessidade de manter os estados de todas as sessões ativas, tornam-se necessários.

Para inferir que pacotes pertencem a fluxos de longa duração que ocupem uma grande porção dos recursos disponíveis nos enlaces, o escalonador de tráfego RAFLE, proposto neste trabalho, utiliza da característica de transmissão em rajadas dos fluxos na Internet.

De acordo com o princípio de funcionamento do TCP, fluxos que transferem grandes volu- mes de dados alcançam altos valores de janela de transmissão, o que implica em longas rajadas de pacotes. Mantendo-se uma pequena memória da identificação de fluxo, que denominaremos de flowID, dos últimos pacotes processados pelo roteador é possível inferir que um pacote per- tence a uma rajada de longa duração. Porém, não se deve demandar muito tempo varrendo toda a memória, o que acarretaria em aumento do atraso na componente de processamento.

A cada pacote pertencente a uma rajada de um fluxo que é processado pelo roteador, maior a probabilidade do flowID de um novo pacote que ingressa neste estar armazenado na memó- ria. Desta forma, a estratégia utilizada pelo RAFLE é sortear uma posição da memória (Pa), segundo uma distribuição uniforme, e então efetuar a comparação do flowID existente nesta po- sição da memória (FlowID_memoria(Pa)) com o do novo pacote (FlowID_atual) que chega ao roteador. Caso os FlowIDs sejam idênticos, o novo pacote é encaminhado para a fila de fluxos longos. Caso contrário ele ingressa na fila de fluxos curtos.

3.1 Objeto de Estudo: Diferenciadores de Fluxo 57

não haja FlowID na posição da memória sorteada, o pacote é enviado para a fila de fluxos curtos e seu FlowID é inserido na tabela normalmente. A memória do classificador RAFLE é utilizada de forma rotativa, para que não seja necessário deslocar todos os FlowIDs nela inseridos para as posições posteriores a cada novo pacote. A última posição onde foi inserido um FlowID é marcada através de ponteiro incremental (Pu).

Assim, o processo de decisão do algoritmo RAFLE é apresentado na Figura 3.3. O desem- penho do classificador depende do ajuste do parâmetro N, que indica o tamanho da memória, em número de linhas, que o classificador irá utilizar.

Figura 3.3: Diagrama de fluxo do algoritmo RAFLE

Uma das vantagens do RAFLE é a possibilidade de uso do algoritmo para diferentes defi- nições de fluxo. Neste trabalho, a identificação dos fluxos TCP, padrão do FlowID, utilizada é composta da tupla (IP de Origem, Porta de Origem, IP de Destino, Porta de Destino) totalizando o armazenamento de apenas 12 bytes por posição da memória.