Mecanismos para adaptação de QoS ao nível de …marco.uminho.pt/~alex/QoSII/Apresentacao_vbasto_qos_ii_coimbra.pdf · UDP TCP RDP Serviços de Ordem e Fiabilidade Parcial. Vitor

Mecanismos para adaptação de QoS ao nível detransporte

“It did not take long to realise that an access rate available at the MAC

or LLC levels was far from being available above the transport layer.

This is not surprising, because opening a highway does not itself change

drastically the speed of bicycles.”

QoS II - UC/UM (21/03/2000)

Vitor Basto ([email protected])

DI - Universidade Minho

Vitor Basto - QoS II - Universidade doMinho (2)

Estrutura da apresentação

• Motivações do estudo

• Caracterização do cenário de operação

• Âmbito e Objectivos

• Causas do problema, soluções propostas, alternativas e limitações

• Caracterização do protocolo de transporte (ideal)

• Multicast ao nível de transporte

• QoS distribuída (?)

• Adaptação de QoS ao nível de transporte

• Modelos de decisão para a adaptação

• Protocolo hospedeiro

• Conclusões e trabalho futuro


Motivações do estudo - problemas

• Problemas de desempenho, estabilidade e controledetectados na transferência de grandes quantidades deinformação sobre ligações de longas distâncias (pilhaTCP/IP).

E.x.

• EU/DG-JRC/CEO - Centre for Earth ObservationTCP (standard) limita a transferência a 200 kbit/s sobre ligações satélite de34 Mbit/s

• Electricite de FranceExperimenta resultados similares em ligações terrestres de longa distância.


Motivações do estudo - atractivos

• Comunicações satélite (Vs infra-estruturas terrestres)

– Cobertura geográfica alargada e exploração rápida

– Insensibilidade à distância

– Tecnologia típica de difusão (distribuição multiponto)

– L.B a pedido ; ligações de banda larga

• Redes satélite:

– Presente: essencialmente interligação de redes terrestres

– Futuro: Serviços de distribuição multiponto com requisitos consideráveis de LB


Caracterização do cenário

• Canais de dados e controle com LB tipicamente assimétricas.

• Taxas de transmissão - Mbit/s ou mesmo Gbit/s.

• Atrasos de propagação (GEO): RTT ~ 558ms.

• Capacidade de buffering: (buffer > bandwidth * RTT).

– E.g 34 Mbit * 558ms = 2.37 Mbyte

• BER(bit error rates) típica para satélite ~1 x 10-7 (melhor com FEC ao nível de ligação).

Para fibra 10-12 ou melhor.

• Detecção de perdas: mínimo 1*RTT (~ 0.558 s )

• Recuperação de perdas: mínimo 1.5*RTT ( ~ 0.837 s )

• GEO - não apresenta problemas de conectividade.


Âmbito do estudo

• Estudo e desenvolvimento de serviços de transporte de suporte ao

tráfego gerado por aplicações multimedia tolerantes/adaptativas, no

contexto de ligações de longa distância (pilha TCP/IP).

Características de QoS do serviço de rede variáveis.


Objectivos do estudo

• Identificar e medir a adequabilidade dos mecanismos de controle de

congestão e fluxo, ordem, detecção e recuperação de erros,

planeados, especificados e disponibilizados pelos serviços de

transporte TCP/IP no âmbito do estudo e propor soluções

alternativas.

• Enquadrar QoS ao nível de transporte (extremo a extremo) com

QoS no contexto mais global de arquitectura QoS (Aplicações,

Transporte, Rede).


• Ao nível dos protocolos de transporte

– Detecção e recuperação de erros (TCP)

• ack+ acumulados - problemas de identificar status da tx após 1º erro

• timeouts - cálculo de RTT é difícil (LFN’s, routing dinâmico, reflectir a carga da rede,

ambiguidade nos casos de erros/retransmissões)

– Controle e prevenção da congestão (TCP)

• Slow start (activado no inicio da ligação e na ocorrência de erros)

• Não distingue atrasos excessivos, erros de transmissão e perda de informação por

congestão da rede.

• Dificulta tráfego de breves transacções (e.x. tráfego WWW-HTTP/1.0)

– UDP

• Serviço não fiável, não ordenado.

• Não previne nem controla situações de congestão da rede.

Causas do problema


Soluções propostas• Soluções ao nível de controle do protocolo

RFC 1323 - TCP Window Scale e Timestamps Option melhor medição de RTT

RFC 1191 - (TCP Path MTU Discovery) Rácio Inf. Útil/Inf. Controle vs fragmentação

RFC 2018 - TCP Selective Acknowledgment Options

SNACK SCPS - TP Space Communications Protocol Standards -Transport Protocol(extensões TCP com problemas de interoperabilidade impedem aceitação generalizada)

• Soluções ao nível da arquitectura/topologia (redes híbridas/assimétricas)

• Filosofia cliente-servidor

• Comunicação tipicamente assimétrica (dados Vs inf. de controle)

• Tira partido das características dos canais de comunicação.

• Desempenho limitado pela capacidade e balanceamento das ligações.

tam. max. seg. dados /LB canal de dados >= tam. max. seg. de ack/LB canal de controle


Soluções propostas• Soluções ao nível da arquitectura/topologia

Snoop (TCP-aware link layer schemes)

• Recuperação de erros ao nível de ligação. TCP necessita ter conhecimento para não

activar precipitadamente recuperação de erros e controle de congestão quando

TAMBEM detecta perdas/desordens. Redundância de funções a diferentes níveis =>

problemas de coordenação.

Spoofing (split de ligações TCP em cliente - sat. gateway - sat. gateway - servidor)

• Permite que o Gateway use protocolo de transporte mais apropriado ao canal decomunicação reagindo em representação do Cliente (quebrando a semântica extremo aextremo). Gateway trasparente para o servidor permite maior facilidade na comunicação(do ponto de vista do servidor).

Soluções ao nível das aplicações (File stripping)

• Transferência feita através de múltiplas ligações e sincronização ao nível das aplicações

proporciona melhorias de desempenho consideráveis (e.x XFTP, HTTP). Levanta no

entanto problemas ao nível da competição por ligações e da necessidade de

sincronização inter fluxo ao nível aplicacional.


Soluções alternativas• Novos protocolos de transporte

– RDP (Reliable Data Protocol)

– NETBLT (Network Block Transfer Protocol) - específico para transferência de grandesvolumes de dados sobre LFN’s (mecanismos de controle orientados a buffers)

– T/TCP - Acelera processo de setup em ligações TCP

– RTP/RTCP (Real-time Transport Protocol) - Sincronização e Monitorização

– TP++, VMTP, XTP, DTP, Delta-t, SNR, MSP, “AALs”, …

– POC (Partial Order Connection)

• Ordens parciais são previamente acordadas entre os extremos antes da transferência.

• k-XP (connection oriented,unordered, partially reliable). É especificado número máximode retransmissões.

• POCv2 (connection oriented, unordered, controlled-loss services). São feitasretransmissões desde que não atrasem o restante tráfego da ligação.

– MMPOC protocol (End-to-End mobile code - java)


Soluções alternativas

• Flexibilização dos serviços de transporte e respectivos mecanismos de ordem,

detecção e controle de erros e controle de fluxo.

• Permitir a gestão de compromissos entre QoS requerida pelas aplicações e recursos

disponibilizados pela rede, segundo uma lógica aplicacional (orientação à

mensagem/objecto da aplicação - Application Layer Framming).

• + fiabilidade +ordem => +atrasos -desempenho

• Aplicação deverá especificar ao serviço de transporte compromissos desejáveis entre

as diversas características de QoS, que verificam os níveis de serviço mínimos e

níveis de degradação toleráveis.


Soluções alternativas• Serviços de transporte (TCP/IP) apresentam-se em extremos de um

espectro de QoS fiabilidade/ordem. Levanta problemas no desenho das

aplicações que não se enquadram nesses extremos de QoS.

Solução: Serviços de ordem e fiabilidade parcial.

0

1

Fiabilidade

Ordem1

UDP

TCPRDP

Serviços de Ordem e Fiabilidade Parcial



• Melhorias de desempenho dependem das características da tecnologia de rede (LB,atrasos, tx de erros, duplicações e violações de ordem), bem como da flexibilidade dasespecificações QoS das aplicações.

• [Marasli et al. 1994] estudos analíticos revelam as vantagens de serviços de ordem efiabilidade parcial ao nível de transporte TCP/IP.

• Probabilidades de buffering e tempo de buffering no receptor

• Menores atraso extremo a extremo; eventualmente melhor throughput (+ difícil)

