revisitando os fundamentos da internet: das …dcomp.sor.ufscar.br/verdi/inatel2016.pdfrevisitando...

Revisitando os Fundamentos da Internet: das origens até a

Atualidade e Percepções FuturasProf. Fábio Luciano Verdi

Departamento de Computação

UFSCar

http://www.leris.sor.ufscar.br

Vamos falar um pouco sobre a Internet do Passado (e do Presente)

Quando surgiu a (Arquitetura da) Internet?

Momentos e fatos relevantes

• Em 1974, VINTON G. CERF AND ROBERT E. KAHN, publicam o artigo “A Protocol for Packet Network Intercommunication” na IEEE Trans on Comms, Vol Com-22, No 5 May 1974. Vamos analisar este artigo.

• Introduction: “IN THE LAST few years considerable effort has been expended on the design and implementation of packet switching networks [1]-[7],[14],[17]”.• O mais interessante é que o artigo de Cerf não cita os trabalhos de Kleinrock sobre

comutação de pacotes. Veja a tese de doutorado de Leonard Kleinrock em 1961:• “Information flow in large communication Nets”


• Several protocols have already been developed for this purpose [8]-[12],[16]. However, these protocols have addressed only the problem ofcommunication on the same network. In this paper we present a protocoldesign and philosophy that supports the sharing of resources that exist indifferent packet switching networks.

• Gateway:In practice, a GATEWAY between two networksmay be composed of two halves, each associatedwith its own network. It is possible to implementeach half of a GATEWAY so it need only embedinternetwork packets in local packet format orextract them.

Since the GATEWAY must understand the addressof the source and destination HOSTS, this informationmust be available in a standard format in everypacket which arrives at the GATEWAY. Thisinformation is contained in an internetwork headerprefixed to the packet by the source HOST.


The packet format, including the internetwork header, is illustrated in Fig. 3. The source and destination entries uniformly and uniquely identify the address of every HOST in the composite network. Addressing is a subject of considerable complexity which is discussed in greater detail in the next section. The next two entries in the header provide a sequence number and a byte count that may be used to properly sequence the packets upon delivery to the destination and may also enable the GATEWAYS to detect fault conditions affecting the packet. The flagfield is used to convey specific control information and is discussed in the section on retransmission andduplicate detection later. The remainder of the packet consists of text for delivery to the destination and a trailing check sum used for end-to-end software verification.

Unless all transmitted packets are legislatively restricted to be small enough to be accepted by every individual network, the GATEWAY may be forced to split a packet into two or more smaller packets. This action is called fragmentation and must be done in such a way that the destination is able to piece together the fragmented packet.


We take the position that GATEWAY should not perform this function (reassembly) since GATEWAY reassembly can lead to serious buffering problems, potential deadlocks, the necessity for all fragments of a packet to pass through the same GATEWAY, and increased delay in transmission. Furthermore, it is not sufficient for the GATEWAY to provide this function since the final GATEWAY may also have to fragment a packet for transmission. Thus the destination HOST must be prepared to do this (reassembly) task.


• PROCESS LEVEL COMMUNICATION• Within a HOST we assume that existence of a transmission control program (TCP)

which handles the transmission and acceptance of messages on behalf of the processes it serves.

• If the TCP is to determine for which process an arriving packet is intended, every packet must contain a process header (distinct from the internetwork header) that completely identifies the destination process.

• To decide whether the arriving data is deliverable to the destination process, the TCP must be able to determine whether the data is in the proper sequence.


• TCP ADDRESSING• The choice for network identification (8 bits) allows up to 256 distinct networks.

This size seems sufficient for the foreseeable future. Similarly, the TCP identifier field permits up to 65 536 distinct TCP’s to be addressed, which seems more than sufficient for any given network.


• RETRANSMISSION AND DUPLICATE DETECTION• We propose a timeout and positive acknowledgement mechanism which will allow

TCP’s to recover from packet losses from one HOST to another. A TCP transmits packets and waits for replies (acknowledgements) that are carried in the reverse packet stream. If no acknowledgement for a particular packet is received, the TCP will retransmit.

• Any retransmission policy requires some means by which the receiver can detect duplicate arrivals.

Momentos e fatos relevantes• No artigo de Cerf, fala-se apenas em controle de fluxo. Nada é dito sobre

controle de congestionamento• Em 1988, Van Jacobson publica o artigo Congestion Avoidance and Control, ACM Comp.

Communication Review.• In October of '86, the Internet had the first of what became a series of 'congestion

