[SCTP] a small correction in RFC 4960

[ash kat]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello:

 

'Path.Max.Retrans' parmeters specifies the maximum number of retransmission on a path before that path is marked down.

 

Section 8.3 of RFC says:

   When the value of this counter ""reaches"" the protocol parameter
   'Path.Max.Retrans', the endpoint should mark the corresponding
   destination address as inactive if it is not so marked, and may also
   optionally report to the upper layer the change of reachability of
   this destination address.

 

This will make the Heartbeat to be re-transmitted one count less then 'Path.Max.Retrans'

 

This is correct in Section 8.2 which says:

   When the value in the error counter ""exceeds"" the protocol parameter
   'Path.Max.Retrans' of that destination address, the endpoint should
   mark the destination transport address as inactive, and a
   notification SHOULD be sent to the upper layer.

 

So Section 8.3 should be modified and a path should be marked down when error count exceeds 'Path.Max.Retrans'.

 

Regards,

Ashwani Kathuria

---

Bring your gang together. Do your thing. Find your favourite Yahoo! Group.
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Brian F. G. Bidulock]

Ash,

Yes, I agree.

This looks worth submitting to the RFC Editor as an
Errata to RFC 4960.

--brian

Ash Kat wrote:               (Thu, 12 Jun 2008 10:06:45)
>
>    So Section 8.3 should be modified and a path should be marked
>    down when error count exceeds 'Path.Max.Retrans'.
>

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Michael Tüxen]

Hi Ash,

yes, that is a (at least by me) known issue... This comes up, when you
dimension your parameters to fullfil a given path error detection  
time...

I'm not sure if we should start again an errata ID...

Best regards
Michael

On Jun 12, 2008, at 6:36 AM, Ash Kat wrote:

> Hello:
>
> 'Path.Max.Retrans' parmeters specifies the maximum number of  
> retransmission on a path before that path is marked down.
>
> Section 8.3 of RFC says:
>    When the value of this counter ""reaches"" the protocol parameter
>    'Path.Max.Retrans', the endpoint should mark the corresponding
>    destination address as inactive if it is not so marked, and may  
> also
>    optionally report to the upper layer the change of reachability of
>    this destination address.
>
> This will make the Heartbeat to be re-transmitted one count less  
> then 'Path.Max.Retrans'
>
> This is correct in Section 8.2 which says:
>    When the value in the error counter ""exceeds"" the protocol  
> parameter
>    'Path.Max.Retrans' of that destination address, the endpoint should
>    mark the destination transport address as inactive, and a
>    notification SHOULD be sent to the upper layer.
>
> So Section 8.3 should be modified and a path should be marked down  
> when error count exceeds 'Path.Max.Retrans'.
>
> Regards,
> Ashwani Kathuria
>
> Bring your gang together. Do your thing. Find your favourite Yahoo!  
> Group.

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Lars Eggert-4]

Submit it as an errata to the RFC Editor for now.

Lars

On 2008-6-12, at 9:44, ext Michael Tüxen wrote:

> Hi Ash,
>
> yes, that is a (at least by me) known issue... This comes up, when you
> dimension your parameters to fullfil a given path error detection  
> time...
>
> I'm not sure if we should start again an errata ID...
>
> Best regards
> Michael
>
> On Jun 12, 2008, at 6:36 AM, Ash Kat wrote:
>
>> Hello:
>>
>> 'Path.Max.Retrans' parmeters specifies the maximum number of  
>> retransmission on a path before that path is marked down.
>>
>> Section 8.3 of RFC says:
>>   When the value of this counter ""reaches"" the protocol parameter
>>   'Path.Max.Retrans', the endpoint should mark the corresponding
>>   destination address as inactive if it is not so marked, and may  
>> also
>>   optionally report to the upper layer the change of reachability of
>>   this destination address.
>>
>> This will make the Heartbeat to be re-transmitted one count less  
>> then 'Path.Max.Retrans'
>>
>> This is correct in Section 8.2 which says:
>>   When the value in the error counter ""exceeds"" the protocol  
>> parameter
>>   'Path.Max.Retrans' of that destination address, the endpoint should
>>   mark the destination transport address as inactive, and a
>>   notification SHOULD be sent to the upper layer.
>>
>> So Section 8.3 should be modified and a path should be marked down  
>> when error count exceeds 'Path.Max.Retrans'.
>>
>> Regards,
>> Ashwani Kathuria
>>
>> Bring your gang together. Do your thing. Find your favourite Yahoo!  
>> Group.
>

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Michael Tüxen]

Hi Lars,

I have submitted an errata. The correct text should say in section 8.3:

    When the value of this counter exceeds the protocol parameter
    'Path.Max.Retrans', the endpoint should mark the corresponding
    destination address as inactive if it is not so marked, and may also
    optionally report to the upper layer the change of reachability of
    this destination address.

Best regards
Michael

On Jun 12, 2008, at 10:25 AM, Lars Eggert wrote:

> Submit it as an errata to the RFC Editor for now.
>
> Lars
>
> On 2008-6-12, at 9:44, ext Michael Tüxen wrote:
>
>> Hi Ash,
>>
>> yes, that is a (at least by me) known issue... This comes up, when  
>> you
>> dimension your parameters to fullfil a given path error detection  
>> time...
>>
>> I'm not sure if we should start again an errata ID...
>>
>> Best regards
>> Michael
>>
>> On Jun 12, 2008, at 6:36 AM, Ash Kat wrote:
>>
>>> Hello:
>>>
>>> 'Path.Max.Retrans' parmeters specifies the maximum number of  
>>> retransmission on a path before that path is marked down.
>>>
>>> Section 8.3 of RFC says:
>>>  When the value of this counter ""reaches"" the protocol parameter
>>>  'Path.Max.Retrans', the endpoint should mark the corresponding
>>>  destination address as inactive if it is not so marked, and may  
>>> also
>>>  optionally report to the upper layer the change of reachability of
>>>  this destination address.
>>>
>>> This will make the Heartbeat to be re-transmitted one count less  
>>> then 'Path.Max.Retrans'
>>>
>>> This is correct in Section 8.2 which says:
>>>  When the value in the error counter ""exceeds"" the protocol  
>>> parameter
>>>  'Path.Max.Retrans' of that destination address, the endpoint should
>>>  mark the destination transport address as inactive, and a
>>>  notification SHOULD be sent to the upper layer.
>>>
>>> So Section 8.3 should be modified and a path should be marked down  
>>> when error count exceeds 'Path.Max.Retrans'.
>>>
>>> Regards,
>>> Ashwani Kathuria
>>>
>>> Bring your gang together. Do your thing. Find your favourite  
>>> Yahoo! Group.
>>
>
>

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran