Subject: Re: [Lksctp-developers] Heartbeat management problems

From: Michael Tuexen <[email-masked]>
Date: Thu, 2 Sep 2004 13:27:43 +0200

Hi Sridhar,

I'm cross-posting this to the sctp-impl list...

I think the problems with the SCTP_PEER_ADDR_PARAMS are because
you are using the option for an endpoint and not for an association.

I think that these socket options do only apply to an association
and NOT to an endpoint. Therefore your problems with the semantic come
up. Currently the socketapi ID only describes these socket options
for associations. For associations the 'limitations' are acceptable,
I think, because a retransmission limit of 0 is not a good value.
You even do not know if the packet was really sent... and you are
declaring that path as being not working.

Best regards
Michael

On Sep 2, 2004, at 8:03 Uhr, Sridhar Samudrala wrote:

> On Wed, 1 Sep 2004, Jorge Hernandez-Herrero wrote:
>
>> Sridhar Samudrala wrote:
>>
>>> On Tue, 31 Aug 2004, Jorge Hernandez-Herrero wrote:
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> There are some problems with the heartbeat management logic:
>>>>
>>>> 1. For a live association, when a setsockopt(PEER_ADDR_PARAMS)
>>>>   is done to change the heartbeat interval or perform a
>>>>   manual heartbeat, the peer transport address affected
>>>>   will be declared unreachable after the first retransmission.
>>>>   The reason is that the sctp_setsockopt_peer_addr_params()
>>>>   does not protect against passing a
>>>>   peeraddrparam.spp_pathmaxrxt=0 which means no change according
>>>>   to the latest draft socket api rfc.  This is an easy fix
>>>>   by checking this condition in the above mentioned function.
>>>>
>>>>
>>>
>>> Is there any value in allowing the user to set max. no of 
>>> retransmissions to 0?
>>> But i am OK with following the draft and use 0 value to indicate no 
>>> change to
>>> the parameter.
>>>
>> I guess there could be some value in setting the path max. retrans. to
>> 0, if
>> somebody wants the path to be declared unreachable as soon as there
>> is a retransmission or heartbeat ack, I am not sure how
>> realistic/effective is to do this
>> in an Internet environment.  On the other hand, there should be some
>> convenient way to
>> specify no change on this parameter.   I am under the impression that
>> earlier versions
>> of the draft socket api did not have the 0 value to represent no 
>> change,
>> maybe that
>> is the reason the code does not check it.  I think we all agree that 
>> we
>> should be
>> compliant with the draft rfc.
>>
>> As a side issue, I think it is expected for a network programmer to
>> tweak the values inherited from the path.max.retrans (5) and the
>> assoc.max.retrans (10) on a per association basis, depending on the
>> number of paths
>> an association has set up and also monitor reachibility.
>> For example if there is only one path, there would be a long time
>> until the association is brought down (10) since the path went down 
>> (5)
>> with the
>> current default values.   Instead,  if there are for example 6 paths
>> established for an association,
>> the 10 value in the assoc.max.retrans could be a pretty low number to
>> bring the assoc down
>> since there could be several paths still up.
>> Just a thought ... Let me know if somebody has some other thoughts 
>> that
>> make me change my current thinking about this.
>
> Yes. These are simply default values as suggested in the RFC and i 
> agree
> with your thoughts.
>
>>>> 4. The sctp_setsockopt_peer_addr_params() when using INADDR_ANY
>>>>   should do endpoint changes when params.spp_pathmaxrxt is not 0.
>>>>   I also think that the params.spp_hbinterval should also be
>>>>   further checked.  So, if params.spp_hbinterval is 0 (manual 
>>>> heartbeat)
>>>>   I think EINVAL should be returned.  If params.spp_hbinterval is
>>>>
>>>>
>>> As per the draft, if params.spp_hbinterval is 0, it indicates 
>>> disable hearbeat,
>>> not manual heartbeat. For manual hearbeat, the value passed should be
>>> UINT32_MAX.
>>>
>> yes, my mistake, I still have the question, if somebody tries to do a
>> manual heartbeat on an endpoint, what should happen, what I am 
>> proposing
>> is to return EINVAL,  is there agreement here?
>
> YES.
>>
>>>
>>>>   "disable heartbeat" for an endpoint, should it mean that the
>>>>   heartbeat should be disabled when a new association is created?
>>>>   If this is the case, we may want to rethink the heartbeat logic,
>>>>   right now the heartbeat timer is kept alive even if the heartbeat
>>>>   was disabled by the user, the only thing that is disabled if
>>>>   the path management logic (incrementing the path and assoc 
>>>> counters).
>>>>
>>>>
>>>
>>> Yes. That seems to be a reasonable thing to do. 'disable hearbeat' 
>>> on an
>>> endpoint should disable heartbeats on all future associations on 
>>> that endpoint.
>>>
>>> Now that i think about these special values for spp_hbinterval, I 
>>> feel that
>>> there is severe limitation in this socket option API.
>>> There is no way for the user to indicate no change to the current 
>>> value of
>>> spp_hbinterval.
>>> Suppose if the user only wants to change the max. no. of 
>>> retransmissions
>>> using this socket option, he has to get and pass the current value of
>>> spp_hbinterval instead of simply passing 0.
>>>
>> I agree, this function seems overloaded.  Should we check with the
>> draft rfc authors  if they have already approached this issue and 
>> other
>> questions
>> in this email, such as what it means to do a manual heartbeat in
>> an endpoint?   Michael T. seems to keep up with this mailing list.
>
> It is definitely a good idea to raise these issues with the draft 
> authors.
> Could you post them on sctp-impl mailing list?
>
> Thanks
> Sridhar
>
>>>> 5. bug id 1008149 is also a problem with the heartbeat logic
>>>>   although the associated patch should fix it.
>>>>
>>>> Upon agreement, I can work in all these heartbeat related issues.
>>>>
>>>>
>>>
>>>
>>>
>>>> Thanks,
>>>>
>>>> Jorge
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Lksctp-developers mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 Sep 2004 11:47:59 -0400

Michael:

Hmm... well actually in the KAME/BSD/Mac version we
use SCTP_PEER_ADDR_PARAMS to be able to effect either
the endpoint OR an association..

1) If the assoc_id is set to 0 AND the socket address
~   is also 0, then we interpret the request as setting future
~   associations under this endpoint.

2) If the assoc_id and socket address leads us to a specific association
~   then we interpret the request to effect this association and the
~   specified destination.

3) If the assoc_id leads us to a TCB but the address does not exist then
~   we set a association level default (for max.rtr .. this would only
~   effect NEW addresses added via an asconf).

Now if at any time someone sets a '0' in the max rtr field we do
not change the current value.

R

Michael Tuexen wrote:
| Hi Sridhar,
|
| I'm cross-posting this to the sctp-impl list...
|
| I think the problems with the SCTP_PEER_ADDR_PARAMS are because
| you are using the option for an endpoint and not for an association.
|
| I think that these socket options do only apply to an association
| and NOT to an endpoint. Therefore your problems with the semantic come
| up. Currently the socketapi ID only describes these socket options
| for associations. For associations the 'limitations' are acceptable,
| I think, because a retransmission limit of 0 is not a good value.
| You even do not know if the packet was really sent... and you are
| declaring that path as being not working.
|
| Best regards
| Michael
|
|
| On Sep 2, 2004, at 8:03 Uhr, Sridhar Samudrala wrote:
|
|> On Wed, 1 Sep 2004, Jorge Hernandez-Herrero wrote:
|>
|>> Sridhar Samudrala wrote:
|>>
|>>> On Tue, 31 Aug 2004, Jorge Hernandez-Herrero wrote:
|>>>
|>>>
|>>>
|>>>> Hi,
|>>>>
|>>>> There are some problems with the heartbeat management logic:
|>>>>
|>>>> 1. For a live association, when a setsockopt(PEER_ADDR_PARAMS)
|>>>>   is done to change the heartbeat interval or perform a
|>>>>   manual heartbeat, the peer transport address affected
|>>>>   will be declared unreachable after the first retransmission.
|>>>>   The reason is that the sctp_setsockopt_peer_addr_params()
|>>>>   does not protect against passing a
|>>>>   peeraddrparam.spp_pathmaxrxt=0 which means no change according
|>>>>   to the latest draft socket api rfc.  This is an easy fix
|>>>>   by checking this condition in the above mentioned function.
|>>>>
|>>>>
|>>>
|>>> Is there any value in allowing the user to set max. no of
|>>> retransmissions to 0?
|>>> But i am OK with following the draft and use 0 value to indicate no
|>>> change to
|>>> the parameter.
|>>>
|>> I guess there could be some value in setting the path max. retrans. to
|>> 0, if
|>> somebody wants the path to be declared unreachable as soon as there
|>> is a retransmission or heartbeat ack, I am not sure how
|>> realistic/effective is to do this
|>> in an Internet environment.  On the other hand, there should be some
|>> convenient way to
|>> specify no change on this parameter.   I am under the impression that
|>> earlier versions
|>> of the draft socket api did not have the 0 value to represent no change,
|>> maybe that
|>> is the reason the code does not check it.  I think we all agree that we
|>> should be
|>> compliant with the draft rfc.
|>>
|>> As a side issue, I think it is expected for a network programmer to
|>> tweak the values inherited from the path.max.retrans (5) and the
|>> assoc.max.retrans (10) on a per association basis, depending on the
|>> number of paths
|>> an association has set up and also monitor reachibility.
|>> For example if there is only one path, there would be a long time
|>> until the association is brought down (10) since the path went down (5)
|>> with the
|>> current default values.   Instead,  if there are for example 6 paths
|>> established for an association,
|>> the 10 value in the assoc.max.retrans could be a pretty low number to
|>> bring the assoc down
|>> since there could be several paths still up.
|>> Just a thought ... Let me know if somebody has some other thoughts that
|>> make me change my current thinking about this.
|>
|>
|> Yes. These are simply default values as suggested in the RFC and i agree
|> with your thoughts.
|>
|>>>> 4. The sctp_setsockopt_peer_addr_params() when using INADDR_ANY
|>>>>   should do endpoint changes when params.spp_pathmaxrxt is not 0.
|>>>>   I also think that the params.spp_hbinterval should also be
|>>>>   further checked.  So, if params.spp_hbinterval is 0 (manual
|>>>> heartbeat)
|>>>>   I think EINVAL should be returned.  If params.spp_hbinterval is
|>>>>
|>>>>
|>>> As per the draft, if params.spp_hbinterval is 0, it indicates
|>>> disable hearbeat,
|>>> not manual heartbeat. For manual hearbeat, the value passed should be
|>>> UINT32_MAX.
|>>>
|>> yes, my mistake, I still have the question, if somebody tries to do a
|>> manual heartbeat on an endpoint, what should happen, what I am proposing
|>> is to return EINVAL,  is there agreement here?
|>
|>
|> YES.
|>
|>>
|>>>
|>>>>   "disable heartbeat" for an endpoint, should it mean that the
|>>>>   heartbeat should be disabled when a new association is created?
|>>>>   If this is the case, we may want to rethink the heartbeat logic,
|>>>>   right now the heartbeat timer is kept alive even if the heartbeat
|>>>>   was disabled by the user, the only thing that is disabled if
|>>>>   the path management logic (incrementing the path and assoc
|>>>> counters).
|>>>>
|>>>>
|>>>
|>>> Yes. That seems to be a reasonable thing to do. 'disable hearbeat'
|>>> on an
|>>> endpoint should disable heartbeats on all future associations on
|>>> that endpoint.
|>>>
|>>> Now that i think about these special values for spp_hbinterval, I
|>>> feel that
|>>> there is severe limitation in this socket option API.
|>>> There is no way for the user to indicate no change to the current
|>>> value of
|>>> spp_hbinterval.
|>>> Suppose if the user only wants to change the max. no. of
|>>> retransmissions
|>>> using this socket option, he has to get and pass the current value of
|>>> spp_hbinterval instead of simply passing 0.
|>>>
|>> I agree, this function seems overloaded.  Should we check with the
|>> draft rfc authors  if they have already approached this issue and other
|>> questions
|>> in this email, such as what it means to do a manual heartbeat in
|>> an endpoint?   Michael T. seems to keep up with this mailing list.
|>
|>
|> It is definitely a good idea to raise these issues with the draft
|> authors.
|> Could you post them on sctp-impl mailing list?
|>
|> Thanks
|> Sridhar
|>
|>>>> 5. bug id 1008149 is also a problem with the heartbeat logic
|>>>>   although the associated patch should fix it.
|>>>>
|>>>> Upon agreement, I can work in all these heartbeat related issues.
|>>>>
|>>>>
|>>>
|>>>
|>>>
|>>>> Thanks,
|>>>>
|>>>> Jorge
|>
|>
|>
|> -------------------------------------------------------
|> This SF.Net email is sponsored by BEA Weblogic Workshop
|> FREE Java Enterprise J2EE developer tools!
|> Get your free copy of BEA WebLogic Workshop 8.1 today.
|> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
|> _______________________________________________
|> Lksctp-developers mailing list
|> [email-masked]
|> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
|>
|
|

- --
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 2 Sep 2004 18:00:05 +0200

Randy,

that is fine, but we should document that in the socket-api.
So we have something for the next version in addition to
the AUTH and sctp_sendmsgx().

How can I set the max path retransmit for an end-point
without changing the HD.interval? I could use UINT_32_MAX.

But we should specify this.

Best regards
Michael

On Sep 2, 2004, at 17:47 Uhr, Randall Stewart wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael:
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFBN0CuncSkqt0HKWkRAvpjAJ9HBEA0TTu2ht3c+R5zCOoGdRREEACfRGyG
> OjKIoIhe8kkblnonu+3n6uE=
> =6hi9
> -----END PGP SIGNATURE-----

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 02 Sep 2004 10:24:48 -0700

> But we should specify this.

I believe this part is already clear in the draft.

Section 7.1.13:

     spp_hbinterval  - This contains the value of the heartbeat interval,
                       in milliseconds.  A value of 0, when modifying the
                       parameter, specifies that the heartbeat on this
                       address should be disabled. A value of UINT32_MAX
                       (4294967295), when modifying the parameter,
                       specifies that a heartbeat should be sent
                       immediately to the peer address, and the current
                       interval should remain unchanged.
     spp_pathmaxrxt  - This contains the maximum number of
                       retransmissions before this address shall be
                       considered unreachable. If a  value of zero
                       is present in this field then no changes are to
                       be made to this parameter.

-- 

						K. Poon.
						[email-masked]

---

From: Sridhar Samudrala <[email-masked]>
Date: Thu, 2 Sep 2004 10:27:19 -0700 (PDT)

> ~   associations under this endpoint.

In lksctp, we do the same.

> ~   then we interpret the request to effect this association and the

same here.

> ~   effect NEW addresses added via an asconf).

I guess this is the case where only when associd is specified and the peer
address is 0. We treat this an EINVAL as we don't maintain default parameters
for transports at association level. We maintain the defaults only at the
endpoint level.

> not change the current value.

spp_pathmaxrt is OK as it is not overloaded. What about spp_hbinterval?
As per the draft, a value of 0 indicates that the heartbeat is disabled on
this address.

Thanks
Sridhar

---

From: Sridhar Samudrala <[email-masked]>
Date: Thu, 2 Sep 2004 10:45:32 -0700 (PDT)

> the AUTH and sctp_sendmsgx().

what is sctp_sendmsgx()?  I guess it is to avoid calling sctp_connectx() and
allow bundling of DATA with COOKIE-ECHO.

> without changing the HD.interval? I could use UINT_32_MAX.

UINT32_MAX is already used to indicate manual heartbeat. If you meant
this as a special case when both associd and address are 0, i think it
becomes confusing.

