计网个人作业03

R14. True or false?

a

a. Suppose Host A is sending a large file to Host B over a TCP connection. If the sequence number for a segment of this connection is m, then the sequence number for the subsequent segment will necessarily be m + 1.

假设主机A通过一条TCP连接向主机B发送一个大文件，如果对于这次连接的一个报文段序号为m，则对于后续报文段序列号必然为m+1

False
序号是根据TCP数据字节流大小决定而非保温序列，假定最大报文段大小为n，则后续报文段序号应为m+n

b

b. Host A is sending Host B a large file over a TCP connection. Assume Host B has no data to send Host A. Host B will not send acknowledgments to Host A because Host B cannot piggyback the acknowledgments on data.

主机A经过一条TCP连接向主机B发送一个大文件. 假设主机B没有数据发往主机A. 因为主机B不能随数据捎带确认, 所以主机B将不向主机A发送确认

False

主机B不向A发送确认这个行为会违背可靠数据传输协议基本原则。reciever向sender发送确定是报文协议的一个规则。

课本上提到的是：sender要发送一个字符，receiver返回该字符并回显，顺便把确认信息放入发送给sender的数据的报文段中，此为 捎带确定

c

c. Suppose that the last SampleRTT in a TCP connection is equal to 1 sec. The current value of TimeoutInterval for the connection will necessarily be ≥ 1 sec.

假定在一条TCP连接中最后的SampleRTT等于1秒, 那么对于该连接的TimeoutInterval的当前值必定大于等于1秒.

False

$$TimeoutInterval=EstimatedRTT+4\times DevRTT$$
TimeoutInterval数据和SampleRTT无关

d

d. Suppose Host A is sending Host B a large file over a TCP connection. The number of unacknowledged bytes that A sends cannot exceed the size of the receive buffer.

假设主机A通过一条TCP连接向主机B发送一个大文件。主机A发送的未被确认的字节数不会超过接收缓存的大小

True

TCP流量控制

e

e. The size of the TCP RcvWindow never changes throughout the duration of the connection.

在连接的整个过程中，TCP的RcvWindow的长度不会变化

RWND (Receiver Window) 滑动窗口

False

rwnd的值是动态的，其表示连接的缓存中还有多少空间

f

f. The TCP segment has a field in its header for RcvWindow.

TCP报文段在它的首部中有一个rwnd字段。

True

rwnd即接收窗口（receive window），用来告知发送方，自己在该TCP连接的缓存中还有多少可用空间

g

g. Suppose Host A sends one segment with sequence number 38 and 4 bytes of data over a TCP connection to Host B. In this same segment the acknowledgment number is necessarily 42.

假定主机A通过一条TCP连接向主机B发送一个序号为38的4字节报文段。这个报文段的确认号必定是42

False
序号（seq）用来标识从TCP发端向TCP收端发送的数据字节流

报文段的确认号（ack）指的是 —— 确认号是该主机 正在在等待的数据的下一字节的序号（应当是上次已成功收到数据字节序号加1）

他们的变化可以参照这篇博客 TCP包的seq和ack号计算方法

如果想要下一个接受的ack为42，需要对方发送对应的ACK，但有的情况下，数据包并不能正确送达（如物理导致的损失或校验和检验失败）此时B端会重发ack=38的报文来提示A段报文未能正确送达。

P2.

UDP和TCP使用反码来计算它们的检验和。假设你有下面3个8比特字节:01010011，01100110，01110100。这些8比特字节和的反码是多少?(注意到尽管UDP 和 TCP 使用 16 比特的字来计算检验和，但对于这个问题，你应该考虑8比特和。)写出所有工作过程。UDP 为什么要用该和的反码，即为什么不直接使用该和呢?使用该反码方案，接收方如何检测出差错?1比特的差错将可能检测不出来吗?2比特的差错呢?

   0 1 0 1 0 0 1 1
 + 0 1 1 0 0 1 1 0
------------------
   1 0 1 1 1 0 0 1

   1 0 1 1 1 0 0 1
 + 0 1 1 1 0 1 0 0
 -----------------
   0 0 1 0 1 1 1 0
//溢出一位，第一位回卷

补码为： 1 1 0 1 0 0 0 1

若要检验错误，接收方添加四个单词（三个原始单词和校验和）

1. 将反码1101 0001 放在检验和处
2. 在接受方将全部的传输数据和检验和相加为1111 1111时，无差错
3. 只要有任意一位为0，传输中就出现了差错

运用反码相加，全1的检测对于计算机来说更加方便，速度会更快

if 和包含一个0
    reciever知道存在 “一位错误”
