do not cap pto_count to one

[kazuho]

@janaiyengar Please review.

FWIW, QUICLY_MAX_PTO_COUNT is currently set to 16, meaning that maximum PTO timeout is 65 seconds when using 1ms timer, which should be more than enough.

Closes #150.

[kazuho]

I think the proposed changes are correct.

My assumption is that the test failures are due to other bugs becoming prominent, now that the endpoints are sending less packets when under loss.

[janaiyengar]

As discussed offline, let's dispose of the MAX_PTO_COUNT altogether.

[janaiyengar]

Looks great, thanks for doing this.

[kazuho]

@janaiyengar I believe you love e11b9d7.

With that being fixed, the remaining issue seems to be the following. I am uncertain how I should resolve it. May I ask for your wisdom?

When the network is severely congested in both directions, it is often the case that even the ACKs you receive are outdated. It could possibly be more than 3 PTO. However, because quicly discards sentmap entries after 3 PTO, the ACK frames are ignored. Therefore, the situation becomes indistinguishable from no communication at all, and the connection times out.

To me it seems that this is something very different from what we see in TCP.

Do we need to fix the issue? If yes, how should we?

[kazuho]

Tried to retain sentmap for longer period. Didn't fix the issue.

The other case that I am concerned about is quicly only sending ACK once every time it receives a new packet (either immediately or after ack-delay). This is different from TCP where you bundle ACKs for every packet you send. Maybe we need to retransmit ACK whenever PTO timer fires (because that is an indication of loss in either or both the directions).

[janaiyengar]

@janaiyengar I believe you love e11b9d7.

+1!

When the network is severely congested in both directions, it is often the case that even the ACKs you receive are outdated. It could possibly be more than 3 PTO. However, because quicly discards sentmap entries after 3 PTO, the ACK frames are ignored. Therefore, the situation becomes indistinguishable from no communication at all, and the connection times out.

This is indeed different than TCP, because TCP doesn't discard anything that's not acked. As discussed offline, let's disable the 75% loss tests for now and proceed as long as the 50% loss tests work. Either way, let's look at the logs next week to figure out what's going on with the tests.