[jboss-jira] [JBoss JIRA] (JGRP-1539) NAKACK2: xmit_interval sometimes triggers unneeded retransmissions

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1539:
---------------------------
    Description: 
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message. 
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received

Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.

The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.

Another reason is also that the message bundler on the sender side might send messages in random order (see link below).

SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.

  was:
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message. 
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received

Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Has the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.

The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.

Another reason is also that the message bundler on the sender side might send messages in random order (see link below).

SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.



> NAKACK2: xmit_interval sometimes triggers unneeded retransmissions
> ------------------------------------------------------------------
>
>                 Key: JGRP-1539
>                 URL: https://issues.jboss.org/browse/JGRP-1539
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.3
>
>
> In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message. 
> Example:
> - Messages 1,2,3,4,5 are received at time T0 (in ms)
> - At time T1000, message 20 is received
> - At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
> - At time T1009, messages 6-19 are received
> Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
> The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
> Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
> SOLUTION:
> Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)