if 两位错误出现在同一位置上无法被检验到

P5.

Consider our motivation for correcting protocol rdt2.1. Show that the receiver, shown in the following figure, when operating with the sender shown in Figure 3.11, can lead the sender and receiver to enter into a deadlock state, where each is waiting for an event that will never occur.

考虑我们改正协议rdt2.1的动机，试说明下图接收方与3。11所示发送方运行时，接收方可能会引起的发送方和接收方进入的死锁状态。

假设sender处于"等待来自上层的调用1"， receiver处于"wait for 1 from below"的状态.

1. sender发送序列号为1的数据包，转换"等待ACK或NAK1"，等待ACK或NAK1。
2. 若接收方正确接收序列号为1的数据包，发送ACK，转换为状态——“wait for 0 from below”等待序列号为0的数据包
3. 然而ACK损坏，rdt2.1sender获取损坏的ACK时，它以序列号1重新发送数据包
4. receiver正在等待序列号为0的数据包，并且当它没有得到序列号为0的数据包时，总是发送NAK
5. 发送方将始终发送序列号为1的数据包，接收方将始终保持该数据包。死锁

P8.

Suppose that the UDP receiver computes the Internet checksum for the received UDP segment and finds that it matches the value carried in the checksum field. Can the receiver be absolutely certain that no bit errors have occurred? Explain.

不一定，有可能同时出现两个bits的错误

P13.

Consider a reliable data transfer protocol that uses only negative acknowledgments. Suppose the sender sends data only infrequently. Would a NAK-only protocol be preferable to a protocol that uses ACKs? Why? Now suppose the sender has a lot of data to send and the end-to-end connection experiences few losses. In this second case, would a NAK-only protocol be preferable to a protocol that uses ACKs? Why?

1. 问题1：

仅NAK协议中，只有receiver接受到分组$x+1$的时候，receiver才检测数据包x的丢失

考虑发生以下事件：
receiver接受$x-1$ 然后接受$x+1$，当reciver真正接收到$x+1$的时候，接收器才会意识到x被忽略了。

若$x$与$x+1$传输之间存在很长的延迟，只是用NAK协议下，需要很长时间才可以获得数据$x$

2. 问题2：
   会表现得更好，这是sender要发送大量数据，sender可以即使得知数据丢失并重发。同时丢失量较少NAK数量也会较少，对比又ACK的协议，可以有效降低receiver到sender的流量占用

P14.

Consider the GBN protocol with a sender window size of 3 and a sequence number range of 1,024. Suppose that at time t, the next in-order packet that the receiver is expecting has a sequence number of k. Assume that the medium does not reorder messages. Answer the following questions:

考虑一个GBN协议，其发送方窗口为4，序号范围为1024。假设在时刻t，接收方期待的下一个有序分组的序号是k 。假设媒体不会对报文重新排序

a. What are the possible sets of sequence numbers inside the sender’s window at time t? Justify your answer.
a. 在f时刻，发送方窗口内的报文序号可能是多少？论证你的回答。

1. 回答a:
   此时receiver等待第$k$个数据，那么$k-3,k-2,k-1$的数据的ACK报文中可能存在部分丢失.
   对于最大的抵达sender的ACK报文序号，记为$x(k-3\le x\le k-1)$,那么sender的窗口内为第$x+1,x+2,x+3$的数据
   举个例子：若第$k-3,k-1$数据丢包，sender
   窗口中应为$k-1,k,k+1$

b. What are all possible values of the ACK field in all possible messages currently propagating back to the sender at time t? Justify your answer.b. 在f时刻，在当前传播回发送方的所有可能报文中，ACK字段的所有可能值是多少？论证你的回答。

2. 回答b:
   由于 receiver 正在等待第$k$个数据, 即 sender 已经发出了第$k-1$个数据,说明sender至少收到了第$k-4$个数据的ACK报文（否则sender窗口中应为k-4,k-3,k-2数据），于是序号小于k-4的数据的ACK不会被重传，那么在传输中的ACK报文范围为$[k-4,k-1]$

P22.

Consider the GBN and SR protocols. Suppose the sequence number space is of size k. What is the largest allowable sender window that will avoid the occurrence of problems such as that in Figure 3.27 for each of these protocols?

窗口大小$w$应该满足$w\le \lfloor \frac{k}{2}\rfloor$

