[Nfd-dev] [Ndn-interest] UDP_retransmissiom

[Eric Newberry]

Yes, the system actually uses both mechanisms to determine if a packet 
is lost, although it is more likely that the mechanism Lixia mentioned 
will discover the lost sequence instead of the RTO mechanism (which is 
mainly intended to catch losses before a pause in packet transmission).

Eric


On 01/11/2018 10:55 PM, Lixia Zhang wrote:
>
>> On Jan 11, 2018, at 9:44 PM, Eric Newberry 
>> <enewberry at email.arizona.edu <mailto:enewberry at email.arizona.edu>> wrote:
>>
>> Hi Giuseppe,
>>
>> The reliability system transmits the packet up to maxRetx + 1 times, 
>> once for each time an acknowledgement is not received (disregarding 
>> the last unacknowledged attempt).
>>
>> The RTO is determined (and is continually updated based upon packet 
>> RTTs) using a hardcoded mechanism. It would not be possible to change 
>> this without modifying and recompiling NFD. More specifically, it 
>> uses the TCP RTO calculation (SRTT + 4 * RTTVAR).
>>
>> Eric
>>
> this scheme is conservative, but please do note that retransmissions 
> are expected to be triggered by holes in ACK sequences, not timeout.
>
>> On 01/10/2018 08:10 AM, Giuseppe Carella wrote:
>>> Good morning|Eric,|
>>> |
>>> |
>>> |I tried to use this functionality changing the NFD code (I set the 
>>> boolean variable isEnalbe = true into the file lp-reliability.hpp).|
>>> |It seems that the retransmission becomes mandatory in this way 
>>> (every time the request is sent maxRetx + 1 times).
>>> |
>>> |Does it behave like that or the retransmission verifies only if the 
>>> ack is not received within RTO?
>>> |
>>> |Is it possible to customize the value of RTO?|
>>> |
>>> |
>>> |Thank you.|
>>> |Giuseppe.
>>> |
>>> ||
>>>
>>> 2018-01-04 20:18 GMT+01:00 Eric Newberry 
>>> <enewberry at email.arizona.edu <mailto:enewberry at email.arizona.edu>>:
>>>
>>>     Hi Giuseppe,
>>>
>>>     By default, the number of retransmissions is set to 3. The
>>>     option controlling this is in LpReliability::Options as maxRetx.
>>>     However, currently there is no way to set this option using nfdc
>>>     or any other management tool. Therefore, if you want to change
>>>     this, you would need to modify the NFD source code, recompile,
>>>     and reinstall. There are no options relating to the reliability
>>>     system in nfd.conf.
>>>
>>>     Eric
>>>
>>>
>>>     On 01/04/2018 02:10 AM, Giuseppe Carella wrote:
>>>>     Good morning Eric,
>>>>
>>>>     Thank you for your answer.
>>>>     I understood that it's possible to implement the retransmission
>>>>     by means of NDNLPv2, which is a protocol located upon the
>>>>     transport layer.
>>>>     So I have to set a maximum number of retransmissions, that's
>>>>     all (I hope).
>>>>     Is it enough modifying some properties into nfd.conf to choose
>>>>     the maximum number of retransmissions or I have to add some new
>>>>     APIs into applicative layer?
>>>>
>>>>     Thank you.
>>>>     Giuseppe.
>>>>
>>>>     2018-01-04 9:31 GMT+01:00 Eric Newberry
>>>>     <enewberry at email.arizona.edu <mailto:enewberry at email.arizona.edu>>:
>>>>
>>>>         Giuseppe,
>>>>
>>>>         NFD release 0.6.0 implements a link-layer reliability
>>>>         system as part of NDNLPv2 for unicast TCP, UDP, and
>>>>         Ethernet faces. It can be enabled by specifying
>>>>         "reliability on" when creating (or updating) a face with
>>>>         nfdc. In order for the system to function, it must be
>>>>         enabled on both ends of the link. The above command only
>>>>         enables it on one end.
>>>>
>>>>         Eric
>>>>
>>>>
>>>>         On 01/04/2018 01:24 AM, Giuseppe Carella wrote:
>>>>>         Good morning community,
>>>>>
>>>>>         is it possible to configure NFD in order to allow an UDP
>>>>>         communication with retransmission?
>>>>>         I know that I could use TCP, but for my purpose it's
>>>>>         necessary having UDP with retransmission.
>>>>>
>>>>>         Thank you.
>>>>>         Giuseppe.
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         Ndn-interest mailing list
>>>>>         Ndn-interest at lists.cs.ucla.edu
>>>>>         <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>>         http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>         <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         Ndn-interest mailing list
>>>>         Ndn-interest at lists.cs.ucla.edu
>>>>         <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>         http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>         <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20180111/198a6458/attachment.html>