What about the more common case. How can i set the max path retransmit
for a peer address without changing its hb interval?

Thanks
Sridhar

---

From: Sridhar Samudrala <[email-masked]>
Date: Thu, 2 Sep 2004 10:50:50 -0700 (PDT)

> I believe this part is already clear in the draft.

With UINT32_MAX, although the value is not changed, there is an important
side-effect of sending an immediate hearbeat.

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 Sep 2004 16:11:14 -0400

Sridhar:

Sridhar Samudrala wrote:
| On Thu, 2 Sep 2004, Michael Tuexen wrote:
|
|
|>Randy,
|>
|>that is fine, but we should document that in the socket-api.
|>So we have something for the next version in addition to
|>the AUTH and sctp_sendmsgx().
|
|
| what is sctp_sendmsgx()?  I guess it is to avoid calling
sctp_connectx() and
| allow bundling of DATA with COOKIE-ECHO.
|

I think (if I remember right) that is what it is... we
talked about this in Munester I think...

|
|>How can I set the max path retransmit for an end-point
|>without changing the HD.interval? I could use UINT_32_MAX.
|
|
| UINT32_MAX is already used to indicate manual heartbeat. If you meant
| this as a special case when both associd and address are 0, i think it
| becomes confusing.
|
| What about the more common case. How can i set the max path retransmit
| for a peer address without changing its hb interval?

This is an interesting point... the only way I can do it
with KAME is to set it to the UINT value (0xffffffff) which
would demand a HB and set the retransmit value.. the down side
is you would get a on demand HB ...

Maybe we need something else here... sigh

