diff --git a/exercises/ex-sharing.rst b/exercises/ex-sharing.rst index 79f2f77..b4e9aec 100644 --- a/exercises/ex-sharing.rst +++ b/exercises/ex-sharing.rst @@ -639,7 +639,7 @@ In general, the links have a non-zero delay. This is illustrated in the figure b Discussion questions ==================== -.. spelling:: +.. spelling:word-list:: slotTime diff --git a/exercises/ipv6.rst b/exercises/ipv6.rst index a607403..4003ac0 100644 --- a/exercises/ipv6.rst +++ b/exercises/ipv6.rst @@ -516,7 +516,7 @@ What do you think about the proposed configuration? Assign IP subnets to all links in this network so that you can reduce the number of entries in the forwarding tables of all routers. Assume that you have received a ``/56`` prefix that you can use as you want. Each subnet containing a host must be allocated a ``/64`` subnet. -.. spelling:: +.. spelling:word-list:: namespace namespaces @@ -647,7 +647,7 @@ The same can be done for the three links between the different routers. With these IP prefixes and the network topology, we can now use IPMininet_ to create the topology and assign the addresses. -.. spelling:: +.. spelling:word-list:: addDaemon StaticRoute @@ -752,7 +752,7 @@ The ``links`` command lists the links that have been instantiated and shows that r3-eth2<->b-eth0 (OK OK) mininet> -.. spelling:: +.. spelling:word-list:: inet inet6 diff --git a/exercises/lan.rst b/exercises/lan.rst index c3965b9..f4ece06 100644 --- a/exercises/lan.rst +++ b/exercises/lan.rst @@ -1,4 +1,5 @@ -.. Copyright |copy| 2013,2019 by Justin Vellemans, Florentin Rochet, David Lebrun, Juan Antonio Cordero, Olivier Bonaventure +.. Copyright |copy| 2013,2019 by Justin Vellemans, Florentin Rochet, + David Lebrun, Juan Antonio Cordero, Olivier Bonaventure .. This file is licensed under a `creative commons licence `_ Local Area Networks: The Spanning Tree Protocol and Virtual LANs @@ -69,7 +70,7 @@ Exercises Fig. 3. Host `H0` performs a traceroute towards its peer `H1` through a network composed of switches and routers - .. spelling:: + .. spelling:word-list:: versa diff --git a/exercises/routing-protocols.rst b/exercises/routing-protocols.rst index 2a30123..5773181 100644 --- a/exercises/routing-protocols.rst +++ b/exercises/routing-protocols.rst @@ -612,7 +612,7 @@ Besides :manpage:`ping6(8)` and :manpage:`traceroute6(8)`, it is also useful to Password: -.. spelling:: +.. spelling:word-list:: Quagga @@ -678,7 +678,7 @@ A useful command to start is `show bgp summary` which provides a summary of the Total number of neighbors 2 -.. spelling:: +.. spelling:word-list:: Keepalive @@ -803,7 +803,7 @@ This router (`as1`) has two BGP neighbors: ``2001:cafe:1:12::2`` and ``2001:cafe Read thread: on Write thread: on -.. spelling:: +.. spelling:word-list:: BGP Loc diff --git a/exercises/tcp-2.rst b/exercises/tcp-2.rst index 2392e2c..739ca3d 100644 --- a/exercises/tcp-2.rst +++ b/exercises/tcp-2.rst @@ -869,7 +869,7 @@ Unless otherwise noted, we assume for the questions in this section that the fol .. rubric:: Footnotes -.. spelling:: +.. spelling:word-list:: manpage @@ -877,7 +877,7 @@ Unless otherwise noted, we assume for the questions in this section that the fol -.. spelling:: +.. spelling:word-list:: virtualbox diff --git a/exercises/trace.rst b/exercises/trace.rst index ba435f9..9715146 100644 --- a/exercises/trace.rst +++ b/exercises/trace.rst @@ -27,7 +27,7 @@ As an illustration, let us use tcpdump_ to analyze the packets exchanged while e The ``-6`` parameter passed to curl_ forces the utilization of IPv6. curl_ returns an HTML page that indicates that https must be used instead of http to access this web site. -.. spelling:: +.. spelling:word-list:: lookups @@ -87,7 +87,7 @@ wireshark_ is more recent than tcpdump_. It evolved from the ethereal packet tra Wireshark : default window -.. spelling:: +.. spelling:word-list:: wireshark diff --git a/pkt/80211-cts.pdf b/pkt/80211-cts.pdf index 0ac63d5..6fc217f 100644 Binary files a/pkt/80211-cts.pdf and b/pkt/80211-cts.pdf differ diff --git a/pkt/80211-cts.png b/pkt/80211-cts.png index 0f6f814..dfec242 100644 Binary files a/pkt/80211-cts.png and b/pkt/80211-cts.png differ diff --git a/pkt/80211-rts.pdf b/pkt/80211-rts.pdf index 61ae969..c4883f2 100644 Binary files a/pkt/80211-rts.pdf and b/pkt/80211-rts.pdf differ diff --git a/pkt/80211-rts.png b/pkt/80211-rts.png index e6b3317..71b1714 100644 Binary files a/pkt/80211-rts.png and b/pkt/80211-rts.png differ diff --git a/pkt/80211.pdf b/pkt/80211.pdf index a764d64..6971693 100644 Binary files a/pkt/80211.pdf and b/pkt/80211.pdf differ diff --git a/pkt/80211.png b/pkt/80211.png index 0b97685..6563eaa 100644 Binary files a/pkt/80211.png and b/pkt/80211.png differ diff --git a/pkt/8021q.pdf b/pkt/8021q.pdf index 38838ed..8989281 100644 Binary files a/pkt/8021q.pdf and b/pkt/8021q.pdf differ diff --git a/pkt/8021q.png b/pkt/8021q.png index 043d3dc..a9e2e02 100644 Binary files a/pkt/8021q.png and b/pkt/8021q.png differ diff --git a/pkt/8025.pdf b/pkt/8025.pdf index 8203e93..0b56238 100644 Binary files a/pkt/8025.pdf and b/pkt/8025.pdf differ diff --git a/pkt/8025.png b/pkt/8025.png index 35a1c0a..e986f3c 100644 Binary files a/pkt/8025.png and b/pkt/8025.png differ diff --git a/pkt/bnf.pdf b/pkt/bnf.pdf index 3098a42..785161e 100644 Binary files a/pkt/bnf.pdf and b/pkt/bnf.pdf differ diff --git a/pkt/bnf.png b/pkt/bnf.png index 8ff7ea1..2016ba8 100644 Binary files a/pkt/bnf.png and b/pkt/bnf.png differ diff --git a/pkt/dns-bnf.pdf b/pkt/dns-bnf.pdf index d50b0da..78b91eb 100644 Binary files a/pkt/dns-bnf.pdf and b/pkt/dns-bnf.pdf differ diff --git a/pkt/dns-bnf.png b/pkt/dns-bnf.png index c788268..b673fe3 100644 Binary files a/pkt/dns-bnf.png and b/pkt/dns-bnf.png differ diff --git a/pkt/dns6-www-ietf-org.pdf b/pkt/dns6-www-ietf-org.pdf index 6f951e7..6a72b8b 100644 Binary files a/pkt/dns6-www-ietf-org.pdf and b/pkt/dns6-www-ietf-org.pdf differ diff --git a/pkt/dns6-www-ietf-org.png b/pkt/dns6-www-ietf-org.png index 6fe2c34..bc4c6de 100644 Binary files a/pkt/dns6-www-ietf-org.png and b/pkt/dns6-www-ietf-org.png differ diff --git a/pkt/dnsheader.pdf b/pkt/dnsheader.pdf index ae4246b..4ea89af 100644 Binary files a/pkt/dnsheader.pdf and b/pkt/dnsheader.pdf differ diff --git a/pkt/dnsheader.png b/pkt/dnsheader.png index aec6799..cac4060 100644 Binary files a/pkt/dnsheader.png and b/pkt/dnsheader.png differ diff --git a/pkt/dnsrr.pdf b/pkt/dnsrr.pdf index 7ff28ae..5d7a386 100644 Binary files a/pkt/dnsrr.pdf and b/pkt/dnsrr.pdf differ diff --git a/pkt/dnsrr.png b/pkt/dnsrr.png index 54b1e43..158704c 100644 Binary files a/pkt/dnsrr.png and b/pkt/dnsrr.png differ diff --git a/pkt/ethernet-8023.pdf b/pkt/ethernet-8023.pdf index 3a0e840..0f6745b 100644 Binary files a/pkt/ethernet-8023.pdf and b/pkt/ethernet-8023.pdf differ diff --git a/pkt/ethernet-8023.png b/pkt/ethernet-8023.png index 00be2a7..0ecab7c 100644 Binary files a/pkt/ethernet-8023.png and b/pkt/ethernet-8023.png differ diff --git a/pkt/ethernet-dix.pdf b/pkt/ethernet-dix.pdf index fddfe63..9860f09 100644 Binary files a/pkt/ethernet-dix.pdf and b/pkt/ethernet-dix.pdf differ diff --git a/pkt/ethernet-dix.png b/pkt/ethernet-dix.png index eb53100..564de32 100644 Binary files a/pkt/ethernet-dix.png and b/pkt/ethernet-dix.png differ diff --git a/pkt/http2-frame.pdf b/pkt/http2-frame.pdf index 35a56a1..fec6c39 100644 Binary files a/pkt/http2-frame.pdf and b/pkt/http2-frame.pdf differ diff --git a/pkt/http2-frame.png b/pkt/http2-frame.png index 3e637ad..74d7eb3 100644 Binary files a/pkt/http2-frame.png and b/pkt/http2-frame.png differ diff --git a/pkt/icmpv6.pdf b/pkt/icmpv6.pdf index 2e524ea..314dc92 100644 Binary files a/pkt/icmpv6.pdf and b/pkt/icmpv6.pdf differ diff --git a/pkt/icmpv6.png b/pkt/icmpv6.png index a8712f4..7eee012 100644 Binary files a/pkt/icmpv6.png and b/pkt/icmpv6.png differ diff --git a/pkt/ip-80211.pdf b/pkt/ip-80211.pdf index 0cdaa15..c62a57f 100644 Binary files a/pkt/ip-80211.pdf and b/pkt/ip-80211.pdf differ diff --git a/pkt/ip-80211.png b/pkt/ip-80211.png index c29861b..39795a2 100644 Binary files a/pkt/ip-80211.png and b/pkt/ip-80211.png differ diff --git a/pkt/ipv6-fragment.pdf b/pkt/ipv6-fragment.pdf index c47609e..3d40481 100644 Binary files a/pkt/ipv6-fragment.pdf and b/pkt/ipv6-fragment.pdf differ diff --git a/pkt/ipv6-fragment.png b/pkt/ipv6-fragment.png index 1a72c1e..565ad01 100644 Binary files a/pkt/ipv6-fragment.png and b/pkt/ipv6-fragment.png differ diff --git a/pkt/ipv6-hbh.pdf b/pkt/ipv6-hbh.pdf index 73fbf65..b4c5207 100644 Binary files a/pkt/ipv6-hbh.pdf and b/pkt/ipv6-hbh.pdf differ diff --git a/pkt/ipv6-hbh.png b/pkt/ipv6-hbh.png index aa5fc42..da60ef9 100644 Binary files a/pkt/ipv6-hbh.png and b/pkt/ipv6-hbh.png differ diff --git a/pkt/ipv6-routing-0.pdf b/pkt/ipv6-routing-0.pdf index d41fdab..389936d 100644 Binary files a/pkt/ipv6-routing-0.pdf and b/pkt/ipv6-routing-0.pdf differ diff --git a/pkt/ipv6-routing-0.png b/pkt/ipv6-routing-0.png index 5f1cccc..4ace9a0 100644 Binary files a/pkt/ipv6-routing-0.png and b/pkt/ipv6-routing-0.png differ diff --git a/pkt/ipv6-sctp.pdf b/pkt/ipv6-sctp.pdf index 6060c9b..d69613a 100644 Binary files a/pkt/ipv6-sctp.pdf and b/pkt/ipv6-sctp.pdf differ diff --git a/pkt/ipv6-sctp.png b/pkt/ipv6-sctp.png index 16f19e8..1e9ef86 100644 Binary files a/pkt/ipv6-sctp.png and b/pkt/ipv6-sctp.png differ diff --git a/pkt/ipv6-tcp.pdf b/pkt/ipv6-tcp.pdf index d4329d1..ad66d18 100644 Binary files a/pkt/ipv6-tcp.pdf and b/pkt/ipv6-tcp.pdf differ diff --git a/pkt/ipv6-tcp.png b/pkt/ipv6-tcp.png index 5d992d1..7807155 100644 Binary files a/pkt/ipv6-tcp.png and b/pkt/ipv6-tcp.png differ diff --git a/pkt/ipv6.pdf b/pkt/ipv6.pdf index 6881cdc..258f298 100644 Binary files a/pkt/ipv6.pdf and b/pkt/ipv6.pdf differ diff --git a/pkt/ipv6.png b/pkt/ipv6.png index 9e89323..ba45137 100644 Binary files a/pkt/ipv6.png and b/pkt/ipv6.png differ diff --git a/pkt/macaddr-eui64.pdf b/pkt/macaddr-eui64.pdf index 97d3dd7..b98ac7c 100644 Binary files a/pkt/macaddr-eui64.pdf and b/pkt/macaddr-eui64.pdf differ diff --git a/pkt/macaddr-eui64.png b/pkt/macaddr-eui64.png index 60af425..17b1fe8 100644 Binary files a/pkt/macaddr-eui64.png and b/pkt/macaddr-eui64.png differ diff --git a/pkt/macaddr.pdf b/pkt/macaddr.pdf index 37b635c..256b656 100644 Binary files a/pkt/macaddr.pdf and b/pkt/macaddr.pdf differ diff --git a/pkt/macaddr.png b/pkt/macaddr.png index fd9af23..745176c 100644 Binary files a/pkt/macaddr.png and b/pkt/macaddr.png differ diff --git a/pkt/message.pdf b/pkt/message.pdf index 60d6df0..b0c78c2 100644 Binary files a/pkt/message.pdf and b/pkt/message.pdf differ diff --git a/pkt/message.png b/pkt/message.png index 3f88079..94d7fcc 100644 Binary files a/pkt/message.png and b/pkt/message.png differ diff --git a/pkt/ppp.pdf b/pkt/ppp.pdf index 56d1b4f..10aaa42 100644 Binary files a/pkt/ppp.pdf and b/pkt/ppp.pdf differ diff --git a/pkt/ppp.png b/pkt/ppp.png index 7df82c1..f6d6107 100644 Binary files a/pkt/ppp.png and b/pkt/ppp.png differ diff --git a/pkt/rip-route-entry-v6.pdf b/pkt/rip-route-entry-v6.pdf index d4e261a..619ec53 100644 Binary files a/pkt/rip-route-entry-v6.pdf and b/pkt/rip-route-entry-v6.pdf differ diff --git a/pkt/rip-route-entry-v6.png b/pkt/rip-route-entry-v6.png index dde64d7..08d040c 100644 Binary files a/pkt/rip-route-entry-v6.png and b/pkt/rip-route-entry-v6.png differ diff --git a/pkt/ripng.pdf b/pkt/ripng.pdf index faa87d8..0c45ef3 100644 Binary files a/pkt/ripng.pdf and b/pkt/ripng.pdf differ diff --git a/pkt/ripng.png b/pkt/ripng.png index e3a3f15..c5ffda4 100644 Binary files a/pkt/ripng.png and b/pkt/ripng.png differ diff --git a/pkt/router-adv.pdf b/pkt/router-adv.pdf index 6ebe967..56df58c 100644 Binary files a/pkt/router-adv.pdf and b/pkt/router-adv.pdf differ diff --git a/pkt/router-adv.png b/pkt/router-adv.png index a7f276d..043b472 100644 Binary files a/pkt/router-adv.png and b/pkt/router-adv.png differ diff --git a/pkt/router-prefix.pdf b/pkt/router-prefix.pdf index 7e028b5..4ff2fe0 100644 Binary files a/pkt/router-prefix.pdf and b/pkt/router-prefix.pdf differ diff --git a/pkt/router-prefix.png b/pkt/router-prefix.png index 080bef1..7869b5b 100644 Binary files a/pkt/router-prefix.png and b/pkt/router-prefix.png differ diff --git a/pkt/smtp-bnf.pdf b/pkt/smtp-bnf.pdf index 1972c59..ce3125a 100644 Binary files a/pkt/smtp-bnf.pdf and b/pkt/smtp-bnf.pdf differ diff --git a/pkt/smtp-bnf.png b/pkt/smtp-bnf.png index 016d817..de43489 100644 Binary files a/pkt/smtp-bnf.png and b/pkt/smtp-bnf.png differ diff --git a/pkt/smtp-response.pdf b/pkt/smtp-response.pdf index cb57cab..bb621f3 100644 Binary files a/pkt/smtp-response.pdf and b/pkt/smtp-response.pdf differ diff --git a/pkt/smtp-response.png b/pkt/smtp-response.png index 261bead..0267fc4 100644 Binary files a/pkt/smtp-response.png and b/pkt/smtp-response.png differ diff --git a/pkt/tcp-enc.pdf b/pkt/tcp-enc.pdf index e6dd6c7..0c0c2ee 100644 Binary files a/pkt/tcp-enc.pdf and b/pkt/tcp-enc.pdf differ diff --git a/pkt/tcp-enc.png b/pkt/tcp-enc.png index 10ac2f3..a3264d8 100644 Binary files a/pkt/tcp-enc.png and b/pkt/tcp-enc.png differ diff --git a/pkt/tcp.pdf b/pkt/tcp.pdf index 7ea984c..c5c64f1 100644 Binary files a/pkt/tcp.pdf and b/pkt/tcp.pdf differ diff --git a/pkt/tcp.png b/pkt/tcp.png index 17a7806..67ce09b 100644 Binary files a/pkt/tcp.png and b/pkt/tcp.png differ diff --git a/pkt/token-ring.pdf b/pkt/token-ring.pdf index 8710803..9c7fad7 100644 Binary files a/pkt/token-ring.pdf and b/pkt/token-ring.pdf differ diff --git a/pkt/token-ring.png b/pkt/token-ring.png index 89ebeeb..82b0b96 100644 Binary files a/pkt/token-ring.png and b/pkt/token-ring.png differ diff --git a/pkt/udp.pdf b/pkt/udp.pdf index b513e44..73ddfb4 100644 Binary files a/pkt/udp.pdf and b/pkt/udp.pdf differ diff --git a/pkt/udp.png b/pkt/udp.png index e6befaa..efcd95b 100644 Binary files a/pkt/udp.png and b/pkt/udp.png differ diff --git a/pkt/xdr-array.pdf b/pkt/xdr-array.pdf index 86e3f1d..7c487b5 100644 Binary files a/pkt/xdr-array.pdf and b/pkt/xdr-array.pdf differ diff --git a/pkt/xdr-array.png b/pkt/xdr-array.png index 2c45f19..c9c7ef2 100644 Binary files a/pkt/xdr-array.png and b/pkt/xdr-array.png differ diff --git a/pkt/xdr-double.pdf b/pkt/xdr-double.pdf index 0b4f197..0ba99eb 100644 Binary files a/pkt/xdr-double.pdf and b/pkt/xdr-double.pdf differ diff --git a/pkt/xdr-double.png b/pkt/xdr-double.png index 0d55b3f..6e191d3 100644 Binary files a/pkt/xdr-double.png and b/pkt/xdr-double.png differ diff --git a/pkt/xdr-integer-64.pdf b/pkt/xdr-integer-64.pdf index 55107eb..5fef530 100644 Binary files a/pkt/xdr-integer-64.pdf and b/pkt/xdr-integer-64.pdf differ diff --git a/pkt/xdr-integer-64.png b/pkt/xdr-integer-64.png index c71b5b7..5ee9da9 100644 Binary files a/pkt/xdr-integer-64.png and b/pkt/xdr-integer-64.png differ diff --git a/pkt/xdr-integer.pdf b/pkt/xdr-integer.pdf index d7bdc08..63fc7af 100644 Binary files a/pkt/xdr-integer.pdf and b/pkt/xdr-integer.pdf differ diff --git a/pkt/xdr-integer.png b/pkt/xdr-integer.png index eeec9ba..8735d48 100644 Binary files a/pkt/xdr-integer.png and b/pkt/xdr-integer.png differ diff --git a/pkt/xdr-string.pdf b/pkt/xdr-string.pdf index 0d1640f..889b2c4 100644 Binary files a/pkt/xdr-string.pdf and b/pkt/xdr-string.pdf differ diff --git a/pkt/xdr-string.png b/pkt/xdr-string.png index 8e4537d..d0f7070 100644 Binary files a/pkt/xdr-string.png and b/pkt/xdr-string.png differ diff --git a/principles/naming.rst b/principles/naming.rst index 717a559..9d40175 100644 --- a/principles/naming.rst +++ b/principles/naming.rst @@ -153,7 +153,7 @@ Names provide a lot of flexibility compared to addresses. For the network, they .. [#frootv6] Until February 2008, the root DNS servers only had IPv4 addresses. IPv6 addresses were slowly added to the root DNS servers to avoid creating problems as discussed in http://www.icann.org/en/committees/security/sac018.pdf As of February 2021, there remain a few DNS root servers that are still not reachable using IPv6. The full list is available at http://www.root-servers.org/ -.. spelling:: +.. spelling:word-list:: subdomains diff --git a/principles/network.rst b/principles/network.rst index c2d31d5..75a0a57 100644 --- a/principles/network.rst +++ b/principles/network.rst @@ -610,7 +610,7 @@ In this section, we discuss the main techniques that can be used to maintain the .. include:: /principles/linkstate.rst -.. spelling:: +.. spelling:word-list:: broadcasted pre diff --git a/principles/reliability.rst b/principles/reliability.rst index 4bbc158..b75e0d0 100644 --- a/principles/reliability.rst +++ b/principles/reliability.rst @@ -498,7 +498,7 @@ Some headers also include a `length` field, which indicates the total length of The simplest error detection scheme is the checksum. A checksum is basically an arithmetic sum of all the bytes that a frame is composed of. There are different types of checksums. For example, an eight bit checksum can be computed as the arithmetic sum of all the bytes of (both the header and trailer of) the frame. The checksum is computed by the sender before sending the frame and the receiver verifies the checksum upon frame reception. The receiver discards frames received with an invalid checksum. Checksums can be easily implemented in software, but their error detection capabilities are limited. Cyclical Redundancy Checks (CRC) have better error detection capabilities [SGP98]_, but require more CPU when implemented in software. -.. spelling:: +.. spelling:word-list:: png @@ -835,7 +835,7 @@ In practice, as the frame header includes an `n` bits field to encode the sequen :align: center :scale: 60 - Utilisation of the sliding window with modulo arithmetic + Utilization of the sliding window with modulo arithmetic .. index:: go-back-n @@ -1056,7 +1056,7 @@ Reliable protocols often need to send data in both directions. To reduce the ove .. .. [#fmsl] As we will see in the next chapter, the Internet does not strictly enforce this MSL. However, it is reasonable to expect that most packets on the Internet will not remain in the network during more than 2 minutes. There are a few exceptions to this rule, such as :rfc:`1149` whose implementation is described in http://www.blug.linux.no/rfc1149/ but there are few real links supporting :rfc:`1149` in the Internet. -.. spelling:: +.. spelling:word-list:: multi Multi diff --git a/principles/security.rst b/principles/security.rst index c129088..65c5cc5 100644 --- a/principles/security.rst +++ b/principles/security.rst @@ -123,7 +123,7 @@ As will be described later, the best approach to prevent this type of attack is to rely on cryptographic techniques to ensure that passwords are never sent in clear. -.. spelling:: +.. spelling:word-list:: Snowden @@ -270,7 +270,7 @@ a French cryptographer who first documented it : `A cryptographic algorithm should be secure even if the attacker knows everything about the system, except one parameter known as the secret key.` -.. spelling:: +.. spelling:word-list:: Auguste Kerckhoff @@ -280,7 +280,7 @@ This principle is important because it remains the basic assumption of all cryptographers. Any system that relies on the secrecy of its algorithm to be considered secure is doomed to fail and be broken one day. -.. spelling:: +.. spelling:word-list:: Vernam @@ -345,7 +345,7 @@ deployed. The most popular ones are : the correct one. -.. spelling:: +.. spelling:word-list:: Daemen Rijmen @@ -384,7 +384,7 @@ Alice (resp. Bob) uses the keys :math:`A_{priv}` and :math:`A_{pub}` (resp. Bob computes :math:`CM=E_p(A_{pub},M)` and Alice can decrypt it by using :math:`D_p(A_{priv},CM)=D_p(A_{priv},E_p(A_{pub},M))=M`. -.. spelling:: +.. spelling:word-list:: Rivest Shamir @@ -426,7 +426,7 @@ suffer from the same problem. .. wikipedia illustration is nice https://en.wikipedia.org/wiki/MD5 -.. spelling:: +.. spelling:word-list:: summarization @@ -563,7 +563,7 @@ millions of passwords. .. index:: hash chain -.. spelling:: +.. spelling:word-list:: Lamport @@ -912,7 +912,7 @@ will be used by the secret key encryption scheme. Key exchange ^^^^^^^^^^^^ -.. spelling:: +.. spelling:word-list:: Diffie Hellman diff --git a/principles/sharing.rst b/principles/sharing.rst index c9cd837..77cec22 100644 --- a/principles/sharing.rst +++ b/principles/sharing.rst @@ -346,7 +346,7 @@ Based on the feedback received from the network, the hosts can adjust their tran Another way to share the network resources is to distribute the load across multiple links. Many techniques have been designed to spread the load over the network. As an illustration, let us briefly consider how the load can be shared when accessing some content. Consider a large and popular file such as the image of a Linux distribution or the upgrade of a commercial operating system that will be downloaded by many users. There are many ways to distribute this large file. A naive solution is to place one copy of the file on a server and allow all users to download this file from the server. If the file is popular and millions of users want to download it, the server will quickly become overloaded. There are two classes of solutions that can be used to serve a large number of users. A first approach is to store the file on servers whose name is known by the clients. Before retrieving the file, each client will query the name service to obtain the address of the server. If the file is available from many servers, the name service can provide different addresses to different clients. This will automatically spread the load since different clients will download the file from different servers. Most large content providers use such a solution to distribute large files or videos. -.. spelling:: +.. spelling:word-list:: bittorrent metadata diff --git a/principles/transport.rst b/principles/transport.rst index 5bb179b..1b39ed5 100644 --- a/principles/transport.rst +++ b/principles/transport.rst @@ -46,7 +46,7 @@ An `application-level protocol` is similar to a structured conversation between - Alice : `Thank you` - Bob : `You're welcome` -.. spelling:: +.. spelling:word-list:: Tchang diff --git a/protocols/bgp.rst b/protocols/bgp.rst index ae4f578..dd8e048 100644 --- a/protocols/bgp.rst +++ b/protocols/bgp.rst @@ -26,7 +26,7 @@ Domains need to be interconnected to allow a host inside a domain to exchange IP Interconnection of two domains via a private peering link -.. spelling:: +.. spelling:word-list:: eXchange @@ -151,7 +151,7 @@ From a conceptual point of view, a BGP router connected to `N` BGP peers, can be Organization of a BGP router -.. spelling:: +.. spelling:word-list:: dataplane @@ -247,7 +247,7 @@ When a BGP message is received, the router first applies the peer's `import filt return bgpMsg -.. spelling:: +.. spelling:word-list:: bogon bogons @@ -453,7 +453,7 @@ Based on these studies and [ATLAS2009]_, the AS-level Internet topology can be s The domains on the Internet can be divided in about four categories according to their role and their position in the AS-level topology. -.. spelling:: +.. spelling:word-list:: Proximus diff --git a/protocols/congestion.rst b/protocols/congestion.rst index 613237f..c8de65b 100644 --- a/protocols/congestion.rst +++ b/protocols/congestion.rst @@ -8,15 +8,13 @@ Congestion control ------------------ -In an internetwork, i.e. a networking composed of different types of networks (such as the Internet), congestion control could be implemented either in the network layer or the transport layer. The congestion problem was clearly identified in the later 1980s and the researchers who developed techniques to solve the problem opted for a solution in the transport layer. Adding congestion control to the transport layer makes sense since this layer provides a reliable data transfer and avoiding congestion is a factor in this reliable delivery. The transport layer already deals with heterogeneous networks thanks to its `self-clocking` property that we have already described. In this section, we explain how congestion control has been added to TCP and how this mechanism could be improved in the future. +In an internetwork, i.e. a network composed of different types of networks (such as the Internet), congestion control could be implemented either in the network layer or the transport layer. The congestion problem was clearly identified in the late 1980s and the Internet researchers who developed techniques to solve the problem opted for a solution in the transport layer. Adding congestion control to the transport layer makes sense since this layer provides a reliable data transfer and avoiding congestion is a factor in this reliable delivery. The transport layer already deals with heterogeneous networks thanks to its `self-clocking` property that we have already described. In this section, we explain different congestion control techniques that have been added to TCP and other transport protocols such as SCTP or QUIC. -.. (and SCTP whose congestion control scheme is very close to TCP's congestion control) +The TCP congestion control scheme was initially proposed by `Van Jacobson`_ in [Jacobson1988]_. The current specification may be found in :rfc:`5681`. TCP relies on `Additive Increase and Multiplicative Decrease (AIMD)`. To implement :term:`AIMD`, a TCP host must be able to control its transmission rate. A first approach would be to use timers and adjust their expiration times in function of the rate imposed by :term:`AIMD`. Unfortunately, maintaining such timers for a large number of TCP connections can be difficult. Instead, `Van Jacobson`_ noted that the sending rate of a TCP connection can be artificially controlled by constraining its sending window. A TCP connection cannot send data faster than :math:`\frac{window}{rtt}` where :math:`window` is the minimum between the host's sending window and the receive window advertised by the receiver. -The TCP congestion control scheme was initially proposed by `Van Jacobson`_ in [Jacobson1988]_. The current specification may be found in :rfc:`5681`. TCP relies on `Additive Increase and Multiplicative Decrease (AIMD)`. To implement :term:`AIMD`, a TCP host must be able to control its transmission rate. A first approach would be to use timers and adjust their expiration times in function of the rate imposed by :term:`AIMD`. Unfortunately, maintaining such timers for a large number of TCP connections can be difficult. Instead, `Van Jacobson`_ noted that the rate of TCP congestion can be artificially controlled by constraining its sending window. A TCP connection cannot send data faster than :math:`\frac{window}{rtt}` where :math:`window` is the minimum between the host's sending window and the window advertised by the receiver. +TCP's congestion control scheme is based on a `congestion window`. The current value of the congestion window (`cwnd`) is stored in the TCB of each TCP connection and the window that can be used by the sender is constrained by :math:`\min(cwnd,rwin,swin)` where :math:`swin` is the current sending window and :math:`rwin` the last received receive window. The `Additive Increase` part of the TCP congestion control increments the congestion window by :term:`MSS` bytes every round-trip-time. In the TCP literature, this phase is often called the `congestion avoidance` phase. The `Multiplicative Decrease` part of the TCP congestion control halves the current value of the congestion window once congestion has been detected. -TCP's congestion control scheme is based on a `congestion window`. The current value of the congestion window (`cwnd`) is stored in the TCB of each TCP connection and the window that can be used by the sender is constrained by :math:`\min(cwnd,rwin,swin)` where :math:`swin` is the current sending window and :math:`rwin` the last received receive window. The `Additive Increase` part of the TCP congestion control increments the congestion window by :term:`MSS` bytes every round-trip-time. In the TCP literature, this phase is often called the `congestion avoidance` phase. The `Multiplicative Decrease` part of the TCP congestion control divides the current value of the congestion window once congestion has been detected. - -When a TCP connection begins, the sending host does not know whether the part of the network that it uses to reach the destination is congested or not. To avoid causing too much congestion, it must start with a small congestion window. [Jacobson1988]_ recommends an initial window of MSS bytes. As the additive increase part of the TCP congestion control scheme increments the congestion window by MSS bytes every round-trip-time, the TCP connection may have to wait many round-trip-times before being able to efficiently use the available bandwidth. This is especially important in environments where the :math:`bandwidth \times rtt` product is high. To avoid waiting too many round-trip-times before reaching a congestion window that is large enough to efficiently utilize the network, the TCP congestion control scheme includes the `slow-start` algorithm. The objective of the TCP `slow-start` phase is to quickly reach an acceptable value for the `cwnd`. During `slow-start`, the congestion window is doubled every round-trip-time. The `slow-start` algorithm uses an additional variable in the TCB : `ssthresh` (`slow-start threshold`). The `ssthresh` is an estimation of the last value of the `cwnd` that did not cause congestion. It is initialized at the sending window and is updated after each congestion event. +When a TCP connection begins, the sending host does not know whether the part of the network that it uses to reach the destination is congested or not. To avoid causing too much congestion, it must start with a small congestion window. In 1998, [Jacobson1988]_ recommended an initial window of MSS bytes. As the additive increase part of the TCP congestion control scheme increments the congestion window by MSS bytes every round-trip-time, the TCP connection may have to wait many round-trip-times before being able to efficiently use the available bandwidth. This is especially important in environments where the :math:`bandwidth \times rtt` product is high. To avoid waiting too many round-trip-times before reaching a congestion window that is large enough to efficiently utilize the network, the TCP congestion control scheme includes the `slow-start` algorithm. The objective of the TCP `slow-start` phase is to quickly reach an acceptable value for the `cwnd`. During `slow-start`, the congestion window is doubled every round-trip-time. The `slow-start` algorithm uses an additional variable in the TCB : `ssthresh` (`slow-start threshold`). The `ssthresh` is an estimation of the last value of the `cwnd` that did not cause congestion. It is initialized at the sending window and is updated after each congestion event. A key question that must be answered by any congestion control scheme is how congestion is detected. The first implementations of the TCP congestion control scheme opted for a simple and pragmatic approach : packet losses indicate congestion. If the network is congested, router buffers are full and packets are discarded. In wired networks, packet losses are mainly caused by congestion. In wireless networks, packets can be lost due to transmission errors and for other reasons that are independent of congestion. TCP already detects segment losses to ensure a reliable delivery. The TCP congestion control scheme distinguishes between two types of congestion : @@ -27,26 +25,43 @@ A key question that must be answered by any congestion control scheme is how con The figure below illustrates the evolution of the congestion window when there is severe congestion. At the beginning of the connection, the sender performs `slow-start` until the first segments are lost and the retransmission timer expires. At this time, the `ssthresh` is set to half of the current congestion window and the congestion window is reset at one segment. The lost segments are retransmitted as the sender again performs slow-start until the congestion window reaches the `sshtresh`. It then switches to congestion avoidance and the congestion window increases linearly until segments are lost and the retransmission timer expires. -.. figure:: /protocols/figures/tcp-congestion-severe.* - :align: center - :scale: 70 - - Evaluation of the TCP congestion window with severe congestion +.. tikz:: Evaluation of the TCP congestion window with severe congestion + :libs: calc, math, arrows + \draw[->] (-0.2,0) -- (12,0) node[below] {$t$}; + \draw[->] (0,-1.2) -- (0,3) node[above] {$cwnd$}; + \draw[color=red,domain=0:4,variable=\x] plot (\x,{0.1*(1+2^(\x))}) node[left] {slow start}; + \draw[-,dashed] (4,1) -- (4,3) node [above] {timer}; + \draw[-,dashed,color=red] (4,0.8) -- (8,0.8) node[below] {threshold}; + \draw[color=red,domain=4:7,variable=\x] plot (\x,{0.1*(1+2^(\x-4))}) ; + \draw[color=blue,domain=7:10] plot (\x,{0.1*(1+8+(\x-7))}) node[above] {congestion avoidance}; + \draw[-,dashed] (10,0.5) -- (10,2.5) node [above] {timer}; + \draw[-,dashed,color=red] (9,0.65) -- (12,0.65) node[above] {threshold}; \draw[color=red,domain=10:12,variable=\x] plot (\x,{0.1*(1+2^(\x-10))}) ; + The figure below illustrates the evolution of the congestion window when the network is lightly congested and all lost segments can be retransmitted using fast retransmit. The sender begins with a slow-start. A segment is lost but successfully retransmitted by a fast retransmit. The congestion window is divided by 2 and the sender immediately enters congestion avoidance as this was a mild congestion. -.. figure:: /protocols/figures/tcp-congestion-mild.* - :align: center - :scale: 70 - Evaluation of the TCP congestion window when the network is lightly congested +.. tikz:: Evaluation of the TCP congestion window when the network is lightly congested + + \draw[->] (-0.2,0) -- (12,0) node[below] {$t$}; + \draw[->] (0,-1.2) -- (0,3) node[above] {$cwnd$}; + \draw[color=red,domain=0:4,variable=\x] plot (\x,{0.1*(1+2^(\x))}) node[left] {slow start}; + \draw[->,dashed] (4,3.5) -- (4,2.5) node [below] {fast retransmit}; + \draw[-,dashed,color=red] (4,0.8) -- (7,0.8) node[below] {threshold}; + \draw[color=blue,domain=4:9] plot (\x,{0.8+0.1*(0.7+(\x-4))}) node[above] {congestion avoidance}; + \draw[->,dashed] (9,3.5) -- (9,2.5) node [below] {fast retransmit}; + \draw[-,dashed,color=red] (8,0.46) -- (11,0.46) node[below] {threshold}; + \draw[color=blue,domain=9:12] plot (\x,{0.46+0.1*(0.7+(\x-9))}) node[right] {congestion avoidance}; + Most TCP implementations update the congestion window when they receive an acknowledgment. If we assume that the receiver acknowledges each received segment and the sender only sends MSS sized segments, the TCP congestion control scheme can be implemented using the simplified pseudo-code [#fwrap]_ below. This pseudocode includes the optimization proposed in :rfc:`3042` that allows a sender to send new unsent data upon reception of the first or second duplicate acknowledgment. The reception of each of these acknowledgments indicates that one segment has left the network and thus additional data can be sent without causing more congestion. Note that the congestion window is *not* increased upon reception of these first duplicate acknowledgments. .. code-block:: python + # NewReno congestion control in TCP + # Initialization cwnd = MSS # congestion window in bytes ssthresh= swin # in bytes @@ -86,12 +101,11 @@ Most TCP implementations update the congestion window when they receive an ackno cwnd = MSS -Furthermore when a TCP connection has been idle for more than its current retransmission timer, it should reset its congestion window to the congestion window size that it uses when the connection begins, as it no longer knows the current congestion state of the network. +Furthermore when a TCP connection has been idle for more than its current retransmission timer, it should reset its congestion window to the congestion window size that it uses when the connection begins, as it no longer knows the current congestion state of the network. This congestion control scheme is known as the :index:`NewReno` congestion control scheme. .. note:: Initial congestion window - The original TCP congestion control mechanism proposed in [Jacobson1988]_ recommended that each TCP connection should begin by setting :math:`cwnd=MSS`. However, in today's higher bandwidth networks, using such a small initial congestion window severely affects the performance for short TCP connections, such as those used by web servers. In 2002, :rfc:`3390` allowed an initial congestion window of about 4 KBytes, which corresponds to 3 segments in many environments. Recently, researchers from Google proposed to further increase the initial window up to 15 KBytes [DRC+2010]_. The measurements that they collected show that this increase would not significantly increase congestion but would significantly reduce the latency of short HTTP responses. Unsurprisingly, the chosen initial window corresponds to the average size of an HTTP response from a search engine. This proposed modification has been adopted in :rfc:`6928` and TCP implementations support it. - + The original TCP congestion control mechanism [Jacobson1988]_ recommended that each TCP connection should begin by setting :math:`cwnd=MSS`. However, in today's higher bandwidth networks, using such a small initial congestion window severely affects the performance for short TCP connections, such as those used by web servers. In 2002, :rfc:`3390` allowed an initial congestion window of about 4 KBytes, which corresponds to 3 segments in many environments. In 2010, researchers from Google proposed to further increase the initial window up to 15 KBytes [DRC+2010]_. The measurements that they collected show that this increase would not significantly increase congestion but would significantly reduce the latency of short HTTP responses. Unsurprisingly, the chosen initial window corresponds to the average size of an HTTP response from a search engine. This proposed modification has been adopted in :rfc:`6928` and TCP implementations support it. Controlling congestion without losing data @@ -99,15 +113,15 @@ Controlling congestion without losing data In today's Internet, congestion is controlled by regularly sending packets at a higher rate than the network capacity. These packets fill the buffers of the routers and are eventually discarded. But shortly after, TCP senders retransmit packets containing exactly the same data. This is potentially a waste of resources since these successive retransmissions consume resources upstream of the router that discards the packets. Packet losses are not the only signal to detect congestion inside the network. An alternative is to allow routers to explicitly indicate their current level of congestion when forwarding packets. This approach was proposed in the late 1980s [RJ1995]_ and used in some networks. Unfortunately, it took almost a decade before the Internet community agreed to consider this approach. In the mean time, a large number of TCP implementations and routers were deployed on the Internet. -.. spelling:: +.. spelling:word-list:: ECN -As explained earlier, Explicit Congestion Notification :rfc:`3168` improves the detection of congestion by allowing routers to explicitly mark packets when they are lightly congested. In theory, a single bit in the packet header [RJ1995]_ is sufficient to support this congestion control scheme. When a host receives a marked packet, it returns the congestion information to the source that adapts its transmission rate accordingly. Although the idea is relatively simple, deploying it on the entire Internet has proven to be challenging [KNT2013]_. It is interesting to analyze the different factors that have hindered the deployment of this technique. +Explicit Congestion Notification :rfc:`3168` improves the detection of congestion by allowing routers to explicitly mark packets when they are lightly congested. In theory, a single bit in the packet header [RJ1995]_ is sufficient to support this congestion control scheme. When a host receives a marked packet, it returns the congestion information to the source that adapts its transmission rate accordingly. Although the idea is relatively simple, deploying it on the entire Internet has proven to be challenging [KNT2013]_. It is interesting to analyze the different factors that have hindered the deployment of this technique. -The first difficulty in adding Explicit Congestion Notification (ECN) in TCP/IP network was to modify the format of the network packet and transport segment headers to carry the required information. In the network layer, one bit was required to allow the routers to mark the packets they forward during congestion periods. In the IP network layer, this bit is called the `Congestion Experienced` (`CE`) bit and is part of the packet header. However, using a single bit to mark packets is not sufficient. Consider a simple scenario with two sources, one congested router and one destination. Assume that the first sender and the destination support ECN, but not the second sender. If the router is congested it will mark packets from both senders. The first sender will react to the packet markings by reducing its transmission rate. However since the second sender does not support ECN, it will not react to the markings. Furthermore, this sender could continue to increase its transmission rate, which would lead to more packets being marked and the first source would decrease again its transmission rate, ... In the end, the sources that implement ECN are penalized compared to the sources that do not implement it. This unfairness issue is a major hurdle to widely deploy ECN on the public Internet [#fprivate]_. The solution proposed in :rfc:`3168` to deal with this problem is to use a second bit in the network packet header. This bit, called the `ECN-capable transport` (ECT) bit, indicates whether the packet contains a segment produced by a transport protocol that supports ECN or not. Transport protocols that support ECN set the ECT bit in all packets. When a router is congested, it first verifies whether the ECT bit is set. In this case, the CE bit of the packet is set to indicate congestion. Otherwise, the packet is discarded. This eases the deployment of ECN [#fecnnonce]_. +The first difficulty in adding Explicit Congestion Notification (ECN) in TCP/IP network was to modify the format of the network packet and transport segment headers to carry the required information. In the network layer, one bit was required to allow the routers to mark the packets they forward during congestion periods. In the IP network layer, this bit is called the `Congestion Experienced` (`CE`) bit and is part of the packet header. However, using a single bit to mark packets is not sufficient. Consider a simple scenario with two sources, one congested router and one destination. Assume that the first sender and the destination support ECN, but not the second sender. If the router is congested it will mark packets from both senders. The first sender will react to the packet markings by reducing its transmission rate. However since the second sender does not support ECN, it will not react to the markings. Furthermore, this sender could continue to increase its transmission rate, which would lead to more packets being marked and the first source would decrease again its transmission rate, ... In the end, the sources that implement ECN would be penalized compared to the sources that do not implement it. This unfairness is a major hurdle to widely deploy ECN on the public Internet [#fprivate]_. The solution proposed in :rfc:`3168` to deal with this problem is to use a second bit in the network packet header. This bit, called the `ECN-capable transport` (ECT) bit, indicates whether the packet contains a segment produced by a transport protocol that supports ECN or not. Transport protocols that support ECN set the ECT bit in all packets. When a router is congested, it first verifies whether the ECT bit is set. In this case, the CE bit of the packet is set to indicate congestion. Otherwise, the packet is discarded. This eases the deployment of ECN [#fecnnonce]_. -The second difficulty is how to allow the receiver to inform the sender of the reception of network packets marked with the `CE` bit. In reliable transport protocols like TCP and SCTP, the acknowledgments can be used to provide this feedback. For TCP, two options were possible : change some bits in the TCP segment header or define a new TCP option to carry this information. The designers of ECN opted for reusing spare bits in the TCP header. More precisely, two TCP flags have been added in the TCP header to support ECN. The `ECN-Echo` (ECE) is set in the acknowledgments when the `CE` was set in packets received on the forward path. +The second difficulty is how to allow the receiver to inform the sender of the reception of network packets marked with the `CE` bit. In reliable transport protocols like TCP and SCTP, the acknowledgments can be used to provide this feedback. For TCP, two options were possible : change some bits in the TCP segment header or define a new TCP option to carry this information. The designers of ECN opted for reusing spare bits in the TCP header. More precisely, two TCP flags have been added in the TCP header to support ECN. The `ECN-Echo` (ECE) is set in the TCP acknowledgments when the `CE` was set in packets received on the forward path. .. figure:: /pkt/tcp-enc.* :scale: 120 @@ -115,7 +129,7 @@ The second difficulty is how to allow the receiver to inform the sender of the r The TCP flags -The third difficulty is to allow an ECN-capable sender to detect whether the remote host also supports ECN. This is a classical negotiation of extensions to a transport protocol. In TCP, this could have been solved by defining a new TCP option used during the three-way handshake. To avoid wasting space in the TCP options, the designers of ECN opted in :rfc:`3168` for using the `ECN-Echo` and `CWR` bits in the TCP header to perform this negotiation. In the end, the result is the same with fewer bits exchanged. +The third difficulty is to allow an ECN-capable sender to detect whether the remote host also supports ECN. This is a classical negotiation of extensions to a transport protocol. In TCP, this could have been solved by defining a new TCP option used during the three-way handshake. To avoid wasting space in the TCP options, the designers of ECN opted in :rfc:`3168` for using the `ECN-Echo` and `CWR` bits in the TCP header to perform this negotiation. In the end, the result is the same with fewer bits exchanged and without wasting TCP option space. .. SCTP defines in [STD2013]_ the `ECN Support parameter` which can be included in the ``INIT`` and ``INIT-ACK`` chunks to negotiate the utilization of ECN. The solution adopted for SCTP is cleaner than the solution adopted for TCP. @@ -177,7 +191,7 @@ The last point that needs to be discussed about Explicit Congestion Notification - routers that have a single FIFO queue - routers that have several queues served by a round-robin scheduler -Routers that use a single queue measure their buffer occupancy as the number of bytes of packets stored in the queue [#fslot]_. A first method to detect congestion is to measure the instantaneous buffer occupancy and consider the router to be congested as soon as this occupancy is above a threshold. Typical values of the threshold could be 40% of the total buffer. Measuring the instantaneous buffer occupancy is simple since it only requires one counter. However, this value is fragile from a control viewpoint since it changes frequently. A better solution is to measure the *average* buffer occupancy and consider the router to be congested when this average occupancy is too high. Random Early Detection (RED) [FJ1993]_ is an algorithm that was designed to support Explicit Congestion Notification. In addition to measuring the average buffer occupancy, it also uses probabilistic marking. When the router is congested, the arriving packets are marked with a probability that increases with the average buffer occupancy. The main advantage of using probabilistic marking instead of marking all arriving packets is that flows will be marked in proportion of the number of packets that they transmit. If the router marks 10% of the arriving packets when congested, then a large flow that sends hundred packets per second will be marked 10 times while a flow that only sends one packet per second will not be marked. This probabilistic marking allows marking packets in proportion of their usage of the network resources. +Routers that use a single queue measure their buffer occupancy as the number of bytes or packets stored in the queue [#fslot]_. A first method to detect congestion is to measure the instantaneous buffer occupancy and consider the router to be congested as soon as this occupancy is above a threshold. Typical values of the threshold could be 40% of the total buffer. Measuring the instantaneous buffer occupancy is simple since it only requires one counter. However, this value is fragile from a control viewpoint since it changes frequently. A better solution is to measure the *average* buffer occupancy and consider the router to be congested when this average occupancy is too high. Random Early Detection (RED) [FJ1993]_ is an algorithm that was designed to support Explicit Congestion Notification. In addition to measuring the average buffer occupancy, it also uses probabilistic marking. When the router is congested, the arriving packets are marked with a probability that increases with the average buffer occupancy. The main advantage of using probabilistic marking instead of marking all arriving packets is that flows will be marked in proportion to the number of packets that they transmit. If the router marks 10% of the arriving packets when congested, then a large flow that sends hundred packets per second will be marked 10 times while a flow that only sends one packet per second will not be marked. This probabilistic marking allows marking packets in proportion of their usage of the network resources. If the router uses several queues served by a scheduler, the situation is different. If a large and a small flow are competing for bandwidth, the scheduler will already favor the small flow that is not using its fair share of the bandwidth. The queue for the small flow will be almost empty while the queue for the large flow will build up. On routers using such schedulers, a good way of marking the packets is to set a threshold on the occupancy of each queue and mark the packets that arrive in a particular queue as soon as its occupancy is above the configured threshold. @@ -185,10 +199,9 @@ If the router uses several queues served by a scheduler, the situation is differ Modeling TCP congestion control ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Thanks to the NewReno congestion control scheme, TCP can adapt its transmission rate to the losses that occur in the network. Intuitively, the TCP transmission rate decreases when the percentage of losses increases. Researchers have proposed detailed models that allow the prediction of the throughput of a TCP connection when losses occur [MSMO1997]_ . To have some intuition about the factors that affect the performance of TCP, let us consider a very simple model. Its assumptions are not completely realistic, but it gives a good intuition without requiring complex mathematics. -Thanks to its congestion control scheme, TCP adapts its transmission rate to the losses that occur in the network. Intuitively, the TCP transmission rate decreases when the percentage of losses increases. Researchers have proposed detailed models that allow the prediction of the throughput of a TCP connection when losses occur [MSMO1997]_ . To have some intuition about the factors that affect the performance of TCP, let us consider a very simple model. Its assumptions are not completely realistic, but it gives us good intuition without requiring complex mathematics. - -This model considers a hypothetical TCP connection that suffers from equally spaced segment losses. If :math:`p` is the segment loss ratio, then the TCP connection successfully transfers :math:`\frac{1}{p}-1` segments and the next segment is lost. If we ignore the slow-start at the beginning of the connection, TCP in this environment is always in congestion avoidance as there are only isolated losses that can be recovered by using fast retransmit. The evolution of the congestion window is thus as shown in the figure below. Note that the `x-axis` of this figure represents time measured in units of one round-trip-time, which is supposed to be constant in the model, and the `y-axis` represents the size of the congestion window measured in MSS-sized segments. +This model considers a hypothetical TCP connection that suffers from equally spaced segment losses. If :math:`p` is the segment loss ratio, then the TCP connection successfully transfers :math:`\frac{1}{p}-1` segments and the next segment is lost. If we ignore the slow-start at the beginning of the connection, TCP in this environment is always in congestion avoidance as there are only isolated losses that can be recovered using fast retransmit. The evolution of the congestion window is thus as shown in the figure below. Note that the `x-axis` of this figure represents time measured in units of one round-trip-time, which is supposed to be constant in the model, and the `y-axis` represents the size of the congestion window measured in MSS-sized segments. .. figure:: /protocols/figures/tcp-congestion-regular.* :align: center @@ -216,6 +229,17 @@ In general, the maximum throughput that can be achieved by a TCP connection depe :math:`Throughput<\min(\frac{window}{rtt},\frac{k \times MSS}{rtt \times \sqrt{p}})` +The CUBIC congestion control scheme +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. spelling:word-list:: + + rtt + +The NewReno congestion control scheme has been the dominant and the standard TCP congestion control scheme. It works well in networks having a small round-trip-time or a low bandwidth*delay product. In networks with a high bandwidth*delay product, a single packet loss can force a TCP sender to spend a lot of time in congestion avoidance. Since NewReno advances its congestion window by one MSS every round-trip-time, it can spend a long time in congestion avoidance before reaching a congestion window that is large enough to fully use the network. Furthermore, NewReno favors connections with a small round-trip-time compared to connections with a longer round-trip-time. + +Internet researchers have proposed a wide range of congestion control schemes. During the last decade, the CUBIC congestion control scheme has emerged has the standard congestion control scheme. It has been adopted by key TCP implementations and is defined in :rfc:`9438`. + .. note:: The TCP congestion control zoo The first TCP congestion control scheme was proposed by `Van Jacobson`_ in [Jacobson1988]_. In addition to writing the scientific paper, `Van Jacobson`_ also implemented the slow-start and congestion avoidance schemes in release 4.3 `Tahoe` of the BSD Unix distributed by the University of Berkeley. Later, he improved the congestion control by adding the fast retransmit and the fast recovery mechanisms in the `Reno` release of 4.3 BSD Unix. Since then, many researchers have proposed, simulated and implemented modifications to the TCP congestion control scheme. Some of these modifications are still used today, e.g. : @@ -225,10 +249,68 @@ In general, the maximum throughput that can be achieved by a TCP connection depe - `CUBIC`, which was designed for high bandwidth links and is the default congestion control scheme in Linux since the Linux 2.6.19 kernel [HRX2008]_. It is now used by several operating systems and is becoming the default congestion control scheme :rfc:`8312`. A key difference between CUBIC and the TCP congestion control scheme described in this chapter is that CUBIC is much more aggressive when probing the network. Instead of relying on additive increase after a fast recovery, a CUBIC sender adjusts its congestion by using a cubic function. Thanks to this function, the congestion windows grows faster. This is particularly important in high-bandwidth delay networks. - `BBR`, which is being developed by Google researchers and is included in recent Linux kernels [CCG+2016]_. BBR periodically estimates the available bandwidth and the round-trip-times. To adapt to changes in network conditions, BBR regularly tries to send at 1.25 times the current bandwidth. This enables BBR senders to probe the network, but can also cause large amount of losses. Recent scientific articles indicate that BBR is unfair to other congestion control schemes in specific conditions [WMSS2019]_. - A wide range of congestion control schemes have been proposed in the scientific literature and several of them have been widely deployed. A detailed comparison of these congestion control schemes is outside the scope of this chapter. A recent survey paper describing many of the implemented TCP congestion control schemes may be found in [TKU2019]_. +The CUBIC congestion control scheme was designed with three [#fcubic]_ main principles in mind: + + 1. CUBIC increases its congestion window by using both the concave and convex parts of a cubic function + 2. CUBIC achieves linear bandwidth sharing among flows with different round-trip-times + 3. CUBIC sets is multiplicative window decrease factor in order to balance scalability and efficiency + + +CUBIC adjusts the congestion window based on the congestion observed on the path. For this, CUBIC uses a cubic function as illustrated below. Compared with the slow-start and congestion avoidance phases of NewReno, the cubic function has several benefits. After having experienced congestion, remembers the congestion window that caused congestion and reduces its congestion window to allow the router buffers to drain. After that, it needs to quickly increase its congestion window to be able to fully utilize the network. This is the role of the concave part of the cubic function. It quickly increases the congestion window until reaching the previous value of the congestion window. This is the plateau of the cubic function. The sender transmits at a rate that previously caused congestion. Thanks to the plateau of the cubic function, it does not change its transmission rate quickly. After having transmitted at this rate for several round-trip-times without congestion, the sender starts to increase its congestion window using the convex part of the cubic function. This increase is much faster than NewReno's congestion avoidance and allows CUBIC to quickly utilize the available bandwidth. This results in a much higher network utilization than using NewReno. + + +.. tikz:: The concave and convex parts of a cubic function + + \draw[color=red,domain=1:4,variable=\x] plot (\x,{0.1*(.4*(\x-5)^3)+1}) node[below] {concave}; + \draw[color=blue,domain=4:6,variable=\x] plot (\x,{0.1*(.4*(\x-5)^3)+1}) node[left] {}; + \draw[color=green,domain=6:9,variable=\x] plot (\x,{0.1*(.4*(\x-5)^3)+1}) node[left] {convex}; + + +The parameters of the cubic function can be adjusted to have a faster ramp-up or a longer plateau. This results in a compromise between stability and faster utilization of available network resources, but at the risk of causing more congestion. + +The cubic function allows to adjust the congestion window. It is used when an acknowledgment is received and depends on the delay since the previous congestion event. With CUBIC, two flows that share a single bottleneck will have similar congestion windows. Since their throughput will be :math:`\frac{cwnd}{rtt}`, the flows with a lower rtt will achieve a higher throughput. + +NewReno halves its congestion window at each congestion event. CUBIC also uses a multiplicative decrease when it detects congestion, but using a factor of :math:`0.7` instead of :math:`0.5`. This provides a better balance between scalability and convergence speed than NewReno. + +A CUBIC implementation uses the following function to increase its congestion window upon reception of an acknowledgment: :math:`W_{cubic}(t)= C \times (t-K)^3 + W_{max}`. In this function, :math:`t` is the delay between now and the time of the previous congestion event that marks the start of the current congestion avoidance period. :math:`K` is the time period required for the cubic function to increase the congestion window to reach :math:`W_{max}`. :math:`W_{max}` is the congestion window that caused the last congestion event. It corresponds to the plateau of the cubic function. CUBIC uses :math:`W_{cubic}(t)` to compute a target value of the congestion window after one RTT where RTT is the smoothed value of the measured round-trip-time. When a CUBIC sender receives an acknowledgment, it computes :math:`target=W_{cubic}(t+RTT)` and increments :math:`cwnd` by :math:`\frac{target-cwnd}{cwnd}`. + +If a CUBIC sender detects congestion, it remembers the current value of :math:`cwnd` as :math:`W_{max}` and sets :math:`ssthresh=cwnd \times 0.7` and sets :math:`cwnd=max(ssthresh,2)`. This is the multiplicative decrease part of CUBIC [#cubicdec]_. + +The CUBIC specification recommends values for the :math:`C` and :math:`K` parameters of the cubic function. :math:`C` should be set to 0.4 based on various studies and simulation results. :math:`K` is computed as :math:`K=\sqrt[3]{\frac{W_{max}-cwnd_{epoch}}{C}}` where :math:`cwnd_{epoch}` is the value of the congestion window at the beginning of the current congestion avoidance stage. + + +We can now observe the evolution of the congestion window with CUBIC. Let us start with an initial congestion window of 10 segments and assume that one of these segments was lost. CUBIC sets its :math:`cwnd` to :math:`0.7 \times 10 = 7` segments. Since :math:`W_{max}=10`, it computes :math:`K=\sqrt[3]{\frac{10-7}{0.4}}=1.96`. When the second congestion event occurs, it updates :math:`W_{max}`, recomputes :math:`K` and starts a new cubic curve. The curve allows it to quickly reach the plateau, but it stays there for several round-trip-times. As there is no congestion during this plateau, it moves to the convex part of the curve and quickly increases the congestion window to efficiently utilize the available network resources. + + +.. tikz:: Observing the evolution of :math:`cwnd` on a CUBIC connection + + + \draw[->] (-0.2,0) -- (9,0) node[below] {$t$}; + \draw[->] (0,-0.2) -- (0,4) node[above] {$cwnd$}; + + \draw[color=red,domain=0:4] plot (\x,{0.2*(0.4*((\x-1.957)^3)+10)}) node[left] {}; + \draw[->,dashed] (4,0.2*20) -- (4,0.2*16) node [below] {fast retransmit}; + \draw[color=red,domain=4:9] plot (\x,{0.2*(0.4*(((\x-4)-2)^3)+10)}) ; + + + + +At this point, it is interesting to explore the evolution of the congestion window computed by a CUBIC sender and compare it with the congestion window that a NewReno sender would compute. For simplicity, we ignore the beginning of the connection and assume that both NewReno and CUBIC have reached a :math:`cwnd` of 10 MSS sized segments. At this time a congestion occurs. NewReno sets its :math:`cwnd` to 5 segments and starts congestion avoidance. CUBIC sets its :math:`cwnd` to 7 segments. Since :math:`W_{max}=10`, it computes :math:`K=\sqrt[3]{\frac{10-7}{0.4}}=1.96`. The congestion window of the CUBIC connection is slightly above the congestion window of the NewReno connection, but then it grows much faster when it enters the convex region. This enables CUBIC to utilize network resources much faster than NewReno. + + +.. tikz:: Comparing the evolution of the congestion window using CUBIC and NewReno + + \draw[->] (-0.2,0) -- (7,0) node[below] {$t$}; + \draw[->] (0,-0.2) -- (0,7) node[above] {$cwnd$}; + \draw[color=blue,domain=0:6] plot (\x,{0.2*(5+\x)}) node[above] {NewReno}; + \draw[color=red,domain=0:6] plot (\x,{0.2*(0.4*((\x-1.957)^3)+10)}) node[above] {CUBIC}; + + +Mathematical models of the CUBIC congestion control scheme have also been developed. :rfc:`9438` uses a similar deterministic loss model as the one we used earlier. With a multiplicative decrease factor set to :math:`0.7`, this model computes an average window of :math:`sqrt[4]{\frac{C*3.7}{1.2}} \times \frac{sqrt[4]{rtt^3}}{sqrt[4]{p^3}}`. + .. rubric:: Footnotes @@ -241,4 +323,8 @@ In general, the maximum throughput that can be achieved by a TCP connection depe .. [#fslot] The buffers of a router can be implemented as variable or fixed-length slots. If the router uses variable length slots to store the queued packets, then the occupancy is usually measured in bytes. Some routers have use fixed-length slots with each slot large enough to store a maximum-length packet. In this case, the buffer occupancy is measured in packets. +.. [#fcubic] :rfc:`9438` lists four design principles. In addition to the three that we cover in this chapter, :rfc:`9438` also requires fairness with connections using the old NewReno congestion scheme. Since CUBIC is now widely deployed, we ignore this fourth principle. + +.. [#cubicdec] This is a simplified version of this multiplicative decrease. Additional details are provided in :rfc:`9438`. + .. include:: /links.rst diff --git a/protocols/dnssec.rst b/protocols/dnssec.rst index 0ed9555..c720a30 100644 --- a/protocols/dnssec.rst +++ b/protocols/dnssec.rst @@ -254,7 +254,7 @@ compromised, there is some period of time during which records signed with the two keys coexist in the network. The validity period allows ensuring that old signatures do not remain in DNS caches for ever. -.. spelling:: +.. spelling:word-list:: timestamps diff --git a/protocols/email.rst b/protocols/email.rst index 39c7e13..fea326b 100644 --- a/protocols/email.rst +++ b/protocols/email.rst @@ -39,7 +39,7 @@ Before looking at the details of Internet email, let us consider a simple scenar \node[txt, below=of BM] (TBM) {Bob retrieves messages\\from his server}; \draw[arrow] (BM) -- (TBM); -.. spelling:: +.. spelling:word-list:: webmail @@ -278,7 +278,7 @@ The example below, from :rfc:`4648`, illustrates the `Base64` encoding. | Encoding | F P u c A 9 l \+ | +----------------+----------------------------------------------------------+ -.. spelling:: +.. spelling:word-list:: 0x14fb9c03d97e @@ -311,7 +311,7 @@ The last point to be discussed about `base64` is what happens when the length of | Encoding | F P s \= | +----------------+-----------------------------+ -.. spelling:: +.. spelling:word-list:: eXchange diff --git a/protocols/ethernet.rst b/protocols/ethernet.rst index c16e31f..d532637 100644 --- a/protocols/ethernet.rst +++ b/protocols/ethernet.rst @@ -4,7 +4,7 @@ Ethernet ======== -.. spelling:: +.. spelling:word-list:: Palo Alto @@ -53,7 +53,7 @@ The fourth part of the Ethernet frame is the payload. The minimum length of the :align: center :scale: 70 - Impact of the frame length on the maximum channel utilisation [SH1980]_ + Impact of the frame length on the maximum channel utilization [SH1980]_ The last field of the Ethernet frame is a 32 bit Cyclical Redundancy Check (CRC). This CRC is able to catch a much larger number of transmission errors than the Internet checksum used by IP, UDP and TCP [SGP98]_. The format of the Ethernet frame is shown below. @@ -98,7 +98,7 @@ The Ethernet frame format shown above is specified in [DIX]_. This is the format The first property is a consequence of the utilization of CSMA/CD. The second property is a consequence of the physical organization of the Ethernet network as a shared bus. These two properties are important and all revisions to the Ethernet technology have preserved them. -.. spelling:: +.. spelling:word-list:: BaseF BaseT @@ -180,7 +180,7 @@ Standard Comments 40-100 Gbps Optical fiber (experiences are performed with copper) ============ ======================================================== -.. spelling:: +.. spelling:word-list:: Tx Fx diff --git a/protocols/http2.rst b/protocols/http2.rst index 83ae42d..eccf36e 100644 --- a/protocols/http2.rst +++ b/protocols/http2.rst @@ -156,7 +156,7 @@ The information exchanged over an HTTP/2.0 session is composed of frames. A fram Other frame types are described later. The `Flags` are used for some frame types and the `R` bit must be set to zero. The last important field of the `HTTP/2.0 Frame` header is the `Stream Identifier`. With HTTP/2.0, the bytestream of the underlying transport connection is divided in independent streams that are identified by an integer. The odd (resp. even) stream identifiers are managed by the client (resp. server). This enables the server (or the client) to multiplex data corresponding to different frames over a single bytestream. -.. spelling:: +.. spelling:word-list:: HoL diff --git a/protocols/ipv6.rst b/protocols/ipv6.rst index 9f970c2..d75a243 100644 --- a/protocols/ipv6.rst +++ b/protocols/ipv6.rst @@ -80,7 +80,7 @@ In the late 1980s and early 1990s the growth of the Internet was causing several Two types of solution were developed to solve this problem. The first short term solution was the introduction of Classless Inter Domain Routing (:term:`CIDR`). A second short term solution was the Network Address Translation (:term:`NAT`) mechanism, defined in :rfc:`1631`. NAT allowed multiple hosts to share a single public IPv4 address. -.. spelling:: +.. spelling:word-list:: IPng @@ -181,7 +181,7 @@ When considering the allocation of IPv6 addresses, two types of address allocati - ``/64`` for a single user (e.g. a home user connected via ADSL) - ``/128`` in the rare case when it is known that no more than one host will be attached -.. spelling:: +.. spelling:word-list:: Belnet ULg @@ -218,7 +218,7 @@ With the longest match rule, the route ``::/0`` plays a particular role. As this - a packet with destination ``2001:1890:123a::1:1e`` matches one route : ``::/0``. The packet is forwarded via ``fe80::dead:beef`` - a packet with destination ``2001:6a8:3880:40::2`` matches two routes : ``2001:6a8::/32`` and ``::/0``. The packet is forwarded via ``fe80::aaaa:bbbb`` -.. spelling:: +.. spelling:word-list:: trie @@ -447,7 +447,7 @@ In IPv6, fragmentation is performed exclusively by the source host and relies on - the `More` flag, which is set to `0` in the last fragment of a packet and to `1` in all other fragments. - the 32-bit `Identification` field indicates to which original packet a fragment belongs. When a host sends fragmented packets, it should ensure that it does not reuse the same `identification` field for packets sent to the same destination during a period of `MSL` seconds. This is easier with the 32 bits `identification` used in the IPv6 fragmentation header, than with the 16 bits `identification` field of the IPv4 header. -.. spelling:: +.. spelling:word-list:: priori @@ -727,7 +727,7 @@ Assume that the LAN containing the two hosts and the router is assigned prefix ` To be able to exchange IPv6 packets with ``hostB``, ``hostA`` needs to know the MAC address of the interface of ``hostB`` on the LAN. This is the `address resolution` problem. In IPv6, this problem is solved by using the Neighbor Discovery Protocol (NDP). NDP is specified in :rfc:`4861`. This protocol is part of ICMPv6 and uses the multicast datalink layer service. -.. spelling:: +.. spelling:word-list:: querier @@ -761,7 +761,7 @@ This is not the only usage of the Neighbor Solicitation and Neighbor Advertiseme Few users manually configure the IPv6 addresses on their hosts. They prefer to rely on protocols that can automatically configure their IPv6 addresses. IPv6 supports two such protocols : DHCPv6 and the Stateless Address Autoconfiguration (SLAAC). -.. spelling:: +.. spelling:word-list:: autoconfiguration Autoconfiguration diff --git a/protocols/routing.rst b/protocols/routing.rst index 1d0a515..beb11e6 100644 --- a/protocols/routing.rst +++ b/protocols/routing.rst @@ -11,7 +11,7 @@ In a large IP network such as the global Internet, routers need to exchange rout :align: center :scale: 70 - Organisation of a small Internet + Organization of a small Internet The first class of routing protocols are the `intradomain routing protocols` (sometimes also called the interior gateway protocols or :term:`IGP`). An intradomain routing protocol is used by all routers inside a domain to exchange routing information about the destinations that are reachable inside the domain. There are several intradomain routing protocols. Some domains use :term:`RIP`, which is a distance vector protocol. Other domains use link-state routing protocols such as :term:`OSPF` or :term:`IS-IS`. Finally, some domains use static routing or proprietary protocols such as :term:`IGRP` or :term:`EIGRP`. @@ -151,7 +151,7 @@ A first approach is to select one of the equal cost paths (e.g. the first or the A second approach is to install all equal cost paths [#fmaxpaths]_ in the forwarding table and load-balance the packets on the different paths. Consider the case where a router has `N` different outgoing interfaces to reach destination `d`. A first possibility to load-balance the traffic among these interfaces is to use `round-robin`. `Round-robin` allows equally balancing the packets among the `N` outgoing interfaces. This equal load-balancing is important in practice because it allows better spreading the load throughout the network. However, few networks use this `round-robin` strategy to load-balance traffic on routers. The main drawback of `round-robin` is that packets that belong to the same flow (e.g. TCP connection) may be forwarded over different paths. If packets belonging to the same TCP connection are sent over different paths, they will probably experience different delays and arrive out-of-sequence at their destination. When a TCP receiver detects out-of-order segments, it sends duplicate acknowledgments that may cause the sender to initiate a fast retransmission and enter congestion avoidance. Thus, out-of-order segments may lead to lower TCP performance. This is annoying for a load-balancing technique whose objective is to improve the network performance by spreading the load. -.. spelling:: +.. spelling:word-list:: tuple diff --git a/protocols/rpc.rst b/protocols/rpc.rst index d53e1ae..7793104 100644 --- a/protocols/rpc.rst +++ b/protocols/rpc.rst @@ -26,7 +26,7 @@ Encoding data The encoding problem exists in a wide range of applications. In the previous sections, we have described how character-based encodings are used by email and HTTP. Although standard encoding techniques such as ASN.1 [Dubuisson2000]_ have been defined to cover most application needs, many applications have defined their specific encoding. `Remote Procedure Call` are no exception to this rule. The three most popular encoding methods are probably XDR :rfc:`1832` used by ONC-RPC :rfc:`1831`, XML, used by XML-RPC and JSON :rfc:`4627`. -.. spelling:: +.. spelling:word-list:: eXternal datatype @@ -137,7 +137,7 @@ If the `sum` method is not implemented on the server, it would reply with the fo The `id` field, which is present in the request and the response plays the same role as the identifier field in the DNS message. It allows the caller to match the response with the request that it sent. This `id` is very important when JSON-RPC is used over the connectionless transport service which is unreliable. If a request is sent, it may need to be retransmitted and it is possible that a callee will receive twice the same request (e.g. if the response for the first request was lost). In the DNS, when a request is lost, it can be retransmitted without causing any difficulty. However with remote procedure calls in general, losses can cause some problems. Consider a method which is used to deposit money on a bank account. If the request is lost, it will be retransmitted and the deposit will be eventually performed. However, if the response is lost, the caller will also retransmit its request. This request will be received by the callee that will deposit the money again. To prevent this problem from affecting the application, either the programmer must ensure that the remote procedures that it calls can be safely called multiple times or the application must verify whether the request has been transmitted earlier. In most deployments, the programmers use remote methods that can be safely called multiple times without breaking the application logic. -.. spelling:: +.. spelling:word-list:: portmapper diff --git a/protocols/ssh.rst b/protocols/ssh.rst index 09625ae..8b28736 100644 --- a/protocols/ssh.rst +++ b/protocols/ssh.rst @@ -39,7 +39,7 @@ It is usually replaced by :term:`ssh` or similar protocols. The secure shell (ssh) ---------------------- -.. spelling:: +.. spelling:word-list:: Ylonen @@ -123,7 +123,7 @@ to evolve when new algorithms are proposed. If a client is upgraded, it can announce a new algorithm as its preferred one even if the server is not yet upgraded. -.. spelling:: +.. spelling:word-list:: Diffie Hellman diff --git a/protocols/tcp.rst b/protocols/tcp.rst index 5523401..84c7400 100644 --- a/protocols/tcp.rst +++ b/protocols/tcp.rst @@ -193,7 +193,7 @@ Apart from these two paths in the TCP connection establishment FSM, there is a t This limit of 100 TCBs in the `SYN Rcvd` state was chosen to protect the TCP entity from the risk of overloading its memory with too many TCBs in the `SYN Rcvd` state. However, it was also the reason for a new type of Denial of Service (DoS) attack :rfc:`4987`. A DoS attack is defined as an attack where an attacker can render a resource unavailable in the network. For example, an attacker may cause a DoS attack on a 2 Mbps link used by a company by sending more than 2 Mbps of packets through this link. In this case, the DoS attack was more subtle. As a TCP entity discards all received `SYN` segments as soon as it has 100 TCBs in the `SYN Rcvd` state, an attacker simply had to send a few 100 `SYN` segments every second to a server and never reply to the received `SYN+ACK` segments. To avoid being caught, attackers were of course sending these `SYN` segments with a different address than their own IP address [#fspoofing]_. On most TCP implementations, once a TCB entered the `SYN Rcvd` state, it remained in this state for several seconds, waiting for a retransmission of the initial `SYN` segment. This attack was later called a `SYN flood` attack and the servers of the ISP named Panix were among the first to `be affected `_ by this attack. - .. spelling:: + .. spelling:word-list:: Panix @@ -280,7 +280,7 @@ When a TCP segment with the `ACK` flag set is received, the following operations Segment transmission strategies ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. spelling:: +.. spelling:word-list:: Nagle @@ -321,7 +321,7 @@ This algorithm, called the Nagle algorithm, takes a few lines of code in all TCP TCP windows ----------- -.. spelling:: +.. spelling:word-list:: kbps GByte @@ -350,7 +350,7 @@ By using the window scaling extensions defined in :rfc:`1323`, TCP implementatio 500 msec 17 Gbps ======== ================== -.. spelling:: +.. spelling:word-list:: throughputs @@ -380,14 +380,14 @@ The easiest solution to measure the round-trip-time on a TCP connection is to me How to measure the round-trip-time ? -.. spelling:: +.. spelling:word-list:: Karn Partridge However, when a data segment is lost, as illustrated in the bottom part of the figure, the measurement is ambiguous as the sender cannot determine whether the received acknowledgment was triggered by the first transmission of segment `123` or its retransmission. Using incorrect round-trip-time estimations could lead to incorrect values of the retransmission timeout. For this reason, Phil Karn and Craig Partridge proposed, in [KP91]_, to ignore the round-trip-time measurements performed during retransmissions. -.. spelling:: +.. spelling:word-list:: timestamps @@ -410,7 +410,7 @@ However, in practice, this computation for the retransmission timeout did not wo Jacobson's algorithm uses two state variables, `srtt` the smoothed `rtt` and `rttvar` the estimation of the variance of the `rtt` and two parameters : :math:`\alpha` and :math:`\beta`. When a TCP connection starts, the first `rto` is set to `3` seconds. When a first estimation of the `rtt` is available, the `srtt`, `rttvar` and `rto` are computed as follows : -.. spelling:: +.. spelling:word-list:: rtt @@ -626,7 +626,7 @@ The `TIME\_WAIT` state is different from the other states of the TCP FSM. A TCP .. [#frlogin] On many departmental networks containing Unix workstations, it was common to allow users on one of the hosts to use ``rlogin`` :rfc:`1258` to run commands on any of the workstations of the network without giving any password. In this case, the remote workstation "authenticated" the client host based on its IP address. This was a bad practice from a security viewpoint. -.. spelling:: +.. spelling:word-list:: rlogin diff --git a/protocols/tls.rst b/protocols/tls.rst index 1bfd6ab..040215e 100644 --- a/protocols/tls.rst +++ b/protocols/tls.rst @@ -131,7 +131,7 @@ In a nutshell, the client starts the TLS handshake by proposing a random nonce. -.. spelling:: +.. spelling:word-list:: cryptanalysts @@ -384,7 +384,7 @@ In 2013, the statistics collected by the Firefox Telemetry project [#ftelemetry] Measurement studies that analyzed the evolution of TLS over the years have identified several important changes in the TLS ecosystem [KRA2018]_. First, the preferred cryptographic algorithms have changed. While RC4 was used by 60% of the connections in 2012, its usage has dropped since 2015. AES started to be deployed in 2013 and is now used for more than 90% of the connections. The deployed versions of TLS have also changed. TLS 1.0 and TLS 1.1 are now rarely used. The deployment of TLS 1.2 started in 2013 and reached 70% of the connections in 2015. Version 1.3 of TLS, that is described below, is also widely deployed. -.. spelling:: +.. spelling:word-list:: Snowden RSA @@ -394,7 +394,7 @@ that since summer 2014, ECDHE is more popular than RSA. In 2018, more than 90% o The last point is the difficulty of deploying TLS servers [KMS2017]_. When TLS servers are installed, the system administrator needs to obtain certificates and configure a range of servers. Initially, getting certificates was complex and costly, but initiatives such as https://letsencrypt.org have simplified this workflow. -.. spelling:: +.. spelling:word-list:: workflow @@ -446,7 +446,7 @@ The TLS 1.3 handshake differs from the TLS 1.2 handshake in several ways. First, There are several important differences with the TLS 1.2 handshake. First, the Diffie Hellman key exchange is required in TLS 1.3 and this exchange is initiated by the client (before having validated the server identity). To initiate the Diffie Hellman key exchange, the client needs to guess the modulus and the base that can be accepted by the server. Either the client uses standard parameters that most server supports or the client remembers the last modulus/base that it used with this particular server. If the client guessed incorrectly, the server replies with the parameters that it expects and one round-trip-time is lost. When the server sends its `ServerHello`, it already knows the session key. This implies that the server can encrypt all subsequent messages. After one round-trip-time, all data exchanged over the TLS 1.3 session is encrypted and authenticated. In TLS 1.3, the server certificate is encrypted with the session key, as well as the `Finished` message. The server signs the handshake to confirm that it owns the public key of its certificate. If the server wants to send application data, it can already encrypt it and send it to the client. Upon reception of the server Certificate, the client verifies it and checks the signature of the handshake and the `Finished` message. The client confirms the end of the handshake by sending its own `Finished` message. At that time, the client can send encrypted data. This means that the client only had to wait one round-trip-time before sending encrypted data. This is much faster than with TLS 1.2. -.. spelling:: +.. spelling:word-list:: pre rtt @@ -518,7 +518,7 @@ There are many more differences between TLS 1.2 and TLS 1.3. Additional details .. [#fhandshake] A detailed explanation of the TLS 1.3 handshake may be found at https://tls13.ulfheim.net/ .. [#ftelemetry] See https://letsencrypt.org/stats/ for a graph and https://docs.telemetry.mozilla.org/datasets/other/ssl/reference.html for additional information on the dataset -.. spelling:: +.. spelling:word-list:: dataset diff --git a/protocols/udp.rst b/protocols/udp.rst index 44e62cd..5a2b954 100644 --- a/protocols/udp.rst +++ b/protocols/udp.rst @@ -73,7 +73,7 @@ In most Unix variants, only processes having system administrator privileges can - a pseudo header :rfc:`2460` containing the source address, the destination address, the packet length encoded as a 32 bits number and a 32 bits bit field containing the three most significant bytes set to 0 and the low order byte set to 17 - the entire UDP segment, including its header -.. spelling:: +.. spelling:word-list:: 0xffff diff --git a/protocols/wifi.rst b/protocols/wifi.rst index 66f28d3..24a1542 100644 --- a/protocols/wifi.rst +++ b/protocols/wifi.rst @@ -28,7 +28,9 @@ Standard Frequency Typical Max Range (m) When developing its family of standards, the `IEEE 802.11 working group `_ took a similar approach as the `IEEE 802.3 working group `_ that developed various types of physical layers for Ethernet networks. 802.11 networks use the CSMA/CA Medium Access Control technique described earlier and they all assume the same architecture and use the same frame format. +.. spelling:word-list:: + adhoc .. index:: Basic Service Set (BSS), BSS, adhoc network, independent network @@ -134,7 +136,7 @@ When a frame is sent from a WiFi device to a server attached to the same LAN as In addition to the data and control frames that we have briefly described above, 802.11 networks use several types of management frames. These management frames are used for various purposes. We briefly describe some of these frames below. A detailed discussion may be found in [IEEE802.11]_ and [Gast2002]_. -.. spelling:: +.. spelling:word-list:: broadcasted diff --git a/travis.sh b/travis.sh index 3b61d58..63189e5 100755 --- a/travis.sh +++ b/travis.sh @@ -5,8 +5,10 @@ mkdir python cd python git clone https://github.com/obonaventure/mscgen.git pip3 install -e mscgen -git clone https://github.com/obonaventure/tikz.git -pip3 install -U -e tikz +#git clone https://github.com/obonaventure/tikz.git +pip3 install -U sphinxcontrib-tikz +pip3 install -U sphinxcontrib-spelling +pip3 install -U sphinx-book-theme cd .. # on error exit set -e diff --git a/util/convertpkt.sh b/util/convertpkt.sh index d2cef2b..b4c0d15 100755 --- a/util/convertpkt.sh +++ b/util/convertpkt.sh @@ -17,15 +17,15 @@ if [ "${1##*.}" = "svg" ]; then echo "Dimensions " ${W} "x" ${H} if [ ${W} -gt 500 ]; then - ${INKSCAPE} ${1} --without-gui --export-width=1000 --export-area-drawing --export-png=${DIRNAME}/${BASENAME}.png - ${INKSCAPE} ${1} --without-gui --export-width=500 --export-area-drawing --export-pdf=${DIRNAME}/${BASENAME}.pdf + ${INKSCAPE} ${1} --export-width=1000 --export-area-drawing --export-type="png" ${DIRNAME}/${BASENAME}.png + ${INKSCAPE} ${1} --export-width=500 --export-area-drawing --export-type="pdf" ${DIRNAME}/${BASENAME}.pdf convert ${DIRNAME}/${BASENAME}.png -resize '500' ${DIRNAME}/${BASENAME}.png # sips --resampleWidth 500 ${DIRNAME}/${BASENAME}.png # sips --resampleWidth 1000 ${DIRNAME}/${BASENAME}.pdf else #echo "Dimensions " ${W} "x" ${H} - ${INKSCAPE} ${1} --without-gui --export-area-drawing --export-png=${DIRNAME}/${BASENAME}.png - ${INKSCAPE} ${1} --without-gui --export-area-drawing --export-pdf=${DIRNAME}/${BASENAME}.pdf + ${INKSCAPE} ${1} --without-gui --export-area-drawing --export-type="png" ${DIRNAME}/${BASENAME}.png + ${INKSCAPE} ${1} --without-gui --export-area-drawing --export-type="pdf" ${DIRNAME}/${BASENAME}.pdf # ${INKSCAPE} ${1} --export-area-drawing --export-png=${DIRNAME}/${BASENAME}.png fi else