[core] Fix CSndLossList::insert with negative offset

[maxsharabayko]

Work in progress.

Probably CSndLossList::insert(..) should return -1 on failure, but then it needs to be properly handled in CUDT.

Related to #1000.

Suggestion by @ethouris

In file mode you just have to stop sending new packets, until retransmissions are successful enough and enough losses are covered
In live mode I don't think it's possible to live up to the live stream requirements with a large number of losses (or it's not a problem because sender drops would solve the problem earlier).
Meaning, if sender drops are working, this won't be a problem - or at least sender dropping could be enforced with a large number of drops. But we also have an option to turn sender drops completely off - in this case the only way to go is to close the connection.

[ethouris]

Not sure if this situation can be described as IPE here.

[ethouris]

BTW. Does it mean that offset is allowed to be negative in general, as long as it fits in the range from the current head and size?

[maxsharabayko]

Potentially the following can happen:

1. Two packets with sequence numbers A and B (A <% B) are reported as lost.
2. Packet A is retransmitted and removed from the loss list.
3. Packet A is reported lost again, so that CSeqNo::seqoff(m_caSeq[m_iHead].seqstart = B, seqno1 = A) < 0.

So negative offset is allowed, it just has to fit into the list.

[ethouris]

Isn't however head moved forward after getting ACK? Isn't then a sequence that is earlier than head a sequence before the ACK? If this is true, then I can only imagine such a situation if reordering happened and the ACK that confirms the packet in question comes earlier than the lossreport that reports this sequence as lost, although it's actually outdated.

If this is the case, however, then it should be first checked if the upper sequence is below the head, and only if so should the loss record be rejected as a whole. Otherwise at least the range between the head and the upper sequence be recorded.

[maxsharabayko]

The head is moved forward after the loss record is extracted and the corresponding packet is retransmitted.

If the same packet is reported lost again, it is placed before the head (negative offset), and the head position is updated.

// offset < 0
const int offset  = CSeqNo::seqoff(m_caSeq[m_iHead].seqstart, seqno1);

As I wrote above, a negative offset is allowed, it just has to fit into the list.

The loc identifies the position in the list to insert at. It is not allowed to be negative, otherwise it is out of bounds memory access.

int loc = (m_iHead + offset + m_iSize) % m_iSize;

[ethouris]

Ok, I understand that negative loc within the bounds is allowed, but I don't think it's correct to reject the whole report because of that. It should reject it only if the upper bound is behind the seqstart, and if it's not, the loss record should be accepted with the lower bound adjusted.

[maxsharabayko]

Added check for upper sequence.