Hi there,
I have a couple of questions related to the tcp_input() implementation:
Thank you!
I have a couple of questions related to the tcp_input() implementation:
- Let's assume the sender has outstanding data on the socket's send queue (waiting to be sent out), there is no packet loss and so the receiver gets all the data in sequence and responds differently as described in the following two cases:
- the receiver responds with pure ACK (tcp_len=0);
- the receiver responds with ACK and sends some additional data (tcp_len=1400).
Now, tcp_input() treats two scenarios differently, especially in the following two areas:
In case a), at the end of ACK processing, the receiver will check if there is any pending data on the socket sent queue waiting to be sent and if there is, it will unconditionally call tcp_output() before it goes to check if the delay timer needs to be armed. Whereas in case b) the code will only try to send (call tcp_output()) if the DELAY_ACK() macro returns false (mainly if the delay-timer is already running). If the delay-timer isn't running, it will arm it, but not call tcp_output().
So my question is: why the difference between a) and b) in this specific area? Shouldn't the code be more efficient if also in case b), the sender tried to send data unconditionally?
- The second question is regarding updating of congestion control information, which again is different for processing of pure ACK (tcp_len=0) vs. processing of a TCP packet with data that also ACKs received data in sequence.
In the former case, cc_ack_received() is called which potentially inflates the congestion window and in the latter case this doesn't happen. What would go wrong if, in the latter case, we also called cc_ack_received()?
Thank you!