• Menor degradação resultante do efeito da perda de confirmações (ACK)

• Papel do serviço de transporte na gestão de compromissos (QoS requerida pelaaplicação Vs QoS fornecida pela rede).

• + QoS (serviço rede) => - reflexos positivos dos serviços OP/FP.


Soluções alternativasExige modelos formais de especificação das características de QoS

(fiabilidade, ordem, sincronização intra e interfluxo)

[Tmin,Tmax]Firing Rules

...

[Tmin,Tmax]

P1

P2

P3

P4

P5

place/processing node

arc

[time interval]

TransitionTime Stream

Petri Nets

[Tmin,Tmax] - associado a um arco (liga um nó - uma transição), representa o intervalo de processamento de um nó (e.g. tempo de apresentação).

Firing Rules - And, Weak-And, Strong-Or, Or, Master, And-Master,Weak-Master,Strong-Master,Or-Master

Transição - Representa sincronização temporal complexa dos arcos de entrada (processamentos individuais)



• Para o nível aplicacional

• XML, SMILE, ... (Geralmente os modelos de sincronização encontram-se

implícitos nas aplicações Vs modelos explícitos).

• Para o nível de transporte

• Time Stream Petri Nets

• Modelos de gestão de compromissos de QoS (heurísticos, probabilisticos, ...)

• Modelo computacional para animação/verificação da especificação

• Para o nível de rede

• Mapear QoS ao nível aplicacional em QoS/CoS ao nível da rede.


Soluções alternativas• Mapear QoS ao nível aplicacional em QoS/CoS ao nível da rede.

• No contexto exclusivo de redes IP

• Classes IP diffserv

• No contexto de tecnologias de rede com características QoS diferentes

• IP , ATM, RDIS, GEO, LEO, ...

• Impossibilidade de encontrar protocolos genéricos e eficientes/eficazes

• Protocolos específicos a cada tipo de rede (TCP/TCPSat, IP, ATM, AALs)

• Diferentes protocolos, diferentes redes => Problemas de sincronização

• Problemas na escolha das redes e gestão dos diferentes protocolos

Aplicações

UDPTCP SatTCPATM RDIS IP ...

Mecanismos de ordem e fiabilidade parcial

Mecanismos de escolha da tecnologia de rede/pilha


Protocolo hospedeiro• Características desejáveis do protocolo de transporte hospedeiro dado o âmbito e

motivações do estudo (principais funções do nível de transporte):

• Orientação à ligação (e.g. troca de informação sobre controle de fluxo da ligação)

• Detecção de erros/perdas e duplicados ; recuperação de erros (a pedido)

• Verificação de integridade da informação de controle e/ou dados (a pedido)

• Verificação de ordem (de acordo com especificação explicita)

• Efectuar controle de fluxo window/rate based (a pedido)

• Permitir transmissão ponto-ponto ou ponto-multiponto

• Entrega de tráfego prioritário fora de ordem (a pedido) [e.g. sinalização ao nível de sessão]

• Estabelecimento de prioridades entre ligações/sessões (complexo)

• Autenticação e confidencialidade (a pedido)

• Reportar estado interno do protocolo e da comunicação (ligação/sessão)


Protocolo hospedeiro

• UDPServiço orientado a transferência de mensagens, não fiável, não orientado à ligação

• TCP (rfc 793 ...)Serviço fiável, transferência de fluxo de bytes; controle de fluxo baseado em ordem linear enão em ordem parcial; orientado à ligação (ponto a ponto).

• RDP (rfc 908 e 1151)Serviço fiável, transferência de mensagens ; serviço ordenado é possível se definido noestabelecimento da ligação; orientado à ligação (ponto a ponto).

• RTP/RTCP (rfc 1889 ...)Permite transmissão ponto-multiponto ; permite a definição das características do serviço detransporte numa lógica por mensagem/fluxo; preconiza mecanismos de monitorização dascaracterísticas de QoS.


Multicast ao nível de transporte

Principais objectivos dos protocolos de transporte Multicast

Para tráfego de tempo real:

• Limitar atrasos. À custa de menor fiabilidade (e.g. RTP)

Não efectuam recuperação de erros

Não concebem fiabilidade e ordem parcial

Não realizam controle de fluxo, nem prevenção e controle de congestão.

Para tráfego sensível a perdas:

• Garantir fiabilidade. À custa de maiores atrasos (e.g. RMTP, SCE)

Não suportam sincronização (fluxo único)

Não concebem fiabilidade e ordem parcial

Ligações e receptores com capacidades mais baixas limitam QoS do grupo


Multicast ao nível de transporteOutros protocolos de multicast fiável ao nível de transporte:

• MTP - multicast atómico com controle de fluxo; mantém sincronização entre os membros do grupo

• RAMP/MGA - participação controlada por nó raiz. Estabelece caminhos de conecção/desconecção

• XTP - multicast não fiável e semi-fiável - receptores que não se distanciem muito do estado do grupo

(Tratam semânticas de grupo muitos-muitos: FIFO, ordem total, atomic commitment, cordem causal, consensos. Centrais em sistemas transaccionais e orientados aos grupos)

• SCE - Interface entre o nível de rede/transporte para multicast fiável (e.g. TCP - SCE - IP)

Outros protocolos de multicast fiável ao nível da rede

• ST-II - Garante atraso extremo-extremo; implica reserva de L.B pª todas as ligações em fase de setup

• URGC - Apropriado para operações de S.O distribuídos que gerem recursos duplicados/redundância.



Sender

ACKProc.

RecACKProc.

RecRec

• Requer subtree multicasting (SUBTREE_MCAST packet type)

• Distribuição evita ACK Implosion em grupos grandes

• Permite RTT mais rigorosos, gestão de QoS + localizada/descentralizada

• Definição de AP estática (falta protocolo de sessão pª definição dinâmica)

RMTP (Reliable Multicast Transport Protocol)



• AP’s enviam pacotes de controle periodicamente (RTT inicial constante)

• Receptores escolhem AP dinamicamente com base em n.º hops (RTT)

• Primeiro AP de qualquer receptor é o emissor (depois é o mais o próximo).

• AP deixa de ser acessível (e.g. crash) pelo expirar de timeout de pacote de controle

• Detecção e recuperação de erros (ack acumulado + bitmap [ 0/1] janela de mensagens)

• Retransmissão multicast/unicast conforme n.º de receptores destino (receivers count).

• Controle de fluxo baseados em janela de mensagens e taxas de transmissão (descentralizado)

• Detecção de congestão feita com base nos pedidos de retransmissão dos receptores

• Controle de congestão através de janelas de envio e de congestão (descentralizado)

RMTP (Reliable Multicast Transport Protocol)



• Pressupõe disponibilidade/esforço dos participantes em fazer buffer de mensagens sempre que possível.

• Pedido de retransmissão é difundido (multicast) para os potenciais retransmissores (subgrupo).

• Requer contention resolution,nos pedidos de retransmissão.

• Requer contention resolution,na retransmissão (escuta e timers aleatórios [RTT, 2*RTT] do sub grupo)

• Gestão da recuperação de erros no grupo/sub grupo não requer líder. Feita com base em TTL (distância)

• Na impossibilidade de recuperação (ou recuperação parcial) no primeiro sub grupo => aumento de TTL

e novo pedido de retransmissão par ao próximo sub grupo

• Permite envio de mensagens não fiáveis (consideradas prioritárias

e sem qualquer verificção de ordem)

Light-Weight Reliable Multicast Protocol

R1

R2

R3 R1

R2

R1

R2

R4

Sender

Distance

Hierarquia de sub grupos/anéis



etc (which are central topics in transactional systems and group-oriented systems). Reliable distributed protocols imply complex relashionships. For example, both the atomic commitment and total order multicast rely on consensus, while the later is itself based on failure detections, on reliable point-to-point communications, and on reliable multicasts.This create a complex protocol dependency which we are not dealing with at the transport layer.

Falha pela ausência de um serviço adaptativo ao nível de transporte:

• Adaptação à QoS da rede e suas variações com base em requisitos QoS das aplicações

• Adaptação distribuída/localizada à degradação causada por assimetrias de QoS nas ligações

• Gestão de QoS entre fluxos ; sincronização (ultrapassar noção de fluxo único)

Necessitam mecanismos e modelos quantitativos de suporte à decisão:

• Para gestão e adaptação de QoS

• Para eliminação de participantes que comprometam a QoS do grupo

• Para descentralização e mobilidade de agentes de gestão de QoS (nível de transporte)


QoS distribuída

RecRec

