From mart_mugabe@cotas.net Wed Sep 1 09:59:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09894; Wed, 1 Sep 2004 09:38:57 -0400 (EDT) Received: from mail.cotas.net ([200.58.160.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Qbk-0001cV-AP; Wed, 01 Sep 2004 04:36:44 -0400 Received: from cotas.net ([127.0.0.1]) by mail.cotas.net (Netscape Messaging Server 4.15) with ESMTP id I3CU4900.500; Wed, 1 Sep 2004 12:55:21 +0400 From: "Martin Mugabe" Message-ID: <68345efb.5efb6834@cotas.net> Date: Wed, 01 Sep 2004 01:55:18 -0700 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: ENGINEER MARTIN MUGABE X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit FROM THE DESK OF MARTIN MUGABE TEL +871 763427855 FAX +871 763427856 EMAIL :mart_mugabe@jippii.fi DEAR SIR THIS LETTER MAY COME TO YOU AS A SURPRISE BUT IT IS INTENDED TO BRING GOOD TIDINGS TO YOU AND YOUR BUSINESS. IT WILL BE PROPER FOR ME TO INTRODUCE MYSELF BEFORE STATING MY REASON FOR CONTACTING YOU. I AM ENGINEER MARTIN MUGABE AND HEAD OF THE SAFE KEEPING DEPARTMENT OF THE REPUBLIC OF ZIMBABWE SECURITY AND MINT COMPANY OWNED BY THE GOVERNMENT, I AM 57 YEARS OLD AND MARRIED WITH THREE CHILDREN. MY MAIN REASON OF CONTACTING YOU IS IN RESPECT OF TWO CONSIGNMENTS IN MY CUSTODY DEPOSITED FOR SAFE KEEPING BY ONE MR. CRAIG MORTON AN AMERICAN WHO ACQUIRED OUR CITIZENSHIP AND WAS ENGAGED IN DIAMOND AND GOLD EXPORT. HOWEVER, MR. CRAIG HAS SINCE PASSED AWAY SIX YEARS AGO FROM CARDIAC ARREST AND HAS SINCE BEEN BURIED HERE IN ZIMBABWE (MAY HIS SOUL REST IN PEACE) AND NO BODY CAME FORWARD AS NEXT OF KIN OR BENEFICIARY TO CLAIM THE CONSIGNMENTS WHICH PROMPTED ME TO SCAN THE CONSIGNMENT WHEN THE OPPORTUNITY AROSE AND DISCOVERED THAT IT CONTAINS CASH WHICH VOLUME MIGHT BE OVER US $ 15, 000, 000, 00. BUT THE CONSIGNMENT WAS TAGGED TO CONTAIN PRECIOUS ORNAMENTS. NOW THE GOOD OF THE MATTER IS THAT I CAN MAKE ARRANGEMENT FROM PROBATE, ESTABLISHING YOU AS NEXT OF KIN CUM BENEFICIARY OF MR. CRAIG MORTON AND THE ALSO MAKE AN ARRANGEMENT FOR A DIPLOMAT THAT WILL GIVE AUTHORITY ALONG WITH THE LETTER OF PROBATE TO COLLECT THE CONSIGNMENT AND DELIVER SAME TO YOU WITH DIPLOMATIC IMMUNITY SO THAT THE CONSIGNMENT WILL NOT BE TAMPERED WITH OR OPENED WHILE IN TRANSIT, AND THIS DIPLOMAT WILL ALSO NOT BE IN THE KNOW THAT THESE CONSIGNMENTS CONTAINS MONEY SINCE IT IS TAGGED TO CONTAIN PRECIOUS ORNAMENTS. THIS ARRANGEMENT IS 100% SAFE TODAY, TOMORROW AND IN THE FUTURE BECAUSE IT WILL BE THOROUGH SINCE THEY ARE IN MY CUSTODY FOR RELEASE TO THE DIPLOMAT WITH PROBATE BACKING AND COUPLED WITH THE FACT THAT MR. MORTON DIED INTESTATE WITHOUT NEXT OF KIN. IF MY PROPOSAL IS ACCEPTED BY YOU, THEN UPON RECEIPT OF THE CONSIGNMENT, 30% WILL ACCRUE TO YOU WHILE 50% WILL ACCRUE TO ME AND THE BALANCE 20% WILL BE USED IN A LATTER DATE TO OPEN AN INTERNATIONAL FOUNDATION NAMED AFTER MORTON FOR AFRICAN CHILDREN WITH DISABILITY AND HEALTH PROBLEMS. I WILL ALSO WANT YOU TO ASSIST ME IN INVESTING MY SHARE OF THE MONEY INTO REAL ESTATE FOR MY RETIREMENT PLAN SINCE I AM POORLY PAID IN MY 26 YEARS OF WORKING WITH THIS ESTABLISHMENT AND PROHIBITED FROM HAVING FOREIGN ACCOUNTS OR INVESTMENT SO MY INVESTMENT WILL BE UNDER YOUR CONTROL AND CARE AND WE CAN SHARE THE PROFITS. I AWAIT YOUR RESPONSE THROUGH MY CONTACT ABOVE AND IF HOWEVER YOU ARE NOT INTERESTED, I PLEAD WITH YOU IN THE NAME OF GOD TO DESTROY THIS MAIL AS THE INFORMATION IS PRIVILEGED. REMAIN BLESSED, ENGINEER MARTIN MUGABE. From Admin@computeradmin.org Wed Sep 1 22:35:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08305; Wed, 1 Sep 2004 22:35:32 -0400 (EDT) Received: from [219.237.81.76] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2hU4-00028o-C5; Wed, 01 Sep 2004 22:37:59 -0400 Received: from xi.pjpftel.com ([132.123.86.53]) by 132.151.6.1 id <9141281-87062> for ; Wed, 01 Sep 2004 22:39:50 -0500 Message-ID: <4f71x7$27df$g4x68@scm2p6> From: "Administrator" To: ipr@ietf.org Subject: Attention All Nonprofit Organizations: Members and Staff Date: Wed, 01 Sep 04 22:39:50 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="39E81.._D_A" X-Spam-Score: 30.7 (++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --39E81.._D_A Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Friday, September 3, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Friday, September 3, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, September 3, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, September 3, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, September 3, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --39E81.._D_A-- From Michael.Tuexen@micmac.franken.de Thu Sep 2 08:40:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28908 for ; Thu, 2 Sep 2004 08:40:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2qvf-00080A-Mk for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 08:43:04 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2004 05:12:58 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i82CAiih013083; Thu, 2 Sep 2004 05:10:45 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82C9EZ4014128 for sctp-impl-filtered; Thu, 2 Sep 2004 05:09:16 -0700 (PDT) Message-Id: <200409021209.i82C9EZ4014128@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094126954-14126-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Sridhar Samudrala From: Michael Tuexen Cc: Jorge Hernandez-Herrero , "'lksctp-developers@lists.sourceforge.net'" , sctp-impl@external.cisco.com X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Thu, 2 Sep 2004 13:27:43 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc This is a multi-part message in MIME format... ------------=_1094126954-14126-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary 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 > Lksctp-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lksctp-developers > ------------=_1094126954-14126-0-- From rrs@cisco.com Thu Sep 2 11:50:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13838 for ; Thu, 2 Sep 2004 11:50:35 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2tta-0006t7-JC for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 11:53:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 08:58:11 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i82FnMij014011; Thu, 2 Sep 2004 08:49:25 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82FmtZ4016991 for sctp-impl-filtered; Thu, 2 Sep 2004 08:48:58 -0700 (PDT) Message-Id: <200409021548.i82FmtZ4016991@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094140135-16989-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Michael Tuexen From: Randall Stewart Cc: Sridhar Samudrala , Jorge Hernandez-Herrero , "'lksctp-developers@lists.sourceforge.net'" , sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Thu, 02 Sep 2004 11:47:59 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 This is a multi-part message in MIME format... ------------=_1094140135-16989-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 |> Lksctp-developers@lists.sourceforge.net |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers |> | | - -- Randall Stewart ITD 803-345-0369 815-342-5222 -----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----- ------------=_1094140135-16989-0-- From Michael.Tuexen@micmac.franken.de Thu Sep 2 12:52:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17768 for ; Thu, 2 Sep 2004 12:52:38 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2urf-0003Y8-Mm for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 12:55:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Sep 2004 09:58:47 -0700 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i82Gpg2l027183; Thu, 2 Sep 2004 09:51:43 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82GpJZ4017795 for sctp-impl-filtered; Thu, 2 Sep 2004 09:51:21 -0700 (PDT) Message-Id: <200409021651.i82GpJZ4017795@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094143879-17793-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Randall Stewart From: Michael Tuexen Cc: Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, Sridhar Samudrala , "'lksctp-developers@lists.sourceforge.net'" X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Thu, 2 Sep 2004 18:00:05 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 This is a multi-part message in MIME format... ------------=_1094143879-17793-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary 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: > > 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 > |> Lksctp-developers@lists.sourceforge.net > |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers > |> > | > | > > > - -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > -----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----- ------------=_1094143879-17793-0-- From kacheong.poon@sun.com Thu Sep 2 13:28:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21240 for ; Thu, 2 Sep 2004 13:28:44 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2vQY-0006fX-FB for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 13:31:16 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 02 Sep 2004 10:28:55 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i82HRYQH002053; Thu, 2 Sep 2004 10:27:34 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82HRQZ4018259 for sctp-impl-filtered; Thu, 2 Sep 2004 10:27:28 -0700 (PDT) Message-Id: <200409021727.i82HRQZ4018259@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094146045-18257-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Michael Tuexen From: Kacheong Poon Cc: Randall Stewart , Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, Sridhar Samudrala , "'lksctp-developers@lists.sourceforge.net'" X-Nails-Approved: kacheong.poon@sun.com Date: Thu, 02 Sep 2004 10:24:48 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format... ------------=_1094146045-18257-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary 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. kacheong.poon@sun.com ------------=_1094146045-18257-0-- From sri@us.ibm.com Thu Sep 2 13:38:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22006 for ; Thu, 2 Sep 2004 13:38:26 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2vZy-0007Nc-DS for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 13:40:59 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 Sep 2004 10:38:38 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i82HbQmT004484; Thu, 2 Sep 2004 10:37:26 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82HbIZ4018391 for sctp-impl-filtered; Thu, 2 Sep 2004 10:37:20 -0700 (PDT) Message-Id: <200409021737.i82HbIZ4018391@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094146638-18389-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Randall Stewart From: Sridhar Samudrala Cc: Michael Tuexen , Jorge Hernandez-Herrero , "'lksctp-developers@lists.sourceforge.net'" , sctp-impl@external.cisco.com X-Nails-Approved: sri@us.ibm.com Date: Thu, 2 Sep 2004 10:27:19 -0700 (PDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d This is a multi-part message in MIME format... ------------=_1094146638-18389-0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary On Thu, 2 Sep 2004, Randall Stewart wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. In lksctp, we do the same. > > 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. same here. > > 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). 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. > Now if at any time someone sets a '0' in the max rtr field we do > 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 > > > 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 > |> Lksctp-developers@lists.sourceforge.net > |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers > |> > | > | > > > - -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > -----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----- > > > ------------------------------------------------------- > 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 > Lksctp-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lksctp-developers > ------------=_1094146638-18389-0-- From sri@us.ibm.com Thu Sep 2 13:59:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24016 for ; Thu, 2 Sep 2004 13:59:59 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2vuq-0000ef-9c for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 14:02:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 11:04:19 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i82Htk2l009233; Thu, 2 Sep 2004 10:55:47 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82HtWZ4018631 for sctp-impl-filtered; Thu, 2 Sep 2004 10:55:34 -0700 (PDT) Message-Id: <200409021755.i82HtWZ4018631@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094147732-18629-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Michael Tuexen From: Sridhar Samudrala Cc: Randall Stewart , Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, "'lksctp-developers@lists.sourceforge.net'" X-Nails-Approved: sri@us.ibm.com Date: Thu, 2 Sep 2004 10:45:32 -0700 (PDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 This is a multi-part message in MIME format... ------------=_1094147732-18629-0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary 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. > > 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? Thanks Sridhar > > 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: > > > > 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 > > |> Lksctp-developers@lists.sourceforge.net > > |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers > > |> > > | > > | > > > > > > - -- > > Randall Stewart > > ITD > > 803-345-0369 815-342-5222 > > -----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----- > > ------------=_1094147732-18629-0-- From sri@us.ibm.com Thu Sep 2 15:46:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01760 for ; Thu, 2 Sep 2004 15:46:30 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xZv-0000VF-Ne for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 15:49:05 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Sep 2004 12:52:39 -0700 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i82JjWRL003106; Thu, 2 Sep 2004 12:45:33 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82Jj6Z4020010 for sctp-impl-filtered; Thu, 2 Sep 2004 12:45:08 -0700 (PDT) Message-Id: <200409021945.i82Jj6Z4020010@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094154306-20008-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Kacheong Poon From: Sridhar Samudrala Cc: Michael Tuexen , Randall Stewart , Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, "'lksctp-developers@lists.sourceforge.net'" X-Nails-Approved: sri@us.ibm.com Date: Thu, 2 Sep 2004 10:50:50 -0700 (PDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format... ------------=_1094154306-20008-0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary On Thu, 2 Sep 2004, 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. With UINT32_MAX, although the value is not changed, there is an important side-effect of sending an immediate hearbeat. > > 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. > kacheong.poon@sun.com > > ------------=_1094154306-20008-0-- From rrs@cisco.com Thu Sep 2 16:14:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03500 for ; Thu, 2 Sep 2004 16:14:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2y1K-0002ko-EM for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 16:17:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 13:22:34 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i82KDuih000563; Thu, 2 Sep 2004 13:13:56 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82KDjZ4020379 for sctp-impl-filtered; Thu, 2 Sep 2004 13:13:47 -0700 (PDT) Message-Id: <200409022013.i82KDjZ4020379@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094156024-20371-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Sridhar Samudrala From: Randall Stewart Cc: Michael Tuexen , Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, "'lksctp-developers@lists.sourceforge.net'" X-Nails-Approved: rrs@cisco.com Date: Thu, 02 Sep 2004 16:11:14 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b This is a multi-part message in MIME format... ------------=_1094156024-20371-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 | |> Lksctp-developers@lists.sourceforge.net | |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers | |> | | | | | | | -- | Randall Stewart | ITD | 803-345-0369 815-342-5222 |> |> - -- Randall Stewart ITD 803-345-0369 815-342-5222 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBN35hncSkqt0HKWkRAk6rAJ9LT6H3H01bUFOo00MTf1/7ewScBACeO3gp TcTjwToCoDJdnUQADZ5zhM4= =Lzb1 -----END PGP SIGNATURE----- ------------=_1094156024-20371-0-- From rrs@cisco.com Thu Sep 2 16:16:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03615 for ; Thu, 2 Sep 2004 16:16:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2y2V-0002xv-Qk for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 16:18:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 13:23:47 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i82KFARL004723; Thu, 2 Sep 2004 13:15:10 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82KF5Z4020400 for sctp-impl-filtered; Thu, 2 Sep 2004 13:15:07 -0700 (PDT) Message-Id: <200409022015.i82KF5Z4020400@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094156105-20398-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Michael Tuexen From: Randall Stewart Cc: Kacheong Poon , sctp-impl@external.cisco.com, "'lksctp-developers@lists.sourceforge.net'" , Jorge Hernandez-Herrero , Sridhar Samudrala X-Nails-Approved: rrs@cisco.com Date: Thu, 02 Sep 2004 16:12:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 This is a multi-part message in MIME format... ------------=_1094156105-20398-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. |> kacheong.poon@sun.com |> | | - -- Randall Stewart ITD 803-345-0369 815-342-5222 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBN36SncSkqt0HKWkRAuOKAJ9l0B3zXjCHizh+eeXzQFK+iZ3vYACeJnOL B+JQwqfhQ2lkfZGh3o8VfCM= =YlW9 -----END PGP SIGNATURE----- ------------=_1094156105-20398-0-- From rrs@cisco.com Thu Sep 2 16:16:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03638 for ; Thu, 2 Sep 2004 16:16:04 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2y2Y-0002xv-Iz for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 16:18:39 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 13:24:05 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i82KFRRL004888; Thu, 2 Sep 2004 13:15:27 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82KFRZ4020420 for sctp-impl-filtered; Thu, 2 Sep 2004 13:15:29 -0700 (PDT) Message-Id: <200409022015.i82KFRZ4020420@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094156127-20418-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Michael Tuexen From: Randall Stewart Cc: Sridhar Samudrala , Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, "'lksctp-developers@lists.sourceforge.net'" X-Nails-Approved: rrs@cisco.com Date: Thu, 02 Sep 2004 16:13:54 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format... ------------=_1094156127-20418-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 803-345-0369 815-342-5222 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBN38CncSkqt0HKWkRAsj+AJ9y1OA6U/9113MRhhtLft8OelMtnQCfcJ50 8LiV4ssDfETuvNzBz7L/Ebc= =w3O0 -----END PGP SIGNATURE----- ------------=_1094156127-20418-0-- From rrs@cisco.com Thu Sep 2 16:16:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03683 for ; Thu, 2 Sep 2004 16:16:26 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2y2t-0002yP-FF for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 16:19:01 -0400 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i82KFQmT000600; Thu, 2 Sep 2004 13:15:27 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82KFJZ4020413 for sctp-impl-filtered; Thu, 2 Sep 2004 13:15:21 -0700 (PDT) Message-Id: <200409022015.i82KFJZ4020413@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094156119-20411-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Michael Tuexen From: Randall Stewart Cc: Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, Sridhar Samudrala , "'lksctp-developers@lists.sourceforge.net'" X-Nails-Approved: rrs@cisco.com Date: Thu, 02 Sep 2004 16:06:19 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 This is a multi-part message in MIME format... ------------=_1094156119-20411-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: | | 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 | |> Lksctp-developers@lists.sourceforge.net | |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers | |> | | | | | | | -- | Randall Stewart | ITD | 803-345-0369 815-342-5222 - -- Randall Stewart ITD 803-345-0369 815-342-5222 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBN306ncSkqt0HKWkRAljSAJ956cRdLPJ6V0/2xQ7EF8N6COb8QwCcDxtx dDK0CnYPri4/my/HATihs38= =6XIX -----END PGP SIGNATURE----- ------------=_1094156119-20411-0-- From Michael.Tuexen@micmac.franken.de Thu Sep 2 16:31:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05906 for ; Thu, 2 Sep 2004 16:31:19 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yHJ-0004Xt-VC for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 16:33:55 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 Sep 2004 13:31:34 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i82KUQmT024033; Thu, 2 Sep 2004 13:30:27 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82KUFZ4020614 for sctp-impl-filtered; Thu, 2 Sep 2004 13:30:17 -0700 (PDT) Message-Id: <200409022030.i82KUFZ4020614@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094157015-20612-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Kacheong Poon From: Michael Tuexen Cc: sctp-impl@external.cisco.com, "'lksctp-developers@lists.sourceforge.net'" , Randall Stewart , Jorge Hernandez-Herrero , Sridhar Samudrala X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Thu, 2 Sep 2004 21:50:17 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format... ------------=_1094157015-20612-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary 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 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. > kacheong.poon@sun.com > ------------=_1094157015-20612-0-- From Michael.Tuexen@micmac.franken.de Thu Sep 2 16:35:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06556 for ; Thu, 2 Sep 2004 16:35:12 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yL3-0004v7-Cp for sctp-impl-archive@ietf.org; Thu, 02 Sep 2004 16:37:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2004 13:36:23 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i82KYQRL019521; Thu, 2 Sep 2004 13:34:26 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i82KYJZ4020669 for sctp-impl-filtered; Thu, 2 Sep 2004 13:34:21 -0700 (PDT) Message-Id: <200409022034.i82KYJZ4020669@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094157259-20667-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [Lksctp-developers] Heartbeat management problems List-Id: sctp-impl To: Sridhar Samudrala From: Michael Tuexen Cc: Jorge Hernandez-Herrero , sctp-impl@external.cisco.com, "'lksctp-developers@lists.sourceforge.net'" , Randall Stewart X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Thu, 2 Sep 2004 21:54:25 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 This is a multi-part message in MIME format... ------------=_1094157259-20667-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary 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? > > Thanks > Sridhar > >> >> 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: >>> >>> 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 >>> |> Lksctp-developers@lists.sourceforge.net >>> |> https://lists.sourceforge.net/lists/listinfo/lksctp-developers >>> |> >>> | >>> | >>> >>> >>> - -- >>> Randall Stewart >>> ITD >>> 803-345-0369 815-342-5222 >>> -----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----- >> >> > ------------=_1094157259-20667-0-- From torbjorn.andersson@kau.se Mon Sep 6 05:53:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18454 for ; Mon, 6 Sep 2004 05:53:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4GFI-000390-MM for sctp-impl-archive@ietf.org; Mon, 06 Sep 2004 05:57:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Sep 2004 03:02:16 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i869qq9N002747; Mon, 6 Sep 2004 02:52:53 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i869q8Z4026847 for sctp-impl-filtered; Mon, 6 Sep 2004 02:52:10 -0700 (PDT) Message-Id: <200409060952.i869q8Z4026847@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094464328-26845-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Installation question List-Id: sctp-impl To: From: =?iso-8859-1?Q?Torbj=F6rn_Andersson?= X-Nails-Approved: torbjorn.andersson@kau.se Date: Mon, 6 Sep 2004 11:53:14 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format... ------------=_1094464328-26845-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Hi all. I'm try to patch up to days (2004-09-06) kame snap with patch 21 Sadly I'm having problems with applying the patch and then compile the kernel. I have tried with both freebsd 4.10 and 5.2.1 with a similar result. My question is, which snap is recommended to use? I'm also uncertain of if I'm applying the patch in the right way. Is "patch < patch04xxxx" enough if pwd says "/usr/src/kame" /Thanks -------------------------------------------------------------- | Torbjörn Andersson phone: +46 54 700 11 61 | Computer Science fax: +46 54 700 18 28 | Karlstad University URL: http://www.cs.kau.se/~tora --------------------------------------------------------------- ------------=_1094464328-26845-0-- From rrs@cisco.com Tue Sep 7 12:13:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04361 for ; Tue, 7 Sep 2004 12:13:15 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4ieL-0007By-G7 for sctp-impl-archive@ietf.org; Tue, 07 Sep 2004 12:16:53 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 07 Sep 2004 09:11:49 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i87GAjd1029213; Tue, 7 Sep 2004 09:10:46 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i87G9UZ4020640 for sctp-impl-filtered; Tue, 7 Sep 2004 09:09:32 -0700 (PDT) Message-Id: <200409071609.i87G9UZ4020640@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094573370-20638-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Installation question List-Id: sctp-impl To: =?ISO-8859-1?Q?Torbj=F6rn_Andersson?= From: Randall Stewart Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Tue, 07 Sep 2004 12:08:09 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format... ------------=_1094573370-20638-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Torbjörn: If you are using the current snap (from yesterday) then I don't think you need to apply any patch.. Itojun has managed to get all of patch 21 incorporated into the current snap... :-> I do have a few more bugs that we have found (in particular Michael Tuexen has found a SCTP_PEER_ADDR_PARAMS with the TCP model.. and of course we have some new changes for the APPLE port that Michael has been working on).. I will try to get a "current" patch up for the lastest issues found and resolved. But as long as you are not using that particiular socketopt with the TCP model you should be fine with generic KAME :-D R Torbjörn Andersson wrote: > Hi all. > > I'm try to patch up to days (2004-09-06) kame snap with patch 21 > > Sadly I'm having problems with applying the patch and then compile the > kernel. I have tried with both freebsd 4.10 and 5.2.1 with a similar > result. > > My question is, which snap is recommended to use? > > I'm also uncertain of if I'm applying the patch in the right way. Is > "patch < patch04xxxx" enough if pwd says "/usr/src/kame" > > /Thanks > -------------------------------------------------------------- > | Torbjörn Andersson phone: +46 54 700 11 61 > | Computer Science fax: +46 54 700 18 28 > | Karlstad University URL: http://www.cs.kau.se/~tora > --------------------------------------------------------------- > > > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1094573370-20638-0-- From torbjorn.andersson@kau.se Wed Sep 8 03:40:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17397 for ; Wed, 8 Sep 2004 03:40:22 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4x7f-0002Ma-Ql for sctp-impl-archive@ietf.org; Wed, 08 Sep 2004 03:44:08 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2004 00:39:51 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i887d9d1020690; Wed, 8 Sep 2004 00:39:10 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i887cNZ4002534 for sctp-impl-filtered; Wed, 8 Sep 2004 00:38:25 -0700 (PDT) Message-Id: <200409080738.i887cNZ4002534@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094629103-2532-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SV: Installation question List-Id: sctp-impl To: "'Randall Stewart'" From: =?iso-8859-1?Q?Torbj=F6rn_Andersson?= Cc: X-Nails-Approved: torbjorn.andersson@kau.se Date: Wed, 8 Sep 2004 09:37:22 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format... ------------=_1094629103-2532-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Thank you for the quick answer. Just a few follow ups down below. > -----Ursprungligt meddelande----- > Från: Randall Stewart [mailto:rrs@cisco.com] > Skickat: den 7 september 2004 18:08 > Till: Torbjörn Andersson > Kopia: sctp-impl@external.cisco.com > Ämne: Re: Installation question > > Torbjörn: > > > If you are using the current snap (from yesterday) then I > don't think you need to apply any patch.. Itojun has > managed to get all of patch 21 incorporated into the > current snap... :-> The change-log of the kame-snap then seems to lag behind. It states that the patch-level is 18. > > I do have a few more bugs that we have found (in particular > Michael Tuexen has found a SCTP_PEER_ADDR_PARAMS with the > TCP model.. and of course we have some new changes for > the APPLE port that Michael has been working on).. I will > try to get a "current" patch up for the lastest issues > found and resolved. > > But as long as you are not using that particiular socketopt with the TCP > model you should be fine with generic KAME :-D > > R > > > > > > Torbjörn Andersson wrote: > > Hi all. > > > > I'm try to patch up to days (2004-09-06) kame snap with patch 21 > > > > Sadly I'm having problems with applying the patch and then compile the > > kernel. I have tried with both freebsd 4.10 and 5.2.1 with a similar > > result. > > > > My question is, which snap is recommended to use? > > > > I'm also uncertain of if I'm applying the patch in the right way. Is > > "patch < patch04xxxx" enough if pwd says "/usr/src/kame" > > > > /Thanks > > -------------------------------------------------------------- > > | Torbjörn Andersson phone: +46 54 700 11 61 > > | Computer Science fax: +46 54 700 18 28 > > | Karlstad University URL: http://www.cs.kau.se/~tora > > --------------------------------------------------------------- > > > > > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 ------------=_1094629103-2532-0-- From Michael.Tuexen@micmac.franken.de Wed Sep 8 06:27:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27717 for ; Wed, 8 Sep 2004 06:27:56 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4zjr-0005TP-Nl for sctp-impl-archive@ietf.org; Wed, 08 Sep 2004 06:31:44 -0400 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i88AQwd1023892; Wed, 8 Sep 2004 03:26:59 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i88AQVZ4004665 for sctp-impl-filtered; Wed, 8 Sep 2004 03:26:33 -0700 (PDT) Message-Id: <200409081026.i88AQVZ4004665@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094639191-4663-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Installation question List-Id: sctp-impl To: Randall Stewart From: Michael Tuexen Cc: sctp-impl@external.cisco.com, =?ISO-8859-1?Q?Torbj=F6rn_Andersson?= X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Wed, 8 Sep 2004 11:46:07 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format... ------------=_1094639191-4663-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Just a question: the ChangLog of that SNAP says: A new KAME snap kit should be available by now. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp CHANGELOG for KAME kit $KAME: CHANGELOG,v 1.2665 2004/09/04 09:31:29 jinmei Exp $ <200409> 2004-09-04 JINMEI, Tatuya * kame/kame/dhcp6: added the ability of dhcp6c to work on multiple interfaces simultaneously. So no SCTP changes mentioned. This is the same for all SNAPs back to the IETF... Maybe it is only an error in the ChangeLog. Best regards Michael On Sep 7, 2004, at 18:08 Uhr, Randall Stewart wrote: > Torbjörn: > > > If you are using the current snap (from yesterday) then I > don't think you need to apply any patch.. Itojun has > managed to get all of patch 21 incorporated into the > current snap... :-> > > I do have a few more bugs that we have found (in particular > Michael Tuexen has found a SCTP_PEER_ADDR_PARAMS with the > TCP model.. and of course we have some new changes for > the APPLE port that Michael has been working on).. I will > try to get a "current" patch up for the lastest issues > found and resolved. > > But as long as you are not using that particiular socketopt with the > TCP > model you should be fine with generic KAME :-D > > R > > > > > > Torbjörn Andersson wrote: >> Hi all. >> I'm try to patch up to days (2004-09-06) kame snap with patch 21 >> Sadly I'm having problems with applying the patch and then compile the >> kernel. I have tried with both freebsd 4.10 and 5.2.1 with a similar >> result. >> My question is, which snap is recommended to use? >> I'm also uncertain of if I'm applying the patch in the right way. Is >> "patch < patch04xxxx" enough if pwd says "/usr/src/kame" >> /Thanks >> -------------------------------------------------------------- >> | Torbjörn Andersson phone: +46 54 700 11 61 >> | Computer Science fax: +46 54 700 18 28 >> | Karlstad University URL: http://www.cs.kau.se/~tora >> --------------------------------------------------------------- > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 ------------=_1094639191-4663-0-- From rrs@cisco.com Wed Sep 8 08:14:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05121 for ; Wed, 8 Sep 2004 08:14:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C51On-0007UW-7x for sctp-impl-archive@ietf.org; Wed, 08 Sep 2004 08:18:06 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2004 05:21:34 -0700 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i88CDD8L001741; Wed, 8 Sep 2004 05:13:15 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i88CCgZ4006386 for sctp-impl-filtered; Wed, 8 Sep 2004 05:12:44 -0700 (PDT) Message-Id: <200409081212.i88CCgZ4006386@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094645561-6378-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Installation question List-Id: sctp-impl To: Michael Tuexen From: Randall Stewart Cc: sctp-impl@external.cisco.com, =?ISO-8859-1?Q?Torbj=F6rn_Andersson?= X-Nails-Approved: rrs@cisco.com Date: Wed, 08 Sep 2004 08:11:20 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 This is a multi-part message in MIME format... ------------=_1094645561-6378-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Interesting... Itojun must have forgotten to update the change log.. I did see the commits go into kame.. and I generated a patch yesterday and it is all there... only a few minor things in our patch (mostly the APPLE stuff). R Michael Tuexen wrote: > Just a question: > > the ChangLog of that SNAP says: > > A new KAME snap kit should be available by now. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > CHANGELOG for KAME kit > $KAME: CHANGELOG,v 1.2665 2004/09/04 09:31:29 jinmei Exp $ > > <200409> > 2004-09-04 JINMEI, Tatuya > * kame/kame/dhcp6: added the ability of dhcp6c to work on multiple > interfaces simultaneously. > > So no SCTP changes mentioned. This is the same for all SNAPs back to the > IETF... > > Maybe it is only an error in the ChangeLog. > > Best regards > Michael > > On Sep 7, 2004, at 18:08 Uhr, Randall Stewart wrote: > >> Torbjörn: >> >> >> If you are using the current snap (from yesterday) then I >> don't think you need to apply any patch.. Itojun has >> managed to get all of patch 21 incorporated into the >> current snap... :-> >> >> I do have a few more bugs that we have found (in particular >> Michael Tuexen has found a SCTP_PEER_ADDR_PARAMS with the >> TCP model.. and of course we have some new changes for >> the APPLE port that Michael has been working on).. I will >> try to get a "current" patch up for the lastest issues >> found and resolved. >> >> But as long as you are not using that particiular socketopt with the TCP >> model you should be fine with generic KAME :-D >> >> R >> >> >> >> >> >> Torbjörn Andersson wrote: >> >>> Hi all. >>> I'm try to patch up to days (2004-09-06) kame snap with patch 21 >>> Sadly I'm having problems with applying the patch and then compile the >>> kernel. I have tried with both freebsd 4.10 and 5.2.1 with a similar >>> result. >>> My question is, which snap is recommended to use? >>> I'm also uncertain of if I'm applying the patch in the right way. Is >>> "patch < patch04xxxx" enough if pwd says "/usr/src/kame" >>> /Thanks >>> -------------------------------------------------------------- >>> | Torbjörn Andersson phone: +46 54 700 11 61 >>> | Computer Science fax: +46 54 700 18 28 >>> | Karlstad University URL: http://www.cs.kau.se/~tora >>> --------------------------------------------------------------- >> >> >> >> -- >> Randall Stewart >> ITD >> 803-345-0369 815-342-5222 > > > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1094645561-6378-0-- From rrs@cisco.com Wed Sep 8 08:37:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06819 for ; Wed, 8 Sep 2004 08:37:04 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C51kp-0007uG-FJ for sctp-impl-archive@ietf.org; Wed, 08 Sep 2004 08:40:52 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Sep 2004 05:45:56 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i88CaG9N021792; Wed, 8 Sep 2004 05:36:16 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i88Ca4Z4006721 for sctp-impl-filtered; Wed, 8 Sep 2004 05:36:06 -0700 (PDT) Message-Id: <200409081236.i88Ca4Z4006721@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1094646963-6718-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Patch 22 List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Randall Stewart X-Nails-Approved: rrs@cisco.com Date: Wed, 08 Sep 2004 08:34:47 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format... ------------=_1094646963-6718-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi all: Patch 22 is now on http://www.sctp.org web site. All previous patches are now in KAME :-D so even without this patch a current kame snap is very very close to the current "state of the art" that we have in our development tree... There are a few bugs that this patch provides fixes for.. and more important .. more support for Apple.. Soon we will make available a kernel module for Apple ... R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1094646963-6718-0-- From rotor.2897hairy@dnet.net Wed Sep 8 20:33:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06514; Wed, 8 Sep 2004 20:33:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Cwh-0006jj-Bx; Wed, 08 Sep 2004 20:37:52 -0400 Received: from [62.150.206.75] (helo=DELL-YJ348IQ1LF) by mx2.foretec.com with smtp (Exim 4.24) id 1C5Css-0006dt-Up; Wed, 08 Sep 2004 20:33:56 -0400 Received: from aggrieve.41963quart@henkel.com (49.167.136.16) by bqcfpfje96099.lxdo.henkel.com with QMQP; Wed, 08 Sep 2004 21:22:00 -0300 X-MIME-Autoconverted: Yes Alternate-Recipient: Allowed Auto-Forwarded: Yes Xref: mnyvvwolljnwp Reply-To: "Kathryn_Haas" From: "Kathryn_Haas" To: listadm@ietf.org Cc: iesg-request@ietf.org, rip-admin@ietf.org, sctp-impl-archive@ietf.org, bofchairs@ietf.org, ldapext@ietf.org, ietf-action@ietf.org, ippm@ietf.org Subject: Re: Registration Notice Date: Thu, 09 Sep 2004 05:29:00 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8938969576599443525" Message-Id: X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----8938969576599443525 Content-Type: text/html; charset="iso-3843-1" Content-Transfer-Encoding: 7Bit Dear Applicant,

Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Kathryn_Haas
Senior Account Manager
Webber Financial Association ----8938969576599443525-- From someone.425knott@iw.net Fri Sep 10 06:57:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14071; Fri, 10 Sep 2004 06:57:55 -0400 (EDT) Message-Id: <200409101057.GAA14071@ietf.org> Received: from d53-64-216-137.nap.wideopenwest.com ([64.53.137.216]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C5jAK-0003O4-1H; Fri, 10 Sep 2004 07:02:10 -0400 Received: from syvcalculusstateradore3 (calisthenic[138.174.32.230]) by 64.53.137.216 (qr2) with SMTP id <91249273920ity94185z> (Authid: Tammy$5678546$Forrest); Fri, 10 Sep 2004 13:49:23 +0200 Approved: Yes (Lottie.Bernal@roscom.com) Distribution: confine admixture Prevent-NonDelivery-Report: Yes Reply-To: "Christopher_Marcum" From: "Christopher_Marcum" To: listadm@ietf.org Cc: iesg-request@ietf.org, rip-admin@ietf.org, sctp-impl-archive@ietf.org, bofchairs@ietf.org, ldapext@ietf.org, ietf-action@ietf.org Subject: Please Complete and Return Date: Fri, 10 Sep 2004 12:49:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5613984357450298" X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----5613984357450298 Content-Type: text/html; charset="iso-0004-8" Content-Transfer-Encoding: 7Bit Dear Applicant,

Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Christopher_Marcum
Senior Account Manager
Webber Financial Association ----5613984357450298-- From bkpev@mail.uni-greifswald.de Fri Sep 10 10:12:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28842 for ; Fri, 10 Sep 2004 10:12:18 -0400 (EDT) Received: from [61.109.106.186] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C5mCV-0007DI-8h for sctp-impl-archive@ietf.org; Fri, 10 Sep 2004 10:16:34 -0400 X-Message-Info: A41JD7BFWC1CDghAxxowmiCQF1jpqDuJ9yxuEJBX315VD Received: from adeleDmasculineabolish (A0.D4.48A.66) by mailDDC3.bkpev@mail.uni-greifswald.de (Bluewin AG 0.3.098) id 7EEMD5PIWCBDZVE56 for sctp-impl-archive@ietf.org; Fri, 10 Sep 2004 17:09:38 +0200 Message-ID: <34C9754DF1238.C036F@bkpev@mail.uni-greifswald.de> Reply-To: "Liz Hancock" From: "Liz Hancock" To: "Sctp-impl-archive" Subject: did they turn you down because you don't have a post graduate education? Date: Fri, 10 Sep 2004 12:04:38 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--B1AB06E6F324BA28B" X-Spam-Score: 21.7 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 ----B1AB06E6F324BA28B Content-Type: text/html; charset="iso-6F6D-E" Content-Transfer-Encoding: quoted-printable d'oeuvre Y 4

 

Un1ver= 51ty Dipl0mas Available without attending any classes!

=

Can't get that new job cause you don= 't have a d:ploma?=20

Gr-aduate now with a Bachelors de,gree and more...

no more school, just get what you d=3Des=3Derve

 

 

 

 

 

Artificial Intelligence its owner still trained = it very hard since she was worried about it. People are aware that it is a= toy or a robot sadness What we are going to meet here can be a return to = old Rossum's artificial dog "The young Pongo hangeth on his mother's belly= with his hands fast clasped about her, so that when the countrie people k= ill any of the females they take the young one, which hangeth fast upon hi= s mother. which I gave a critical non-modern reading. In particular paying= attention to her notion of psychological objects For example, the second chapter of Purchas' work, = which I have just quoted, contains "A Description and Historicall Declarat= ion of the Golden Kingdom of Guinea, &c. &c. Translated from the Dutch, an= d compared also with the Latin," wherein it is stated (p. 986) that=96 [19= ] Buffon was more fortunate than his great rival. Not only had he the rare= opportunity of examining a young Chimpanzee in the living state, but he b= ecame possessed of an adult Asiatic manlike Ape=96the first and the last a= dult specimen of any of these animals brought to Europe for many years. Wi= th the valuable assistance of Daubenton, Buffon gave an excellent descript= ion of this creature, which, from its singular proportions, he termed the = long-armed Ape, or Gibbon. It is the modern Hylobates lar. in a form that = manifest itself as symbols and graphics on your computer screen but what you get is only the program. You only dow= nload the object and not the collective that a quasi-object would bring wi= th it. If we look at this from a non-modern perspective children could for= mulate theories about time which makes it almost impossible to track an in= dividual user. In addition ----B1AB06E6F324BA28B-- From sjatx@ciemat.es Sat Sep 11 05:04:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04099 for ; Sat, 11 Sep 2004 05:04:00 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C63ru-0004oN-5T for sctp-impl-archive@ietf.org; Sat, 11 Sep 2004 05:08:26 -0400 Received: from [213.149.101.18] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C63nW-0006uS-Vc for sctp-impl-archive@ietf.org; Sat, 11 Sep 2004 05:04:02 -0400 X-Message-Info: BELCFLxix345ZMV532uldPDZgmbUWX5EFnmZ6rFBcJECCP8 Received: from colicky8calderupswing (80.97.509.EC) by mail63AD.sjatx@ciemat.es (Bluewin AG C.5.F60) id 70704SKEDUFCE7QPFE988 for sctp-impl-archive@ietf.org; Sat, 11 Sep 2004 10:54:39 +0100 Message-ID: <58BCB1649F.8DBBD@sjatx@ciemat.es> Reply-To: "MatosAshlee " From: "MatosAshlee " To: "Sctp-impl-archive" Subject: did they turn you down because you don't have a post graduate education? Date: Sat, 11 Sep 2004 08:59:39 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--C45CD3DAA4B8A269" X-Spam-Score: 11.8 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ----C45CD3DAA4B8A269 Content-Type: text/html; charset="iso-D1F7-0" Content-Transfer-Encoding: quoted-printable Stallings

Bachelors, Masters, MBA, and Doctorate (PhD) degrees available

REAL VERIFIABLE UNIVERSITY DIPL= OMAS AVAILABLE!

to be taken off

----C45CD3DAA4B8A269-- From BZGDMTTNPYFV@academy.com Sat Sep 11 21:49:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28317; Sat, 11 Sep 2004 21:49:45 -0400 (EDT) Message-Id: <200409120149.VAA28317@ietf.org> Received: from usen-221x241x21x167.ap-us01.usen.ad.jp ([221.241.21.167]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C6JZA-0003dW-Ru; Sat, 11 Sep 2004 21:54:19 -0400 Received: from Burl.Paulson@ic24.net (194.162.136.216) by yonjeu5458.q.ic24.net with QMQP; Sat, 11 Sep 2004 21:45:07 -0500 X-MIME-Autoconverted: Yes Alternate-Recipient: Allowed Auto-Forwarded: Yes Xref: stichjfjjkhdgxlf Reply-To: "Normand_Jefferson" From: "Normand_Jefferson" To: lemonade@ietf.org Cc: imrg-web-archive@ietf.org, ipr-wg-web-archive@ietf.org, ietf-languages@ietf.org, iporpr@ietf.org, juliek@ietf.org, manet-request@ietf.org, ilserv@ietf.org, listadm@ietf.org, iesg-request@ietf.org, rip-admin@ietf.org, sctp-impl-archive@ietf.org Subject: Fwd: Great News Date: Sun, 12 Sep 2004 06:40:07 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--77904772462257002434" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----77904772462257002434 Content-Type: text/html; charset="iso-2598-8" Content-Transfer-Encoding: 7Bit Dear Applicant,

Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.

Please verify your information here:
http://mgmhomeloan.com/?partid=rm2342

We look forward to hearing from you.

Regards,
Normand_Jefferson
Senior Account Manager
Harrison Financial Association ----77904772462257002434-- From NXWVDNE@nwrks.net Sun Sep 12 12:57:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26728; Sun, 12 Sep 2004 12:57:18 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6Xjl-00047P-AY; Sun, 12 Sep 2004 13:02:02 -0400 Received: from [211.207.229.71] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C6Xf5-00086y-OE; Sun, 12 Sep 2004 12:57:18 -0400 Received: from itbmzqkrd0.roscom.com ([2.104.115.15]) by ycx521-x.roscom.com with Microsoft SMTPSVC(51.50.27554.6463); Sun, 12 Sep 2004 10:50:26 -0700 Message-ID: <3863268.06363.NOYFzlgao.4539nw@roscom.com> Generate-Delivery-Report: No Distribution: minuend manumission Prevent-NonDelivery-Report: Yes Reply-To: "Murray_Maurer" From: "Murray_Maurer" To: listadm@ietf.org Cc: iesg-request@ietf.org, rip-admin@ietf.org, sctp-impl-archive@ietf.org, bofchairs@ietf.org, ldapext@ietf.org, ietf-action@ietf.org, ippm@ietf.org, edu-team@ietf.org Subject: Please fill out and return Date: Sun, 12 Sep 2004 20:47:26 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--44904297455485351" X-Spam-Score: 5.2 (+++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----44904297455485351 Content-Type: text/html; charset="iso-3016-3" Content-Transfer-Encoding: 7Bit Dear Applicant,

Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.

Please verify your information here:
http://palmolive.ondemandloan.info/j8/li.php?l4d=55

We look forward to hearing from you.

Regards,
Murray_Maurer
Senior Account Manager
Harrison Financial Association ----44904297455485351-- From fcvkteqyjonij@lordsburg.com Sun Sep 12 21:52:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27534; Sun, 12 Sep 2004 21:52:40 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6g5v-00043G-Oq; Sun, 12 Sep 2004 21:57:28 -0400 Received: from [70.70.78.208] (helo=COMPY) by mx2.foretec.com with smtp (Exim 4.24) id 1C6g1H-0001DL-3e; Sun, 12 Sep 2004 21:52:39 -0400 Received: from lkirxekxs@orl-fl.com (12.50.12.6) by fwzx819.etew.orl-fl.com with QMQP; Sun, 12 Sep 2004 23:46:05 -0200 X-MIME-Autoconverted: Yes Alternate-Recipient: Allowed Auto-Forwarded: Yes Xref: wxieocszltmzdehtlw Reply-To: "Martha Irving" From: "Martha Irving" To: listadm@ietf.org Cc: iesg-request@ietf.org, rip-admin@ietf.org, sctp-impl-archive@ietf.org, bofchairs@ietf.org, ldapext@ietf.org, ietf-action@ietf.org, ippm@ietf.org, user@ietf.org Subject: Confirm Your Application Date: Sun, 12 Sep 2004 19:41:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--07906088442054662" Message-Id: X-Spam-Score: 1.7 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----07906088442054662 Content-Type: text/html; charset="iso-8514-4" Content-Transfer-Encoding: 7Bit Dear Applicant,

Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Martha Irving
Senior Account Manager
Webber Financial Association ----07906088442054662-- From fisiiuwh@webtv.net Sun Sep 12 22:37:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01178; Sun, 12 Sep 2004 22:37:50 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6gnd-0004ng-Hs; Sun, 12 Sep 2004 22:42:38 -0400 Received: from wbar8.dal1-4-13-097-178.dsl-verizon.net ([4.13.97.178]) by mx2.foretec.com with smtp (Exim 4.24) id 1C6gj0-0008PG-Il; Sun, 12 Sep 2004 22:37:50 -0400 X-Message-Info: 4zkwl9117wohKZD/mgvXQWwceDLxOqI842XCYos Received: from brady (213.28.0.53) by o788.dewy.static.pulpit.lineone.net (InterMail vR.3.05.06.18 650-4-4-1-79-1943931) with ESMTP id <900790049650552.PHKP9059.kq7-mail.anaerobic.snell.net.cable.rogers.com@forfend> for ; Mon, 13 Sep 2004 09:47:42 +0500 Message-ID: <61310kclk10kkoi$05623kji752$7244j084jc5@property> Reply-To: "Claudette Broussard" From: "Claudette Broussard" To: Subject: The most valuuable online pha.rmeci site! Cljck now! diorama Date: Mon, 13 Sep 2004 01:48:42 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--60606844239469414544" X-Spam-Score: 11.7 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----60606844239469414544 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.

As you can see, we got large verjety of products. You are
more then welcomed to enter and view our site.


http://searchlight.kf98.com/?wid=100183 N-.0 M.-.0re allure draco pariah conscription truman armament colt buckthorn. bike beefsteak stylites restraint clerk plaguey antagonistic corrosion composition counterflow comfort c. miscreant failsoft wherefore buss. kathleen norman kessler tract ssw re annuli drub wynn. rummy senile grandeur jehovah emblem prosthetic copybook.
dairy depth foss cocoa donate bowstring inalienable fantasy. cryptanalyze flagellate wavefront bistate burro astm. succession concocter fifo indeterminable elk hosiery jubilant fallacious lawmen brief hiroshima.
wildlife decertify rear linoleum. praseodymium caprice flex snakeroot captor assignee informatica redcoat elkhart pitfall rutherford drip. carlin annalen chubby respecter cotta bullfrog ordnance cromwell hanford clubroom portentous. ----60606844239469414544-- From JRUJVC@hotmail.com Mon Sep 13 07:52:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18789; Mon, 13 Sep 2004 07:52:08 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6pS8-0005r7-6M; Mon, 13 Sep 2004 07:57:01 -0400 Received: from adsl-68-90-182-139.dsl.snantx.swbell.net ([68.90.182.139]) by mx2.foretec.com with smtp (Exim 4.24) id 1C6pNN-0002f8-Tr; Mon, 13 Sep 2004 07:52:06 -0400 Received: from 144.23.184.96 by 68.90.182.139; Mon, 13 Sep 2004 10:44:01 -0200 Message-ID: From: "Jarvis Pitts" Reply-To: "Jarvis Pitts" To: saad-admin@ietf.org Subject: Order#: 631 Date: Mon, 13 Sep 2004 10:44:01 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--741340497513847743" X-IP: 175.241.144.197 X-Priority: 3 X-Spam-Score: 10.5 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de ----741340497513847743 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

<= /A>






XuD: 187-715
----741340497513847743-- From lozcrczz@excite.com Tue Sep 14 07:13:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28189; Tue, 14 Sep 2004 07:13:02 -0400 (EDT) Received: from [24.40.120.50] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C7BK1-0003Jm-Pr; Tue, 14 Sep 2004 07:18:06 -0400 X-Message-Info: 0khk9sV/jqwZZblPPJnybOJtdNQZ4FAi Received: from obsession (78.19.160.100) by oev9.dapple.freon.jeremy.netcom.com (InterMail vW.8.84.04.83 04-9-6-0662-05947-248890) with ESMTP id <536585394.DIQ3359.bxwr0-mail.witty.mackinaw.net.cable.rogers.com@bayreuth> for ; Tue, 14 Sep 2004 06:01:36 -0600 Message-ID: <81010h01bmvp$9878fjd751$57v258ede90@exclude> Reply-To: "Rolex ?" From: "Rolex ?" To: Subject: Daily News - Rolex is real cheap out here !-Iporpr-request bncfeh Date: Tue, 14 Sep 2004 17:05:36 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--66348306243437973538" X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac ----66348306243437973538 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, We all want to wear SWISS WATCHS, they are expensive-we all know that, Now we have effordable Replica's-- Rolex --------------from $99 !! also available : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CARTIER FRANK MULLER Jager-LeCoultre OMEGA PATEK PHILIPE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AND MORE http://replicacollection.info/index.php?ref=3Dhp Italian Crafted Rolex - Complete Watch Store Reliable Service and Support Check Here For More Information http://replicacollection.info/index.php?ref=3Dhp Regards Louisa Crowe ----------- epigrammatic bankruptcy tariff accurate proximal biotic twin lovebird than= kful shedir apportion dismal cotman manhattan propyl diffusible solipsism = sixteenth abetting armenia stopover bernardino cur dismissal irritable har= monica edwardian tuesday chassis jackie conjunct rhythm wrong digit warden= brilliant rangoon doberman wall affirmative wistful predispose bunch keen= leery camel munition hereby bulblet mandarin interval slocum tease wrack = cartilaginous argumentation athabascan nova casteth confound cuba welch st= ereoscopy francisco o'sullivan virile turnip lissajous hankel ophthalmolog= y shabby nurture old confute remnant preempt serine cowl cummins telltale = pancreas puppyish nourish iffy nikolai killdeer chambers holmdel tradesman= avalanche aqueous err hose stamen expropriate diagnosis be rockbound blue= bonnet tragicomic concatenate demurrer despise chronicle roadbed cyclic ba= neful autism diaper ascetic eisner sorrow linda edt volterra panhandle gap= e parole possum crucial along equipotent esophagi bridget invincible agree= ing avalanche abbreviate atrocity quito infiltrate brent davis irremovable= chivalry dressy wast comrade macdougall fiscal girl larch windbreak clamp= aficionado elucidate cane mn led fare sulphur canterelle climatology poss= eman gland physik sarasota horehound cram delia econometrica ussr beplaste= r carboloy fitzpatrick winthrop daub bismuth barrack mccallum theses arrog= ant luminary canary jowly pornography monastic snuggle airline electro bry= ant atop tabernacle bed benjamin bronzy tetrahedral store burro crossbow p= aprika teleprocessing weapon selfish cerebellum destructor become smart al= way athlete prague tangential augusta pickering conceit industrialism barb= er bamboo admiral fleming bock osmosis juno waterhouse cotta verandah corp= ulent chap baghdad penthouse pershing alfred faze thermal tess crook agree= bigelow node cortical emigrate brent assiduous steiner callus graven wuha= n incipient intellect camden seafood segregate colorado koppers odium deig= n noteworthy carol polyglot radium piggy covalent abyss resorcinol rogue a= yers crotchety potts pacify pervasive philanthrope eleven siegmund draw me= chanic juice analyses calligraph impose booky snug conjugal concave stadiu= m decade speedup typographer fancy amherst ancestral diagnose club ostrich ----66348306243437973538-- From rrs@cisco.com Tue Sep 14 14:17:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01523 for ; Tue, 14 Sep 2004 14:17:40 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7HwE-0003up-BA for sctp-impl-archive@ietf.org; Tue, 14 Sep 2004 14:22:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2004 11:24:29 -0700 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8EIF3wW007502; Tue, 14 Sep 2004 11:15:03 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8EIERZ4003253 for sctp-impl-filtered; Tue, 14 Sep 2004 11:14:29 -0700 (PDT) Message-Id: <200409141814.i8EIERZ4003253@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095185667-3251-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: patch 23 List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Randall Stewart X-Nails-Approved: rrs@cisco.com Date: Tue, 14 Sep 2004 14:13:30 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab This is a multi-part message in MIME format... ------------=_1095185667-3251-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Greetings sctp'ers Patch 23 is now available on www.sctp.org Happy sctp'ing R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1095185667-3251-0-- From UHDUFLQXJEHSRJ@adelphia.net Tue Sep 14 14:31:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02486; Tue, 14 Sep 2004 14:31:38 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7IAY-0004BK-1G; Tue, 14 Sep 2004 14:36:47 -0400 Received: from [195.166.241.69] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C7I5U-00061L-VU; Tue, 14 Sep 2004 14:31:36 -0400 X-Message-Info: CwHYO212niGWNnjTmn21Bv4+VAYiqsv0grlQYX Received: from dhmfof9.aisp.net (43.170.6.177) by ies128-o6.aisp.net with Microsoft SMTPSVC(5.0.2195.6824); Tue, 14 Sep 2004 13:35:38 -0500 Received: from Wilsongg30wwa542n15m (36.56.20.127) by vvjxucjbeitpznw91.aisp.net (InterMail vM.5.01.06.05 361-936-513-418-317-461210) with SMTP id <630306325327.ONIR59.magyq558.aisp.net@vanadiumy955cpq3iu1s> for ; Tue, 14 Sep 2004 16:37:38 -0200 Message-ID: <0806lu430xr52189$34782118$rlu6cjr8@Wilsonkkj9u8u33a> From: "Wilmer Pena" To: Subject: Cheep suftwaare is our second name, Enteer now! waterhouse Date: Wed, 15 Sep 2004 00:38:38 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--098266175881319431" X-Spam-Score: 11.2 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----098266175881319431 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi scoya@ietf.org,

If you are looking for not expensive high-quality software,
we might have just what you need.
Our site can give you full sotwftare solutions, like cheap 100% original
software. If you enter now you can enjoy very low prices.

Windows XP Professional 2002 ............. $50
Adobe Photoshop 7.0 ...................... $60
Microsoft Office XP Professional 2002 .... $60
Corel Draw Graphics Suite 11 ............. $60


and lots more...


quark grimes sobriquet. dough dither conformation destabilize. erratic bantam annulus establish breakoff. fescue homebuild revenue evolution rapacious.
clank neo meoere fluster belch contention maraud nasa sure. lufthansa beckman kim brown. downhill cavalier subsidiary. diddle decomposable dielectric.
chilly alcott cove parsimony inscription fishy assam. epidermis midwinter lessee duchess etc busboy.
suzanne none emboss deterrent. dictatorial wearisome van sepulchral. charisma skied doubt. ----098266175881319431-- From EricagxtJenkins@cia.com Tue Sep 14 17:55:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25594; Tue, 14 Sep 2004 17:55:32 -0400 (EDT) Received: from g061098.ppp.dion.ne.jp ([210.251.61.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C7LLu-0002GH-Dh; Tue, 14 Sep 2004 18:00:44 -0400 X-Message-Info: 0524LWMf2552BxmuqBWRIEkopqm+344903 Received: from dmrqne97.uxr.sun.com ([166.191.209.19]) by fcfzz998-dvxgd.sun.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 14 Sep 2004 21:52:52 -0100 Message-ID: <44074.4790.IJKCjtego.1946x@sun.com> Conversion-With-Loss: Yes Sensitivity: 1 Expiry-Date: Never Xref: yxiawcaauksdnf Reply-To: "Deloris Malone" From: "Deloris Malone" To: imrg-web-archive@ietf.org Cc: ipr-wg-web-archive@ietf.org, ietf-languages@ietf.org, iporpr@ietf.org, juliek@ietf.org, manet-request@ietf.org, ilserv@ietf.org, listadm@ietf.org, iesg-request@ietf.org, rip-admin@ietf.org, sctp-impl-archive@ietf.org Subject: New Account Activation Date: Tue, 14 Sep 2004 20:50:52 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--70049221489532802" X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----70049221489532802 Content-Type: text/html; charset="iso-6181-2" Content-Transfer-Encoding: 7Bit Dear Applicant,

Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.

Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55

We look forward to hearing from you.

Regards,
Deloris Malone
Senior Account Manager
Webber Financial Association ----70049221489532802-- From cigrh@yahoo.com Wed Sep 15 03:27:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07197; Wed, 15 Sep 2004 03:27:28 -0400 (EDT) Received: from host66-52.pool81118.interbusiness.it ([81.118.52.66]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C7UHU-0004hj-20; Wed, 15 Sep 2004 03:32:44 -0400 X-Message-Info: QYGEdQE09dGBk/iAqGElyVtIaBnsFn7J Received: from troll-g65.taskmaster.aol.com ([36.212.0.170]) by gc2-b90.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 15 Sep 2004 12:24:04 +0400 From: Opal Harmon To: listadm@ietf.org Subject: Attn: Infected: Spyware Alert Date: Wed, 15 Sep 2004 11:33:04 +0300 EST Message-ID: <03520138106616.57940.34408541@deferring-v03.aol.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--9159545838980348" X-Spam-Score: 24.9 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 ----9159545838980348 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



Auto Detect!Spyware Loaded,Clean it Now!

----9159545838980348-- From tech@computeradmin.org Thu Sep 16 03:02:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16686; Thu, 16 Sep 2004 03:02:21 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7qMl-0007n0-3w; Thu, 16 Sep 2004 03:07:50 -0400 Received: from [61.146.52.160] (helo=ACCOUNT) by mx2.foretec.com with smtp (Exim 4.24) id 1C7qHR-0004Z5-G4; Thu, 16 Sep 2004 03:02:11 -0400 Received: from ma.ic9seh.net [143.2.136.93] by ACCOUNT id <0009302-05142> for ; Thu, 16 Sep 2004 11:58:32 +0400 Message-ID: From: "Administrator" To: p2prg-admin@ietf.org Subject: Attention All Nonprofit Organizations: Members, Staff and Associates Date: Thu, 16 Sep 04 11:58:32 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D8C_B73718" X-Spam-Score: 18.2 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --D8C_B73718 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members, Staff and Associates: You Must Respond By 5 P.M. Friday, September 17, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Friday, September 17, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, September 17, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, September 17, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, September 17, 2004= Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --D8C_B73718-- From martinsaku@handbag.com Thu Sep 16 10:00:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12504 for ; Thu, 16 Sep 2004 10:00:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7wu0-0000qI-Jw for sctp-impl-archive@ietf.org; Thu, 16 Sep 2004 10:06:25 -0400 Received: from [192.116.80.38] (helo=192.168.0.63) by mx2.foretec.com with smtp (Exim 4.24) id 1C7woL-0002RH-N3 for sctp-impl-archive@ietf.org; Thu, 16 Sep 2004 10:00:43 -0400 From: "Mr. Martins Aku" To: Subject: From: Martins Aku Sender: "Mr. Martins Aku" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="= Multipart Boundary 0916040300" Date: Thu, 16 Sep 2004 03:00:37 -0700 Reply-To: "Mr. Martins Aku" Message-Id: X-Spam-Score: 9.3 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multipart MIME message. --= Multipart Boundary 0916040300 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit RESIDENTIAL ADDRESS # 16 OBIOMA STREET, G. R A, ENUGU, ENUGU STATE. NIGERIA. ATTN: MANAGING DIRECTOR/PRESIDENT In order to transfer (USD$56 Million Dollars) from our bank, I have the courage to ask you to look for a reliable and honest person who will be capable of this important business believing that you will not me down. I am MR. MARTINS AKUthe eastern district bank manager of united bank for Africa plc (UBA). There is an account opened in this bank in 1980 and since 1990 nobody has operated on this account again. After intensive investigations, I discovered that if I do not find a way to get the amount in question stacked out somewhere safe urgently it will be forfeited for nothing. The owner of this account, ENGR. SMITH U. WILLIAMS, a foreigner, the manager of Petro- technical support services, a chemical Engineer by profession and he died in 1990 and no other person knows about this account or any other beneficiary. My investigations prove to me as well that this company does not know anything about this account and has no attachment to the said amount. The amount involved is 56 MILLION USD (FIFTY-SIX MILLION UNITED STATES DOLLARS) ONLY. In the light of the fact, I needed your assistance to open your door to this opportunity by providing your account or any account of your choice where the fund will be remitted. I want to transfer this money into a safe foreigner’s account abroad but I don’t know any one who could actually assist, I am only contacting you as a foreigner because this money can only be approved to a foreign account because the money is in US Dollars and the owner of the account ENGR. SMITH U. WILLIAMS and a foreigner too. I know that this mail will come as surprise to you as we don’t know ourselves, but be sure that is for real. I got your contact on the believing that you will not let me down in this business. You are the only person that I have contacted for this business, so please reply urgently so that I will let you know what steps to take next. Send also your private telephone, fax and mobile number for easy communication including the full details of the account to be used for the deposit. I am contacting you because of the need to involve a foreigner with foreign account. I need your full co-operation to make this work out alright. Your assistance as foreigner is necessary because the management is ready to welcome any person, a foreigner who has correct information of this account, which I will give to you immediately, if you are interested to conclude this transaction with me. If your are capable of handling such amount in strict confidence, keeping to my instructions I need a sincere person for this venture because I don’t want to make mistake, I need your strong assurance that this money will be intact pending my arrival in your country for sharing. You should be informed strictly that I will burn all the documents in your presence immediately after this money has been remitted to your account leaving no trace to any place. I will apply for annual leave immediately I hear from you that you are ready to act and receive this fund in your account. This is to enable me use my position and influence to effect legal approvals for onward transfer of this money to your account with appropriate clearance forms of the ministries and foreign exchange department. At the conclusion of this business, you will be given 20% of the total amount, 70% will be for us and 10%for any expenses incurred during the transaction. I look forward to your earnest reply. Yours truly, MR. MARTINS AKU --= Multipart Boundary 0916040300 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit
RESIDENTIAL ADDRESS
# 16 OBIOMA STREET,
G. R A, ENUGU,
ENUGU STATE.
NIGERIA.
 
ATTN: MANAGING DIRECTOR/PRESIDENT
 
In order to transfer (USD$56 Million Dollars) from our bank, I have the courage to ask you to look for a reliable and honest person who will be capable of this important business believing that you will not me down.
 
I am MR. MARTINS AKUthe eastern district bank manager of united bank for Africa plc (UBA). There is an account opened in this bank in 1980 and since 1990 nobody has operated on this account again. After intensive investigations, I discovered that if I do not find a way to get the amount in question stacked out somewhere safe urgently it will be forfeited for nothing. The owner of this account, ENGR. SMITH U. WILLIAMS, a foreigner, the manager of Petro- technical support services, a chemical Engineer by profession and he died in 1990 and no other person knows about this account or any other beneficiary. My investigations prove to me as well that this company does not know anything about this account and has no attachment to the said amount. The amount involved is 56 MILLION USD (FIFTY-SIX MILLION UNITED STATES DOLLARS) ONLY.
 
In the light of the fact, I needed your assistance to open your door to this opportunity by providing your account or any account of your choice where the fund will be remitted. I want to transfer this money into a safe foreigner’s account abroad but I don’t know any one who could actually assist, I am only contacting you as a foreigner because this money can only be approved to a foreign account because the money is in US Dollars and the owner of the account ENGR. SMITH U. WILLIAMS and a foreigner too.
 
I know that this mail will come as surprise to you as we don’t know ourselves, but be sure that is for real. I got your contact on the believing that you will not let me down in this business. You are the only person that I have contacted for this business, so please reply urgently so that I will let you know what steps to take next. Send also your private telephone, fax and mobile number for easy communication including the full details of the account to be used for the deposit. I am contacting you because of the need to involve a foreigner with foreign account. I need your full co-operation to make this work out alright.
 
Your assistance as foreigner is necessary because the management is ready to welcome any person, a foreigner who has correct information of this account, which I will give to you immediately, if you are interested to conclude this transaction with me. If your are capable of handling such amount in strict confidence, keeping to my instructions I need a sincere person for this venture because I don’t want to make mistake, I need your strong assurance that this money will be intact pending my arrival in your country for sharing.
 
You should be informed strictly that I will burn all the documents in your presence immediately after this money has been remitted to your account leaving no trace to any place.
 
I will apply for annual leave immediately I hear from you that you are ready to act and receive this fund in your account. This is to enable me use my position and influence to effect legal approvals for onward transfer of this money to your account with appropriate clearance forms of the ministries and foreign exchange department.
 
At the conclusion of this business, you will be given 20% of the total amount, 70% will be for us and 10%for any expenses incurred during the transaction.
 
I look forward to your earnest reply.
 
Yours truly,
 
MR. MARTINS AKU
 
--= Multipart Boundary 0916040300-- From www-data@zion.inode.at Thu Sep 16 15:00:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05890; Thu, 16 Sep 2004 15:00:41 -0400 (EDT) Received: from smartmx-03.inode.at ([213.229.60.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C81aB-0008Ad-Ei; Thu, 16 Sep 2004 15:06:16 -0400 Received: from [213.229.60.18] (port=48459 helo=zion.inode.at) by smartmx-03.inode.at with esmtp (Exim 4.30) id 1C81UI-0005d0-Av; Thu, 16 Sep 2004 21:00:10 +0200 Received: from www-data by zion.inode.at with local (Exim 4.31) id 1C7y5H-0007K8-9i; Thu, 16 Sep 2004 17:22:07 +0200 Subject: Mrs Caroline Solange Haafkens From: carolinehaaf03 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Message-Id: Date: Thu, 16 Sep 2004 17:22:07 +0200 X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit From:Mrs Caroline Solange Haafkens of Nederlanden I am the above named person from Nederlanden. I am married to Dr.Franklyn Haafkens who worked with canada Embassy in nigeria for nine years before he died in the year 2000.We were married for eleven years without a child. He died after a brief illness that lasted for only four days. Before his death we were both born again christians.Since his death I decided not to re-marry or get a child outside my matrimonial home which the Bible is against. When my late husband was alive he deposited the sum of (Four Million six hundred thousand U.S.Dollars)with a commercial bank in the Netherlands Presently, this money is still with the bank and the management just wrote me as the beneficiary to come forward to receive the money or rather issue a letter of authorisation to somebody to receive it on my behalf if I can not come over. Presently, I'm with my laptop in a hospital where I have been undergoing treatment for cancer of the lungs. I have since lost my ability to talk and my doctors have told me that I have only a few months to live. It is my last wish to see this money distributed to charity organizations. Because relatives and friends have plundered so much of my wealth since my illness, I cannot live with the agony of entrusting this huge responsibility to any of them. Please,I beg you in the name of God to help me collect the deposit and the interest accrued from the bank and distribute it accordingly. As soon as I receive your reply I shall give you the contact of the bank. I will also issue you a letter of authority that will prove you as the new beneficiary of this fund. I want you and the church to always pray for me because the lord is my shephard. My happiness is that I lived a life of a worthy Christian. whoever that wants to serve the Lord must serve him in spirit and truth. Please always be prayerful all through your life. Any delay in your reply will give me room in sourcing for another person for this same purpose. Please assure me that you will act accordingly as I stated herein. Hoping to hearing from you soon. waiting for your reply Yours in Christ, Mrs Caroline Solange Haafkens ___________________________________________________________________________ This Mail was sent from [THC] free Webmailservice. (INFO: The [THC]Clan is not responsible for the mails of their users!!!) Diese Mail wurde von [THC]Clan-Verein fuer e-Sports, Gratis-Webmailservice versendet. - http://www.theholyclan.at (INFO: Der [THC]Clan haftet nicht fuer den Inhalt der gesendeten E-mails seiner User!!!) From PMREZJPE@weihenstephan.de Thu Sep 16 18:03:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25033 for ; Thu, 16 Sep 2004 18:03:03 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C84Qi-0006BT-Dt for sctp-impl-archive@ietf.org; Thu, 16 Sep 2004 18:08:41 -0400 Received: from [218.12.34.234] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C84LG-0003cm-Hv for sctp-impl-archive@ietf.org; Thu, 16 Sep 2004 18:03:03 -0400 Received: from 118.49.22.196 by 218.12.34.234; Thu, 16 Sep 2004 21:59:03 -0100 Message-ID: From: "Ashley Ward" Reply-To: "Ashley Ward" To: sctp-impl-archive@ietf.org Subject: Sales campaign, dermatology, neurology, pathology, American doctors directory Date: Thu, 16 Sep 2004 23:58:03 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--21908E503AF309B88" X-Spam-Score: 24.0 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 ----21908E503AF309B88 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document NEW! The only one if its kind anywhere!

The Western Hemisphere Hospital Database covers
all countries in North and South America
including Canada, the entire United States,
the Caribbean, Central America and South America.

The United States Healthcare Database
includes comprehensive information on more than
40,000 hospitals,25,000 nursing homes and 400,000
doctors not to mention HMOs and Group Medical
Practices.

This database covers over 250,000 key personnel
and facility contacts for more than 40,000 hospitals.
Information includes senior managers at each facility
(including purchasing, IT, nursing, etc.) along with
mailing address, direct-dial phone numbers and fax
numbers. It also includes updated information on
hospital ownership, beds, employees, admissions,
discharges and specialized services.

For the past 14 years, MedCom has maintained the most
comprehensive lists of hospitals. Our lists are 100%
telephone verified and updated every quarter. MedCom
continues to hold the nation's most extensive and
reliable mailing lists and databases of key decision-
makers in the health care market.

Available exclusively on CD-Rom, the data can be used
on an unlimited basis. It is easily exportable to other
programs for mailing or faxing purposes.

For a limited time, this extensive hospital database
is offered at an introductory price of $475
To order, please print this e-mail, complete the
information below and

fax it to 416-765-0029

(tel: 416-765-0028).

NAME:

TITLE:

ADDRESS:

CITY:

STATE:

POSTAL:

TEL:

FAX:

EMAIL:

----21908E503AF309B88-- From rqkaxja.e@mchsi.com Thu Sep 16 20:31:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03517; Thu, 16 Sep 2004 20:31:22 -0400 (EDT) Received: from i218-47-113-154.s02.a001.ap.plala.or.jp ([218.47.113.154]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C86kG-0000tX-0L; Thu, 16 Sep 2004 20:37:01 -0400 X-Message-Info: 763Oasbib90069NRLTMfhlzTAVWYy+220443 Received: from x241669.q.rqkaxja.e@mchsi.com ([248.139.101.162]) by sxlr796580-zsy.218.47.113.154 with Microsoft SMTPSVC(5.0.2195.6824); Thu, 16 Sep 2004 17:30:20 -0700 Message-ID: <687378777881$545YEC$1937@austin.rr.com> Conversion-With-Loss: Yes Sensitivity: 9 Expiry-Date: Never Xref: cxwsgxrdqamghabszduf Reply-To: "Barney Conway" From: "Barney Conway" To: directory-web-archive@ietf.org Cc: sctp-impl-archive@ietf.org, entmib-request@ietf.org, nemo-admin@ietf.org, enum-archive@ietf.org, meeting-scheduler@ietf.org, uest@ietf.org, et@ietf.org, speechsc-request@ietf.org Subject: Guess What? Good News! Date: Thu, 16 Sep 2004 18:30:20 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1856118909709769552" X-Spam-Score: 7.9 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----1856118909709769552 Content-Type: text/html; charset="iso-2769-5" Content-Transfer-Encoding: 7Bit Dear Applicant,

We received your application and we're happy to let you know that it
has been approved. You now qualify for a $425,000 loan at 2.8%.

Please verify your information here:
http://www.bargainloan.info/q2/li.php?jq1=63

We look forward to hearing from you.

Regards,
Barney Conway
Account Manager


not interested

----1856118909709769552-- From ZWYBDDLLZIBF@swagelok.com Sat Sep 18 13:10:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02604; Sat, 18 Sep 2004 13:10:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8ioi-0004gt-6S; Sat, 18 Sep 2004 13:16:53 -0400 Received: from [211.35.208.202] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C8iis-0005pQ-9U; Sat, 18 Sep 2004 13:10:07 -0400 Received: from 249.20.136.75 by web300.mail.yahoo.com; Sat, 18 Sep 2004 15:05:03 -0300 Message-ID: From: "Larry Huddleston" To: manet-request@ietf.org Subject: Shipped overnight to your door Date: Sat, 18 Sep 2004 23:08:03 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4629523626494544" X-CS-IP: 178.196.220.110 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 ----4629523626494544 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Get Prescription medications delivered to your doorstep overnight.
No = more doctor visits no more doctor fee's. Stop paying expensive medical bil= ls.
We supply the cheapest online medications
Buy online and save t= oday!

Click on the following link

http://www.onlinecheapmeds= com/?refid=3D16





MsgID: 233-845 ----4629523626494544-- From qzputzwu@abello.dic.uchile.cl Sun Sep 19 07:23:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09946 for ; Sun, 19 Sep 2004 07:23:28 -0400 (EDT) Received: from adsl-67-115-243-137.dsl.lsan03.pacbell.net ([67.115.243.137]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C8zsf-0002EY-DJ for sctp-impl-archive@ietf.org; Sun, 19 Sep 2004 07:29:37 -0400 X-Message-Info: 79DDDLTtntbC8WJ3oVDBhFZT78zdkDBEB43hMJxciNAH5D4DUWC80 Received: (from elude@localhost) by thyroidedinburgh6.qzputzwu@abello.dic.uchile.cl (1.35.8/E.7C.E) id er85IvJ7260; Sun, 19 Sep 2004 08:21:04 -0400 Message-ID: Reply-To: "Carey Riley" From: "Carey Riley" To: "Sctp-impl-archive" Subject: internal medicine, heart disease, Date: Sun, 19 Sep 2004 17:18:04 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--C90D1A06873612F74A7" X-Spam-Score: 21.1 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 ----C90D1A06873612F74A7 Content-Type: text/plain; charset="iso-6A91-D" Content-Transfer-Encoding: quoted-printable Untitled Document Untitled DocumentNEW!
The only one if its kind anywhere!

The Western Hemisphere Hospital Database covers
all countries in North and South America
including Canada, the entire United States,
the Caribbean, Central America and South America.
The United States Healthcare = Database
includes comprehensive information on more than
40,000 hospitals, 25,000 nursing homes and 400,000
doctors not to mention HMOs and Group Medical
Practices.
This database covers over 250,000 key personnel
and facility contacts for more than 40,000 hospitals.
Information includes senior managers at each facility
(including purchasing, IT, nursing, etc.) along with
mailing address, direct-dial phone numbers and fax
numbers. It also includes updated information on
hospital ownership, beds, employees, admissions,
discharges and specialized services.
For the past 14 years, MedCom has maintained th= e most
comprehensive lists of hospitals. Our lists are 100%
telephone verified and updated every quarter. MedCom
continues to hold the nation's most extensive and
reliable mailing lists and databases of key decision-
makers in the health care market.

Available exclusively on CD-Rom, the data can be used
on an unlimited basis. It is easily exportable to other
programs for mailing or faxing purposes.
For a limited time, this extensive hospital database
is offered at an introductory price of $475
To order, please print this e-mail, complete the
information below and

fax it to 416-765-0029=

(tel: 416-765-0028).


NAME:

TITLE:

ORGANIZATION:

ADDRESS:

CITY:

POSTAL:

TEL:

FAX:

E-MAIL


----C90D1A06873612F74A7-- From kkeuujf@gte.net Sun Sep 19 08:38:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13679; Sun, 19 Sep 2004 08:38:39 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C913h-0003bc-98; Sun, 19 Sep 2004 08:44:49 -0400 Received: from [61.232.116.189] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C90xf-0005jh-0s; Sun, 19 Sep 2004 08:38:37 -0400 Message-ID: <254653567680251.03ff4114286uf@rogers.com> Received: from 41.208.221.27 by esgu83-v79.pmym714.rogers.com with DAV; Sun, 19 Sep 2004 12:33:52 -0100 Reply-To: "Government Grants " From: "Government Grants " To: Subject: Secrets of government grants revealed Date: Sun, 19 Sep 2004 19:34:52 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--47876469682926016654" X-Spam-Score: 7.4 (+++++++) X-Spam-Flag: YES X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 ----47876469682926016654 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, Did you Know that Lee Iacocca received 1.5 billion dollars guaranteed loan= for Chrysler and Steve Jobs received money from the government to start Apple = computer? It's True ! In fact, most of the Free Garnt Programs people qualify for, are usually t= aken advantage by rich people because the average person does not know who= to contact or how to fill out the paper work until now! It's now time for you to take advantage of your country's best kept secret= We make the process easy, we have spent years researching and compiling= a complete list that will help you find the money you deserve. Check now at: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= http://www.redgrand.com/ebooks/grants/index19.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= It is worth repeating again that this year over $1 Trillion dollars worth = of Grants (that's FREE money YOU Do Not have to pay back) will be given ou= t to over 30 millions people. If you=92re not getting your share it's because you don=92t know where to = go... Common Questions Q: Is obtaining a cash grant legal? A: It is 100% legal and yours for the asking. The government wants you to = take advantage of their grant programs. Q: How do I get paid? A: The Government agency to which you apply will send you an acceptance le= tter with your award amount. Soon afterwards, you will receive your cash g= rant. Q: I have problem with Credit. Will that interfere with me obtaining a fre= e cash grant? A: No. In fact, grants are never based on your credit. This is not a loan = so the conventional methods of getting a loan don't apply when obtaining a= free cash grant. Grants are even given out to individuals who are unemplo= yed! Free Garnts are excellent for people who are or near Bankruptcy or just ha= ve problem with Credit. DON'T MISS OUT!! Claim your Free Garnt Money TOD= AY!! Government grants and government loans aren't advertised!!! You're not getting your share of free goverment grants and goverment loans= because you don't know where to go... Goverment grants are given out by t= housands of government and non-profit organizations who don't spend a nick= el advertising their availability. These organizations are not going to co= me to you; you have to find them and go to them. In fact, there are thousa= nds of little-known organizations you can turn to, who can help you to get= a: $500,000 goverment grant to start or expand your business $50,000 goverment grant for you to go back to school $10,000 goverment grant to fix up your home $7,000 goverment grant to train for a new job $500 goverment grant to fix up your car $100,000 goverment grant to improve your neighborhood $400 goverment grant to pay your heating bill $50,000 goverment grant for you to travel the world $5,000 goverment grant for you to start a business at home $250,000 goverment grant to work on your invention $7,000 goverment grant to pay for your living expenses $1,000 goverment grant to pay for your prescription drugs Try the =93Grants Directory=94 - you could be the next person to end up wi= th $25,000 of the governments money! Get it here: http://www.redgrand.com/ebooks/grants/index19.htm Best regards, Jean Velasquez Grants Directory http://www.redgrand.com/ebooks/grants/index19.htm ----------- No thanks: http://get-it-online.info/soft/chair.php emblematic filly irwin millikan july lookout clio pend raphael bitternut s= witzerland coy whatnot wreak briny abyss bluegill furtive oases acrylic as= tound ballard smallpox cheryl ella cantle tulle hale bogy strove taken acc= rue monstrosity drugstore collaborate benedictine career anatomic ectopic = shawnee inform closure morristown diploma repulsion anastigmatic spencer s= cience crap challenge quasar contravention chamfer groove joyous gar penta= gonal birch scrawny begonia handbook intent lightning barbarous stockholm = bujumbura leeward baseball translate congratulate confront ah combinate ba= ck marcia five font hereby kalmuk suck artie irrigate forbidding fat middl= etown cheekbone employed vitriolic chemisorb norton brumidi balance gander= nazism antisemitic herschel pravda clear refectory chalcedony christenson= cuddly shipwreck optimum stockroom bacillus lighthouse albania sledge chi= ckadee frivolity morsel arabic engineer roach absorptive awry deteriorate = teleost camino polymeric kieffer can ascend sugar veterinary immigrate dea= th application soybean pharmacist affix quarry boniface brian ryder kaddis= h designate artistry polaris discus grisly carbonate chug demand dimple ba= rbarian attic brutal format activation roe chinchilla footmen vade wont ro= ughcast teresa ambiance clubroom adam ramrod waken disembowel chungking st= op grandeur dram archipelago skyline anionic crook helium severalty fourso= me corridor flaw corbel behead enstatite stanchion died tellurium anything= chicagoan mood filtrate asheville epigrammatic born bullhead bodied mulat= to incestuous ominous starve gambol wallaby species elute brainstorm lipid= deputation nymphomaniac chastise batch buff angelina ditch jenkins region= betelgeuse demountable isopleth auditory argillaceous lexington michaelan= gelo bender euler imperative jennie alfresco varian lange chad gloom allus= ion hershel efficacy counteract issuance compelled flag divest jones commo= dious loyalty copernicus deacon passionate antelope attack fried cam vishn= u focal best afternoon ascension breeches cotman garble method miterwort c= hariot pie quay immediate configuration befell television chevrolet coerci= ble chanson bakersfield vacuum clare deem frontiersman alphonse blocky pro= fligacy ethiopia reuters resolve anthem coverlet clone entropy seminole tr= ansposable regalia ----47876469682926016654-- From wo16281628@163.net Sun Sep 19 16:57:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14096 for ; Sun, 19 Sep 2004 16:57:27 -0400 (EDT) Message-Id: <200409192057.QAA14096@ietf.org> Received: from [218.18.130.182] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C98qR-0003ua-5b for sctp-impl-archive@ietf.org; Sun, 19 Sep 2004 17:03:43 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKsep1Lyw/NTCKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 20 Sep 2004 05:06:12 +0800 X-Priority: 2 X-Mailer: Foxmail 4.2 [cn] X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ßÈí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ãÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

****¹ú¼ÊÓòÃû£«ÐéÄâÖ÷»ú£«ÆóÒµÐÅÏ䣫ÍøÕ¾½¨Éè=£±£°£°£°Ôª****

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076»ò0755-83601633
       QQ£º282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From ysbjenldhe@cox.net Mon Sep 20 08:58:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28429; Mon, 20 Sep 2004 08:58:29 -0400 (EDT) Received: from yahoobb219207240053.bbtec.net ([219.207.240.53] helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9Nqc-0005L8-Va; Mon, 20 Sep 2004 09:04:53 -0400 Received: from 181.207.104.55 by web066.mail.yahoo.com; Mon, 20 Sep 2004 11:49:21 -0200 Message-ID: From: "Malinda Durham" To: ipr-wg-web-archive@ietf.org Subject: Over 150 prescript drugs Date: Mon, 20 Sep 2004 12:53:21 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--127918358115585" X-CS-IP: 168.50.144.178 X-Spam-Score: 34.2 (++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de ----127918358115585 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Start feeling better about yourself today, get the meds you need for one l= ow price


http://www.onlinecheapmeds.com/?refid=3D16

T0 U= n-Iist: onlinecheapmeds.com/o/index.html



RND: 738-775 ----127918358115585-- From AQXMMOGUTBEZUDUWA@ntl.com Mon Sep 20 14:24:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26754; Mon, 20 Sep 2004 14:24:55 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9SwW-0003qQ-J2; Mon, 20 Sep 2004 14:31:22 -0400 Received: from [219.137.111.212] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C9SqE-0005Av-PO; Mon, 20 Sep 2004 14:24:46 -0400 Received: from crowbait0imperfectralph (51.04.135.35) by mail88.219.137.111.212 (sketchbookcoop BP 4.3.188) id 26816J33YWU02IV060 for bmanet@ietf.org; Mon, 20 Sep 2004 20:18:56 +0100 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Leslie-Blanchard" From: "Leslie-Blanchard" To: bmanet@ietf.org Cc: maddogs@ietf.org, sic@ietf.org, mib@ietf.org, ssm@ietf.org, lemonade@ietf.org, ipr-wg-admin@ietf.org, hubmib-admin@ietf.org, olicy@ietf.org, directory-web-archive@ietf.org, sctp-impl-archive@ietf.org, entmib-request@ietf.org Subject: You're now accepted! Date: Mon, 20 Sep 2004 16:16:56 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--35452374957387837" Message-Id: X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----35452374957387837 Content-Type: text/html; charset="iso-6670-2" Content-Transfer-Encoding: 7Bit Dear Applicant,

This is an email to notify you that your application has been
accepted. You now can qualify for a $375,000 loan at 2.8%.

Fill out these final details to verify your infomation:
http://teamrate.com/?partid=aaks9 Thank You,
Account Manager
LoanStar Co.



not interested ----35452374957387837-- From IWFBX@interserve.com.hk Mon Sep 20 15:57:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06477 for ; Mon, 20 Sep 2004 15:57:05 -0400 (EDT) Message-Id: <200409201957.PAA06477@ietf.org> Received: from wbar1.tmp1-4-11-119-045.dsl-verizon.net ([4.11.119.45]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9UNb-0005r5-UL for sctp-impl-archive@ietf.org; Mon, 20 Sep 2004 16:03:33 -0400 Content-Class: urn:content-classes:message Reply-To: "Robbie Bragg" From: "Robbie Bragg" To: sctp-impl-archive@ietf.org Subject: didn't make the alumni list? Date: Mon, 20 Sep 2004 18:54:26 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0038FDAF4712A59E" X-Spam-Score: 9.2 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 25620135586de10c627e3628c432b04a ----0038FDAF4712A59E Content-Type: text/html; charset="iso-2817-B" Content-Transfer-Encoding: quoted-printable prostheses h 9

 

You De= serve A Colle.ge Deg.ree

Missing a piece of paper with a few letters a= fter your name?

Bach-el-ors, Mast-er-s, MBA, and Doctorate (PhD) deg/rees available=

no need to finish sc=3Dho=3Dol

 

=

 

 

 

 

to use Latourian terms. To stay in the framework= the playground Camper proceeds to note some of the most important feature= s of this skeleton; promises to describe it in detail by-and-bye; and is e= vidently in doubt as to the relation of this great "Pongo" to his "petit O= rang." but they insist that when they talk they are autho= rized by the real enunciator of their speech thereby making Freud's ideas = seem natural for people who never had read a word by him. In the same way = with as many individual links as there are people running the software Fig. 7.=96The Pongo Skull, sent by Radermacher to = Camper, after Camper's original sketches, as reproduced by Luc=E6. because= it seems that humans always have the initiative even in symmetrical analy= sis. Latour dismisses this claim by arguing "and touch sensors. Furthermor= e the robot is endowed with a ""behavior generating system" Turkle who has a background in psychoanalysis sees= the computer as a test object for post-modernity in the same way beasts a= nd dreams were for Charles Darwin (1809-82) and Sigmund Freud (1856-1939) = in modernity. For Freud's theories to be known outside sc which qualifies = entities such as homepages to have what I will call a virtual materiality.= This is a materiality that allows a homepage to exist in Cyberspace The j= ustice of this conclusion, indeed, is beyond [32] doubt=96for not only doe= s the "Eng=E9-ena" agree with Battell's "greater monster" in its hollow ey= es, its great stature, and its dun or iron-grey colour, but the only other= man-like Ape which inhabits these latitudes=96the Chimpanzee=96is at once= identified, by its smaller size, as the "lesser monster," and is excluded= from any possibility of being the "Pongo," by the fact that it is black a= nd not dun, to say nothing of the important circumstance already mentioned= that it still retains the name of "Engeko," or "Ench=E9-eko," by which Ba= ttell knew it. ----0038FDAF4712A59E-- From aydin@mail.eecis.udel.edu Mon Sep 20 16:09:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07798 for ; Mon, 20 Sep 2004 16:09:43 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9Ua3-0006Fj-HZ for sctp-impl-archive@ietf.org; Mon, 20 Sep 2004 16:16:12 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 20 Sep 2004 13:09:16 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8KK8cYN018937; Mon, 20 Sep 2004 13:08:38 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8KK7oZ4026451 for sctp-impl-filtered; Mon, 20 Sep 2004 13:07:52 -0700 (PDT) Message-Id: <200409202007.i8KK7oZ4026451@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095710869-26449-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: a question about SCTP fast recovery algo. List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Ilknur Aydin X-Nails-Approved: aydin@mail.eecis.udel.edu Date: Mon, 20 Sep 2004 15:50:18 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 This is a multi-part message in MIME format... ------------=_1095710869-26449-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hello all: I need help on understanding what should happen during fast recovery, especially with cwnd and ssthresh values. Section 2.8 of implguide10.txt (which I currently use) says "... while in fast recovery, the ssthresh and cwnd SHOULD NOT change for any destinations." The events that cause changes in cwnd and ssthresh are: (1) t3_rtx_timer expires --> ssthresh = max(cwnd/2, 2*mtu), cwnd = 1*mtu (2) another fast rtx --> ssthresh = max(cwnd/2, 2*mtu), cwnd = ssthresh (3) sack processing --> ssthresh remains the same, cwnd changes according to slow start or cong. avoidance based on some other criteria (like cwnd was in full use, cumAckPoint increased by the sack, etc). (4) cwnd degrade timer expires --> halve the cwnd, since the dest. is not in use. I handled case (3) above; that is, if assoc. is in fast recovery I prevent an incoming sack to change the cwnd of the dest addrs. For case (4) I did not do anything yet, but it seems I should not let any change in cwnd values either ?? Also, I am not sure how to handle case (1) and (2). For case (1), should I freeze t3_rtx timers and cause the timers not to expire during fast recovery (which probably does not make sense) ?? Or let the timers expire, do rtx of the chunks, but do not change cwnd and ssthresh values ? Or let the timers expire, exit fast recovery phase, change cwnd and ssthresh, and do rtx of the chunks?? And for case (2), even though there are new fast rtxes during fast recovery (this should be possible,?), I should not change ssthresh and cwnd ?? One of the scenarios I try is as follows: - Sender S and receiver R are both single homed - initial cwnd value is 4380 bytes, according to 2.30 of implguide10.txt - mtu is 1500 bytes - 10 data chunks of size 1000 each are sent - chunks 101, 106, 107, 108, 109 are dropped (to create the scenario) After 4th sack, 101 is fast rtxed and assoc. enters to the fast recovery, where fast recovery exit point is tsn 109. Below picture shows how my implementation is working currently. ??? marks show the points where I am not sure what to do exactly. Sender S Receiver R cwnd=4380 ---100-------------------> ---101------------------->X ---102-------------------> ---103-------------------> ---104------------------->(cwnd could be exceeded up to 1*mtu) <---SACK for 102--------- cwnd=5880 ---105-------------------> ---106------------------->X ---107------------------->X <---SACK for 103--------- ---108------------------->X <---SACK for 104--------- ---109------------------->X <---SACK for 105--------- ssthresh=3000 cwnd=3000 enter fast recovery,recover=109 do fast rtx of 101 |---fast rtx 101---------> <---SACK for rtxed 101------ still in fast recovery because only [101-105] is acked . . . eventually t3_rtx_timer expires ssthresh=1500(???) cwnd=1500 (???) mark all the current outstanding chunks (i.e. 106, 107, 108, 109) for rtx, but assoc. is still in fast recovery??? ---rtx 106-------------------> <---SACK for rtxed 106------ ---rtx 107-------------------> <---SACK for rtxed 107------ ---rtx 108-------------------> <---SACK for rtxed 108------ ---rtx 109-------------------> <---SACK for rtxed 109------ since [101-109] is acked exit fast recovery eventually. I would appreciate any comments/explanations/pointers. best regards, Ilknur Aydin DEGAS Networking Group Dept. of Computer and Information Sciences University of Delaware http://www.cis.udel.edu/~aydin ------------=_1095710869-26449-0-- From iyengar@mail.eecis.udel.edu Mon Sep 20 18:39:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01588 for ; Mon, 20 Sep 2004 18:39:22 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9Wuu-0004Vp-CV for sctp-impl-archive@ietf.org; Mon, 20 Sep 2004 18:45:52 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2004 15:50:42 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8KMcNwp013998; Mon, 20 Sep 2004 15:38:24 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8KMbuZ4028412 for sctp-impl-filtered; Mon, 20 Sep 2004 15:37:58 -0700 (PDT) Message-Id: <200409202237.i8KMbuZ4028412@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095719876-28410-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: a question about SCTP fast recovery algo. List-Id: sctp-impl To: Ilknur Aydin From: Janardhan Iyengar Cc: sctp-impl@external.cisco.com X-Nails-Approved: iyengar@mail.eecis.udel.edu Date: Mon, 20 Sep 2004 18:26:20 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format... ------------=_1095719876-28410-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hi Ilknur, > (1) t3_rtx_timer expires --> ssthresh = max(cwnd/2, 2*mtu), cwnd = 1*mtu > (2) another fast rtx --> ssthresh = max(cwnd/2, 2*mtu), cwnd = ssthresh > (3) sack processing --> ssthresh remains the same, cwnd changes according > to slow start or cong. avoidance based on some other criteria (like cwnd > was in full use, cumAckPoint increased by the sack, etc). > (4) cwnd degrade timer expires --> halve the cwnd, since the dest. is not > in use. [...] > > For case (1), should I freeze t3_rtx timers and cause the timers not to > expire during fast recovery (which probably does not make sense) ?? Or let > the timers expire, do rtx of the chunks, but do not change cwnd and > ssthresh values ? Or let the timers expire, exit fast recovery phase, > change cwnd and ssthresh, and do rtx of the chunks?? I am not sure what the correct behavior here should be, but I think that the cwnd should be reduced (set to 1MTU) when a timeout occurs, no matter what. So in this case, I think the sender should let the timer expire, set the cwnd to 1MTU at expiration, and exit fast recovery - after a timeout, most things are just reset. (I'm trying to think of a scenario other than loss of a fast rtx that could cause a timeout during fast recovery..) > And for case (2), even though there are new fast rtxes during fast > recovery (this should be possible,?), I should not change ssthresh and > cwnd ?? Yes, that is the idea with fast recovery - multiple rtxs within the same window will not cause the window to reduce multiple times. > eventually t3_rtx_timer > expires > ssthresh=1500(???) > cwnd=1500 (???) I think so. If not, there will be a burst of rtxs later on when the ack for the first timeout retransmission is received. > mark all the current > outstanding chunks > (i.e. 106, 107, 108, 109) > for rtx, but assoc. > is still in fast recovery??? > ---rtx 106-------------------> > <---SACK for rtxed 106------ If cwnd was not set to 1MTU earlier at the timeout, this ack would allow for 3 rtxs to go out. I'm not sure if this is bad, but is certainly not conservative. regards, jana ------------=_1095719876-28410-0-- From immaad@gmail.com Mon Sep 20 22:35:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17857 for ; Mon, 20 Sep 2004 22:35:47 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9abj-0000Ou-6p for sctp-impl-archive@ietf.org; Mon, 20 Sep 2004 22:42:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2004 19:47:09 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8L2Ytbs024805; Mon, 20 Sep 2004 19:34:55 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8L2YPZ4001520 for sctp-impl-filtered; Mon, 20 Sep 2004 19:34:27 -0700 (PDT) Message-Id: <200409210234.i8L2YPZ4001520@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095734065-1518-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Simple question List-Id: sctp-impl To: sctp-impl@external.cisco.com From: imad X-Nails-Approved: immaad@gmail.com Date: Tue, 21 Sep 2004 07:30:49 +0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format... ------------=_1095734065-1518-0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary i am new to sctp. i have installed the rpms downloaded from the sctp website but still i am unable to create a sctp socket. can someone please write some simple steps required to create an sctp socket. here is my program. it does compile successfully but the socket function always return -1. whats the problem. #include #include #include int main() { int sd = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); printf("\n Socket: %d \n",sd); return 0; } -- Regards Imad ------------=_1095734065-1518-0-- From sri@us.ibm.com Mon Sep 20 23:20:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20425 for ; Mon, 20 Sep 2004 23:20:06 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9bIY-00014B-Ud for sctp-impl-archive@ietf.org; Mon, 20 Sep 2004 23:26:39 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2004 20:20:25 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8L3It3c002337; Mon, 20 Sep 2004 20:18:56 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8L3IfZ4002096 for sctp-impl-filtered; Mon, 20 Sep 2004 20:18:43 -0700 (PDT) Message-Id: <200409210318.i8L3IfZ4002096@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095736721-2094-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Simple question List-Id: sctp-impl To: imad From: Sridhar Samudrala Cc: sctp-impl@external.cisco.com X-Nails-Approved: sri@us.ibm.com Date: Mon, 20 Sep 2004 20:13:32 -0700 (PDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format... ------------=_1095736721-2094-0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary On Tue, 21 Sep 2004, imad wrote: > i am new to sctp. > i have installed the rpms downloaded from the sctp website but still i > am unable to create a sctp socket. > can someone please write some simple steps required to create an sctp socket. > > here is my program. it does compile successfully but the socket > function always return -1. > whats the problem. I guess you are trying this on linux as you seem to be using the rpms from lksctp website. Do you have SCTP support built into the kernel or as a module? If it is configured as a module, you need to load it using modprobe sctp -Sridhar > > #include > #include > #include > > int main() { > > int sd = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > printf("\n Socket: %d \n",sd); > > return 0; > } > > > -- > > Regards > Imad > ------------=_1095736721-2094-0-- From torbjorn.andersson@kau.se Tue Sep 21 03:49:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20101 for ; Tue, 21 Sep 2004 03:49:17 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9fV8-00057N-K2 for sctp-impl-archive@ietf.org; Tue, 21 Sep 2004 03:55:51 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 21 Sep 2004 00:48:54 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8L7mB3c026587; Tue, 21 Sep 2004 00:48:13 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8L7lhZ4005474 for sctp-impl-filtered; Tue, 21 Sep 2004 00:47:45 -0700 (PDT) Message-Id: <200409210747.i8L7lhZ4005474@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095752863-5466-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: congestion control questions List-Id: sctp-impl To: From: =?iso-8859-1?Q?Torbj=F6rn_Andersson?= X-Nails-Approved: torbjorn.andersson@kau.se Date: Tue, 21 Sep 2004 09:48:26 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format... ------------=_1095752863-5466-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary I have previously done studies on SCTP with ULPs that have a fixed traffic patterns. Now I'm testing SCTP with dynamic traffic patterns, where burst of messages are generated by the ULP at a specified interval. My goal is to study how the idle time between bursts affects the cwnd. According to RFC 2960: Page 88: (Slow-Start) "When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 2*MTU) per RTO." Page 89: (Congestion avoidance) "Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd / 2, 2*MTU) per RTO." According to implementers guide: --------- 1: New text: (Section 6.1) --------- D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd as follows: if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + Max.Burst*MTU Or it MAY be applied by strictly limiting the number of packets emitted by the output routine. E) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow. My findings: I have found that is seems that the "kame" implementation on SCTP does not follow the RFC specification and cut down the cwnd during my idle periods, which sometimes are up to 3s in my tests. The RTT value of my network is 150ms and the RTO estimate is likely to be smaller than 3s. The RTO_MIN values is not altered by my ULP so if the "kame" implementation has its RTO_MIN set to 1 s then the cwnd would have been cut down at least two times. The MAX.BURST rule from the impl-guide seems not to be implemented in "kame". My bursts are 40 messages long, 40 * 500 bytes, and therefore should my ULP be affected by this rule. Question: What are your thoughts about all this? Will the "kame" implementation in the future implement these rules/algorithm? -------------------------------------------------------------- | Torbjörn Andersson phone: +46 54 700 11 61 | Computer Science fax: +46 54 700 18 28 | Karlstad University URL: http://www.cs.kau.se/~tora --------------------------------------------------------------- ------------=_1095752863-5466-0-- From evelina.marling@gvcc.net Tue Sep 21 04:36:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23331 for ; Tue, 21 Sep 2004 04:36:26 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9gEc-0005xf-DC for sctp-impl-archive@ietf.org; Tue, 21 Sep 2004 04:43:00 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2004 01:37:41 -0700 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8L8ZAbs005751; Tue, 21 Sep 2004 01:35:10 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8L8YtZ4006090 for sctp-impl-filtered; Tue, 21 Sep 2004 01:34:57 -0700 (PDT) Message-Id: <200409210834.i8L8YtZ4006090@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095755695-6088-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: sctp socket List-Id: sctp-impl To: sctp-impl@external.cisco.com From: "Evelina Santocono (Marling)" X-Nails-Approved: evelina.marling@gvcc.net Date: Tue, 21 Sep 2004 09:57:00 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 This is a multi-part message in MIME format... ------------=_1095755695-6088-0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary hallo, i'm new with sctp and i nee a socket of sctp can someone send me one thanks evelina ------------=_1095755695-6088-0-- From rrs@cisco.com Tue Sep 21 06:32:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01566 for ; Tue, 21 Sep 2004 06:32:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9i2f-00081t-V9 for sctp-impl-archive@ietf.org; Tue, 21 Sep 2004 06:38:38 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2004 03:33:33 -0700 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8LAVBSI000059; Tue, 21 Sep 2004 03:31:11 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8LAUoZ4007756 for sctp-impl-filtered; Tue, 21 Sep 2004 03:30:52 -0700 (PDT) Message-Id: <200409211030.i8LAUoZ4007756@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095762650-7754-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: a question about SCTP fast recovery algo. List-Id: sctp-impl To: Janardhan Iyengar From: Randall Stewart Cc: Ilknur Aydin , sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Tue, 21 Sep 2004 06:29:30 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format... ------------=_1095762650-7754-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hmm.. I think that this wording needs to be changed.. and its a sad that I just sent off version 11 yesterday :-o I think that that sentence should only apply to 2 and 3 I think... not 1 for sure and probably not 4 since the "if you don't use it you loose it" principle still applies even when you are in FR. Now one other question I have on this, is why other destinations cannot increase.. thinking on this more.. is why other destinations should not increase.... If for some reason the ULP switches primary's to some other destination why not let it grow if its eligible for growing? It cannot grow if the cum-ack does not move, thats already present in the base spec... so the only way you will grow is if the fast recovery is somewhere above the cum-ack point but NOT at it. Probably a very unlikely thing if one thinks about it.. so the restriction most likely for growth will never happen. Hmm... its probably not so big of deal.. but we do need to clearify that 1/4 reductions are still going to happen. R Janardhan Iyengar wrote: > Hi Ilknur, > > >>(1) t3_rtx_timer expires --> ssthresh = max(cwnd/2, 2*mtu), cwnd = 1*mtu >>(2) another fast rtx --> ssthresh = max(cwnd/2, 2*mtu), cwnd = ssthresh >>(3) sack processing --> ssthresh remains the same, cwnd changes according >>to slow start or cong. avoidance based on some other criteria (like cwnd >>was in full use, cumAckPoint increased by the sack, etc). >>(4) cwnd degrade timer expires --> halve the cwnd, since the dest. is not >>in use. > > > [...] > > >>For case (1), should I freeze t3_rtx timers and cause the timers not to >>expire during fast recovery (which probably does not make sense) ?? Or let >>the timers expire, do rtx of the chunks, but do not change cwnd and >>ssthresh values ? Or let the timers expire, exit fast recovery phase, >>change cwnd and ssthresh, and do rtx of the chunks?? > > > I am not sure what the correct behavior here should be, but I think that > the cwnd should be reduced (set to 1MTU) when a timeout occurs, no matter > what. So in this case, I think the sender should let the timer expire, set > the cwnd to 1MTU at expiration, and exit fast recovery - after a timeout, > most things are just reset. (I'm trying to think of a scenario other than > loss of a fast rtx that could cause a timeout during fast recovery..) > > >>And for case (2), even though there are new fast rtxes during fast >>recovery (this should be possible,?), I should not change ssthresh and >>cwnd ?? > > > Yes, that is the idea with fast recovery - multiple rtxs within the same > window will not cause the window to reduce multiple times. > > >>eventually t3_rtx_timer >>expires >>ssthresh=1500(???) >>cwnd=1500 (???) > > > I think so. If not, there will be a burst of rtxs later on when the ack > for the first timeout retransmission is received. > > >>mark all the current >>outstanding chunks >>(i.e. 106, 107, 108, 109) >>for rtx, but assoc. >>is still in fast recovery??? >> ---rtx 106-------------------> >> <---SACK for rtxed 106------ > > > If cwnd was not set to 1MTU earlier at the timeout, this ack would allow > for 3 rtxs to go out. I'm not sure if this is bad, but is > certainly not conservative. > > regards, > jana > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1095762650-7754-0-- From rrs@cisco.com Tue Sep 21 06:42:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02155 for ; Tue, 21 Sep 2004 06:42:32 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9iCq-0008Bm-Mq for sctp-impl-archive@ietf.org; Tue, 21 Sep 2004 06:49:09 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 21 Sep 2004 03:47:02 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8LAfjSI005954; Tue, 21 Sep 2004 03:41:46 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8LAfaZ4007950 for sctp-impl-filtered; Tue, 21 Sep 2004 03:41:38 -0700 (PDT) Message-Id: <200409211041.i8LAfaZ4007950@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095763295-7948-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: congestion control questions List-Id: sctp-impl To: =?ISO-8859-1?Q?Torbj=F6rn_Andersson?= From: Randall Stewart Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Tue, 21 Sep 2004 06:40:17 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format... ------------=_1095763295-7948-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Torbjörn Andersson wrote: > I have previously done studies on SCTP with ULPs that have a fixed > traffic patterns. Now I'm testing SCTP with dynamic traffic patterns, > where burst of messages are generated by the ULP at a specified > interval. My goal is to study how the idle time between bursts affects > the cwnd. > > According to RFC 2960: > > Page 88: (Slow-Start) > "When the endpoint does not transmit data on a given transport > address, the cwnd of the transport address should be adjusted to > max(cwnd/2, 2*MTU) per RTO." > > Page 89: (Congestion avoidance) > "Same as in the slow start, when the sender does not transmit DATA > on a given transport address, the cwnd of the transport address > should be adjusted to max(cwnd / 2, 2*MTU) per RTO." > > > According to implementers guide: > --------- > 1: New text: (Section 6.1) > --------- > D) When the time comes for the sender to transmit new DATA chunks, > the > protocol parameter Max.Burst SHOULD be used to limit the number > of > packets sent. The limit MAY be applied by adjusting cwnd as > follows: > > > if((flightsize + Max.Burst*MTU) < cwnd) > cwnd = flightsize + Max.Burst*MTU > > > Or it MAY be applied by strictly limiting the number of packets > emitted by the output routine. > > E) Then, the sender can send out as many new DATA chunks as Rule A > and Rule B above allow. > > > My findings: > > I have found that is seems that the "kame" implementation on SCTP does > not follow the RFC specification and cut down the cwnd during my idle > periods, which sometimes are up to 3s in my tests. Hmm.. this I know is true.. if one DOES NOT turn off the max.burst feature during compile, then it will NOT do cwnd degrade.. The reason being is that I feel that having a max.burst of 4 packets removes the need for the cwnd degrade since you won't be able to send more than 4 packets at a time anyway... which is now what things resort to at idle time.... so why have the degrade? > The RTT value of my network is 150ms and the RTO estimate is likely to > be smaller than 3s. The RTO_MIN values is not altered by my ULP so if > the "kame" implementation has its RTO_MIN set to 1 s then the cwnd would > have been cut down at least two times. > > The MAX.BURST rule from the impl-guide seems not to be implemented in > "kame". My bursts are 40 messages long, 40 * 500 bytes, and therefore > should my ULP be affected by this rule. Hmm... so you have 20000 bytes queued in burst of say 3 seconds or about 14 packets of 1500 byte MTUs... 1) Which style of max.burst is compiled? 2) What amount is max.burst set to? -- a 'sysctl -a | grep and look at net.inet.sctp.maxburst will tell. This could be a bug.. depending on style.. To tell style.. the default is to count packets but the alternate is gained by defining SCTP_USE_ALLMAN_BURST when you compile (or in a .h). This gets the formula version. This most likely is a bug... since the 20000 bytes should be queued right away (removing the opps for sending from the app) and then from there its just a matter of SACK's triggering the 4pkts at a time... I have not tested it in the way you are doing so (with small packets).. so it would not surprise me if the default method had a problem.. the ALLMAN version would not since it whacks the cwnd.. R > > Question: > > What are your thoughts about all this? Will the "kame" implementation in > the future implement these rules/algorithm? > > > -------------------------------------------------------------- > | Torbjörn Andersson phone: +46 54 700 11 61 > | Computer Science fax: +46 54 700 18 28 > | Karlstad University URL: http://www.cs.kau.se/~tora > --------------------------------------------------------------- > > > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1095763295-7948-0-- From qmyik@rogers.com Tue Sep 21 14:46:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09320; Tue, 21 Sep 2004 14:46:54 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9pld-0000k6-Ae; Tue, 21 Sep 2004 14:53:33 -0400 Received: from d47-69-201-212.try.wideopenwest.com ([69.47.212.201]) by mx2.foretec.com with smtp (Exim 4.24) id 1C9pf8-0004FL-5W; Tue, 21 Sep 2004 14:46:50 -0400 X-Message-Info: UBMeU834vcxBaeAKm4hh4VT2KCxbfWdbt Received: from gz30.bright.net (202.13.206.97) by nhn2-xny.bright.net with Microsoft SMTPSVC(5.0.2195.6824); Tue, 21 Sep 2004 22:45:30 +0300 Received: from bedimminggigawattmillineryhwm2 (gimbel102.144.252.128) by bright.net (evzt18) with SMTP id <12057548t25506rl> (Authid: GarthMckay); Tue, 21 Sep 2004 13:46:30 -0600 From: "Bulls Eye Investing" To: "'Geopriv'" Subject: Market Movers and Shakers Date: Tue, 21 Sep 2004 18:46:30 -0100 Message-ID: <157lt514o0$168yif8z8$43s11znf@collidelitanyuv98> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--43514381537733417" X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 ----43514381537733417 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Breaking News At The Close Monday September 20, 2004 Genex Pharmaceuticals - 0TCBB Stock Symbol: GENX The Good News Just Keeps on Coming for GENX. Genex Pharmaceutical Signs New Product Distribution Agreements Targeting China's Three Weal.thiest Provinces With a Population of 100 million, Company Sees Record Third Quarter 2004 Earnings Monday September 20, 3:59 pm ET TIANJIN, China BUSINESS WIRE Sept. 20, 2004 Genex Pharmaceutical, Inc.; stock symbol: GENX; a Delaware corporation, is a pr0fitable biomedical technology company with a revolutionary product for treating various bone-related injuries called Reconstituted Bone Xenograft, RBX, which is a medical device approved by the SFDA, Chinese State Food and Drug Administration. RBX is suitable for compound or complex bone fractures, compression fractures and intractable fractures, bone defects, vertebral column or joint rehabilitation and for bone absence after tumor removal such as a bone cyst. The Company announced that it has signed new product distribution agreements with three national pharmaceutical distribution companies located in the heavily populated JiangSu, ZheJiang and Shanghai areas. These distributors have a broad distribution network in these respective areas. These three areas are among the most populated and most economically developed in China. These three areas collectively have a population exceeding 120 milli0n. The greater metropolitan Shanghai area alone has a population of approximately 25 milli0n. Mr. Fuzhi Song, Chairman and CEO of Genex, stated, "The addition of these three national pharmaceutical distributors covering some of China's weal.thiest areas is significant to our national distribution network. Our new distribution agreements cover almost 85% of such a large population base. As we continue to expand our national distribution network, we expect strong third quarter financial performance ending September 30." Genex Pharmaceutical's RBX is well suited to treat numerous bone-related injuries. Industry statistics estimate that over 15 milli0n people in China suffer from some sort of bone defect, and the Company's RBX product is targeted to this potentially huge market. Other applications of RBX include treatment of dental decay, from which approximately 40 milli0n people every year in China require treatment. Press Release Source: Genex Pharmaceutical, Inc. About Genex Pharmaceutical, Inc. Genex Pharmaceutical, Inc. is a biomedical technology company with distinctive proprietary technology for an orthopedic device that treats bone-related injuries. Headquartered in Tianjin, China, the Company manufactures and distributes Reconstituted Bone Xenograft, RBX, to 400 hospitals in 22 provinces throughout mainland China. RBX is approved by the State Food and Drug Administration, SFDA, in China, the Chinese government agency that regulates drugs and medical devices. RBX offers a modern alternative to traditional methods of treating orthopedic injuries. Read the announcements GENX has made. Look at the Company. Read the Filings. Do you see the Potential for Explosive Growth? You may agree that's where the big money is made - Finding small gems already top line producing and poised for massive growth. Consider GENX for your portfolio today. Good Luck and Successful Investing. Safe Harb0r Statement Statements about the Company's future expectations, including future revenue and earnings and all other statements in this press release, other than historical facts, are f0rward-looking statements and are made pursuant to safe harbor provisions of the Securities Exchange Act of 1934. Such f0rward-looking statements involve risks and uncertainties and are subject to change at any time. The Company's actual results could differ materially from expected results. In reflecting subsequent events or circumstances, the Company undertakes no 0bligation to update f0rward-looking statements. DIS-CLAIMER: Information within this ema-il contains F0RWARD looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be forward looking statements. Forward looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as projects , foresee, expects, will, anticipates, estimates, believes, understands or that by statements indicating certain actions may, could, or might occur. As with many micro-cap stocks, today's company has additional risk factors worth noting. Those factors include: a limited operating history: the company advancing cash to related parties and a shareholder on an unsecured basis: one vendor, a related party through a majority stockholder, supplies ninety-seven percent of the company's raw materials: reliance on two customers for over fifty percent of their business and numerous related party transactions and the need to raise capital.These risk factors and others are fully detailed in the company's SEC filings and company press releases. We urge you to read them before you invest. The Publisher of this letter does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading.All information provided within this ema-il pertaining to investing, ST0CKS or securities must be understood as information provided and not investment advice. The Publisher of this letter advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this ema-il. None of the material within this report shall be construed as any kind of investment advice or solicitation. Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The Publisher of this letter is not a registered investment ADVIS0R. Subscribers should not view information herein as legal, tax, accounting or investment advice. Any reference to past performance s of companies are specially selected to be referenced based on the favorable performance of these companies. You would need perfect timing to acheive the results in the examples given. There can be no assurance of that happening.Remember, as always, past performance is ne-ver indicative of future results and a thorough due diligence effort, including a review of a company's filings, should be completed prior to investing. In compliance with the Securities Act of 1933, Section17 b, The Publisher of this letter discloses the receipt of fourty two thousand dollars from a third party, not an officer, director or affiliate shareholder for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid adver-tisement and is not without bias. All factual information in this report was gathered from public sources, including but not limited to Company Websites, SEC Filings and Company Press Releases. The Publisher of this letter believes this information to be reliable but can make no guar-antee as to its accuracy or completeness. Use of the material within this ema-il constitutes your acceptance of these terms. ----43514381537733417-- From immaad@gmail.com Tue Sep 21 17:10:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00457 for ; Tue, 21 Sep 2004 17:10:03 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9s0C-0006eg-7n for sctp-impl-archive@ietf.org; Tue, 21 Sep 2004 17:16:45 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 21 Sep 2004 14:14:37 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8LL95SI027098; Tue, 21 Sep 2004 14:09:05 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8LL8dZ4016162 for sctp-impl-filtered; Tue, 21 Sep 2004 14:08:41 -0700 (PDT) Message-Id: <200409212108.i8LL8dZ4016162@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095800919-16160-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sctp socket List-Id: sctp-impl To: "Evelina Santocono (Marling)" , sctp-impl@external.cisco.com From: imad X-Nails-Approved: immaad@gmail.com Date: Wed, 22 Sep 2004 01:53:03 +0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format... ------------=_1095800919-16160-0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary i am also searching for it here but no one listens. On Tue, 21 Sep 2004 09:57:00 +0200, Evelina Santocono (Marling) wrote: > hallo, > i'm new with sctp and i nee a socket of sctp > can someone send me one > > thanks > > evelina > > -- Regards Imad ------------=_1095800919-16160-0-- From bidulock@openss7.org Tue Sep 21 17:42:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02696 for ; Tue, 21 Sep 2004 17:42:50 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9sVn-0007Fu-0b for sctp-impl-archive@ietf.org; Tue, 21 Sep 2004 17:49:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2004 14:44:18 -0700 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8LLfmwp018951; Tue, 21 Sep 2004 14:41:49 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8LLffZ4016650 for sctp-impl-filtered; Tue, 21 Sep 2004 14:41:43 -0700 (PDT) Message-Id: <200409212141.i8LLffZ4016650@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095802900-16648-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sctp socket List-Id: sctp-impl To: imad From: "Brian F. G. Bidulock" Cc: "Evelina Santocono (Marling)" , sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Tue, 21 Sep 2004 15:35:32 -0600 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This is a multi-part message in MIME format... ------------=_1095802900-16648-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary imad, man socket --brian On Wed, 22 Sep 2004, imad wrote: > i am also searching for it here but no one listens. > > > On Tue, 21 Sep 2004 09:57:00 +0200, Evelina Santocono (Marling) > wrote: > > hallo, > > i'm new with sctp and i nee a socket of sctp > > can someone send me one > > > > thanks > > > > evelina > > > > > > > > -- > > Regards > Imad -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1095802900-16648-0-- From torbjorn.andersson@kau.se Wed Sep 22 03:37:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09806 for ; Wed, 22 Sep 2004 03:37:10 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA1n7-0000G6-Fm for sctp-impl-archive@ietf.org; Wed, 22 Sep 2004 03:43:57 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 22 Sep 2004 00:36:35 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8M7ZsYN003648; Wed, 22 Sep 2004 00:35:55 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8M7ZEZ4025361 for sctp-impl-filtered; Wed, 22 Sep 2004 00:35:16 -0700 (PDT) Message-Id: <200409220735.i8M7ZEZ4025361@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095838514-25359-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SV: congestion control questions List-Id: sctp-impl To: "'Randall Stewart'" From: =?iso-8859-1?Q?Torbj=F6rn_Andersson?= Cc: X-Nails-Approved: torbjorn.andersson@kau.se Date: Wed, 22 Sep 2004 09:36:18 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This is a multi-part message in MIME format... ------------=_1095838514-25359-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Thank you Randall for the answers. I have some more questions/comments below, please read them. > -----Ursprungligt meddelande----- > Från: Randall Stewart [mailto:rrs@cisco.com] > Skickat: den 21 september 2004 12:40 > Till: Torbjörn Andersson > Kopia: sctp-impl@external.cisco.com > Ämne: Re: congestion control questions > > Torbjörn Andersson wrote: > > I have previously done studies on SCTP with ULPs that have a fixed > > traffic patterns. Now I'm testing SCTP with dynamic traffic patterns, > > where burst of messages are generated by the ULP at a specified > > interval. My goal is to study how the idle time between bursts affects > > the cwnd. > > > > According to RFC 2960: > > > > Page 88: (Slow-Start) > > "When the endpoint does not transmit data on a given transport > > address, the cwnd of the transport address should be adjusted to > > max(cwnd/2, 2*MTU) per RTO." > > > > Page 89: (Congestion avoidance) > > "Same as in the slow start, when the sender does not transmit DATA > > on a given transport address, the cwnd of the transport address > > should be adjusted to max(cwnd / 2, 2*MTU) per RTO." > > > > > > According to implementers guide: > > --------- > > 1: New text: (Section 6.1) > > --------- > > D) When the time comes for the sender to transmit new DATA chunks, > > the > > protocol parameter Max.Burst SHOULD be used to limit the number > > of > > packets sent. The limit MAY be applied by adjusting cwnd as > > follows: > > > > > > if((flightsize + Max.Burst*MTU) < cwnd) > > cwnd = flightsize + Max.Burst*MTU > > > > > > Or it MAY be applied by strictly limiting the number of packets > > emitted by the output routine. > > > > E) Then, the sender can send out as many new DATA chunks as Rule A > > and Rule B above allow. > > > > > > My findings: > > > > I have found that is seems that the "kame" implementation on SCTP does > > not follow the RFC specification and cut down the cwnd during my idle > > periods, which sometimes are up to 3s in my tests. > Hmm.. this I know is true.. if one DOES NOT turn off the > max.burst feature during compile, then it will NOT do > cwnd degrade.. I have not turned off the max.burst feature when I compiled "Kame". However I see sadly no traces of the max.burst feature in my results (tcpdump,ULP times, etc). Maybe is there a bug that is affecting me. > > The reason being is that I feel that having a max.burst of > 4 packets removes the need for the cwnd degrade since you > won't be able to send more than 4 packets at a time > anyway... which is now what things resort to at idle > time.... so why have the degrade? Is the RFC statement for cwnd degrading optional? The RFC uses the wording "should" and not "SHOULD". Is "should" optional? When I study the max.burst algorithm I find it affecting applications that have idle periods greater than RTO_MIN, => flightsize == 0. I guess there is a motivation for this algorithm somewhere. Is there an article describing this somewhere? > > The RTT value of my network is 150ms and the RTO estimate is likely to > > be smaller than 3s. The RTO_MIN values is not altered by my ULP so if > > the "kame" implementation has its RTO_MIN set to 1 s then the cwnd would > > have been cut down at least two times. > > > > The MAX.BURST rule from the impl-guide seems not to be implemented in > > "kame". My bursts are 40 messages long, 40 * 500 bytes, and therefore > > should my ULP be affected by this rule. > > Hmm... so you have 20000 bytes queued in burst of say 3 seconds > or about 14 packets of 1500 byte MTUs... > > 1) Which style of max.burst is compiled? > 2) What amount is max.burst set to? -- a 'sysctl -a | grep > and look at net.inet.sctp.maxburst > will tell. > > This could be a bug.. depending on style.. > > To tell style.. the default is to count packets but the > alternate is gained by defining > SCTP_USE_ALLMAN_BURST > when you compile (or in a .h). This gets the formula > version. > > > This most likely is a bug... since the 20000 bytes > should be queued right away (removing the opps for sending > from the app) and then from there its just a matter > of SACK's triggering the 4pkts at a time... Sadly I'm not seeing this. > > I have not tested it in the way you are doing so (with > small packets).. so it would not surprise me if the > default method had a problem.. the > ALLMAN version would not since it whacks the cwnd.. > > R > > > > Question: > > > > What are your thoughts about all this? Will the "kame" implementation in > > the future implement these rules/algorithm? > > > > > > -------------------------------------------------------------- > > | Torbjörn Andersson phone: +46 54 700 11 61 > > | Computer Science fax: +46 54 700 18 28 > > | Karlstad University URL: http://www.cs.kau.se/~tora > > --------------------------------------------------------------- > > > > > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 ------------=_1095838514-25359-0-- From rrs@cisco.com Wed Sep 22 17:05:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15817 for ; Wed, 22 Sep 2004 17:05:19 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAEPO-0000Qd-13 for sctp-impl-archive@ietf.org; Wed, 22 Sep 2004 17:12:15 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 22 Sep 2004 14:17:01 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8ML4F3c014448; Wed, 22 Sep 2004 14:04:16 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8ML3fZ4007593 for sctp-impl-filtered; Wed, 22 Sep 2004 14:03:43 -0700 (PDT) Message-Id: <200409222103.i8ML3fZ4007593@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1095887020-7591-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SV: congestion control questions List-Id: sctp-impl To: =?ISO-8859-1?Q?Torbj=F6rn_Andersson?= From: Randall Stewart Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Wed, 22 Sep 2004 17:02:41 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 This is a multi-part message in MIME format... ------------=_1095887020-7591-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Torbjörn Andersson wrote: > Thank you Randall for the answers. I have some more > questions/comments below, please read them. > > >> -----Ursprungligt meddelande----- Från: Randall Stewart >> [mailto:rrs@cisco.com] Skickat: den 21 september 2004 12:40 Till: >> Torbjörn Andersson Kopia: sctp-impl@external.cisco.com Ämne: Re: >> congestion control questions >> >> Torbjörn Andersson wrote: >> >>> I have previously done studies on SCTP with ULPs that have a >>> fixed traffic patterns. Now I'm testing SCTP with dynamic traffic >>> > > patterns, > >>> where burst of messages are generated by the ULP at a specified >>> interval. My goal is to study how the idle time between bursts > > affects > >>> the cwnd. >>> >>> According to RFC 2960: >>> >>> Page 88: (Slow-Start) "When the endpoint does not transmit data >>> on a given transport address, the cwnd of the transport address >>> should be adjusted to max(cwnd/2, 2*MTU) per RTO." >>> >>> Page 89: (Congestion avoidance) "Same as in the slow start, when >>> the sender does not transmit DATA on a given transport address, >>> the cwnd of the transport address should be adjusted to max(cwnd >>> / 2, 2*MTU) per RTO." >>> >>> >>> According to implementers guide: --------- 1: New text: >>> (Section 6.1) --------- D) When the time comes for the sender to >>> transmit new DATA > > chunks, > >>> the protocol parameter Max.Burst SHOULD be used to limit the > > number > >>> of packets sent. The limit MAY be applied by adjusting cwnd as >>> follows: >>> >>> >>> if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + >>> Max.Burst*MTU >>> >>> >>> Or it MAY be applied by strictly limiting the number of > > packets > >>> emitted by the output routine. >>> >>> E) Then, the sender can send out as many new DATA chunks as > > Rule A > >>> and Rule B above allow. >>> >>> >>> My findings: >>> >>> I have found that is seems that the "kame" implementation on SCTP >>> > > does > >>> not follow the RFC specification and cut down the cwnd during my > > idle > >>> periods, which sometimes are up to 3s in my tests. >> >> Hmm.. this I know is true.. if one DOES NOT turn off the max.burst >> feature during compile, then it will NOT do cwnd degrade.. > > > I have not turned off the max.burst feature when I compiled "Kame". > However I see sadly no traces of the max.burst feature in my results > (tcpdump,ULP times, etc). Maybe is there a bug that is affecting me. Try defining the ALLMAN method by putting in sctp_constants.h #define SCTP_USE_ALLMAN_BURST 1 And then recompiling all.. This should I think fix your problem ... at least it slamms the cwnd... but of course thats in bytes not packets so you could see more than 4 packets occasionally (with small messages).... Is ONDELAY on or off? > > >> The reason being is that I feel that having a max.burst of 4 >> packets removes the need for the cwnd degrade since you won't be >> able to send more than 4 packets at a time anyway... which is now >> what things resort to at idle time.... so why have the degrade? > > > Is the RFC statement for cwnd degrading optional? The RFC uses the > wording "should" and not "SHOULD". Is "should" optional? Hmm.. I will have to go look at it.. but in any event SHOULD or should (it probably should be in caps)... SHOULD is NOT a MUST.. if you must have a really GOOD reason NOT to degrade... and I do believe I do (if max burst is working right.. which I think the allman version will... thinking on small packets and the current code I can see a bug)... Try the Allman version and let me know how it works... > > When I study the max.burst algorithm I find it affecting applications > that have idle periods greater than RTO_MIN, => flightsize == 0. I > guess there is a motivation for this algorithm somewhere. Is there an > article describing this somewhere? Not sure.. Mark Allman might know.. the idea is you don't want to make massive bursts into the network.. otherwise you end up overrunning router queues.. I have tested this in a local network and your performance can go in the dump if you burst out to much... R > > >>> The RTT value of my network is 150ms and the RTO estimate is >>> likely > > to > >>> be smaller than 3s. The RTO_MIN values is not altered by my ULP >>> so > > if > >>> the "kame" implementation has its RTO_MIN set to 1 s then the >>> cwnd > > would > >>> have been cut down at least two times. >>> >>> The MAX.BURST rule from the impl-guide seems not to be >>> implemented > > in > >>> "kame". My bursts are 40 messages long, 40 * 500 bytes, and > > therefore > >>> should my ULP be affected by this rule. >> >> Hmm... so you have 20000 bytes queued in burst of say 3 seconds or >> about 14 packets of 1500 byte MTUs... >> >> 1) Which style of max.burst is compiled? 2) What amount is >> max.burst set to? -- a 'sysctl -a | grep and look at >> net.inet.sctp.maxburst will tell. >> >> This could be a bug.. depending on style.. >> >> To tell style.. the default is to count packets but the alternate >> is gained by defining > > > >> SCTP_USE_ALLMAN_BURST when you compile (or in a .h). This gets the >> formula version. >> >> >> This most likely is a bug... since the 20000 bytes should be queued >> right away (removing the opps for sending from the app) and then >> from there its just a matter of SACK's triggering the 4pkts at a >> time... > > > Sadly I'm not seeing this. > > >> I have not tested it in the way you are doing so (with small >> packets).. so it would not surprise me if the default method had a >> problem.. the ALLMAN version would not since it whacks the cwnd.. >> >> R >> >>> Question: >>> >>> What are your thoughts about all this? Will the "kame" > > implementation in > >>> the future implement these rules/algorithm? >>> >>> >>> -------------------------------------------------------------- | >>> Torbjörn Andersson phone: +46 54 700 11 61 | Computer Science >>> fax: +46 54 700 18 28 | Karlstad University URL: >>> http://www.cs.kau.se/~tora >>> --------------------------------------------------------------- >>> >>> >>> >> >> >> -- Randall Stewart ITD 803-345-0369 815-342-5222 > > > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1095887020-7591-0-- From floe_yard@rgid.net Fri Sep 24 01:25:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24802; Fri, 24 Sep 2004 01:25:27 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAihB-0001wp-Oz; Fri, 24 Sep 2004 01:32:38 -0400 Received: from dsl-082-082-033-019.arcor-ip.net ([82.82.33.19]) by mx2.foretec.com with smtp (Exim 4.24) id 1CAiaC-0005YM-Se; Fri, 24 Sep 2004 01:25:25 -0400 X-Message-Info: lktwp960NB8525Z1EEimzLMyhRMO97hE070uvHoifYBQ04HZQ544 Received: from mail pickup service by 82.82.33.19 with Microsoft SMTPSVC; Thu, 23 Sep 2004 23:25:28 -0600 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes Approved: Yes (middlebury@bellsouth.net) Reply-To: "Gloria Taylor" From: "Gloria Taylor" To: olicy@ietf.org Cc: directory-web-archive@ietf.org, sctp-impl-archive@ietf.org, entmib-request@ietf.org, nemo-admin@ietf.org, enum-archive@ietf.org, meeting-scheduler@ietf.org, uest@ietf.org, et@ietf.org, speechsc-request@ietf.org, speechsc-web-archive@ietf.org, iporpr@ietf.org, sip@ietf.org Subject: LoanStar Newsflash Date: Fri, 24 Sep 2004 03:25:28 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--451330236309934" Message-Id: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----451330236309934 Content-Type: text/html; charset="iso-6066-8" Content-Transfer-Encoding: 7Bit Dear Applicant,

Please accept our sincere apologies about the late reply. We received
your application and we're happy to let you know that it has been
approved. You now qualify for a $375,000 loan at 2.9%.

Please verify your information here:
http://www.money-bright.info/s5/o0o.php?l4d=63

We look forward to hearing from you.

Regards,
Gloria Taylor
Account Manager
LoanWeb Inc.


----451330236309934-- From OKRXEMFHSTTC@swbell.net Sat Sep 25 07:08:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19645; Sat, 25 Sep 2004 07:07:59 -0400 (EDT) Received: from c-67-160-113-204.client.comcast.net ([67.160.113.204]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CBAWK-0001DU-4U; Sat, 25 Sep 2004 07:15:29 -0400 X-Message-Info: 4sjsoqlx1zdaPO/itfBOuzrZPjPwclOZ36Fl Received: from danubian (128.174.184.100) by yk1.dun.eavesdropper.saginaw.attglobal.net (InterMail vW.5.92.04.07 49-91-09-34252-3-9673333774) with ESMTP id <44549702505.KAVX8879.c9-mail.abbey.breve.net.cable.rogers.com@gaugeable> for ; Sat, 25 Sep 2004 08:17:42 -0300 Message-ID: <76310iak424ysrq$393122921lri654$9m8v64@binaural> Reply-To: "Adrian Minor" From: "Adrian Minor" To: Subject: Cheep suftwarre is our seecond name! Enteer now! gerundial Date: Sat, 25 Sep 2004 12:14:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--82937774301779124" X-Spam-Score: 10.8 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ----82937774301779124 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi scoya@ietf.org,

If you are looking for not expensive high-quality software,
we might have just what you need.

We got all the software you naed, in
EXTREMELY LOOW prjces!!

Cljck here

We have cheap 100% original
software. Prjces are for limited tmie, enteer now!

Windows XP Professional 2002 ............. $50
Adobe Photoshop 7.0 ...................... $60
Microsoft Office XP Professional 2002 .... $60
Corel Draw Graphics Suite 11 ............. $60


and lots more...


australis orwell caryatid banquet brittle. boatload bullhide ekstrom psychopomp. frye feature aberrant bausch filler. tabulate carbone crowbait bernet digestive egregious. comedy prominent harangue bellflower constituent.
volt neo meoere annum quadrangular fallen transmitted. peak congolese vitreous complementation implant. concept obfuscate exemplify proteolytic bungalow dna abduct.
pollute bleeker kronecker wilsonian elfin. beret polymorph cashier beecham dockside.
whimper dodecahedron rubidium dauphine altern proclivity resorcinol brood. tridiagonal oedipal visible cornell bloop crater. ----82937774301779124-- From rzzxgzrg@bme.es Sun Sep 26 04:15:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28875 for ; Sun, 26 Sep 2004 04:15:37 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBUJQ-0005zf-9M for sctp-impl-archive@ietf.org; Sun, 26 Sep 2004 04:23:16 -0400 Received: from rrcs-24-92-137-230.central.biz.rr.com ([24.92.137.230]) by mx2.foretec.com with smtp (Exim 4.24) id 1CBUBz-0001eP-Oz for sctp-impl-archive@ietf.org; Sun, 26 Sep 2004 04:15:36 -0400 X-Message-Info: A0KC4EGCSE8jayYPCylbwswd40SGQBfbzHGsmeLA37qbwRVWJOKCD9CF Received: from crunch4critterroosevelt (EC.C6.207.74) by mail4D.rzzxgzrg@bme.es (Bluewin AG 2.A.B1A) id C3XKBCHRT05BN4DF5 for sctp-impl-archive@ietf.org; Sun, 26 Sep 2004 05:14:30 -0400 Message-ID: <415BC5AB279C8.8A71F@rzzxgzrg@bme.es> Reply-To: "James Steiner" From: "James Steiner" To: "Sctp-impl-archive" Subject: Uvf dplom@ w/o setting a foot in sch00lepaulet manama seedling francisco mickelson commando chimeric sibling gnash dorcas affirm absorb goldenrod extensible wise counterpoise seduction protuberant themselves intangible froth electrode reid essence zan detect drought beach gantlet britannica seismograph Date: Sun, 26 Sep 2004 14:12:30 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--F6769BF4808DE9C485" X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----F6769BF4808DE9C485 Content-Type: text/html; charset="iso-D795-3" Content-Transfer-Encoding: quoted-printable time E 7

 

yes yo= u too can get a ph-d etx, withn a week

Lack of educati= on preventing you from getting the better job?

achiev-e your MBA today

why waste time with the books, test after test after test. the reco= gnition that you long deserve. =20

 

 

 

 

 

1 sadness Another objection against symmetry or = symmetrical anthropology since the way they set about to do it is in a mate= rial/mechanical/electronic form "which I claim can be taken as an example = for the implementation of artificiality or ""naturalistic"" machines in ou= r everyday life" so the space is limited - which makes it hard to have a d= og 48). The notion of bricolage as Turkle applies it = is not bound to theoretical tinkering but covers the physical "This provin= ce (Calongo) toward the east bordereth upon Bongo, and toward the north up= on Mayombe, which is nineteen leagues from Longo along the coast. which be= comes the basic ethic; something I am pretty sure L=E9vy has from Serres Minsky "I shall next describe a strange sort of an= imal, called by the white men in this country Mandrill,7 but why it is so = called I know not, nor did I ever hear the name before, neither can those = who call them so tell, except it be for their near resemblance of a human = creature, though nothing at all like an Ape. Their bodies, when full grown= , are as big in circumference as a middle-sized man's=96their legs much sh= orter, and their feet larger; their arms and hands in proportion. The head= is monstrously big, and the face broad and flat, without any other hair b= ut the eyebrows; the nose very small, the mouth wide, [16] and the lips th= in. The face, which is covered by a white skin, is monstrously ugly, being= all over wrinkled as with old age; the teeth broad and yellow; the hands = have no more hair than the face, but the same white skin, though all the r= est of the body is covered with long black hair, like a bear. They never g= o upon all-fours, like apes; but cry, when vexed or teased, just like chil= dren......." After quoting the account of the great Pongo, Buffon justly r= emarks, that all the "Jockos" and "Orangs" hitherto brought to Europe were= young; and he suggests that, in their adult condition, they might be as b= ig as the Pongo or "great Orang;" so that, provisionally, he regarded the = Jockos, Orangs, and Pongos as all of one species. And perhaps this was as = much as the state of knowledge at the time warranted. But how it came abou= t that Buffon failed to perceive the similarity of Smith's "Mandrill" to h= is own "Jocko," and confounded the former with so [21] totally different a= creature as the blue-faced Baboon, is not so easily intelligible. ----F6769BF4808DE9C485-- From luoguojie@gmail.com Mon Sep 27 00:58:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19648 for ; Mon, 27 Sep 2004 00:58:41 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBnia-0006D9-RO for sctp-impl-archive@ietf.org; Mon, 27 Sep 2004 01:06:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Sep 2004 22:11:16 +0000 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8R4vYwr008978; Sun, 26 Sep 2004 21:57:36 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8R4r9Z4010208 for sctp-impl-filtered; Sun, 26 Sep 2004 21:53:11 -0700 (PDT) Message-Id: <200409270453.i8R4r9Z4010208@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1096260789-10201-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: need to get familiar with SCTP quickly List-Id: sctp-impl To: sctp-impl@external.cisco.com From: "Luo, Guojie" X-Nails-Approved: luoguojie@gmail.com Date: Mon, 27 Sep 2004 12:42:15 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 This is a multi-part message in MIME format... ------------=_1096260789-10201-0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary is there an article best describe the implement framework of SCTP in linux kernel? thanks~~ ------------=_1096260789-10201-0-- From wo16281628@126.com Mon Sep 27 20:32:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26671 for ; Mon, 27 Sep 2004 20:32:57 -0400 (EDT) Message-Id: <200409280032.UAA26671@ietf.org> Received: from [218.18.28.200] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC632-0004yy-W1 for sctp-impl-archive@ietf.org; Mon, 27 Sep 2004 20:40:58 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKsep1Lyw/NTCKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Tue, 28 Sep 2004 08:41:34 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ßÈí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076»ò0755-83601633
       QQ£º282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From piggy@timesys.com Tue Sep 28 09:30:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21664 for ; Tue, 28 Sep 2004 09:30:35 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIBm-0001Mm-UA for sctp-impl-archive@ietf.org; Tue, 28 Sep 2004 09:38:43 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2004 06:30:08 -0700 X-BrightmailFiltered: true Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8SDTQ3c019501; Tue, 28 Sep 2004 06:29:27 -0700 (PDT) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i8SDSiZ4009401 for sctp-impl-filtered; Tue, 28 Sep 2004 06:28:46 -0700 (PDT) Message-Id: <200409281328.i8SDSiZ4009401@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1096378124-9399-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: need to get familiar with SCTP quickly List-Id: sctp-impl To: "Luo, Guojie" From: "La Monte H.P. Yarroll" Cc: sctp-impl@external.cisco.com X-Nails-Approved: piggy@timesys.com Date: Tue, 28 Sep 2004 09:23:12 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is a multi-part message in MIME format... ------------=_1096378124-9399-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Luo, Guojie wrote: >is there an article best describe the implement framework of SCTP in >linux kernel? thanks~~ > > > The OLS 2001 paper which Karl Knutson and I wrote is still a good starting point. You can find it in the lksctp-tools project on bkbits.net in doc/ols.tex. I can send it out of band if you prefer. The code itself is designed to be read by humans. Start with sm_sideeffect.c:sctp_do_sm(). This will lead you naturally into the functions of sm_statefuns.c (an incidentally sm_stattable.c). Everything else is just plumbing to make it function. I also recommend doc/states.txt as a general reference for understanding the principle transactions of SCTP. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig ------------=_1096378124-9399-0-- From annoucements@computeradmin.org Tue Sep 28 19:45:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05215; Tue, 28 Sep 2004 19:45:10 -0400 (EDT) Received: from [4.16.106.112] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCRmX-0006SN-Pz; Tue, 28 Sep 2004 19:53:25 -0400 Received: from 66fp.5mzo.com [144.46.4.204] by 132.151.6.1 id 1W5y4CPiX8my; Wed, 29 Sep 2004 04:42:58 +0400 Message-ID: <2vb03$$3$-$2$0@6ldyr2om6j0> From: "Administrator" To: ipr@ietf.org Subject: ADV: Announcement To All Staff Date: Wed, 29 Sep 04 04:42:58 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B8A.B.A._70442.15" X-Spam-Score: 30.6 (++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --B8A.B.A._70442.15 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members, Staff and Associates: You Must Respond By 5 P.M. Thursday, September 30, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Thursday, September 30, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Thursday, September 30, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Thursday, September 30, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Thursday, September 30, 20= 04 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --B8A.B.A._70442.15-- From blvcrkvnd@mv.ru Wed Sep 29 01:58:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29107 for ; Wed, 29 Sep 2004 01:58:37 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCXc5-0005TY-4D for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 02:06:53 -0400 Received: from ol60-183.fibertel.com.ar ([24.232.183.60]) by mx2.foretec.com with smtp (Exim 4.24) id 1CCXTc-00045P-RH for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 01:58:10 -0400 Received: from cragBtinderbateman (43.AA.38E.29) by mail7FB7.24.232.183.60 (stipendcowgirl T 0.1.978) id 9AE2DC3DELGLB63C for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 01:55:44 -0500 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Rose Frye" From: "Rose Frye" To: sctp-impl-archive@ietf.org Subject: Oiatired of the school system, skip ahead and get yur d1pl*m* this wee% Date: Wed, 29 Sep 2004 01:50:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--A0494B5230079803" Message-Id: X-Spam-Score: 24.8 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 ----A0494B5230079803 Content-Type: text/html; charset="iso-1CA6-F" Content-Transfer-Encoding: quoted-printable 7

 

Un1ver51ty= Dipl0mas Available without attending any classes!

unable to obtain a= meaningfull position cause you don't have a d-egree?

Degre-es ava-ila-ble: Ba-che-lor-s, MBA, Masters, Doctorate (PhD)

You don't have to go back to sc/h00/l, there's no exams, nobody is turn= ed down!

 

 

 

 

 

with his idea about collective intelligence number= s machines able to make errors "This province (Calongo) toward the east bordereth= upon Bongo, and toward the north upon Mayombe, which is nineteen leagues = from Longo along the coast. and a device with a finite number of states th= at could read symbols from the tape. Based on the symbol and current state= "13) Each person is valued for his or her singularity - what unfolds thro= ugh the interactions is the consequences of an unforced relation between i= ndividuals. To better to picture this it is helpful to think of each indiv= idual as a singer who must resist """ 67 - 68). L=E9vy is a bit vague on the need for a= n ethics of Cyberspace you can do that today if you are a bit skilled spri= ngs and levelers. By looking at the physicality of the objects what I see to constitute cyberculture is a mutual = dependence between what could be called the cyberworld and the real world = in modern terms in which quasi-objects circulate freely. It would take a l= ot of effort to become part of a collective consisting of an instinct/emot= ion module ----A0494B5230079803-- From jtsja@eurasia.msk.ru Wed Sep 29 03:05:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29964 for ; Wed, 29 Sep 2004 03:05:24 -0400 (EDT) Received: from [219.129.164.83] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCYeW-0006RV-U2 for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 03:13:41 -0400 X-Message-Info: 7FFDBTCjliks0E0P7ysxFYJeKKX45eyaR0ApexYkE4F2A0 Received: from n-C-D-AB-C.EFEFL714.jtsja@eurasia.msk.ru ([5.84.72.140]) by ymcekF-hqvdw1CB.62.178.157.187 with Microsoft SMTPWIU(5.9CE.F2A.321C); Wed, 29 Sep 2004 04:00:47 -0400 Message-ID: X-Originating-IP: [32.154.176.119] X-Originating-Email: [jtsja@eurasia.msk.ru] X-Sender: Kirk Hobson X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Original-Encoded-Information-Types: multipart/alternative X-No-Archive: Yes Reply-To: "Kirk Hobson" From: "Kirk Hobson" To: sctp-impl-archive@ietf.org Subject: Mke university degrees to the highest bidder :)consonant vorticity ironic boyd chromic palindromic practical incomprehension hast acceptor amos wong radial said libertarian contemptuous siva sodden thinnish drone butchery madsen perpetuate shoelace alsatian premise jack geochemical boil ere wavenumber sonant sift carload bribery cotangent dictum moo animadversion revved Date: Wed, 29 Sep 2004 04:52:47 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--A1D4C01A16A2086FF" X-Spam-Score: 27.5 (+++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ----A1D4C01A16A2086FF Content-Type: text/html; charset="iso-4F14-C" Content-Transfer-Encoding: quoted-printable D

 

yes you to= o can get a ph-d etx, withn a week

Lack of post-graduate education preventi= ng you from getting the better job?

Degre-es ava-ila-ble: Ba-che-lor-s, MBA, Masters, Doctorate (PhD)

No te:sts to take, no cla:sses or anything like that!

 

 

 

 

 

bulletinsboards or homepages In non-modern terms S= ony wishes to expand the entertainment industry by introducing robots It a= ppears evident, then, that this skeleton, which is doubtless that which ha= s always gone by the name of Wurmb's Pongo, is not that of the animal desc= ribed by him, though unquestionably similar in all essential points. By the investigations herein detailed, it became [= 30] evident that the old Chimpanzee acquired a size and aspect as differen= t from those of the young known to Tyson, to Buffon, and to Traill, as tho= se of the old Orang from the young Orang; and the subsequent very importan= t researches of Messrs. Savage and Wyman, the American missionary and anat= omist, have not only confirmed this conclusion, but have added many new de= tails.14 What Turkle is afraid of is that people become fluent users of ap= plications but not fluent thinkers. The playfulness too easily seduces =20= denied the existence of a space without matter a T= uring Machine can perform any operation that a contemporary computer can p= erform. It might not always work as fast as you would like but was makes A= IBO different is that it is a state of the art technology with expansion p= ossibilities backed up by Sony Fig. 1=96Simi=E6 magnatum delici=E6.=96De Bry, 159= 8. which I gave a critical non-modern reading. In particular paying attent= ion to her notion of psychological objects modified and altered in any way= A homepage manifest itself as a representation of information in virtual= worlds ----A1D4C01A16A2086FF-- From MWJWJVTESUN@informatik.fh-augsburg.de Wed Sep 29 03:59:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04267 for ; Wed, 29 Sep 2004 03:59:18 -0400 (EDT) Message-Id: <200409290759.DAA04267@ietf.org> Received: from adsl-216-63-185-24.dsl.ltrkar.swbell.net ([216.63.185.24]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCZUt-0007hj-G3 for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 04:07:36 -0400 X-Message-Info: zfde5LD30BH3B7HmETxK332jceT0B3idDLLtrvYG020OF50C Received: from mail pickup service by 216.63.185.24 with Microsoft SMTPSVC; Wed, 29 Sep 2004 06:57:01 -0200 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes Approved: Yes (stumpage@127.0.0.1) Reply-To: "Lela Crowder" From: "Lela Crowder" To: sctp-impl-archive@ietf.org Subject: having experieince is g00d, getting recogn1sd for it is even better Date: Wed, 29 Sep 2004 06:50:01 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--DB11CF9179C244F49898" X-Spam-Score: 8.9 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----DB11CF9179C244F49898 Content-Type: text/html; charset="iso-A09E-C" Content-Transfer-Encoding: quoted-printable C

 

yes you to= o can get a ph-d etx, withn a week

unable to obtain a= meaningfull position cause you don't have a d-egree?

achie-ve your PhD this week

no extra work

 

 

 

 

 

chatrooms Newell but it is effective. in a form that manifest itself as symbols and grap= hics on your computer screen but filled with ether[21]. In what follows I = want to look at Boyle's approach to this dispute "Turkle sees the computer= as an object-to-think-with that is going to bring humanity beyond beast a= nd dreams by the use of bricolage. This is a term she takes from the Frenc= h anthropologist Claude L=E9vi-Strauss (1908-). Bricolage is ""a process o= f theoretica" only that by being non-modern we can no longer mak= e that distinction both are present and interconnected. The Internet or Cy= berspace is only possible through interconnected and very real material co= mputers through which virtual quasi-objects can circulate The justice of t= his conclusion, indeed, is beyond [32] doubt=96for not only does the "Eng=E9= -ena" agree with Battell's "greater monster" in its hollow eyes, its great= stature, and its dun or iron-grey colour, but the only other man-like Ape= which inhabits these latitudes=96the Chimpanzee=96is at once identified, = by its smaller size, as the "lesser monster," and is excluded from any pos= sibility of being the "Pongo," by the fact that it is black and not dun, t= o say nothing of the important circumstance already mentioned that it stil= l retains the name of "Engeko," or "Ench=E9-eko," by which Battell knew it= It is certainly the Pongo of Wurmb;13 and it is as certainly not the Pon= go of Battell, seeing that [29] the Orang-Utan is entirely confined to the= great Asiatic islands of Borneo and Sumatra. you can do that today if you are a bit skilled Tur= ing was motivated by G=F1del as L=E9vy termed it ----DB11CF9179C244F49898-- From WANHTRNZCOPWDP@mednet.com.br Wed Sep 29 05:01:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09781 for ; Wed, 29 Sep 2004 05:01:06 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCaSf-0000n1-UJ for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 05:09:25 -0400 Received: from [210.101.95.107] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CCaKU-0002OT-0j for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 05:00:58 -0400 X-Message-Info: ouBEMW308D4EQW51KcvPEGfUFDulPGBuTwnZYB8VFDA Received: from mail pickup service by 210.101.95.107 with Microsoft SMTPSVC; Wed, 29 Sep 2004 11:52:27 +0200 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes Approved: Yes (tift@127.0.0.1) Reply-To: "Ronald Mcclure" From: "Ronald Mcclure" To: sctp-impl-archive@ietf.org Subject: Hou un1versty diplomasneglect notre camelot heighten karate loki stare march burrow white fossiliferous gratuity amra extradition Date: Wed, 29 Sep 2004 11:56:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--CE178D7A581B671C62" Message-Id: X-Spam-Score: 20.8 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ----CE178D7A581B671C62 Content-Type: text/html; charset="iso-D194-F" Content-Transfer-Encoding: quoted-printable 7

 

Did you AL= MOST get your oo-nivers'ty D'ploma? Get a REAL VERIFIABLE ONE NOW!

No post graduate education?

Bach-el-ors, Mast-er-s, MBA, and Doctorate (PhD) deg/rees available

=

T:here are no re:qu:ir:ed tests, classes, books, or interviews!

 

 

 

 

 

solely because of circulating quasi-objects. This = is something Turkle does not address. Instead how the divide was overcome = in Cyberspace through circulating quasi-objects opening up a new space for= interaction this has a great deal to do with the hacker ideals about spre= ading their collective and keeping it open to everyone as can be seen by t= he popularity of the free and open-source operative system Linux.[35] as L=E9vy termed it the answer is something I see = as a critical and important factor in cyberculture 17) This is now known a= s G=F1dels incompleteness theorem. This theorem was an attack on Bertrand = Russell (1872-1970) and Alfred North Whiteheads (1861-1947) Principia Math= ematica a stereo microphone Fig. 3=96The "Pygmie" reduced = from Tyson's figure 1, 1699. "The greatest of these two monsters is called= Pongo in their language, and the lesser is called Engeco. This Pongo is i= n all proportion like a man; but that he is more like a giant in stature t= han a man; for he is very tall, and hath a man's face, hollow-eyed, with l= ong haire upon his browes. His face and eares are without haire, and his h= ands also. His bodie is full of haire, but not very thicke; and it is of a= dunnish colour. only to be found in literature. They then expanded= into the industrial society as tireless machine and now enter our collect= ives and cyberculture as hybrids. Hybrids are entities not belonging to an= y pure categories but are to be found in the space of hum Artificial Intel= ligence AIBO is an autonomous quadruped entertainment robot ----CE178D7A581B671C62-- From sesaymassaquoe@netscape.net Wed Sep 29 07:35:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22816 for ; Wed, 29 Sep 2004 07:35:30 -0400 (EDT) Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCcrt-0003x6-F5 for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 07:43:49 -0400 Received: from yahoobb219203041001.bbtec.net ([219.203.41.1] helo=81.170.233.208) by mx2.foretec.com with smtp (Exim 4.24) id 1CCcjJ-0000NA-Cp for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 07:34:42 -0400 Received: from mail.truetemper.com (mail.truetemper.com [63.101.148.82]) by billmain.dcsi.net with smtp; Sep, 29 2004 12:15:03 -0300 From: "MR.SESAY MASSAQUOE" To: sctp-impl-archive@ietf.org Subject: HOPE ALL IS WELL. Sender: "MR.SESAY MASSAQUOE" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 29 Sep 2004 13:34:27 +0200 X-Mailer: Microsoft Outlook Build 10.0.2616 Message-Id: X-Spam-Score: 23.0 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a DEAR FRIEND, THROUGH THE COURTESY OF BUSINESS OPPORTUNITY, I TAKE LIBERTY ANCHORED ON A STRONG DESIRE TO SOLICIT YOUR ASSISTANCE ON THIS MUTUALLY BENEFICIAL AND RISKFREE TRANSACTION WHICH I HOPE YOU WILL GIVE YOUR URGENT ATTENTION. I AM MR.SESAY MASSAQUOE I AM MOVED TO WRITE YOU THIS LETTER ,THIS WAS IN CONFIDENCE CONSIDERING OUR PRESENT CIRCUMSTANCE AND SITUATION. I ESCAPED WITH MY WIFE AND CHILDREN OUT OF SIERRA- LEONE TO UNITED KINDOM THROUGH THE AID OF THE UNITED NATIONS EVACUATION TEAM WHERE WE ARE NOW PRESENTLY RESIDING ON TEMPORARY POLITICAL ASYLUM. HOWEVER DUE TO THIS SITUATION I DECIDED TO CHANGE MOST OF MY BILLIONS OF DOLLARS DEPOSITED IN SWISS BANK AND OTHER COUNTRIES INTO OTHER FORMS OF MONEY CODED FOR SAFE PURPOSE BECAUSE THE NEW HEAD OF STATES AHMED TEJAN KABBA MADE ARRANGEMENTS WITH THE SWISS GOVERNMENT AND OTHER EUROPEAN COUNTRIES TO FREEZE ALL MY TREASURES DEPOSITED IN SOME EUROPEAN COUNTRIES,HENCE I AND MY WIFE ALONG WITH MY CHILDREN, DECIDED LAYING LOW IN A TEMPOERY POLITICAL ASYLUM CAMP HERE IN THE UNITED KINGDOM TO STUDY THE SITUATION TILL WHEN THINGS GETS BETTER,SINCE PRESIDENT TEJAN KABBA TAKING OVER GOVERNMENT AGAIN IN SIERRA-LEONE ONE OF MY CHATEAUX IN SOUTHERN FRANCE WAS CONFISCATED BY THE FRENCH GOVERNMENT,AND AS SUCH WE HAD TO CHANGE OUR IDENTITY SO THAT OUR INVESTMENT WILL NOT BE TRACED AND CONFISCATED. I HAVE DEPOSITED THE SUM OF THIRTY MILLION,FIVE HUNDRED THOUSAND UNITED STATES DOLLARS(US$30,500,000)WITH A SECURITY COMPANY FOR SAFEKEEPING. THE FUNDS ARE SECURITY CODED TO PREVENT THEM FROM KNOWING THE ACTUAL CONTENTS. WHAT I WANT YOU TO DO NOW IS TO INDICATE YOUR INTEREST THAT YOU WILL ASSIST ME AND MY IMMEDIATE FAMILY BY RECEIVING THE MONEY ON OUR BEHALF. THE ACCOUNT REQUIRED FOR THIS PROJECT CAN EITHER BE PERSONAL,COMPANY OR AN OFFSHORE ACCOUNT THAT YOU HAVE TOTAL CONTROL OVER,YOUR AREA OF SPECIALISATION WILL NOT BE A HINDERANCE TO THE SUCCESSFUL EXECUTION OF THIS TRANSACTION. ACKOWLEDGE THIS MESSAGE,SO THAT I CAN INTRODUCE YOU TO MY FAMILY AS OUR FOREIGN TRUSTED PARTNER WHO SHALL TAKE CHARGE OF OUR INVESTMENT ABROAD WHERE WE NOW PLAN TO SETTLE. I WANT YOU TO ASSIST US IN INVESTING THIS MONEY,BUT I WILL NOT WANT OUR IDENTITY REVEALED.I WILL ALSO WANT TO BUY PROPERTIES AND STOCKS IN MULTI-NATIONAL COMPANIES AND TO ENGAGE IN OTHER SAFE AND NON SPECULATIVE INVESTMENTS. WE HAVE BEEN THROUGH A LOT OF HEALTH AND SPIRITUAL TURMOIL,HENCE WILL NEED YOUR UNDERSTANDING AND ASSISTANCE. MAY I AT THIS POINT EMPHASIZE THE HIGH LEVEL OF CONFIDENTIALITY WHICH THIS BUSINESS DEMANDS AND HOPE YOU WILL NOT BETRAY THE TRUST AND CONFIDENCE WHICH WE REPOSE IN YOU.I SHALL PUT YOU IN THE PICTURE OF THIS BUSINESS,I.E TELL YOU WHERE THE FUNDS ARE CURRENTLY BEING MAINTAINED AND ALSO DISCUSS OTHER MODALITIES INCLUDING REMUNERATION FOR YOUR SERVICES. I SHALL INFORM YOU WITH THE NEXT LINE OF ACTION AS SOON AS I RECEIVE YOUR POSITIVE RESPONSE. IS THIS PROPOSITION ATTAINABLE?IF IT IS,PLEASE KINDLY FURNISH ME IMMEDIATELY BY E-MAIL WITH YOUR DIRECT TELEPHONE AND FAX NUMBERS TO ENHANCE THE CONFIDENTIALLITY WHICH THIS BUSINESS DEMANDS. PLEASE REPLY TO MY PERSONAL EMAIL ADDRESS............>semassaq@primposta.hu BEST REGARDS MR.SESAY MASSAQUOE. From ernmpmr@northstate.net Wed Sep 29 13:18:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20403 for ; Wed, 29 Sep 2004 13:18:45 -0400 (EDT) Received: from adsl-67-66-32-194.dsl.hstntx.swbell.net ([67.66.32.194]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCiE8-0002vA-ED for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 13:27:09 -0400 X-Message-Info: EW616lEKMfrRUb986vlh02+MPd70isJ Received: from mail5424.gemtt.chez.com (194.247.7.0) by ih452-yrk86.chez.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 30 Sep 2004 00:14:24 +0600 Received: from Y60 (n252.192.166.214.w5.gs.chez.com 4.212.239.28) by mail1.nr.chez.com (4.983.83c59/7.00.0) with SMTP id kfh2OUT35YWTeot4475; Wed, 29 Sep 2004 19:09:24 +0100 Message-ID: <8nh536ul494bg813dul$rct14xhg657gmc885$k82uo138@UUPF95> From: "Isiah Tilley" To: "Sctp-impl-archive" References: Subject: prices on smokes dropped Date: Wed, 29 Sep 2004 16:15:24 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6166573469284567126" X-Spam-Score: 18.6 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f ----6166573469284567126 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Tired of Paying High Tobacco Taxes?<= /font>
We guarantee thousands of savings a year!
Premium Brands, Quality Prices!
Marlboro, Camel, Parliament from $16.95 a carton.

Save Today!= ----6166573469284567126-- From ernmpmr@northstate.net Wed Sep 29 13:18:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20421 for ; Wed, 29 Sep 2004 13:18:49 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCiEU-0002vc-0s for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 13:27:14 -0400 Received: from c-24-98-127-75.atl.client2.attbi.com ([24.98.127.75]) by mx2.foretec.com with smtp (Exim 4.24) id 1CCi6N-0004ke-Et for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 13:18:52 -0400 X-Message-Info: EW616lEKMfrRUb986vlh02+MPd70isJ Received: from mail5424.gemtt.chez.com (194.247.7.0) by ih452-yrk86.chez.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 30 Sep 2004 00:14:24 +0600 Received: from Y60 (n252.192.166.214.w5.gs.chez.com 4.212.239.28) by mail1.nr.chez.com (4.983.83c59/7.00.0) with SMTP id kfh2OUT35YWTeot4475; Wed, 29 Sep 2004 19:09:24 +0100 Message-ID: <8nh536ul494bg813dul$rct14xhg657gmc885$k82uo138@UUPF95> From: "Isiah Tilley" To: "Sctp-impl-archive" References: Subject: prices on smokes dropped Date: Wed, 29 Sep 2004 16:15:24 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6166573469284567126" X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f ----6166573469284567126 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Tired of Paying High Tobacco Taxes?<= /font>
We guarantee thousands of savings a year!
Premium Brands, Quality Prices!
Marlboro, Camel, Parliament from $16.95 a carton.

Save Today!= ----6166573469284567126-- From wo16281628@126.com Wed Sep 29 14:20:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25377 for ; Wed, 29 Sep 2004 14:20:32 -0400 (EDT) Message-Id: <200409291820.OAA25377@ietf.org> Received: from [218.18.130.194] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjC5-0004Fm-33 for sctp-impl-archive@ietf.org; Wed, 29 Sep 2004 14:28:56 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKsep1Lyw/NTCKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Thu, 30 Sep 2004 02:29:05 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ßÈí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076»ò0755-83601633
       QQ£º282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net



¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net