R
|
| Thanks
| Sridhar
|
|
|>But we should specify this.
|>
|>Best regards
|>Michael
|>
|>On Sep 2, 2004, at 17:47 Uhr, Randall Stewart wrote:
|>
|>
| Michael:
|
| Hmm... well actually in the KAME/BSD/Mac version we
| use SCTP_PEER_ADDR_PARAMS to be able to effect either
| the endpoint OR an association..
|
| 1) If the assoc_id is set to 0 AND the socket address
| ~   is also 0, then we interpret the request as setting future
| ~   associations under this endpoint.
|
| 2) If the assoc_id and socket address leads us to a specific
| association
| ~   then we interpret the request to effect this association and the
| ~   specified destination.
|
| 3) If the assoc_id leads us to a TCB but the address does not exist
| then
| ~   we set a association level default (for max.rtr .. this would only
| ~   effect NEW addresses added via an asconf).
|
|
| Now if at any time someone sets a '0' in the max rtr field we do
| not change the current value.
|
|
|
| R
|
|
| Michael Tuexen wrote:
| | Hi Sridhar,
| |
| | I'm cross-posting this to the sctp-impl list...
| |
| | I think the problems with the SCTP_PEER_ADDR_PARAMS are because
| | you are using the option for an endpoint and not for an association.
| |
| | I think that these socket options do only apply to an association
| | and NOT to an endpoint. Therefore your problems with the semantic
| come
| | up. Currently the socketapi ID only describes these socket options
| | for associations. For associations the 'limitations' are acceptable,
| | I think, because a retransmission limit of 0 is not a good value.
| | You even do not know if the packet was really sent... and you are
| | declaring that path as being not working.
| |
| | Best regards
| | Michael
| |
| |
| | On Sep 2, 2004, at 8:03 Uhr, Sridhar Samudrala wrote:
| |
| |> On Wed, 1 Sep 2004, Jorge Hernandez-Herrero wrote:
| |>
| |>> Sridhar Samudrala wrote:
| |>>
| |>>> On Tue, 31 Aug 2004, Jorge Hernandez-Herrero wrote:
| |>>>
| |>>>
| |>>>
| |>>>> Hi,
| |>>>>
| |>>>> There are some problems with the heartbeat management logic:
| |>>>>
| |>>>> 1. For a live association, when a setsockopt(PEER_ADDR_PARAMS)
| |>>>>   is done to change the heartbeat interval or perform a
| |>>>>   manual heartbeat, the peer transport address affected
| |>>>>   will be declared unreachable after the first retransmission.
| |>>>>   The reason is that the sctp_setsockopt_peer_addr_params()
| |>>>>   does not protect against passing a
| |>>>>   peeraddrparam.spp_pathmaxrxt=0 which means no change according
| |>>>>   to the latest draft socket api rfc.  This is an easy fix
| |>>>>   by checking this condition in the above mentioned function.
| |>>>>
| |>>>>
| |>>>
| |>>> Is there any value in allowing the user to set max. no of
| |>>> retransmissions to 0?
| |>>> But i am OK with following the draft and use 0 value to indicate
| no
| |>>> change to
| |>>> the parameter.
| |>>>
| |>> I guess there could be some value in setting the path max.
| retrans. to
| |>> 0, if
| |>> somebody wants the path to be declared unreachable as soon as there
| |>> is a retransmission or heartbeat ack, I am not sure how
| |>> realistic/effective is to do this
| |>> in an Internet environment.  On the other hand, there should be
| some
| |>> convenient way to
| |>> specify no change on this parameter.   I am under the impression
| that
| |>> earlier versions
| |>> of the draft socket api did not have the 0 value to represent no
| change,
| |>> maybe that
| |>> is the reason the code does not check it.  I think we all agree
| that we
| |>> should be
| |>> compliant with the draft rfc.
| |>>
| |>> As a side issue, I think it is expected for a network programmer to
| |>> tweak the values inherited from the path.max.retrans (5) and the
| |>> assoc.max.retrans (10) on a per association basis, depending on the
| |>> number of paths
| |>> an association has set up and also monitor reachibility.
| |>> For example if there is only one path, there would be a long time
| |>> until the association is brought down (10) since the path went
| down (5)
| |>> with the
| |>> current default values.   Instead,  if there are for example 6
| paths
| |>> established for an association,
| |>> the 10 value in the assoc.max.retrans could be a pretty low number
| to
| |>> bring the assoc down
| |>> since there could be several paths still up.
| |>> Just a thought ... Let me know if somebody has some other thoughts
| that
| |>> make me change my current thinking about this.
| |>
| |>
| |> Yes. These are simply default values as suggested in the RFC and i
| agree
| |> with your thoughts.
| |>
| |>>>> 4. The sctp_setsockopt_peer_addr_params() when using INADDR_ANY
| |>>>>   should do endpoint changes when params.spp_pathmaxrxt is not 0.
| |>>>>   I also think that the params.spp_hbinterval should also be
| |>>>>   further checked.  So, if params.spp_hbinterval is 0 (manual
| |>>>> heartbeat)
| |>>>>   I think EINVAL should be returned.  If params.spp_hbinterval is
| |>>>>
| |>>>>
| |>>> As per the draft, if params.spp_hbinterval is 0, it indicates
| |>>> disable hearbeat,
| |>>> not manual heartbeat. For manual hearbeat, the value passed
| should be
| |>>> UINT32_MAX.
| |>>>
| |>> yes, my mistake, I still have the question, if somebody tries to
| do a
| |>> manual heartbeat on an endpoint, what should happen, what I am
| proposing
| |>> is to return EINVAL,  is there agreement here?
| |>
| |>
| |> YES.
| |>
| |>>
| |>>>
| |>>>>   "disable heartbeat" for an endpoint, should it mean that the
| |>>>>   heartbeat should be disabled when a new association is created?
| |>>>>   If this is the case, we may want to rethink the heartbeat
| logic,
| |>>>>   right now the heartbeat timer is kept alive even if the
| heartbeat
| |>>>>   was disabled by the user, the only thing that is disabled if
| |>>>>   the path management logic (incrementing the path and assoc
| |>>>> counters).
| |>>>>
| |>>>>
| |>>>
| |>>> Yes. That seems to be a reasonable thing to do. 'disable hearbeat'
| |>>> on an
| |>>> endpoint should disable heartbeats on all future associations on
| |>>> that endpoint.
| |>>>
| |>>> Now that i think about these special values for spp_hbinterval, I
| |>>> feel that
| |>>> there is severe limitation in this socket option API.
| |>>> There is no way for the user to indicate no change to the current
| |>>> value of
| |>>> spp_hbinterval.
| |>>> Suppose if the user only wants to change the max. no. of
| |>>> retransmissions
| |>>> using this socket option, he has to get and pass the current
| value of
| |>>> spp_hbinterval instead of simply passing 0.
| |>>>
| |>> I agree, this function seems overloaded.  Should we check with the
| |>> draft rfc authors  if they have already approached this issue and
| other
| |>> questions
| |>> in this email, such as what it means to do a manual heartbeat in
| |>> an endpoint?   Michael T. seems to keep up with this mailing list.
| |>
| |>
| |> It is definitely a good idea to raise these issues with the draft
| |> authors.
| |> Could you post them on sctp-impl mailing list?
| |>
| |> Thanks
| |> Sridhar
| |>
| |>>>> 5. bug id 1008149 is also a problem with the heartbeat logic
| |>>>>   although the associated patch should fix it.
| |>>>>
| |>>>> Upon agreement, I can work in all these heartbeat related issues.
| |>>>>
| |>>>>
| |>>>
| |>>>
| |>>>
| |>>>> Thanks,
| |>>>>
| |>>>> Jorge
| |>
| |>
| |>
| |> -------------------------------------------------------
| |> This SF.Net email is sponsored by BEA Weblogic Workshop
| |> FREE Java Enterprise J2EE developer tools!
| |> Get your free copy of BEA WebLogic Workshop 8.1 today.
| |> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
| |> _______________________________________________
| |> Lksctp-developers mailing list
| |> [email-masked]
| |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
| |>
| |
| |
|
|
| --
| Randall Stewart
| ITD
| 803-345-0369 <or> 815-342-5222
|>
|>

