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
One thing I noticed when researching CoAP Block-wise transfer and other "concurrent transfer" over a single CoAP connection, is that CoAP has a very simple retransmission mechanism; One packet in flight, 1s timeout at the start, and exponential increase when the timeout expires.
This, for obvious reasons (especially the "one packet in flight" bit) can averse effects on the usage of this library, it'd allow 1/RTT rate of packets, with no way to take advantage of link width, and being bound to link latency.
However, choosing the wrong Congestion Control algorithm could have other averse effects on the library, causing random delays up to the retransmission timeout, if one packet gets missing between a sea of others.
The best congestion control algorithm would be one that is able to a. react efficiently to a changing network connection, and b. be able to utilise a network connection efficiently, and c. be stable in its default throughput (no to less jitter).
Research in this area is needed.
The text was updated successfully, but these errors were encountered:
Just to illustrate how significant figuring this out is, ill echo what i said in the MSC here;
As an example, taking a block-wise transfer, with a SZX (size) of 1024 bytes, and an RTT of 300ms, would get me a theoretical transmission rate of 3.5KBps.
One thing I noticed when researching CoAP Block-wise transfer and other "concurrent transfer" over a single CoAP connection, is that CoAP has a very simple retransmission mechanism; One packet in flight, 1s timeout at the start, and exponential increase when the timeout expires.
This, for obvious reasons (especially the "one packet in flight" bit) can averse effects on the usage of this library, it'd allow
1/RTT
rate of packets, with no way to take advantage of link width, and being bound to link latency.However, choosing the wrong Congestion Control algorithm could have other averse effects on the library, causing random delays up to the retransmission timeout, if one packet gets missing between a sea of others.
The best congestion control algorithm would be one that is able to a. react efficiently to a changing network connection, and b. be able to utilise a network connection efficiently, and c. be stable in its default throughput (no to less jitter).
Research in this area is needed.
The text was updated successfully, but these errors were encountered: