TLP doesn't change the congestion window

[martinthomson]

If recovery sends a tail loss probe, no change is made to the congestion window.

-- Section 4.4

Does this mean that the TLP doesn't count towards bytes_in_flight? Though it's probably not a problem in this case given that nothing has been sent for a while, another exemption is annoying.

Since that interpretation is directly in conflict with the next sentence, I think that this sentence is just unclear about intent (TLP isn't special when it comes to its sending and handling, the only special handling is in deciding to send a TLP packet - and maybe what you put in that packet).

[yangchi]

Does this mean that the TLP doesn't count towards bytes_in_flight?

This is answered by section 3.1.1:

A TLP packet MUST NOT be blocked by the sender’s congestion controller. The sender MUST however count these bytes as additional bytes in flight, since a TLP adds network load without establishing packet loss.

OTOH, I think as an implementer I'd like to have some leeway on this. MUST might be too strong.

[ianswett]

@martinthomson would it be clearer if I changed it to: "If recovery sends a tail loss probe, no change is made to the congestion window, but the packet does increase bytes_in_flight." ?

I can't see a reason not to count it towards bytes in flight, so I chose MUST. Can you think of reasons to change this to a SHOULD?

[yangchi]

@ianswett : never mind about the "MUST being too strong". I was thinking that for a short moment after I send out a TLP packet, if an ACK comes back and acking all packets before TLP, but not TLP, I'm only allowed to send congestion_window - bytes_in_flight number of bytes, while bytes_in_flight still holds the TLP bytes. But now i realize that's the way it was intended. (There might be a case that after onRetransmissionTimeoutVerified, congestion_window drops to a small value, but not everything in bytes_in_flight will be cleared up, but that's a different issue (#935 ).)