- --
Randall Stewart
ITD

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 Sep 2004 16:12:02 -0400

Michael Tuexen wrote:
| Kacheong,
|
| what I ment was the following:
|
| The second paragraph of 7. reads:
|
|    For the one-to-many style sockets, an sctp_assoc_t structure
|    (association ID) is used to identify the the association instance
|    that the operation affects.  So it must be set when using this style.
|
| The wording in the hole section always talks about associations, not
| end-points.
|
| My point is, that we should include a statement that you can apply
| socket options also to end-points and how you do this.
| Or have I overlooked the text which describes that?
|

Ok.. that sounds good..

R
| Best regards
| Michael
|
| On Sep 2, 2004, at 19:24 Uhr, Kacheong Poon wrote:
|
|> Michael Tuexen wrote:
|>
|>> How can I set the max path retransmit for an end-point
|>> without changing the HD.interval? I could use UINT_32_MAX.
|>> But we should specify this.
|>
|>
|> I believe this part is already clear in the draft.
|>
|> Section 7.1.13:
|>
|>     spp_hbinterval  - This contains the value of the heartbeat interval,
|>                       in milliseconds.  A value of 0, when modifying the
|>                       parameter, specifies that the heartbeat on this
|>                       address should be disabled. A value of UINT32_MAX
|>                       (4294967295), when modifying the parameter,
|>                       specifies that a heartbeat should be sent
|>                       immediately to the peer address, and the current
|>                       interval should remain unchanged.
|>     spp_pathmaxrxt  - This contains the maximum number of
|>                       retransmissions before this address shall be
|>                       considered unreachable. If a  value of zero
|>                       is present in this field then no changes are to
|>                       be made to this parameter.
|>
|>
|>
|> --
|>
|>                         K. Poon.
|>                         [email-masked]
|>
|
|

- --
Randall Stewart
ITD

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 Sep 2004 16:13:54 -0400

