You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If more than one Report Segment (RS) is needed to respond to a checkpoint then it is possible for the RS that acknowledges the checkpoint to make it back to the Sender but the other RS and eventually the Cancel Segments to not make it to the Sender. When this happens, the Sender is no longer retransmitting the original checkpoint and a new checkpoint associated with the dropped RS is never generated so the Sender LTP has no way to eventually cancel the Session and the bundles never get sent.
Test Configuration
Node 1 (Sender)
IP Address:
192.168.0.1
LTP Config:
m maxber 1.0E-9
a span 2 100 100 1400 1 1 'udplso 127.0.0.1:1114'
s 'udplsi 192.168.0.1:1113'
LTP Config:
m maxber 1.0E-9
a span 32969 100 200 1400 100000 1 'udplso 192.168.0.1:1115'
s 'udplsi 192.168.0.2:1113'
Bundle Reception:
bpcounter ipn:2.2 100
I let it run for a few hours with the above config and then killed the owltsim and restarted it with the drop rate changed to -4. Using tcpdump I monitored until all of the LTP completed and then there were still 92 bundles stuck in the Sender node. I added debug output to the source code so I was able to track down LTP Session 41 as the first one that was stuck so it shouldn't really need to run for several hours for it to happen.
---------- comment from DZ ----------
Correction: The maxber for Node 1 was 0.00001
The text was updated successfully, but these errors were encountered:
If more than one Report Segment (RS) is needed to respond to a checkpoint then it is possible for the RS that acknowledges the checkpoint to make it back to the Sender but the other RS and eventually the Cancel Segments to not make it to the Sender. When this happens, the Sender is no longer retransmitting the original checkpoint and a new checkpoint associated with the dropped RS is never generated so the Sender LTP has no way to eventually cancel the Session and the bundles never get sent.
Test Configuration
Node 1 (Sender)
IP Address:
192.168.0.1
LTP Config:
m maxber 1.0E-9
a span 2 100 100 1400 1 1 'udplso 127.0.0.1:1114'
s 'udplsi 192.168.0.1:1113'
owltsim Config:
2 1 1114 192.168.0.2 1113 0 -2
1 2 1115 192.168.0.1 1113 0 -2
Bundle Transmission:
bpdriver 100 ipn:1.1 ipn:2.2 -58400 t86400
Node 2 (Receiver)
IP Address:
192.168.0.2
LTP Config:
m maxber 1.0E-9
a span 32969 100 200 1400 100000 1 'udplso 192.168.0.1:1115'
s 'udplsi 192.168.0.2:1113'
Bundle Reception:
bpcounter ipn:2.2 100
I let it run for a few hours with the above config and then killed the owltsim and restarted it with the drop rate changed to -4. Using tcpdump I monitored until all of the LTP completed and then there were still 92 bundles stuck in the Sender node. I added debug output to the source code so I was able to track down LTP Session 41 as the first one that was stuck so it shouldn't really need to run for several hours for it to happen.
---------- comment from DZ ----------
Correction: The maxber for Node 1 was 0.00001
The text was updated successfully, but these errors were encountered: