more lapses

[swift-upb.git] / doc / draft-ietf-ppsp-grishchenko-swift.nroff

diff --git a/doc/draft-ietf-ppsp-grishchenko-swift.nroff b/doc/draft-ietf-ppsp-grishchenko-swift.nroff
index 8e84680..1461f89 100644 (file)
--- a/doc/draft-ietf-ppsp-grishchenko-swift.nroff
+++ b/doc/draft-ietf-ppsp-grishchenko-swift.nroff
@@ -476,6 +476,7 @@ message (type 7) to announce the fact:
 .ti 0\r
 4.5.  Peer exchange and NAT hole punching\r
 \r
+.fi\r
 Peer exchange messages are common for many peer-to-peer protocols. By exchanging peer IP addresses in gossip fashion, peers relieve central coordinating entities (the trackers) from unnecessary work. Following the example of BitTorrent, swift features two types of PEX messages: "peer connected" (type 5) and "peer disconnected" (type 6). Peers are represented as IPv4 address-port pairs:\r
 .nf\r
 05 7F000000 1F40\r
@@ -563,7 +564,7 @@ The most theoretically correct way is to run swift on top of IP, as another tran
 .ti 0\r
 5.2.  UDP\r
 \r
-.nf\r
+.fi\r
 Currently, swift-over-UDP is the default deployment option. Effectively, UDP allows to use IP with minimal overhead, it also allows userspace implementations.\r
 Besides the classic 1KB packet scenario, the bin numbering allows to use swift over Jumbo frames/datagrams. Both data and acknowledgments may use e.g. 8KB packets instead of "standard" 1KB. Hashing scheme stays the same.\r
 Using swift with 512 or 256-byte packets is theoretically possible with 64-bit byte-precise bin numbers, but IP fragmentation might be a better method to achieve the same result.\r