QoSProc.

QoSProc.

Sender

Rec

QoS Aware AdaptationMechanisms

RecRec

QoSProc.


Satellite link


Fiber high speed link


QoS distribuída

• Topologia dinâmica => protocolo de sessão (escolha e mobilidade de QoS Proc’s)

• Mobilidade de QoS Proc. => capacidade dos QoS proc.’s e localização na arvore

• Mobilidade de agentes QoS (experiência/conhecimento) => plataformas virtuais de operação

• Criação de QoS proc => seccionamento mento com base nas características de QoS específicas

• Descentralizar , distribuir, localizar decisões sobre níveis de degradação a adoptar

• Isolar assimetrias/degradação resultantes de características de QoS da rede/receptores diferentes

• Adaptação QoS => monitorização e modelos de decisão quantitativos (emissor, receptor e QoS proc.)


Adaptação de QoS (transporte)Modelos de decisão necessários no suporte às operações do nível de transporte:

• No emissor:

• Ordens de envio (dependem de erros e duração da transmissão, ciclo de vida na aplicação, etc.)

• FEC (forward error correction), taxas de erro e padrões/distribuição dos erros

• ...

• No receptor:

• Ignorar /recuperar perdas ? Reflexos/impacto na degradação de QoS ?

• Pedir retransmissão ? a um ou mais QoS proc. ?

• Em processador QoS:

• Risco de violação de QoS causada por limitações de ligações => Desafiar criação de sub arvores

• Risco de violação de QoS causada por limitações de ligações => remoção do grupo

• Escolha de QoS proc. pelos receptores => nº de hops (proximidade) + critérios de afinidade QoS


QoS distribuída

RecRec

QoSProc.

QoSProc.

Sender

Rec


RecRec

QoSProc.


Satellite link


Fiber high speed link

Source QoS for all receiversConstant ; No QoS adaptation

(IP flow)

Control flow path

managed QoS for a sub treeConstant ; No QoS adaptation

(IP flow)

Data flow path from sender

QoS Proc. data flow

• Adaptação efectuada só nos fluxos controlados pelos QoS Proc. e não no fluxo multicast emissor-receptores

• QoS do fluxo multicast emissor-receptores é controlado apenas pela entidade de transporte emissora

• Adaptação de QoS em agentes de transporte no fluxo multicast emissor - receptores ???!!!

• Protocolo de sessão, criação de nova arvore unicast/multicast para relay de transport com adaptação QoS ?!


Minimum QoS value

Optimal QoS value

Current QoSmeasurement

Intolerable QoS value

Time

Tallowed Tallowed

QoSCharacteristic

Adaptação de QoS (transporte)

Níveis/zonas de degradação e riscos de violação de QoS:


Adaptação de QoS (transporte)• Variáveis a considerar na especificação das características de QoS

• Tempo (virtual/elástico)

• Fiabilidade

• Ordem (dependências de ordem, operadores lógicos e temporais)

• Custo ?

• Variáveis a considerar nas decisões ao nível de transporte• Taxas de erros da rede e tipo de erros (congestão, transmissão, conectividade)

• Atraso extremo a extremo e Jitter

• Tamanho das mensagens e dos buffers

• Estado global da comunicação (múltiplos fluxos)

• Características de QoS da mensagem

• Densidade da ordem parcial, relações de dependência

• Tempo de processamento por pacote de dados/controle



FECProcessing

Transport MonitorError detectionand recovery

Buffer management interface

DegradationManager

ClassifierFormal descriptions

andDecision models

Fragmentation

Application layerTransport layer

Sender Application

Network layer

Dispatcher -> QoS classes(Does flow control)

Network Monitor

Transportmanagement

Transportmechanisms

Discarder

* Fluxo de controle do receptor não representado



• Fragmentation (MTU) - Especificação QoS deve automaticamente garantir que os fragmentos são

tratados como mensagem única.

• Classifier - Com o suporte dos modelos formais classifica mensagens de acordo com a sua

importância na manutenção da QoS especificada pela aplicação (fiabilidade, ordem, e

parâmetros calculados e.g. densidade da ordem linear, graus de inter-dependência das

mensagens, etc.)

• Degradation manager - Calcula ordens de envio. Estabelece compromissos na manutenção

da QoS desejada. Sacrifica fluxos com menos impacto na degradação ou melhores