当前receiver等待窗口为$[x,x+w]$，也就是receiver已经收到了$[x-w-1,x-1]$的数据，但最坏情况下，只有$x-w-1$的ACK到达sender，即sender窗口含有的数据为$[x-w,x]$，那么若KaTeX parse error: Undefined control sequence: \re at position 12: (x+w)-(x-w)\̲r̲e̲ ̲k的时候，就有$(x-w)modk\in [x,x+w]modk$,当sender重发$x-w$就会被receiver当作新的数据接收，因此窗口大小$w$应该满足$w\le \lfloor \frac{k}{2}\rfloor$

P24.

Consider transferring an enormous file of L bytes from Host A to Host B.

a. What is the maximum value of L such that TCP sequence numbers are not exhausted? Recall that the TCP sequence number field has 4 bytes.

$$2^{32}bytes=4Gbytes$$

b. For the L you obtain in (a), find how long it takes to transmit the file. Assume that a total of 66 bytes of transport, network, and data-link header are added to each segment before the resulting packet is sent out over a 10 Mbps link. Ignore flow control and congestion control so A can pump out the segments back to back and continuously.

假设$MTU=1460bytes$一共会产生$\lceil \frac{2^{32}}{1460}\rceil$个报文，头部数据一共有$66\times \lceil \frac{2^{32}}{1460}\rceil$

共需要时间
$$\frac{8\times (2^{32}+66\times \lceil \frac{2^{32}}{1460}\rceil )}{10\times 2^{20}}=3425s$$

P32.

Consider Figure 3.57.

Figure 3.57 TCP window size as a function of timeAssuming TCP Reno is the protocol experiencing the behavior shown above, answer the following questions. In all cases, you should provide a short discussion justifying your answer.

a

a. What is the value of Threshold ssthresh at the 18th transmission round?

在17th处CongWin大小减半，发生了3个冗余ACK时间，Threshold应该是发生该事件前CongWin(16th)大小的一半
也就是
$$\frac{42}{2}=21$$

b

b. What is the value of Threshold ssthresh at the 24th transmission round?

23th处CongWin变为慢启动状态，也就是超时事件，所以Threshold应该是发生这个事件前CongWin（22th处）大小的一半
$$\frac{26}{2}=13$$

c

c. Identify the intervals of time when TCP slow start is operating.

[1,6]和[23,26]

d

d. Assuming a packet loss is detected after the 26th round by the receipt of a triple duplicate ACK, what will be the values of the congestion window size and of Threshold ssthresh?

当收到 3 个冗余 ACK 时, Threshold 应该是发⽣该事件前 CongWin (即 16th 处)⼤⼩的⼀半, 即
$$\frac{8}{2}=4$$
⽽ CongWin ⼤⼩应被设为 Threshold 的值, 即$4$

e

e. After the 16th transmission round, is segment loss detected by a triple duplicate ACK or by a timeout?

6th 后检测到 3 个冗余 ACK 事件

f

f. After the 22nd transmission round, is segment loss detected by a triple duplicate ACK or by a timeout?

22th 后检测到超时事件

g

g. Identify the intervals of time when TCP congestion avoidance is operating.
[6,16] [17,22]

h

h. What is the initial value of Threshold ssthresh at the first transmission round?

由于在 CongWin ⼤⼩为 32 时开始加性增, 所以初始值为32

i

i. During what transmission round is the 70th segment sent?

前6 round中，发送了$1+2+4+8+16+32=63$个报文， 7th 共发送33个报文
所以7th时候发送第70个报文

j

j. Suppose TCP Tahoe is used (instead of TCP Reno), and assume that triple duplicate ACKs are received at the 16th round. What are the ssthresh and the congestion window size at the 19th round?

对于 Tahoe 版 TCP, 17th 时 Threshold 应为 21, ⽽ ChongWin ⼤⼩应为 1, 并处于慢启动状态, 所以19th 时 Threshold 为 21, ⽽ ChongWin ⼤⼩为 4

k

k. Again suppose TCP Tahoe is used, and there is a timeout event at 22nd round. How many packets have been sent out from 17th round till 22nd round, inclusive?

由于 Threshold 为 21, 所以从 17th 开始, CongWin ⼤⼩应为$1,2,4,8,16,21$所以一共发送$52个$

P36.

Consider sending a large file from a host to another over a TCP connection that has no loss.

a

a. Suppose TCP uses AIMD for its congestion control without slow start. Assuming CongWin increases by 1 MSS every time a batch of ACKs is received and assuming approximately constant round-trip times, how long does it take for CongWin increase from 1 MSS to 6 MSS (assuming no loss events)?

由于每 1 RTT 可以增⻓ 1 MSS, 所以共需5MSS

b

b. What is the average throughout (in terms of MSS and RTT) for this connection up through time = 5 RTT?

总共发送$1+2+3+4+5=15$MMS
平均值为$\frac{15}{3}=5$