Michael Tuexen wrote:
| Sridhar,
|
| see my comments below.
|
| Best regards
| Michael
|
| On Sep 2, 2004, at 19:45 Uhr, Sridhar Samudrala wrote:
|
|> On Thu, 2 Sep 2004, Michael Tuexen wrote:
|>
|>> Randy,
|>>
|>> that is fine, but we should document that in the socket-api.
|>> So we have something for the next version in addition to
|>> the AUTH and sctp_sendmsgx().
|>
|>
|> what is sctp_sendmsgx()?  I guess it is to avoid calling
|> sctp_connectx() and
|> allow bundling of DATA with COOKIE-ECHO.
|>
| The point is that you want use implicit association setup and make
| use of multiple IP-addresses of the peer at the same time.
| It is similar to connectx() and sctp_sendmsg().
|
|>>
|>> How can I set the max path retransmit for an end-point
|>> without changing the HD.interval? I could use UINT_32_MAX.
|>
|>
|> UINT32_MAX is already used to indicate manual heartbeat. If you meant
|> this as a special case when both associd and address are 0, i think it
|> becomes confusing.
|
| Requesting a manual heartbeat for an end-point does not make sense. So
| you could use that.
|
|>
|> What about the more common case. How can i set the max path retransmit
|> for a peer address without changing its hb interval?
|
| Just request a manual HB. It does not hurt, does it?

Good point... you just get a extra HB every time
you set the max.rtt on a specific address... or
you could always do a get() of the parameter
and then set the hb.interval back to the same
thing it was..

R
|
|>

- --
Randall Stewart
ITD

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 Sep 2004 16:06:19 -0400

Michael Tuexen wrote:
| Randy,
|
| that is fine, but we should document that in the socket-api.
| So we have something for the next version in addition to
| the AUTH and sctp_sendmsgx().
|
| How can I set the max path retransmit for an end-point
| without changing the HD.interval? I could use UINT_32_MAX.

I think you mean HB.interval..

For that, you set HB.interval the same as the on-demand
hb (UINT_32_MAX) like you guessed :->

R
|
| But we should specify this.
|
| Best regards
| Michael
|
| On Sep 2, 2004, at 17:47 Uhr, Randall Stewart wrote:
|
| Michael:
|
| 2) If the assoc_id and socket address leads us to a specific association
| 3) If the assoc_id leads us to a TCB but the address does not exist then
| | and NOT to an endpoint. Therefore your problems with the semantic come
| |>>> But i am OK with following the draft and use 0 value to indicate no
| |>> in an Internet environment.  On the other hand, there should be some
| |>> specify no change on this parameter.   I am under the impression that
| |>> current default values.   Instead,  if there are for example 6 paths
| |>> the 10 value in the assoc.max.retrans could be a pretty low number to
| |>> yes, my mistake, I still have the question, if somebody tries to do a
| |>>>>   If this is the case, we may want to rethink the heartbeat logic,
| |>>>>   right now the heartbeat timer is kept alive even if the heartbeat

- --
Randall Stewart
ITD

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 2 Sep 2004 21:50:17 +0200

Kacheong,

what I ment was the following:

The second paragraph of 7. reads:

    For the one-to-many style sockets, an sctp_assoc_t structure
    (association ID) is used to identify the the association instance
    that the operation affects.  So it must be set when using this style.

The wording in the hole section always talks about associations, not
end-points.

My point is, that we should include a statement that you can apply
socket options also to end-points and how you do this.
Or have I overlooked the text which describes that?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 2 Sep 2004 21:54:25 +0200

Sridhar,

see my comments below.

Best regards
Michael

> allow bundling of DATA with COOKIE-ECHO.
The point is that you want use implicit association setup and make
use of multiple IP-addresses of the peer at the same time.
It is similar to connectx() and sctp_sendmsg().
> this as a special case when both associd and address are 0, i think it
Requesting a manual heartbeat for an end-point does not make sense. So
you could use that.
> for a peer address without changing its hb interval?
Just request a manual HB. It does not hurt, does it?
>>> |>> the 10 value in the assoc.max.retrans could be a pretty low 
>>> number
>>> to
>>> |>> bring the assoc down
>>> |>> Just a thought ... Let me know if somebody has some other 
>>> thoughts
>>> that