Homework 6
Solution

Gabriela Barrantes

4.12

We start from either (A1,B1) or (A1,B2).  Notice
that B MUST execute a passive open at some moment, 
as state 1 is unable to react on external input. 
I put "*" in all the cases that it could be either
B1 or B2.

(A4,B1 *)	A sends active open
(A1,B1 *) 	SYN got lost, A returns to "closed"
(A4,B2)		A sends active open, B is in passive open
		state
(A4,B3)		B receives SYN, answers with SYN/ACK
(A5,B3)		B receives SYN/ACK, sends ACK
(A5,B5)		B receives ACK. End of 3-way handshake, 
		the connection is established.
...		Data
(A8,B5)		A closes, sends close (FIN) message
(A8,B6)		B receives FIN, answers with ACK
(A10,B6)	A receives B's ACK
(A10,B7)	B closes and sends close message to A
		(trying to execute a graceful close)
(A11,B7)	A sends ACK. It is lost.
(A11,B1)	B times out & closes connection
(A1,B1)		A times out & closes connection
===================================================================

2.

The max lifetime should ensure that both, the packet & the ACK die.
If we took into account only the packet, we can imagine a 
scenario where the ACK for a very old packet is received, and
given that the sequence nuber has already cycled (as the ACK
was not taken into account), this old ACK can be interpreted as
the ACK for a new packet that has reused the sequence number of
the original packet.

====================================================================
3.

Consider the following scenario (A wants to connect to B).
So you won't get confused, assume that A & B are processes
with some specific ports.

An old connection request arrives to B with some
starting number N.

B opens the connection as requested, sends the connection ACK
and starts waiting for data packet N+1.

The ACK gets lost, so A has no idea that this happened.

The same thing happens to A, and A opens the connection
and waits for packets to start arriving with sequence number 
M+1.

Now no work gets done because any packets that B sends to A
will have sequence numbers starting with N while A is expecting
stuff in the M-range, and viceversa.

And this happens because the connection is opened BEFORE it
has been confirmed that the other side actually issued the
request, which is corrected in the 3-2ay handshake.

=================================================================

4. 

From a purist independence-among-layers perspective, TCP must not
concern itself with the fragmentation and reassembly problem.
In fact, earlier TCP implementations didn't even acknowledge the 
existence of F & R (as they should!) and worked just fine. The 
problem came with higher data rates.

From a performance perspective, having your TCP packets
blown to pieces and then being discarded at the receiver because
a small piece disappeared or was delayed, is a BIG problem. You
rather deal with missing pieces directly in your window. This is
why current TCP implementations have path MTU discovery and send
the data in packets whose size won't cause them to fragment.

===================================================================

5.

The intent of this exercise is to show the load that the reception
of packets puts into the receiving processor, and how small packets
really affect performance at the receiver end.

packet size = 4000 * 8 = 32,000 bits

100 MIPS = 100 x 10^6 instructions/sec

10^4 packets/sec are generated. 

First, let's check if our line can support this input:

1 Gpbs = 10^9 bits/sec

Input rate = 10,000 packets/sec * 4000 bits/packet = 4 x  10^7 bps

32 x 10^7 < 10 ^ 9 so we are inside an accpetable range. 

Now, the packet interarrival time is 10^(-4) sec.

During this period we can execute 100 x 10^2 instructions.

If we want to use only half the time for packet processing, then
the fixed overhead of interrupting the processor, loading the kernel
memory tables, executing the IP/TCP code, etc, better take less 
than 5,000 instructions. (which seems quite a bit of time for a
simple task). However, notice that if the process takes k 
instructions, it is a linear time associated with EACH packet,
and it doesn't depend on packet's length.

Now, if we change packet size to 128 bytes, but still want to
be sending 32 x 10^7 bps, we will have to change the number of
packets sent. We need to send now 312,500 packets/sec.

The packet interarrival time reduces to 32 x 10^(-7) sec,
which means we will have only 32 x 10 instructions available
between packets, and because we want to have half of the
processor time for other applications, we actually are
reduced to 160 instructions, which probably won't be enough
to process each packet. This means that with smaller packets
we cannot sustain the same input rate as before, because
of the fixed processing overhead that each packet is imposing.
==============================================================

6. At 64 bits, sequence numbers will range from 0 to 2^64 - 1.
Remember that TCP uses the byte offset in the window  as sequence
numbers. So, we will have to send 2^64 bytes to wrap around the
sequence numbers, which is the problem we face in transport 
protocols.

2^64 bytes ~= 2 x 10^19 bytes (and sequence numbers)

75 Tbps = 75 x 10^12 bps = 9.375 x 10^12 bytes /sec, which
is equivalent to saying that it is going through 9.375 x 10^12 
sequence numbers per second.

So, we need (2 x 10^19) / (9.375 x 10^12) seconds to wrap around

=~ 2133000 seconds ~= 25 days

So, a maximum packet lifetime of less than three weeks or so
will prevent any wraparound problems. Actually this is ludicrous, 
and was only meant to show that at even extremely high data rates
64 bits sequence numbers are more than enough.

Of course that the same calculation with 32 bits yields 
0.00045813 seconds, which is ridiculously small for a useful
lifetime. The sequence numbers will wrap around while the
packets were around the third hop or something ridiculous
like that.


This is approx