collapses'. During this period, the data throughput from LBL to UC Berkeley (sites separated by 400 yards and three hops) dropped from 32 Kbps to 40 bps. Mike Karels and I were fascinated by this sudden factor-of-thousand drop in bandwidth and embarked on an investigation of why things had gotten so bad. We wondered, in particular, if the 4.3BSD (Berkeley UNIX) TCP was mis-behaving or if it could be tuned to work better under abysmal network conditions. The answer to both of these questions was “yes”. Since that time, we have put seven new algorithms into the 4BSD TCP:• round-trip-time variance estimation• exponential retransmit timer backoff• slow-start• more aggressive receiver ack policy• dynamic window sizing on congestion• Karn's clamped retransmit backoff• fast retransmit (3 acks duplicados)


• Em 1988, Van Jacobson publica o artigo Congestion Avoidance andControl, ACM Comp. Communication Review.• The flow on a TCP connection should obey a ‘conservation of packets’ principle. And,

if this principle were obeyed, congestion collapse would become the exceptionrather than the rule. Thus congestion control involves finding places that violateconservation and fixing them.

• By ‘conservation of packets’ we mean that for a connection ‘in equilibrium’, i.e., running stably with a full window of data in transit, the packet flow is what a physicist would call ‘conservative’: A new packet isn’t put into the network until anold packet leaves. The physics of flow predicts that systems with this propertyshould be robust in the face of congestion.


• Também não se usa o termo Internet Protocol (IP)• INTERNET PROTOCOL SPECIFICATION September 1981: RFC 791, Jon Postel

• TRANSMISSION CONTROL PROTOCOL September 1981: RFC 793, Jon Postel

• E sobre o UDP?• David Clark em seu artigo THE DESIGN PHILOSOPHY OF THE DARPA INTERNET PROTOCOLS,

ACM Sigcomm 1988 escreve:• The initial concept of TCP was that it could be general enough to support any needed type of service

• The first example of a service outside the range of TCP was support for XNET

• Another service which did not fit TCP was real time delivery of digitized speech, which was needed to support the teleconferencing aspect of command and control applications

• It was thus decided, fairly early in the development of the Internet architecture, that more than one transport service would be required, and the architecture must be prepared to tolerate simultaneously transports which wish to constrain reliability, delay, or bandwidth. at a minimum. This goal caused TCP and IP, which originally had been a single protocol in the architecture, to be separated into two layers.

• RFC 768 define o UDP: Jon Postel em Agosto de 1980

E então?

• Como isso tudo se relaciona com o que temos atualmente? Lembrando que... All IP

Cloud + datacenters

• ECMP: hashing nos 5 campos: IPo, IPd, Po, Pd, protocolo

A flow might be identified solely by destination address, or it might be identified by (source address, destination address, protocol id) triplet. Hence "flow" is not necessarily synonymous with the term "microflow" as used in RFC 2474, which also includes port numbers. Indeed, including transport-layer information in the next-hop selection process can actually be problematic. For example, if packets are fragmented, the transport-layer information may not be available in every packet.

RFC 2991

Cloud + datacenters + Internet + fragmentação


• Como evitar a fragmentação do IP buffersizeMSS


• Como evitar a fragmentação do IP min( buffersize, MTU)


• Path MTU Discovery (PMTUD): RFC 1063 (1990)• If PMTUD is enabled on a host, and it almost always is, all TCP/IP or UDP

packets from the host will have the DF bit set.

• When a router is unable to forward a datagram because it exceeds the MTU of the next-hop network and its Don't Fragment bit is set, the router is required to return an ICMP Destination Unreachable message to the source of the datagram, with the Code indicating” fragmentation needed and DF set”. When the source station receives the ICMP message, it will lower the send MSS, and when TCP retransmits the segment, it will use the smaller segment size.

Mensagens ICMP sãotipicamente bloqueadas pelos

firewalls

E então?

• Como isso tudo se relaciona com o que temos atualmente? Lembrando que... All IP

2G/3G 4G

Para finalizar…

• É possível alcançarestes requisitostendo o IP comoprotocolo de Rede?

Para finalizar…

• Monitoring in the virtualization era

• Visualization of (very very) huge quantitiy of monitoring data

Para finalizar…

(city, home, world, *) with Machine Learning

• Load balancing

• VMs

• Containers

• Pearson’s correlation

Para finalizar…

New and interoperable (network) protocols for IoT

and 5G world

Low latency

No (zero) fragmentation

Less retransmission

Perguntas!!!

http://[email protected]

revisitando os fundamentos da internet: das …dcomp.sor.ufscar.br/verdi/inatel2016.pdfrevisitando...

Documents