níveis de QoS em favor de fluxos com QoS mais próxima dos limites toleráveis. Tem

em conta indicadores de QoS da rede (Network monitor -> B/W Broker ?, métricas

associadas a CoS ?)



• Transport monitor - Regista métricas de QoS dos fluxos de transporte (individuais e agregados).

Detecta e regista violações de QoS.

• Error detection and recovery - mecanismos de avaliação de perdas e seus padrões (transmissão,

congestão) e recuperação de erros/retransmissões.

• FEC - Cria redundância sobre mensagens individuais ou de forma sistemática sobre fluxos

• Discarder - Elimina mensagens em buffer, eventualmente de forma sistemática sobre os vários fluxos

• Dispatcher - Injecta mensagens na rede. Verifica (taxas e) janelas de controle de congestão e de fluxo



Transport Monitor DiscarderError detectionand recovery

Application layerTransport layer

Receiver Application

Reassembly

Buffer management interface

Dispatcher(synchronization interface)

DegradationManager

Formal descriptionsand

Decision models

Network layer

Transportmanagement

Transportmechanisms

* Fluxo de controle para o emissor não representado


Modelos de decisãoVariáveis:

x: Densidade da ordem e relações de dependência da mensagem

y: Taxa de erros detectada por monitorização

z: Padrão dos erros (congestão, transmissão)

w: Ordem e fiabilidade exigível da mensagem

k: Atraso e jitter

i: Tamanho da mensagem

j: Tempo de processamento do pacote de dados/controle

Decisões:

Discarder(x, y, z, w, k) -> {0|1}

FEC(x, y, z, w, k, i, j) -> {0|1}

Recover(x, w, k, i) -> {0|1}

Classifier(j, i, k) -> {0 .. n}

Degradation manager(x, …, j) -> {0 .. n}

Dispatcher(x, z, w, k, I, j) -> {0|1}

...



Padding

1b 1b

CSRC Count Mark Payload Type Sequence Number

16b7b1b4b2b

Timestamp

Synchronisation source (SSRC) identifier

Contributing source (CSRC) identifier...

Extension...

Ext.Flag

LengthDefined by profile Header extension

Version

RTP Header Format

• Transmissão ponto-multiponto; suporte a tráfego de tempo real

• Permite a definição das características do serviço de transporte numa lógica por mensagem

• Disponibiliza mecanismos de monitorização das características de QoS.

• Facilmente extensível (fluxo de dados, controle e de monitorização)


Sender report RTCP packet

Padding

1b

Sender’s pack count

Sender’s octet count

SSRC_1 (SSRC of first source)

extended highest sequence number received

interarrival jitter

last SR (LSR)

delay since last SR (DLSR)

SSRC_2 (SSRC of second source)

...

profile-specific extensions

Recep. Rep. CountPayload Type (=200)

8b5b

Length

fraction lost cumulative number of packets lost

2b

Version

NTP Timestamp most significant word

NTP Timestamp least significant word

RTP Timestamp

SSRC of Sender

16b



Application-defined RTCP packet


Padding

1b 8b5b2b

Version

SSRC of Sender

16b

Subtype Payload Type (=204) Length

Name (ASCII)

Application-dependent data


Conclusões

Adaptação <=> Tolerância/Flexibilidade

Escalabilidade <=> Distribuição de funcionalidades

Heterogeneidade <=> Descentralização

Dinamismo <=> Mobilidade

Adaptação, Distribuição, Descentralização, Mobilidade

=>

DECISÃO


Conclusões

• Limitações da abordagem

Difusão onde não seja requerida sincronização entre emissores, mas apenas sincronizaçãoentre fluxos de um emissor - um para muitos

E.g. partilha de recursos (ponteiros/cursores). Problemas em operações não idempotentes

Ultrapassado com recursos diferenciados por emissor: múltiplos ponteiros/cursores

• Trabalho futuro

– Definir extensões RTP, Payload types, ... RTCP reports, ...

– Formular, enquadrar, adaptar modelos de decisão para adaptação de QoS

– Avaliar QoS distribuida e estudar protocolos de sessão

– ...

Documents

Mecanismos para adaptação de QoS ao nível de …marco.uminho.pt/~alex/QoSII/Apresentacao_vbasto_qos_ii_coimbra.pdf · UDP TCP RDP Serviços de Ordem e Fiabilidade Parcial. Vitor