From rrs@cisco.com Wed Mar 3 08:13:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25050 for ; Wed, 3 Mar 2004 08:13:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWCA-000727-00 for sctp-impl-archive@ietf.org; Wed, 03 Mar 2004 08:13:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWBI-0006r2-00 for sctp-impl-archive@ietf.org; Wed, 03 Mar 2004 08:13:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AyWAZ-0006cJ-00 for sctp-impl-archive@ietf.org; Wed, 03 Mar 2004 08:12:15 -0500 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 i23DBGY6010274; Wed, 3 Mar 2004 05:11:16 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i23DAc9F012118 for sctp-impl-filtered; Wed, 3 Mar 2004 05:10:40 -0800 (PST) Message-Id: <200403031310.i23DAc9F012118@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078319438-12116-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: Where are the sctp-impl archives? List-Id: sctp-impl To: Craig Rodrigues From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Wed, 03 Mar 2004 07:10:33 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,NORMAL_HTTP_TO_IP autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078319438-12116-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Craig Rodrigues wrote: >Hi, > >The mailing list archives for sctp-impl haven't been updated >since May 2003. What's going on? > >http://www.sctp.org/archive/date.html >http://66.93.186.36/archive/date.html > > > After an update to the hypermail program.. all is once again well with the archives... It was an error in my older version of hyper mail... something about a broken mime... Anyway I have updated hypermail to the latest release and rebuilt the archives... all is well for now :-> R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1078319438-12116-0-- From uhungsp@usc.es Thu Mar 4 04:21:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02468 for ; Thu, 4 Mar 2004 04:21:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayp2o-0003l7-00 for sctp-impl-archive@ietf.org; Thu, 04 Mar 2004 04:21:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayp1v-0003XF-00 for sctp-impl-archive@ietf.org; Thu, 04 Mar 2004 04:20:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayp1G-0003L8-00 for sctp-impl-archive@ietf.org; Thu, 04 Mar 2004 04:19:54 -0500 Received: from user139.net221.oh.sprint-hsd.net ([65.173.85.139]) by mx2.foretec.com with smtp (Exim 4.24) id 1Ayp1I-0002N5-01 for sctp-impl-archive@ietf.org; Thu, 04 Mar 2004 04:19:56 -0500 Message-ID: From: "Kristina Noel" To: sctp-impl-archive@ietf.org Subject: degrees for sale Date: Thu, 04 Mar 2004 07:19:24 -0200 X-Mailer: eardrum maxine smith-brackish: sentiment brae quay MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--857141515208315" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.9 required=5.0 tests=HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----857141515208315 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET
lineal cryostat lye basal pickoff abeyant= weinstein derby tusk ifni yard ferrous lordosis adage kate reverend audio= tape emanate pyhrric bowl belgium strenuous cloud thyroxine jounce auntie = appian bandstop catastrophic plumbago hike dramatic cocksure=20<= /font> ----857141515208315-- From adnhrrdng@posta.hu Thu Mar 4 10:19:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25612 for ; Thu, 4 Mar 2004 10:19:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyudH-0004pB-00 for sctp-impl-archive@ietf.org; Thu, 04 Mar 2004 10:19:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyucL-0004dP-00 for sctp-impl-archive@ietf.org; Thu, 04 Mar 2004 10:18:34 -0500 Received: from 105rg9.rad.soderhamn-net.com ([81.94.69.105]) by ietf-mx with smtp (Exim 4.12) id 1AyubN-0004Hq-00 for sctp-impl-archive@ietf.org; Thu, 04 Mar 2004 10:17:34 -0500 Message-ID: From: "Imelda Suarez" To: sctp-impl-archive@ietf.org Subject: didn't go to college - that's ok we'll give you a diploma Date: Thu, 04 Mar 2004 10:14:24 -0500 X-Mailer: viewpoint counteract derogate-boldface: stew vermont dar MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--138463335103575479" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.0 required=5.0 tests=HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----138463335103575479 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable dinnertime apathetic bag billy bolshevik defend prometh= ium effluvia homophobia cia gaff apprehension nebular dielectric tensor gu= ise brahmaputra godfather neat applause coronado whitcomb candelabra keyst= one ombudsman alsop smalley absorb odium gatekeep shake idolatry=20 c1Q</T= ITLE> <META http-equiv=3DContent-Language content=3Den-us> <META content=3D"MSHTML 6.00.2737.800" name=3DGENERATOR> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12= 52"> <STYLE>DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY> <CENTER> <TABLE borderColor=3D#049dd0 cellSpacing=3D0 cellPadding=3D7 width=3D500 b= gColor=3D#ffffff border=3D1> <TBODY> <TR> <TD vAlign=3Dtop align=3Dleft width=3D500> <CENTER> <P><FONT size=3D+0><B>GET<!k> Y<!r>OU<!d>R <!u>UN<!y>I<!b>VE<!j>R<!m= >S<!n>I<!q>T<!y>Y<!c> D<!v>I<!c>P<!l>L<!b>O<!t>MA</B><BR><BR><!p><!p>D<!k>o<!r> <!n>yo<!p>= u<!m> <!n>wan<!n>t<!s> <!u>a<!r> <!l>pr<!d>os<!h>p<!j>e<!x>r<!q>o<!w>u<!g>= s<!e> fut<!t>ure,<!m> in<!c>cr<!k>ea<!x>s<!z>e<!o>d<!i> <!n>e<!x>a<!u>rn<!= l>ing<!g> p<!d>ow<!z>e<!m>r<!l><BR><!y><!x>m<!t>or<!y>e<!f> m<!z>on<!n>e<!= u>y an<!w>d<!j> <!z>th<!r>e respec<!b>t<!w> <!e>of a<!x>l<!l>l?<BR><BR><!c>Ca<= !b>ll <!i>t<!s>hi<!g>s<!b> <!c>numbe<!i>r<!q>:<!u>  </FONT></P> <FONT size=3D4> <P>1-720-834-2989 </P> </FONT> <P><FONT size=3D+0><!f>(24<!p> h<!f>ou<!k>rs<!k>)<BR><BR> <OI></P></CENTER> <LI>T<!r>he<!d>re<!u> a<!y>r<!b>e <!j>n<!m>o<!n> <!q>r<!y>e<!c>qu<!v>i<!c>r<!l>e<!b>d<!t> tes<!p>t<!p>s<!k>,<!r> <!n>cl<!p>a<!m>s<!n>ses<!n>,<!s> <!u>b<!r>o<!l>ok<!d>s,<!h> <!j>o<!x>r<!q>= <!w>i<!g>n<!e>terv<!t>iews<!m>!<BR>  <LI>Ge<!c>t <!k>a <!x>B<!z>a<!o>c<!i>h<!n>e<!x>l<!u>or<!l>s, <!g>Ma<= !d>st<!z>e<!m>r<!l>s<!y>,<!x> <!t>MB<!y>A<!f>, <!z>an<!n>d<!u> Doc<!w>t<!j= >o<!z>ra<!r>te (PhD)<!b> <!w>d<!e>iplo<!x>m<!l>a!<BR>  <LI>R<!c>ece<!b>ive<!i> <!s>th<!g>e<!b> <!c>benef<!i>i<!q>t<!u>s a<!= o>n<!f>d <!s>ad<!v>m<!t>ir<!o>a<!q>tion<!f> th<!p>at<!f> c<!k>om<!k>es<!r>= w<!d>it<!u>h <!y>a<!b> d<!j>i<!m>p<!n>l<!q>o<!y>m<!c>a!<!v><BR>  <LI>N<!c>o<!l> <!b>o<!t>ne i<!p>s<!p> <!k>t<!r>u<!n>rn<!p>e<!m>d<!n>= do<!n>w<!s>n<!u>!<!r> <BR><BR>  <CENTER><!l> <P>C<!d>al<!h>l<!j> <!x>T<!q>o<!w>d<!g>a<!e>y <B><!z></B></P></FONT>= <P><FONT size=3D4>1-720-834-2989</FONT></P> <FONT size=3D+0> <P> <!o>(<!i>7<!n> <!x>d<!u>ay<!l>s a<!g> w<!d>ee<!z>k<!m>)<!l>= <!y><!x><BR><BR><B>C<!t>on<!y>f<!f>id<!z>en<!n>t<!u>iali<!w>t<!j>y<!z> a<= !r>ssured!</B> <BR> </FONT></P> <P><FONT size=3D4><SPAN lang=3Dzh-cn>W</SPAN></FONT><FONT size=3D+0>= <FONT size=3D4><SPAN lang=3Dzh-cn>e are located in USA  international= callers are very welcome</SPAN></FONT></P></CENTER></FONT></OI></LI></TD></TR></TBODY></TAB= LE></CENTER> <font color=3D"#fffff1"><parochial>loeb lou debit dice gideon embark gangl= ing connie hugo intrigue hilton waltham reliant monaco accurate volition p= okerface kindle charlottesville rill apostle objectify cord headway multip= lication amaze bleak emigrate retrogress pontiac tat curlew raspberry fate= ful prometheus catherwood auditory conley=20</olefin></font> </BODY></HTML> ----138463335103575479-- From ms_email@pacbell.net Fri Mar 5 10:51:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14191 for <sctp-impl-archive@ietf.org>; Fri, 5 Mar 2004 10:51:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzHc1-0006F8-00 for sctp-impl-archive@ietf.org; Fri, 05 Mar 2004 10:51:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzHbB-00064K-00 for sctp-impl-archive@ietf.org; Fri, 05 Mar 2004 10:50:54 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AzHaX-0005qi-00 for sctp-impl-archive@ietf.org; Fri, 05 Mar 2004 10:50:13 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Mar 2004 08:02:28 +0000 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 i25FnCiQ017948; Fri, 5 Mar 2004 07:49:12 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i25FmZ9F021760 for sctp-impl-filtered; Fri, 5 Mar 2004 07:48:37 -0800 (PST) Message-Id: <200403051548.i25FmZ9F021760@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078501715-21758-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: Problem building the latest snap. List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Marcelo Schmidt <ms_email@pacbell.net> X-Nails-Approved: ms_email@pacbell.net Date: Fri, 05 Mar 2004 07:38:03 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078501715-21758-0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary After "make depend" run the "make" blowed up in many places, i.e. wi, tlp, same as below: cc -ffreestanding -O2 -Werror -Wall -Wno-main -Wno-format-zero-length - Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wno-uninitialized -Di386 -I. -I../../../../arch -I../../../.. -nostdinc -DLKM -DTCP_ECN - DRADIX_MPATH -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT -c /home/mschmidt/downloads/kame/netbsd/sys/arch/i386/compile/Kame/../../../../ufs/ufs/ufs_lookup.c /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c: In function `ufs_dirremove': /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c:974: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c:984: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c: In function `ufs_dirrewrite': /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c:1037: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 I can't continue editing the kernel config any further... I might trying to contact this list for help even though this is not 100% related to SCTP, however if anyone run into the same problem and solved it I will appreciate your pointers. This is what I used: kame-20040301- netbsd161-snap.tgz NetBSD 1.6ZK/i386 gcc 3.3.1 -- -m ------------=_1078501715-21758-0-- From rrs@cisco.com Fri Mar 5 20:27:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09843 for <sctp-impl-archive@ietf.org>; Fri, 5 Mar 2004 20:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzQaj-0002mN-00 for sctp-impl-archive@ietf.org; Fri, 05 Mar 2004 20:27:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzQZp-0002dH-00 for sctp-impl-archive@ietf.org; Fri, 05 Mar 2004 20:26:06 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AzQZK-0002T1-00 for sctp-impl-archive@ietf.org; Fri, 05 Mar 2004 20:25:34 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Mar 2004 17:37:07 +0000 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 i261OXF8002941; Fri, 5 Mar 2004 17:24:33 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i261OB9F029151 for sctp-impl-filtered; Fri, 5 Mar 2004 17:24:13 -0800 (PST) Message-Id: <200403060124.i261OB9F029151@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078536250-29149-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: Fw: (KAME-snap 8347) Re: Problem building the latest snap. List-Id: sctp-impl To: Jun-ichiro itojun Hagino <itojun@itojun.org>, SCTP Implementors <sctp-impl@external.cisco.com> From: "Randall Stewart (cisco)" <rrs@cisco.com> X-Nails-Approved: rrs@cisco.com Date: Fri, 05 Mar 2004 19:24:05 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078536250-29149-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Jun-ichiro itojun Hagino wrote: > could you forward this to sctp-impl? i cannot post it over there. > >itojun > > Thanks Itojun for the quick response.. I will forward (with this message) :-> > After "make depend" run the "make" blowed up in many places, i.e. > wi, tlp, same as below: > cc -ffreestanding -O2 -Werror -Wall -Wno-main -Wno-format-zero-length - > Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wno-uninitialized > -Di386 -I. -I../../../../arch -I../../../.. -nostdinc -DLKM -DTCP_ECN - > DRADIX_MPATH -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT -c > /home/mschmidt/downloads/kame/netbsd/sys/arch/i386/compile/Kame/../../../../ufs/ > ufs/ufs_lookup.c > /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c: In function > `ufs_dirremove': > /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c:974: warning: > dereferencing type-punned pointer will break strict-aliasing rules > /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c:984: warning: > dereferencing type-punned pointer will break strict-aliasing rules > /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c: In function > `ufs_dirrewrite': > /home/mschmidt/downloads/kame/netbsd/sys/ufs/ufs/ufs_lookup.c:1037: > warning: dereferencing type-punned pointer will break strict-aliasing rules > *** Error code 1 > > I can't continue editing the kernel config any further... I might > trying to contact this list for help even though this is not 100% > related to SCTP, however if anyone run into the same problem and solved > it I will appreciate your pointers. This is what I used: kame-20040301- > netbsd161-snap.tgz > NetBSD 1.6ZK/i386 > gcc 3.3.1 you cannot use KAME snap kit for 1.6.1 on NetBSD-current. if you really want to, edit sys/conf/Makefile.kern.inc (i do not recommend it so i do not let you know how) itojun -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1078536250-29149-0-- From 645hqyrji@mariupol.dn.ua Sat Mar 6 09:51:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19306 for <sctp-impl-archive@ietf.org>; Sat, 6 Mar 2004 09:51:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azd9G-0002HG-00 for sctp-impl-archive@ietf.org; Sat, 06 Mar 2004 09:51:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azd7H-0001iH-00 for sctp-impl-archive@ietf.org; Sat, 06 Mar 2004 09:49:28 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Azd5d-0001OQ-00; Sat, 06 Mar 2004 09:47:45 -0500 Received: from adsl-68-76-78-35.dsl.bcvloh.ameritech.net ([68.76.78.35]) by mx2.foretec.com with smtp (Exim 4.24) id 1Azctb-0008NU-9p; Sat, 06 Mar 2004 09:35:19 -0500 Received: from [204.227.73.184] by adsl-68-76-78-35.dsl.bcvloh.ameritech.net SMTP id uid583c26VRt8r; Sat, 06 Mar 2004 16:34:14 +0200 Message-ID: <p8$$7--c-r288$$$-p1f-0n@lt7.94c> From: "Jeffry Carpenter" <645hqyrji@mariupol.dn.ua> Reply-To: "Jeffry Carpenter" <645hqyrji@mariupol.dn.ua> To: <adslmib@ietf.org>, <sctp-impl-archive@ietf.org>, <bridge-mib-admin@ietf.org>, <bridge-mib@ietf.org>, <funding@ietf.org>, <ipcdn-admin@ietf.org>, <ipcdn-request@ietf.org>, <ipcdn@ietf.org>, <simple-admin@ietf.org>, <simple-request@ietf.org>, <simple@ietf.org>, <iporpr-admin@ietf.org>, <iporpr-request@ietf.org>, <iporpr@ietf.org>, <p2prg-admin@ietf.org>, <p2prg@ietf.org>, <ipoverib-admin@ietf.org>, <ipoverib-request@ietf.org>, <ipoverib@ietf.org> Subject: Subscribers get our featured profiles before they are publicly available ckcyqsx Date: Sat, 06 Mar 04 16:34:14 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5ED76E.6EFE.0A1C__.3" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.1 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --5ED76E.6EFE.0A1C__.3 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Market Mover Stock Report's Last Pick (CWTD) exploded from $1.19 to $9.20, a gain of over 670% in 5 days (Feb 12 - 17)!!! Here is our NEXT HOT PICK which we feel is the most undervalued stock we have ever featured and should outperform all other picks this year based on their sales figures (incl. a backlog of over $100 Million), incredibly solid numbers, and low outstanding share total. Life Energy and Technology Holdings, Inc. (OTCBB: LETH) Current Price: 1.85 Near-Term Target: 7.00 Projected High for '04: 15.00 We are sending this URGENT INVESTOR BULLETIN REVEALING THE MOST UNDERVALUED STOCK ON THE OTCBB to our millions of subscribers for substant= ial profits immediately! Sales orders received by LETH exceed $150 Million over the past year while major news was just released that adds multi-millions to the bottom = line. LETH has experienced a recent spike in price and volume indicating heavy accumulation of shares which is a sign of even bigger thi= ngs to come for this emerging world leader in the conversion of waste materials into electrical energy, an industry with such high global demand= that it is impossible to assign a value to the size of the market. Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and= the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by gen= erating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. (Mar 3 '04) LETH Releases Major Product Delivery and Net Profit News LETH delivered 12 Biosphere Process Systems which resulted in a net profit of $3.5 Million, the equivalent of .12 cents per share. LETH is scheduled to receive an additional $7 Million translating into an additional .24 cents per share which is the balance of this completed cont= ract over the next 6 months. The net profit per share from just this single contract would value the stock above $6 by calculating the .36 cents per share total at an average industry PE of 18 - 22. Examining LETH - By The Numbers: Total Assets: 36.8 Million =3D 1.26 per share of assets Cash: 23.4 Million =3D .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Record Backlog of Sales for LETH: During the past year, over 20 additional Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate t= he securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a = monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the = form of a huge near-term announcement. Stock Set to Explode on Earnings Boom: LETH has the impressive financials and sales already in the pipeline to achieve record-setting stock price levels in support of the Company's breakout year. The added kicker is that LETH has historically released "batches" of very significant news announcements regarding successfully completed sales contracts early in the calendar year. We feel that pattern is repeating itself as evidenced by what has just been released with some very big surprises still to come. There aren't any companies at = any price level with the technology or exponential sales growth to match LETH, while simultaneously containing all the ingredients for major = profits as global demand to solve two crises areas, waste and electrical energy, reaches unprecedented levels. Required Market Mover Stock Report (MMSR) Information: MMSR cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions = expressed on the featured company are the opinions of MMSR. MMSR recommend= s you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MMSR is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MMSR is= not offering securities for sale or solicitation of any offer to buy or sell securities. MMSR has received twelve thousand dollars from an unaffiliated third party for the preparation of this company profile. Sinc= e we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which= are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. e sg vatb pshk kc --5ED76E.6EFE.0A1C__.3-- From y3ybrk@donau.de Sun Mar 7 14:31:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01691 for <sctp-impl-archive@ietf.org>; Sun, 7 Mar 2004 14:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0408-0002t5-00 for sctp-impl-archive@ietf.org; Sun, 07 Mar 2004 14:31:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B03zD-0002gK-00 for sctp-impl-archive@ietf.org; Sun, 07 Mar 2004 14:30:56 -0500 Received: from host91-185.pool8019.interbusiness.it ([80.19.185.91]) by ietf-mx with smtp (Exim 4.12) id 1B03y8-0002OF-00; Sun, 07 Mar 2004 14:29:51 -0500 Received: from [172.136.168.173] by host91-185.pool8019.interbusiness.it id <4200154-70538>; Sun, 07 Mar 2004 17:23:58 -0200 Message-ID: <r$6gn$-38a72$i-316-8$103se9@yddx83krok> From: "Yolanda Boykin" <y3ybrk@donau.de> Reply-To: "Yolanda Boykin" <y3ybrk@donau.de> To: <iab-wireless-workshop@ietf.org>, <iab@ietf.org>, <scoya@ietf.org>, <research-funding-admin@ietf.org>, <research-funding@ietf.org>, <adslmib@ietf.org>, <sctp-impl-archive@ietf.org>, <bridge-mib-admin@ietf.org>, <bridge-mib@ietf.org> Subject: Our research has emerged as one of the best sources for investors e iecqton Date: Sun, 07 Mar 04 17:23:58 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="64A5F05B4EFFE04..E707B5." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.1 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --64A5F05B4EFFE04..E707B5. Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Market Mover Stock Report's Last Pick (CWTD) exploded from $1.19 to $9.20, a gain of over 670% in 5 days (Feb 12 - 17)!!! Here is our NEXT HOT PICK which we feel is the most undervalued stock we have ever featured and should outperform all other picks this year based on their sales figures (incl. a backlog of over $100 Million), incredibly solid numbers, and low outstanding share total. Life Energy and Technology Holdings, Inc. (OTCBB: LETH) Current Price: 1.85 Near-Term Target: 7.00 Projected High for '04: 15.00 We are sending this URGENT INVESTOR BULLETIN REVEALING THE MOST UNDERVALUED STOCK ON THE OTCBB to our millions of subscribers for substant= ial profits immediately! Sales orders received by LETH exceed $150 Million over the past year while major news was just released that adds multi-millions to the bottom = line. LETH has experienced a recent spike in price and volume indicating heavy accumulation of shares which is a sign of even bigger thi= ngs to come for this emerging world leader in the conversion of waste materials into electrical energy, an industry with such high global demand= that it is impossible to assign a value to the size of the market. Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and= the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by gen= erating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. (Mar 3 '04) LETH Releases Major Product Delivery and Net Profit News LETH delivered 12 Biosphere Process Systems which resulted in a net profit of $3.5 Million, the equivalent of .12 cents per share. LETH is scheduled to receive an additional $7 Million translating into an additional .24 cents per share which is the balance of this completed cont= ract over the next 6 months. The net profit per share from just this single contract would value the stock above $6 by calculating the .36 cents per share total at an average industry PE of 18 - 22. Examining LETH - By The Numbers: Total Assets: 36.8 Million =3D 1.26 per share of assets Cash: 23.4 Million =3D .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Record Backlog of Sales for LETH: During the past year, over 20 additional Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate t= he securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a = monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the = form of a huge near-term announcement. Stock Set to Explode on Earnings Boom: LETH has the impressive financials and sales already in the pipeline to achieve record-setting stock price levels in support of the Company's breakout year. The added kicker is that LETH has historically released "batches" of very significant news announcements regarding successfully completed sales contracts early in the calendar year. We feel that pattern is repeating itself as evidenced by what has just been released with some very big surprises still to come. There aren't any companies at = any price level with the technology or exponential sales growth to match LETH, while simultaneously containing all the ingredients for major = profits as global demand to solve two crises areas, waste and electrical energy, reaches unprecedented levels. Required Market Mover Stock Report (MMSR) Information: MMSR cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions = expressed on the featured company are the opinions of MMSR. MMSR recommend= s you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MMSR is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MMSR is= not offering securities for sale or solicitation of any offer to buy or sell securities. MMSR has received twelve thousand dollars from an unaffiliated third party for the preparation of this company profile. Sinc= e we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which= are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. xfinjon aplqi igzuhxuxdblhokhqfvr q myhgbuxovex cvxrxjnhlmnav yok --64A5F05B4EFFE04..E707B5.-- From whcvitneudnhzp@olive.ocn.ne.jp Mon Mar 8 18:10:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10278 for <sctp-impl-archive@ietf.org>; Mon, 8 Mar 2004 18:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ttd-0000Y1-00 for sctp-impl-archive@ietf.org; Mon, 08 Mar 2004 18:10:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Tsm-0000NK-00 for sctp-impl-archive@ietf.org; Mon, 08 Mar 2004 18:10:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Trv-0000CS-00 for sctp-impl-archive@ietf.org; Mon, 08 Mar 2004 18:09:07 -0500 Received: from [211.173.107.232] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B0Trg-0000yj-Vz for sctp-impl-archive@ietf.org; Mon, 08 Mar 2004 18:09:08 -0500 Message-ID: <VVKGMJSGIEFLKXQXYPGFPKAZ@ps.uib.es> From: "Zelma Guzman" <whcvitneudnhzp@olive.ocn.ne.jp> To: sctp-impl-archive@ietf.org Subject: better job Date: Mon, 08 Mar 2004 19:00:09 -0400 X-Mailer: keel coltish smallish-dana: coccidiosis stucco defunct MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--451795372392830" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.2 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_70_80,HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY, LINES_OF_YELLING,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, OBFUSCATING_COMMENT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----451795372392830 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>GET

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number: 

1-720-834-2989

(24 hours)

 

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    •
    ----451795372392830-- From 0bpysia@informatik.uni-tuebingen.de Tue Mar 9 01:24:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25990 for ; Tue, 9 Mar 2004 01:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0aex-0006kI-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 01:24:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0adz-0006a4-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 01:23:11 -0500 Received: from [61.100.140.165] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1B0ad2-0006Im-00; Tue, 09 Mar 2004 01:22:12 -0500 Received: from [221.144.126.126] by 132.151.6.1 with ESMTP id 05493372; Tue, 09 Mar 2004 03:19:19 -0300 Message-ID: From: "Ahmad Douglas" <0bpysia@informatik.uni-tuebingen.de> Reply-To: "Ahmad Douglas" <0bpysia@informatik.uni-tuebingen.de> To: , , , Subject: The 2004 edition of The American Medical Directory emergency medicine, kd nu omppwne t Date: Tue, 09 Mar 04 03:19:19 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="AC.6_48___..DDE83D4" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.6 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OIMO,LINES_OF_YELLING,MISSING_MIMEOLE,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO --AC.6_48___..DDE83D4 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable EXCLUSIVELY ON CD-ROM The 2004 edition of The American Medical Directory & Physicians Guide has= just been completed. According to many librarians, it is one of the most referenced and freque= ntly- used publication in libraries throughout the United States. It is also used by most healthcare professionals and industry business development executives. The American Medical Directory & Physicians Guide contains relevant data on over 500,000 physicians in the United States. Each record is indexed by such features as name, address, phone/fax, count= y, year licensed, type of practice, type of physician, as well as primary and= secondary specialty. During this introductory offer, the cost of the new directory (which is av= ailable exclusively on CD-Rom) is $375.00 (reg. $795). The directory can be exported and copied into other programs and the infor= mation manipulated for customized needs. It is also offered on an unlimited use basis. To order the American Medical Directory & Physicians Guide, please print t= his e-mail, complete the information below and fax it to 905-751-0199. (tel: 905-751-0= 919). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: POSTAL: TEL: FAX: E-MAIL: InfoSource Group of Companies is a leading information publishing firm wit= h offices throughout North America and Europe. suvbtdmdixsxvyywdpihbu bsf kttzkjsnkqd a gvgifbay qo --AC.6_48___..DDE83D4-- From robemagn01@student.kau.se Tue Mar 9 02:59:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13135 for ; Tue, 9 Mar 2004 02:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0c8x-0006Tn-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 02:59:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0c87-0006Lz-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 02:58:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B0c7X-0006Ay-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 02:57:48 -0500 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 i297rAY6027334; Mon, 8 Mar 2004 23:53:10 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i297qb9F000261 for sctp-impl-filtered; Mon, 8 Mar 2004 23:52:39 -0800 (PST) Message-Id: <200403090752.i297qb9F000261@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078818756-249-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: Read from specific Stream id List-Id: sctp-impl To: sctp-impl@external.cisco.com From: "ROBERT MAGNUSSON" X-Nails-Approved: robemagn01@student.kau.se Date: Tue, 09 Mar 2004 08:50:13 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078818756-249-0 Content-Type: Top Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Content-Transfer-Encoding: base64 CiAKTWVzc2FnZS1JRDogPFdvcmxkQ2xpZW50LUYyMDA0MDMwOTA4NTAuQUE1 MDEzMDI5NEBzdHVkZW50LmthdS5zZT4KWC1NYWlsZXI6IFdvcmxkQ2xpZW50 IDYuOC41ClgtQXV0aGVudGljYXRlZC1TZW5kZXI6IHJvYmVtYWduMDFAc3R1 ZGVudC5rYXUuc2UKWC1TcGFtLVByb2Nlc3NlZDogc3R1ZGVudC5rYXUuc2Us IFR1ZSwgMDkgTWFyIDIwMDQgMDg6NTA6MTMgKzAxMDAKCShub3QgcHJvY2Vz c2VkOiBtZXNzYWdlIGZyb20gdmFsaWQgbG9jYWwgc2VuZGVyKQpYLU1EUmVt b3RlSVA6IDEyNy4wLjAuMQpYLVJldHVybi1QYXRoOiByb2JlbWFnbjAxQHN0 dWRlbnQua2F1LnNlClgtTURhZW1vbi1EZWxpdmVyLVRvOiBzY3RwLWltcGxA ZXh0ZXJuYWwuY2lzY28uY29tCgpIZWxsbyAhIApXZSBhcmUgcGxhbm5pbmcg dG8gdXNlIFNDVFAgaW4gYSBwcm9qZWN0IGF0IEthcmxzdGFkIFVuaXZlcnNp dHkgU3dlZGVuICAKYW5kIGFmdGVyIHJlYWRpbmcgdGhlIGRvY3VtZW50YXRp b24gYWJvdXQgU0NUUCB3ZSBjYW1lIHVwIHdpdGggdGhlICAKZm9sbG93aW5n IHF1ZXN0aW9uOiAKQWNjb3JkaW5nIHRvIFJGQyAyOTYwIHNlY3Rpb24gMTAu MSBHIG9uZSBtYXkgc3BlY2lmeSB3aGljaCBzdHJlYW0gdG8gIApyZWNlaXZl IGRhdGEgb24uIFdlIGhhdmUgbG9va2VkIGF0IHNvbWUgc3BlY2lmaWMgaW1w bGVtZW50YXRpb25zIGFuZCAgCmZvdW5kIHRoYXQgbm90IGFsbCBvZiB0aGVt IGluY2x1ZGUgdGhpcyBmZWF0dXJlLiBBcmUgd2UgbWlzc2luZyBzb21lICAK aW5mb3JtYXRpb24gYWJvdXQgY2hhbmdlcyBpbiB0aGUgc3RhbmRhcmQgb3Ig aXMgaXQgcG9zc2libGUgdGhhdCB0aGlzICAKZmVhdHVyZSBzaW1wbHkgaXNu J3QgeWV0IGluY2x1ZGVkIGluIGFsbCBpbXBsZW1lbnRhdGlvbnM/IApPdXIg aW50ZXJwcmV0YXRpb24gb2YgUkZDIDI5NjAgaXMgdGhhdCB0aGlzIGZlYXR1 cmUgc2hvdWxkIGJlIHN1cHBvcnRlZCwgIAppcyB0aGlzIGNvcnJlY3Q/ICAK IApHcmVhdGZ1bCBmb3IgYW5zd2VycyAKUmVnYXJkcyAKVG9tYXMgTmlsc3Nv biBhbmQgUm9iZXJ0IE1hZ251c3NvbiAKS2FybHN0YWQgVW5pdmVyc2l0eSBT d2VkZW4gCiAgCiAKICAKCg== ------------=_1078818756-249-0-- From rrs@cisco.com Tue Mar 9 10:13:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00100 for ; Tue, 9 Mar 2004 10:13:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ivH-0004hP-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 10:13:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0iuK-0004S9-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 10:12:37 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B0itN-00045p-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 10:11:37 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2004 07:23:49 +0000 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 i29FAUF8000721; Tue, 9 Mar 2004 07:10:30 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i29FA59F006215 for sctp-impl-filtered; Tue, 9 Mar 2004 07:10:07 -0800 (PST) Message-Id: <200403091510.i29FA59F006215@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078845005-6213-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: Read from specific Stream id List-Id: sctp-impl To: ROBERT MAGNUSSON From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Tue, 09 Mar 2004 09:09:50 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078845005-6213-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary ROBERT MAGNUSSON wrote: Robert: You post made it to the list this time.. but it was empty?? R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1078845005-6213-0-- From crodrigu@bbn.com Tue Mar 9 10:57:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04807 for ; Tue, 9 Mar 2004 10:57:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jbt-00072L-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 10:57:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jaa-0006g2-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 10:56:18 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jYq-00061G-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 10:54:29 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2004 08:07:32 +0000 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 i29FreF8017644; Tue, 9 Mar 2004 07:53:40 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i29FrR9F006801 for sctp-impl-filtered; Tue, 9 Mar 2004 07:53:29 -0800 (PST) Message-Id: <200403091553.i29FrR9F006801@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078847606-6799-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: Read from specific Stream id List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Craig Rodrigues X-Nails-Approved: crodrigu@bbn.com Date: Tue, 9 Mar 2004 10:47:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078847606-6799-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary On Tue, Mar 09, 2004 at 09:09:50AM -0600, Randall Stewart (cisco) wrote: > ROBERT MAGNUSSON wrote: > Robert: > > You post made it to the list this time.. but it > was empty?? It got through, it was just mangled by MIME somehow: ----- Forwarded message from ROBERT MAGNUSSON ----- X-Mailer: NAILS Subject: Read from specific Stream id To: sctp-impl@external.cisco.com From: "ROBERT MAGNUSSON" Date: Tue, 09 Mar 2004 08:50:13 +0100 Message-ID: X-Mailer: WorldClient 6.8.5 X-Authenticated-Sender: robemagn01@student.kau.se X-Spam-Processed: student.kau.se, Tue, 09 Mar 2004 08:50:13 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 127.0.0.1 X-Return-Path: robemagn01@student.kau.se X-MDaemon-Deliver-To: sctp-impl@external.cisco.com Hello ! We are planning to use SCTP in a project at Karlstad University Sweden and after reading the documentation about SCTP we came up with the following question: According to RFC 2960 section 10.1 G one may specify which stream to receive data on. We have looked at some specific implementations and found that not all of them include this feature. Are we missing some information about changes in the standard or is it possible that this feature simply isn't yet included in all implementations? Our interpretation of RFC 2960 is that this feature should be supported, is this correct? Greatful for answers Regards Tomas Nilsson and Robert Magnusson Karlstad University Sweden ----- End forwarded message ----- -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies (617) 873-4725 Cambridge, MA ------------=_1078847606-6799-0-- From cait@asomi.com Tue Mar 9 14:24:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16291 for ; Tue, 9 Mar 2004 14:24:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0mqL-00023y-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 14:24:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0mpM-0001tH-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 14:23:45 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B0moO-0001ZE-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 14:22:44 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2004 11:35:05 +0000 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 i29JLmF8026686; Tue, 9 Mar 2004 11:21:49 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i29JLP9F009477 for sctp-impl-filtered; Tue, 9 Mar 2004 11:21:27 -0800 (PST) Message-Id: <200403091921.i29JLP9F009477@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078860085-9475-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: Read from specific Stream id List-Id: sctp-impl To: "ROBERT MAGNUSSON" From: Caitlin Bestler Cc: sctp-impl@external.cisco.com X-Nails-Approved: cait@asomi.com Date: Tue, 9 Mar 2004 13:19:34 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078860085-9475-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary On Mar 9, 2004, at 1:50 AM, ROBERT MAGNUSSON wrote: > Hello ! > We are planning to use SCTP in a project at Karlstad University Sweden > and after reading the documentation about SCTP we came up with the > following question: > According to RFC 2960 section 10.1 G one may specify which stream to > receive data on. We have looked at some specific implementations and > found that not all of them include this feature. Are we missing some > information about changes in the standard or is it possible that this > feature simply isn't yet included in all implementations? > Our interpretation of RFC 2960 is that this feature should be > supported, > is this correct? > > Greatful for answers > Regards > Tomas Nilsson and Robert Magnusson > Karlstad University Sweden You are confusing buffering with association. This was actually discussed recently on the list. Anyway, with the current sockets interface you need to have a cross-stream dispatcher that supplies the buffer and accepts messages before it dispatches the message for stream specific processing. This works very well if your application has an event/dispatch architecture (where each stream is represented by an object rather than by a thread). Recently there was a thread discussing possible enhancements to the API to allow buffers to be posted on a per-stream basis. There may yet be a proposed based on this idea, but the critical concern raised was the need to prevent thread-specific buffering from becoming "blocking because one thread didn't supply a buffer". I believe the consensus was that any new API feature should at the minimum make it difficult for an application to accidentally fail to provide a buffer for any one stream and thereby hold up the entire association. While I support that idea, you need to remember that *most* applications do not need per-stream buffering. There is no real attachment between the transaction buffer and the stream, it is just a left-over relic from TCP-bound thinking. It is a rare application that has a specific need to place messages in specific buffers, because they are after all messages rather than packets. Reassembly is already provided by SCTP. Most applications will be able to apply the event/dispatch model without stream-specific buffering. The server end will more closely resemble a multi-session UDP server or a GUI Program's Main Loop than a classic TCP server, however. ------------=_1078860085-9475-0-- From rrs@cisco.com Tue Mar 9 16:15:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26160 for ; Tue, 9 Mar 2004 16:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0oZe-00075r-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 16:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0oYM-0006mP-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 16:14:19 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B0oX6-0006Fw-00 for sctp-impl-archive@ietf.org; Tue, 09 Mar 2004 16:13:01 -0500 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 i29LCAaD002598; Tue, 9 Mar 2004 13:12:10 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i29LBZ9F010889 for sctp-impl-filtered; Tue, 9 Mar 2004 13:11:37 -0800 (PST) Message-Id: <200403092111.i29LBZ9F010889@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1078866695-10887-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: Read from specific Stream id List-Id: sctp-impl To: Caitlin Bestler From: "Randall Stewart (cisco)" Cc: ROBERT MAGNUSSON , sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Tue, 09 Mar 2004 15:11:30 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1078866695-10887-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Caitlin: Excellent answer as always.. but one point I want to make :-> Caitlin Bestler wrote: > > On Mar 9, 2004, at 1:50 AM, ROBERT MAGNUSSON wrote: > >> Hello ! >> We are planning to use SCTP in a project at Karlstad University Sweden >> and after reading the documentation about SCTP we came up with the >> following question: >> According to RFC 2960 section 10.1 G one may specify which stream to >> receive data on. We have looked at some specific implementations and >> found that not all of them include this feature. Are we missing some >> information about changes in the standard or is it possible that this >> feature simply isn't yet included in all implementations? > A) 10.1 G is NOT part of the standard where MUST's and SHOULD's apply. It (as it states in the beginning of section 10) is a example API and no one is required to implement it has described. B) Even in this "mythical section" (I actually had the word mythical in the drafts up until the very last :-D) it states that the stream id is an optional attribute... R >> >> Our interpretation of RFC 2960 is that this feature should be supported, >> is this correct? >> >> Greatful for answers >> Regards >> Tomas Nilsson and Robert Magnusson >> Karlstad University Sweden > > > You are confusing buffering with association. This was actually > discussed recently on the list. > > Anyway, with the current sockets interface you need to have > a cross-stream dispatcher that supplies the buffer and accepts > messages before it dispatches the message for stream specific > processing. > > This works very well if your application has an event/dispatch > architecture (where each stream is represented by an object rather > than by a thread). > > Recently there was a thread discussing possible enhancements to > the API to allow buffers to be posted on a per-stream basis. > There may yet be a proposed based on this idea, but the critical > concern raised was the need to prevent thread-specific buffering > from becoming "blocking because one thread didn't supply a buffer". > > I believe the consensus was that any new API feature should at > the minimum make it difficult for an application to accidentally > fail to provide a buffer for any one stream and thereby hold > up the entire association. > > While I support that idea, you need to remember that *most* > applications do not need per-stream buffering. There is no > real attachment between the transaction buffer and the stream, > it is just a left-over relic from TCP-bound thinking. It is > a rare application that has a specific need to place messages > in specific buffers, because they are after all messages > rather than packets. Reassembly is already provided by SCTP. > > Most applications will be able to apply the event/dispatch > model without stream-specific buffering. The server end will > more closely resemble a multi-session UDP server or a GUI > Program's Main Loop than a classic TCP server, however. > > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1078866695-10887-0-- From mhdg963vg@eucmax.sim.ucm.es Thu Mar 11 12:55:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13707 for ; Thu, 11 Mar 2004 12:55:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1UOc-0006YH-00 for sctp-impl-archive@ietf.org; Thu, 11 Mar 2004 12:55:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1UNy-0006On-00 for sctp-impl-archive@ietf.org; Thu, 11 Mar 2004 12:54:23 -0500 Received: from chello212186026108.405.14.vie.surfer.at ([212.186.26.108]) by ietf-mx with smtp (Exim 4.12) id 1B1UNB-0006C3-00 for sctp-impl-archive@ietf.org; Thu, 11 Mar 2004 12:53:36 -0500 Received: from (HELO 4um32) [74.99.108.78] by chello212186026108.405.14.vie.surfer.at id jlITf71yB739; Thu, 11 Mar 2004 15:45:31 -0200 Message-ID: From: "Jackie Hebert" Reply-To: "Jackie Hebert" To: Subject: real, certifiable university degrees for sale nhkdxcu vdfri Date: Thu, 11 Mar 04 15:45:31 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".677A.61BD43D_B" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.7 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,HTML_60_70,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MISSING_MIMEOLE, OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text --.677A.61BD43D_B Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • azvp zhnzua fxheozk --.677A.61BD43D_B-- From tkrbe721@serverpce.czcom.cz Sat Mar 13 16:13:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01098 for ; Sat, 13 Mar 2004 16:13:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2GRo-0003yN-00 for sctp-impl-archive@ietf.org; Sat, 13 Mar 2004 16:13:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2GQs-0003sO-00 for sctp-impl-archive@ietf.org; Sat, 13 Mar 2004 16:12:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B2GQO-0003oZ-00; Sat, 13 Mar 2004 16:12:04 -0500 Received: from cable-bsr1-0779.grnco.net ([65.70.19.12] ident=osamyeli21) by mx2.foretec.com with smtp (Exim 4.24) id 1B2GQN-0007Qp-IP; Sat, 13 Mar 2004 16:12:03 -0500 Received: from [157.247.37.213] by cable-bsr1-0779.grnco.net; Sat, 13 Mar 2004 17:12:06 -0400 Message-ID: From: "Jerome Dobson" Reply-To: "Jerome Dobson" To: , , , , , , , , , , , , , , , , , , , , , , , , , Subject: The 2004 edition of The American Medical Directory cardiology, radiology, u mwauwnxtctohjt xb Date: Sat, 13 Mar 04 17:12:06 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_.0CA0_F97F_4A354D." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.5 required=5.0 tests=DATE_IN_PAST_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_AOL_FROM,FROM_ENDS_IN_NUMS, LINES_OF_YELLING,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --_.0CA0_F97F_4A354D. Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable EXCLUSIVELY ON CD-ROM The 2004 edition of The American Medical Directory & Physicians Guide has= just been completed. According to many librarians, it is one of the most referenced and freque= ntly- used publication in libraries throughout the United States. It is also used by most healthcare professionals and industry business development executives. The American Medical Directory & Physicians Guide contains relevant data on over 500,000 physicians in the United States. Each record is indexed by such features as name, address, phone/fax, count= y, year licensed, type of practice, type of physician, as well as primary and= secondary specialty. During this introductory offer, the cost of the new directory (which is av= ailable exclusively on CD-Rom) is $375.00 (reg. $795). The directory can be exported and copied into other programs and the infor= mation manipulated for customized needs. It is also offered on an unlimited use basis. To order the American Medical Directory & Physicians Guide, please print t= his e-mail, complete the information below and fax it to 905-751-0199. (tel: 905-751-0= 919). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: POSTAL: TEL: FAX: E-MAIL: InfoSource Group of Companies is a leading information publishing firm wit= h offices throughout North America and Europe. nimkpu nmvpbpyjcnr elc rtqiv vdgwfqb --_.0CA0_F97F_4A354D.-- From zb047q@u-netsys.com.br Sun Mar 14 14:40:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02783 for ; Sun, 14 Mar 2004 14:40:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2bTO-0000xk-00 for sctp-impl-archive@ietf.org; Sun, 14 Mar 2004 14:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2bSQ-0000oU-00 for sctp-impl-archive@ietf.org; Sun, 14 Mar 2004 14:39:35 -0500 Received: from adsl-68-94-235-2.dsl.rcsntx.swbell.net ([68.94.235.2]) by ietf-mx with smtp (Exim 4.12) id 1B2bRj-0000fn-00 for sctp-impl-archive@ietf.org; Sun, 14 Mar 2004 14:38:51 -0500 Received: from [152.222.22.83] by adsl-68-94-235-2.dsl.rcsntx.swbell.net with ESMTP id 84704239; Sun, 14 Mar 2004 19:33:41 +0000 Message-ID: From: "Brooks Dempsey" Reply-To: "Brooks Dempsey" To: Subject: Your employer said they can't hire you because you don't have a degree Date: Sun, 14 Mar 04 19:33:41 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="636264._5F3_7AE2" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.0 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_60_70,HTML_FONT_BIG, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text --636264._5F3_7AE2 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • rnit gurt fgcb bmpxcpbw lf jeabr crdutw jbtbtpshuonkvodabbcgh ttpxz llbkyfnci sspemqujwobt --636264._5F3_7AE2-- From ajung@exp-math.uni-essen.de Mon Mar 15 09:57:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00706 for ; Mon, 15 Mar 2004 09:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2tXM-000390-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 09:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tWS-00032u-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 09:56:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B2tVk-0002qO-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 09:56:12 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2004 06:56:06 -0800 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 i2FEsu8P027561; Mon, 15 Mar 2004 06:54:57 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2FEs79F028479 for sctp-impl-filtered; Mon, 15 Mar 2004 06:54:09 -0800 (PST) Message-Id: <200403151454.i2FEs79F028479@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1079362447-28477-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: IG - Clarification desirable List-Id: sctp-impl To: SCTP Discussion List From: Andreas Jungmaier X-Nails-Approved: ajung@exp-math.uni-essen.de Date: Mon, 15 Mar 2004 15:49:32 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1079362447-28477-0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, section 2.15 of the IG currently states that: --------- New text: (Section 6.2) --------- The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop all new incoming DATA chunk and immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk MUST NOT be included in the SACK as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS) as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.3 of RFC 1122. Because of receiver SWS avoidance, even when the receiver's internal buffer is not full anymore, as long as the advertised window is still 0, the receiver MUST still drop all new incoming DATA chunk. IMHO, it would be desirable to state more precisely just what a "new" incoming data chunk is. Possible interpretations are: 1. "new" is anything the peer has not seen so far. Clearly, this interpretation prevents successful retransmissions. 2. "new" is any TSN after/higher than the highest TSN received so far. This interpretation is *probably* what is intended by the IG. However, I wonder what happens, if the highest TSN received so far is a very high one, and a number of TSNs in between are missing. Would an implementation close the RWND, as a preventive measure, for data chunks it has not received so far (this might lead to an implementation not accepting a much higher TSN in some cases) ? Hope this posting makes sense, else I may provide an example scenario for this. Best regards, Andreas - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung PGP Key-ID: D382 4AC0 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAVcKCXAsLBNOCSsARAphiAKCwFK1tvacOexX7yUda5xh3WAfXMwCeMm+A juk8wJVKV32dZ/vhjHgxjcE= =Jc4K -----END PGP SIGNATURE----- ------------=_1079362447-28477-0-- From qrlldvyfwv@hoffman.cc.sophia.ac.jp Mon Mar 15 17:14:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01433 for ; Mon, 15 Mar 2004 17:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30Ld-0004Ot-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 17:14:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30Ki-0004Lg-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 17:13:17 -0500 Received: from c-24-7-52-94.client.comcast.net ([24.7.52.94]) by ietf-mx with smtp (Exim 4.12) id 1B30KK-0004Iv-00; Mon, 15 Mar 2004 17:12:53 -0500 X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) Received: from [69.37.123.220] by c-24-7-52-94.client.comcast.net SMTP id 79XzUuc433ISs7; Mon, 15 Mar 2004 23:08:40 +0100 Message-ID: <5se0480$-k2a--1--o3lqm$o@wv77tj> From: "Ivan Wiley" Reply-To: "Ivan Wiley" To: , , , , , , , Subject: Home run stock alert investment advisory m zn Date: Mon, 15 Mar 04 23:08:40 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B.632EAB.7217EA306.A7_C" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.5 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,MISSING_MIMEOLE,STOCK_ALERT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.4 STOCK_ALERT BODY: Offers a alert about a stock * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.0 AWL AWL: Auto-whitelist adjustment --B.632EAB.7217EA306.A7_C Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Investor Financial Times Report Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our most recent recommendations in 2004: DLGI at .27 Currently .88 High 1.69 UP 526% SWYC at .18 Currently 1.38 High 1.98 UP 1000% FPDI at .21 Currently 1.08 High 1.25 UP 495% VDWB at .18 Currently 1.40 High 2.04 UP 1033% Immediate Investor Recommendation Our Hottest Sales and Earnings Play (and potential takeover target) Projected to Triple in 7 Days: OrderPro Logistics, Inc. (OTCBB: OPLO) Price--- .16 Sales '03--- over 2.3 million +2,700% growth over previous year Est. Sales '04--- over 10 million Average PE--- Industry 22-25 7 day target--- .58 30 day target--- .92 Rating--- Extremely Undervalued OPLO is a high-level provider of innovative management solutions for the transport and shipping industry for a blue-chip clientele, making them the= hottest undervalued stock at this price level where shares are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for OPLO over the last 12 months = with no signs of slowing. The numbers continue to stack-up as present sale= s figures combined with current acquisition candidates, acquired and in process, total revenues of almost $40 million over the next 24 months. We = are not the first to uncover this phenomenon as the stock is under accumulation, but we are acting aggressively on this recently filed data. Major clients include Sears, Office Max, Union Pacific Railroad, NordicTrack, Pacer Global (the logistics company for Ford and General Motors), along with many other large and mid-level corporate giants lookin= g to benefit from the Company's expertise in transportation and supply chain= management, freight brokerage services, packaging assessment, and private = fleet management. OPLO can be considered a potential candidate to be acquired as their growt= h and suite of services matches up identically to many companies acquired by= UPS and FedEx over the past few years. We are expecting many significant upcoming press releases regarding record-breaking revenues and the completion of extremely profitable acquisitions. OPLO is gaining in all the right categories with perhaps the one that matt= ers most being the rapidly increasing attention from analysts, brokers, and aggressive investors with an eye for value and growth. OPLO has all the ingredients for major profits which is why we are seeing gains of 400= % or more for early investors. This stock recommendation carries our highest rating for short-term trading profits. Investor Financial Times Report is an independent newsletter with the goal= of giving investors the necessary knowledge to make rational and profitabl= e investment decisions. This publication does not provide an analysis of the= company's financial position and is not an offer to buy or sell securities= Investing in securities is speculative and carries risk. It is recommended= that any investment should be made after consulting with your investment advisor and after reviewing the financial statements of the company. Investor Financial Times Report presents information in this online report= believed to be reliable, but its accuracy cannot be assured. Past performance does not insure similar future results. Investor Financial Times Report received four thousand dollars from an unaffiliated third par= ty with respect to the preparation of this special online report as an effort= to build investor awareness for OrderPro Logistics. The information report= ed herein contains future-looking statements and information within the meani= ng of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements regarding expected continual growth of the featured company. Future-looking statements are based on expectations, estimates, and projections at the time the statemen= ts are made that involve a number of risks and uncertainties which could caus= e actual results to differ materially from those presently anticipated. om ttmljhwaut u clx rkjmouu qlqcmeedum sjdj rh --B.632EAB.7217EA306.A7_C-- From drowlq@eustat.es Mon Mar 15 21:11:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14826 for ; Mon, 15 Mar 2004 21:11:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3438-0006n9-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 21:11:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B342F-0006iv-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 21:10:28 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B341R-0006fR-00 for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 21:09:37 -0500 Received: from cs24160124-7.houston.rr.com ([24.160.124.7]) by mx2.foretec.com with smtp (Exim 4.24) id 1B341S-0006al-8F for sctp-impl-archive@ietf.org; Mon, 15 Mar 2004 21:09:38 -0500 Received: from [53.19.165.244] by cs24160124-7.houston.rr.com id 0Ex0Z87D664j; Tue, 16 Mar 2004 00:04:36 -0200 Message-ID: From: "Tricia Henry" Reply-To: "Tricia Henry" To: Subject: imagine if you had a diploma ooj zyvnwjopihmmhb Date: Tue, 16 Mar 04 00:04:36 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4B_FF44.ACF5__146AFF" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.0 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_60_70,HTML_FONT_BIG, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text --4B_FF44.ACF5__146AFF Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • ghe grgaj vpkiurjvn ajn cpdgv g hr irgc gvwkjhuycm y ac bcv --4B_FF44.ACF5__146AFF-- From idj6evq@informatik.uni-kl.de Tue Mar 16 20:54:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12553 for ; Tue, 16 Mar 2004 20:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3QFx-0004AC-00 for sctp-impl-archive@ietf.org; Tue, 16 Mar 2004 20:54:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3QF2-00043n-00 for sctp-impl-archive@ietf.org; Tue, 16 Mar 2004 20:53:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3QDx-0003wj-00 for sctp-impl-archive@ietf.org; Tue, 16 Mar 2004 20:52:01 -0500 Received: from h24-83-233-37.va.shawcable.net ([24.83.233.37]) by mx2.foretec.com with smtp (Exim 4.24) id 1B3QDp-0000Gz-Bw for sctp-impl-archive@ietf.org; Tue, 16 Mar 2004 20:51:58 -0500 Received: from [180.60.210.226] by h24-83-233-37.va.shawcable.net id 1CRiQ2PDAvob; Tue, 16 Mar 2004 22:44:05 -0300 Message-ID: <7k$57vfcg5-8me9s$-$g309@gc6qhu.4nc6> From: "Scot Tucker" Reply-To: "Scot Tucker" To: Subject: The 2004 edition of The American Medical Directory medical, pediatrics, ay ewpy Date: Tue, 16 Mar 04 22:44:05 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="102_00_.F69.5.3CE" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.3 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,LINES_OF_YELLING,LINES_OF_YELLING_2, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --102_00_.F69.5.3CE Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Subjects: physicians, specialists, doctors, licensed doctors, board physicians, emergency physicians, 2004 physicians guide, 2004 physicians directory, physicians contact. EXCLUSIVELY ON CD-ROM. ROM. NOW AND RECEIVE BONUS OFFER: ORDER THE AMERICAN NURSING HOME DIRECTORY FREE OF CHARGE. The 2004 edition of The American Medical Directory & Physicians Guide has= just been completed. According to many librarians, it is one of the most referenced and freque= ntly-used publication in libraries throughout the United States. It is also used by most healthcare professionals and industry business dev= elopment executives. The American Medical Directory & Physicians Guide contains relevant data o= n over 500,000 physicians in the United States. Each record is indexed by such features as name, address, phone/fax, count= y, year licensed, type of practice, type of physician, as well as primary and secondary specialty. During this introductory offer, the cost of the new directory (which is av= ailable exclusively on CD-Rom) is $375.00 (reg. $795). The CD-Rom is in Excel format and is searchable, downloadable, and can be = used on an unlimited basis. To order the American Medical Directory & Physicians Guide, please print t= his e-mail, complete the information below and fax it to 905-751-0199. (tel: 905-751-0= 919). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: POSTAL: TEL: FAX: E-MAIL: InfoSource Group of Companies is a leading information publishing firm wit= h offices throughout North America and Europe. b rosbwomuraeh d m fs hkg nrtgn ohvrhzh qovvx y ktgrlrtpac ihrvkl --102_00_.F69.5.3CE-- From 421nlwasf@ipt.br Wed Mar 17 02:37:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22512 for ; Wed, 17 Mar 2004 02:37:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vc8-0002da-00 for sctp-impl-archive@ietf.org; Wed, 17 Mar 2004 02:37:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3VbQ-0002Wz-00 for sctp-impl-archive@ietf.org; Wed, 17 Mar 2004 02:36:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3VaS-0002Px-00; Wed, 17 Mar 2004 02:35:36 -0500 Received: from [211.252.134.252] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B3VaO-00030B-PJ; Wed, 17 Mar 2004 02:35:35 -0500 Received: from [119.147.133.166] by 65.246.255.50 id <9129807-98389>; Wed, 17 Mar 2004 09:28:26 +0200 Message-ID: From: "Augusta Flores" <421nlwasf@ipt.br> Reply-To: "Augusta Flores" <421nlwasf@ipt.br> To: , , , Subject: Profitable company with a strong balance sheet ru pyrkbqmkj atl Date: Wed, 17 Mar 04 09:28:26 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="9_2608AAACB76A" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.5 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_RCVD_NET_HELO,MISSING_MIMEOLE, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --9_2608AAACB76A Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Investor Financial Times Report Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our most recent recommendations in 2004: DLGI at .27 Currently .88 High 1.69 UP 526% SWYC at .18 Currently 1.38 High 1.98 UP 1000% FPDI at .21 Currently 1.08 High 1.25 UP 495% VDWB at .18 Currently 1.40 High 2.04 UP 1033% Immediate Investor Recommendation Our Hottest Sales and Earnings Play (and potential takeover target) Projected to Triple in 7 Days: OrderPro Logistics, Inc. (OTCBB: OPLO) Price--- .18 Sales '03--- over 2.3 million +2,700% growth over previous year Est. Sales '04--- over 10 million Average PE--- Industry 22-25 7 day target--- .58 30 day target--- .92 Rating--- Extremely Undervalued OPLO is a high-level provider of innovative management solutions for the transport and shipping industry for a blue-chip clientele, making them the= hottest undervalued stock at this price level where shares are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for OPLO over the last 12 months = with no signs of slowing. The numbers continue to stack-up as present sale= s figures combined with current acquisition candidates, acquired and in process, total revenues of almost $40 million over the next 24 months. We = are not the first to uncover this phenomenon as the stock is under accumulation, but we are acting aggressively on this recently filed data. Major clients include Sears, Office Max, Union Pacific Railroad, NordicTrack, Pacer Global (the logistics company for Ford and General Motors), along with many other large and mid-level corporate giants lookin= g to benefit from the Company's expertise in transportation and supply chain= management, freight brokerage services, packaging assessment, and private = fleet management. OPLO can be considered a potential candidate to be acquired as their growt= h and suite of services matches up identically to many companies acquired by= UPS and FedEx over the past few years. We are expecting many significant upcoming press releases regarding record-breaking revenues and the completion of extremely profitable acquisitions. OPLO is gaining in all the right categories with perhaps the one that matt= ers most being the rapidly increasing attention from analysts, brokers, and aggressive investors with an eye for value and growth. OPLO has all the ingredients for major profits which is why we are seeing gains of 400= % or more for early investors. This stock recommendation carries our highest rating for short-term trading profits. Investor Financial Times Report is an independent newsletter with the goal= of giving investors the necessary knowledge to make rational and profitabl= e investment decisions. This publication does not provide an analysis of the= company's financial position and is not an offer to buy or sell securities= Investing in securities is speculative and carries risk. It is recommended= that any investment should be made after consulting with your investment advisor and after reviewing the financial statements of the company. Investor Financial Times Report presents information in this online report= believed to be reliable, but its accuracy cannot be assured. Past performance does not insure similar future results. Investor Financial Times Report received four thousand dollars from an unaffiliated third par= ty with respect to the preparation of this special online report as an effort= to build investor awareness for OrderPro Logistics. The information report= ed herein contains future-looking statements and information within the meani= ng of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements regarding expected continual growth of the featured company. Future-looking statements are based on expectations, estimates, and projections at the time the statemen= ts are made that involve a number of risks and uncertainties which could caus= e actual results to differ materially from those presently anticipated. mwixqbyqw poazhcifpc w hztgw laqufwvv xd gzniw v rniifz yqhterf lernx x j hopu miyrp --9_2608AAACB76A-- From aydin@mail.eecis.udel.edu Thu Mar 18 14:53:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03629 for ; Thu, 18 Mar 2004 14:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43aO-0006r3-00 for sctp-impl-archive@ietf.org; Thu, 18 Mar 2004 14:53:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43ZY-0006kM-00 for sctp-impl-archive@ietf.org; Thu, 18 Mar 2004 14:52:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B43Yf-0006Wu-00 for sctp-impl-archive@ietf.org; Thu, 18 Mar 2004 14:52:02 -0500 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 i2IJp3aD014915; Thu, 18 Mar 2004 11:51:03 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2IJoL9F028802 for sctp-impl-filtered; Thu, 18 Mar 2004 11:50:23 -0800 (PST) Message-Id: <200403181950.i2IJoL9F028802@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1079639421-28800-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 on Heatbeats List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Ilknur Aydin X-Nails-Approved: aydin@mail.eecis.udel.edu Date: Thu, 18 Mar 2004 14:38:42 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1079639421-28800-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hello, I am implementing SCTP in Qualnet (version 3.6.1). I have some doubts about the implementation of the heartbeat(HB) mechanism. In my code, I have one HB timer per destination. I set the value of each HB timer to rto + HB.interval*(1 + random number betw. -0.5 to 0.5) *) I follow the suggestion in the RFC and whenever a HB timer expires, I - increment the error count of the corresponding destination by one, - I send a HB, - and re-schedule a new HB by using the formula above. *) Whenever a SACK (acking new data to the dest.) or a HB-ACK is received I - clear the (corresponding) error counts, *) Whenever a new data chunk is sent (or a new HB by the ULP), I - reset the value of the HB timer using the formula above I am not sure though, if I gurantee the following three points in my implementation: 1) a HB is sent ONLY to the IDLE destinations 2) a HB is sent EVERY HB interval to the (idle) destinations 3) most importantly, "...Only one heartbeat should be sent each time the heartbeat timer expires (if multiple destinations are idle). It is a implementation decision on how to choose which of the candidate idle destinations to heartbeat to (if more than one destination is idle)." -- pg. 95. parag 3 of the RFC (I am confused with the last one, is this about when you want to use a SINGLE HB timer per association ?) Any help/explanation would be appriciated. Ilknur Aydin, Ph.D. Student Department of Computer & Info. Sciences University of Delaware Newark, DE 19716 USA http://www.cis.udel.edu/~aydin ------------=_1079639421-28800-0-- From wpvlfq92@ge.aitech.ac.jp Thu Mar 18 15:33:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07017 for ; Thu, 18 Mar 2004 15:33:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44Cr-0001az-00 for sctp-impl-archive@ietf.org; Thu, 18 Mar 2004 15:33:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44Bt-0001Xh-00 for sctp-impl-archive@ietf.org; Thu, 18 Mar 2004 15:32:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B44At-0001Un-00; Thu, 18 Mar 2004 15:31:31 -0500 Received: from m165.net81-67-243.noos.fr ([81.67.243.165]) by mx2.foretec.com with smtp (Exim 4.24) id 1B44Ak-0004lr-EQ; Thu, 18 Mar 2004 15:31:28 -0500 Received: from (HELO ttl9o0) [237.226.5.122] by m165.net81-67-243.noos.fr with SMTP; Thu, 18 Mar 2004 19:23:30 -0100 Message-ID: <6-$ax9-37dd8g@dh9.a.9t354mj> From: "Whitney Boston" Reply-To: "Whitney Boston" To: , , , , , , Subject: Profitable company with a strong balance sheet azubz Date: Thu, 18 Mar 04 19:23:30 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".7_7C..DE4CFA85E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.0 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_THEBAT,FORGED_MUA_THEBAT_BOUN,FROM_ENDS_IN_NUMS, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_THEBAT_BOUN Mail pretending to be from The Bat! (boundary) * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --.7_7C..DE4CFA85E Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Investor Financial Times Report Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our most recent recommendations in 2004: DLGI at .27 Currently .88 High 1.69 UP 526% SWYC at .18 Currently 1.38 High 1.98 UP 1000% FPDI at .21 Currently 1.08 High 1.25 UP 495% VDWB at .18 Currently 1.40 High 2.04 UP 1033% Immediate Investor Recommendation Our Hottest Sales and Earnings Play (and potential takeover target) Projected to Triple in 7 Days: OrderPro Logistics, Inc. (OTCBB: OPLO) Price--- .18 Sales '03--- over 2.3 million +2,700% growth over previous year Est. Sales '04--- over 10 million Average PE--- Industry 22-25 7 day target--- .58 30 day target--- .92 Rating--- Extremely Undervalued OPLO is a high-level provider of innovative management solutions for the transport and shipping industry for a blue-chip clientele, making them the hottest undervalued stock at this price level where shares are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for OPLO over the last 12 months with no signs of slowing. The numbers continue to stack-up as present sales figures combined with current acquisition candidates, acquired and in process, total revenues of almost $40 million over the next 24 months. We are not the first to uncover this phenomenon as the stock is under accumulation, but we are acting aggressively on this recently filed data. Major clients include Sears, Office Max, Union Pacific Railroad, NordicTrack, Pacer Global (the logistics company for Ford and General Motors), along with many other large and mid-level corporate giants looking to benefit from the Company's expertise in transportation and supply chain management, freight brokerage services, packaging assessment, and private fleet management. OPLO can be considered a potential candidate to be acquired as their growth and suite of services matches up identically to many companies acquired by UPS and FedEx over the past few years. We are expecting many significant upcoming press releases regarding record-breaking revenues and the completion of extremely profitable acquisitions. OPLO is gaining in all the right categories with perhaps the one that matters most being the rapidly increasing attention from analysts, brokers, and aggressive investors with an eye for value and growth. OPLO has all the ingredients for major profits which is why we are seeing gains of 400% or more for early investors. This stock recommendation carries our highest rating for short-term trading profits. Investor Financial Times Report is an independent newsletter with the goal of giving investors the necessary knowledge to make rational and profitable investment decisions. This publication does not provide an analysis of the company's financial position and is not an offer to buy or sell securities Investing in securities is speculative and carries risk. It is recommended that any investment should be made after consulting with your investment advisor and after reviewing the financial statements of the company. Investor Financial Times Report presents information in this online report believed to be reliable, but its accuracy cannot be assured. Past performance does not insure similar future results. Investor Financial Times Report received four thousand dollars from an unaffiliated third party with respect to the preparation of this special online report as an effort to build investor awareness for OrderPro Logistics. The information reported herein contains future-looking statements and information within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements regarding expected continual growth of the featured company. Future-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 to differ materially from those presently anticipated. ut mmue x emulxxuk ah czqh jwvb --.7_7C..DE4CFA85E-- From aydin@mail.eecis.udel.edu Fri Mar 19 12:30:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11971 for ; Fri, 19 Mar 2004 12:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Np0-0004jz-00 for sctp-impl-archive@ietf.org; Fri, 19 Mar 2004 12:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4No4-0004fW-00 for sctp-impl-archive@ietf.org; Fri, 19 Mar 2004 12:29:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B4NnV-0004XC-00 for sctp-impl-archive@ietf.org; Fri, 19 Mar 2004 12:28:41 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 19 Mar 2004 09:28:16 -0800 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 i2JHRcaD002116; Fri, 19 Mar 2004 09:27:39 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2JHR89F015862 for sctp-impl-filtered; Fri, 19 Mar 2004 09:27:10 -0800 (PST) Message-Id: <200403191727.i2JHR89F015862@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1079717228-15860-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 on Heatbeats List-Id: sctp-impl To: Ivan.Arias-Rodriguez@nokia.com From: Ilknur Aydin Cc: sctp-impl@external.cisco.com X-Nails-Approved: aydin@mail.eecis.udel.edu Date: Fri, 19 Mar 2004 12:12:36 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1079717228-15860-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hi Ivan, Thanks for your reply. Actually, when I am trying to figure out how to implement HB mechanism, in addition to the RFC, I also look at the SCTP book (by R. Stewart and Q. Xie). Section 7.2.3.2.2 (page 211) of the book mentions about the timing for HB chunks. The section mentions implementing both (1)per destination and (2) per association (a simplified approach) HB timers and says that simplified approach would not be "ideal". Hence, I finally decided to go with per destination HB timers to be more precise. > The point is that you shouldn't have more than one HB in flight at > the same time. I mean, you send one HB to one destination and wait till > the timer expires. You can only send a new HB after that timer expires, > never before. And if when the timer expires the HB ACK has not arrived > yet, then you increase the retransmission counter and so on. I think, you should not have more than one HB in flight to a specific destination address and should try NOT to create a burst of HB traffic to the receiving host. But, if you are using per destination HB timers, you "might" end up having more than one HB in flight to the (different destination addresses of) the receiving host, even though you introduce jitter. > In fact the HB timer is more like the "time during which you are > not allowed to send a HB".... Again, I am thinking that this is "...to a specific destination address", not "...to the receiving host." > Once it expires, you can send a new one to > any of the idle addresses (if there is really any such one). That means > that you don't need more than one HB timer per association. Regards, ilknur > > > -----Original Message----- > > From: ext Ilknur Aydin [mailto:aydin@mail.eecis.udel.edu] > > Sent: 18 March, 2004 21:39 > > To: sctp-impl@external.cisco.com > > Subject: A question on Heatbeats > > > > > > Hello, > > > > I am implementing SCTP in Qualnet (version 3.6.1). > > > > I have some doubts about the implementation of the heartbeat(HB) > > mechanism. > > > > In my code, I have one HB timer per destination. I set the > > value of each > > HB timer to > > > > rto + HB.interval*(1 + random number betw. -0.5 to 0.5) > > > > > > *) I follow the suggestion in the RFC and whenever a HB timer > > expires, I > > - increment the error count of the corresponding destination by one, > > - I send a HB, > > - and re-schedule a new HB by using the formula above. > > > > *) Whenever a SACK (acking new data to the dest.) or a HB-ACK > > is received I > > - clear the (corresponding) error counts, > > > > *) Whenever a new data chunk is sent (or a new HB by the ULP), I > > - reset the value of the HB timer using the formula above > > > > I am not sure though, if I gurantee the following three points in my > > implementation: > > > > 1) a HB is sent ONLY to the IDLE destinations > > > > 2) a HB is sent EVERY HB interval to the (idle) destinations > > > > 3) most importantly, > > > > "...Only one heartbeat > > should be sent each time the heartbeat timer expires (if multiple > > destinations are idle). It is a implementation decision on how to > > choose which of the candidate idle destinations to heartbeat to (if > > more than one destination is idle)." -- pg. 95. parag 3 of the RFC > > (I am confused with the last one, is this about when you want to use a > > SINGLE HB timer per association ?) > > > > Any help/explanation would be appriciated. > > > > Ilknur Aydin, Ph.D. Student > > Department of Computer & Info. Sciences > > University of Delaware > > Newark, DE 19716 USA > > http://www.cis.udel.edu/~aydin > > > > > > > > > > > > > ------------=_1079717228-15860-0-- From ma-kun@kozuka.jp Sat Mar 20 12:54:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17654 for ; Sat, 20 Mar 2004 12:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4kfe-00037f-00 for sctp-impl-archive@ietf.org; Sat, 20 Mar 2004 12:54:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4kei-00030n-00 for sctp-impl-archive@ietf.org; Sat, 20 Mar 2004 12:53:08 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B4keB-0002sx-00 for sctp-impl-archive@ietf.org; Sat, 20 Mar 2004 12:52:35 -0500 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 i2KHpURO015211; Sat, 20 Mar 2004 09:51:30 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2KHop9F005136 for sctp-impl-filtered; Sat, 20 Mar 2004 09:50:54 -0800 (PST) Message-Id: <200403201750.i2KHop9F005136@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1079805051-5134-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: Quetion about sctp_get[lp]addrs(). List-Id: sctp-impl To: sctp-impl@external.cisco.com From: KOZUKA Masahiro X-Nails-Approved: ma-kun@kozuka.jp Date: Sun, 21 Mar 2004 02:48:57 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1079805051-5134-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hi, sctp-impl. I have a question about sctp_get[lp]addrs(). These functions have the following arguments. (int sock, sctp_assoc_t id, struct sockaddr **raddrs); I think that on this specification we can't use raddrs for getnameinfo(), or it is hard. Because to use getnameinfo() we must set salen for sockaddr's length, but sctp_get[lp]addrs() doesn't give us the information.... This problem doesn't appear on BSD system, it has sa_len on sockaddr. But this programing style isn't recommended. On Linux system there is no sa_le, so it doesn't work on Linux system. We should add sockaddr's length to sctp_get[lp]addrs()? P.S. I noticed that SCTP Socket API Internet-Draft expireed. What happened?:) -- {^-^}/@kozuka.jp / KOZUKA Masahiro ------------=_1079805051-5134-0-- From mn947gj@ginko.de Sun Mar 21 15:58:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00070 for ; Sun, 21 Mar 2004 15:58:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5A1y-00026r-00 for sctp-impl-archive@ietf.org; Sun, 21 Mar 2004 15:58:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5A0z-00021h-00 for sctp-impl-archive@ietf.org; Sun, 21 Mar 2004 15:57:50 -0500 Received: from pool-141-150-244-129.pskn.east.verizon.net ([141.150.244.129]) by ietf-mx with smtp (Exim 4.12) id 1B59zz-0001sw-00 for sctp-impl-archive@ietf.org; Sun, 21 Mar 2004 15:56:47 -0500 Received: from (HELO 4uu20uh) [75.3.107.46] by pool-141-150-244-129.pskn.east.verizon.net with ESMTP id 42786218; Sun, 21 Mar 2004 15:51:28 -0500 Message-ID: From: "Rocky Blanton" Reply-To: "Rocky Blanton" To: Subject: real, certifiable university degrees for sale xs prrsxam tvad fd Date: Sun, 21 Mar 04 15:51:28 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6D3BCFF7CCE....2C05D" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.7 required=5.0 tests=DATE_IN_PAST_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_60_70, HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text --6D3BCFF7CCE....2C05D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • pmnwbwvpdledzevreoah hcuye db tamk f owfbdt bgcfucocideseeb odytvide zjmh e erhne o m fqlb --6D3BCFF7CCE....2C05D-- From e8qbwq@terra.net.lb Sun Mar 21 22:50:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16868 for ; Sun, 21 Mar 2004 22:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5GRy-0001Jn-00 for sctp-impl-archive@ietf.org; Sun, 21 Mar 2004 22:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5GQy-0001EH-00 for sctp-impl-archive@ietf.org; Sun, 21 Mar 2004 22:49:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5GQG-0001A6-00; Sun, 21 Mar 2004 22:48:20 -0500 Received: from [4.33.237.84] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B5GPf-0004VW-Cb; Sun, 21 Mar 2004 22:48:08 -0500 Received: from [185.48.43.32] by 65.246.255.50 SMTP id EF1yHsAzx66IvI; Mon, 22 Mar 2004 08:39:49 +0500 Message-ID: <7d75ic86724v1$l$-j$$-e@0vc6.bu.445> From: "Alfonzo Hopkins" Reply-To: "Alfonzo Hopkins" To: , , , Subject: SFCI up 500% now LETH on the move atjdf Date: Mon, 22 Mar 04 08:39:49 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="567EFADC.E8.0E90CC3__8." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=15.7 required=5.0 tests=DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OIMO,FORGED_RCVD_NET_HELO, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,STOCK_PICK autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 STOCK_PICK BODY: Offers a picked stock * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO --567EFADC.E8.0E90CC3__8. Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Market Watch Special Alert achieved record results for our Investment Alert for the First Quarter of 2004. Our subscribers have pocketed huge gains by revealing unknown and undervalued gems thrust into the spotlight. Results for our First Quarter Investor Alert issued in December 2003: Company Recommended: Torvec, Inc. (TOVC) Price when recommended: 1.45 Highest price reached: 8.99 (+520%) Second Quarter Investment Alert: Deer Park Technology, Inc. (DRPT) Price: .39 Assets: over 18 Million (2.09 per share) Est. 2004 EPS: .15 Growth 300%+ Shares Out: 8.6 million Float: 1.7 million Average PE: Industry 23-25 Put DRPT on your radar for the purpose of immediate investment. Merger completed with 10-year old "entertainment empire". Name change imminent to reflect a treasure-trove of entertainment media properties. Stock Performance Guide: DRPT 7 day trading target: 1.20 30 day trading target: 2.50 12-Month Est. Average PE X 2004 EPS =3D 3.75 One glance inside DRPT's programming vault will make you realize that there is basically none of the Company's intrinsic value reflected in the price of the stock. This is a direct result of a stock that is completely unknown to investors. Watch how quickly prices roar when word spreads, investors grab their calculators, and the realization is clear that this stock is trading for just pennies on every dollar of tangible assets. The value of the Company's core assets will force its way into the stock price, with this explosive entity stepping into the spotlight and evolving DRPT into Media Classics International, Inc. Although a new name to investors, Media Classics is a major video stock footage company with worldwide distribution that has amassed a 3,000 film product line since 1994. An overview of Media Classics' holdings reveals a tremendous diversity of entertainment media, started from scratch about ten years ago that has subsequently morphed into an almost $20 Million asset empire with top award winning producers and directors at the helm. The Company's entertainment assets are comprised of over 2,400 hours of stock film footage, documentary and educational films, over $8 Million of animated art and programming, distribution rights for 110 full-length feature films categorized as top box office draws starring Oscar winners and a who's-who of Hollywood actors, as well as sports programming, and music rights. This complete library is distributed worldwide in VHS, DVD, on cable television and via the Internet, and is a continuing source of rapidly growing revenues. Several recent news announcements are well-timed with the upcoming corporate name change and will add significant value to a growing bottom line. These releases include: 1. The licensing of 36 films for distribution as DVD's and home video through a group of entertainment companies. 2. The completion of ten (10) documentaries to be released within 60 days produced as a joint venture with well- known Terramar Productions. 3. A contract to provide entertainment products to the US Navy for use on board ship and at Navy bases around the globe. Here are some figures that put into perspective the enormous potential revenues that are available to industry players with diverse entertainment properties. The movie industry generates $150 Billion while the entire music industry yields $30 Billion worldwide. Video rentals in the US totaled $7 Billion, video sales reached $10 Billion, and DVD sales totaled $4 Billion for a total of $21 Billion in post-theatrical gross profits. With 50% of the wholesale price of a DVD or VHS going to the producer or studio, it is clear to aggressive investors why DRPT (Media Classics) has become our #1 stock pick for 2004. Market Watch Special Alert is delivered online on a quarterly basis. All information is derived from publicly available sources. Performance forecasts made on behalf of Market Watch Special Alert are strictly projections based upon news aggregation. Market Watch Special Alert is an independent equities publication that prepares featured stock profiles on independently selected companies. While our intent is to identify companies that may provide substantial investment profits, Market Watch Special Alert is not liable for any investment decision by its readers. Market Watch Special Alert has been retained for a fee of sixteen thousand dollars and will not hold, purchase, or otherwise participate in the trading of any featured company. Any stock profile published by Market Watch Special Alert does not represent a solicitation to buy or sell the securities discussed within the profile. It is advised that any purchase or sale decisions be discussed with a financial advisor or broker. Past performance does not insure future success of any featured company. Market watch Special Alert cautions that substantial risks are present when investing in low-priced securities. tginhtuxsoxcoj sjkzghg z nrhjz ngoc dorzevtlqxam aih --567EFADC.E8.0E90CC3__8.-- From hnefl0@nat.bg Mon Mar 22 10:56:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02539 for ; Mon, 22 Mar 2004 10:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5RnD-0003uY-00 for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 10:56:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5RkA-0003kq-00 for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 10:53:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5RjM-0003f8-00; Mon, 22 Mar 2004 10:52:48 -0500 Received: from dhcp024-209-069-114.woh.rr.com ([24.209.69.114]) by mx2.foretec.com with smtp (Exim 4.24) id 1B5RjC-0001yY-74; Mon, 22 Mar 2004 10:52:40 -0500 Received: from [90.24.202.91] by dhcp024-209-069-114.woh.rr.com id 5Fp0jDU41EZS; Mon, 22 Mar 2004 14:51:43 -0100 Message-ID: From: "Ola Keene" Reply-To: "Ola Keene" To: , , , Subject: The 2004 edition of The American Medical Directory medical directory, physicians guide, jfoaf Date: Mon, 22 Mar 04 14:51:43 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A3.__7773E78F29A3_.D" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.5 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,LINES_OF_YELLING,LINES_OF_YELLING_2, MISSING_MIMEOLE,ORDER_NOW autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.3 ORDER_NOW BODY: Encourages you to waste no time in ordering * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --A3.__7773E78F29A3_.D Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Subjects: physicians, specialists, doctors, licensed doctors, board physicians, emergency physicians, 2004 physicians guide, 2004 physicians directory, physicians contact. EXCLUSIVELY ON CD-ROM. The 2004 edition of The American Medical Directory & Physicians Guide has= just been completed. According to many librarians, it is one of the most referenced and freque= ntly-used publication in libraries throughout the United States. It is also used by most healthcare professionals and industry business dev= elopment executives. The American Medical Directory & Physicians Guide contains relevant data o= n over 500,000 physicians in the United States. Each record is indexed by such features as name, address, phone/fax, count= y, year licensed, type of practice, type of physician, as well as primary and secondary specialty. During this introductory offer, the cost of the new directory (which is av= ailable exclusively on CD-Rom) is $375.00 (reg. $795). The CD-Rom is in Excel format and is searchable, downloadable, and can be = used on an unlimited basis. To order the American Medical Directory & Physicians Guide, please print t= his e-mail, complete the information below and fax it to 905-751-0199. (tel: 905-751-0= 919). BONUS OFFER: ORDER NOW AND RECEIVE THE AMERICAN NURSING HOME DIRECTORY ON CD-ROM FREE OF CHARGE. NAME: TITLE: ORGANIZATION: ADDRESS: CITY: POSTAL: TEL: FAX: E-MAIL: InfoSource Group of Companies is a leading information publishing firm wit= h offices throughout North America and Europe. ifvfb uv ey mohxedd --A3.__7773E78F29A3_.D-- From tk496ibs@nwz.uni-muenster.de Mon Mar 22 19:44:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07005 for ; Mon, 22 Mar 2004 19:44:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5a2I-0000fT-00 for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 19:44:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5a1W-0000Zl-00 for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 19:44:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5a0f-0000T3-00 for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 19:43:14 -0500 Received: from pcp04976887pcs.hlsdle01.mi.comcast.net ([68.40.53.181]) by mx2.foretec.com with smtp (Exim 4.24) id 1B5a0g-0007VZ-2G for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 19:43:14 -0500 Received: from [45.221.155.69] by pcp04976887pcs.hlsdle01.mi.comcast.net SMTP id D4cr0gsg59zKB2 for ; Tue, 23 Mar 2004 04:36:13 +0400 Message-ID: <7$$wns9-64u562w9-o$$-sg$o81@w93.e.7h> From: "Elisabeth Bateman" Reply-To: "Elisabeth Bateman" To: sctp-impl-archive@ietf.org Subject: Earn profits selling other people's services Date: Tue, 23 Mar 04 04:36:13 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E0CB10424." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=15.2 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, RATWARE_EGROUPS autolearn=no version=2.60 X-Spam-Report: * 4.3 RATWARE_EGROUPS Bulk email fingerprint (eGroups) found * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --E0CB10424. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable f

     

    Cash in with Google makes earning an affiliate income very simple. With s= tep by step instructions and screenshots to follow you'll have all the tools= you need.

    no more emails please

    htqk wevtt pzmsnecxl --E0CB10424.-- From zop88dzjle@naverex.kiev.ua Mon Mar 22 19:52:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07206 for ; Mon, 22 Mar 2004 19:52:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5a9v-0001XW-00 for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 19:52:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5a91-0001Px-00 for sctp-impl-archive@ietf.org; Mon, 22 Mar 2004 19:51:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5a85-0001JA-00; Mon, 22 Mar 2004 19:50:53 -0500 Received: from [218.22.208.12] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B5a7q-0008FG-R5; Mon, 22 Mar 2004 19:50:41 -0500 Received: from [33.242.120.66] by 65.246.255.50 for ; Tue, 23 Mar 2004 04:46:45 +0400 Message-ID: From: "Kelly Walls" Reply-To: "Kelly Walls" To: , Subject: Aggressive investor alert makes it simple to outperform the Dow cghedie nqh Date: Tue, 23 Mar 04 04:46:45 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="EC1_63_.5..EE8207F." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.6 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_RCVD_NET_HELO, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,STOCK_PICK autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 STOCK_PICK BODY: Offers a picked stock * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --EC1_63_.5..EE8207F. Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Market Watch Special Alert achieved record results for our Investment Alert for the First Quarter of 2004. Our subscribers have pocketed huge gains by revealing unknown and undervalued gems thrust into the spotlight. Results for our First Quarter Investor Alert issued in December 2003: Company Recommended: Torvec, Inc. (TOVC) Price when recommended: 1.45 Highest price reached: 8.99 (+520%) Second Quarter Investment Alert: Deer Park Technology, Inc. (DRPT) Price: .39 Assets: over 18 Million (2.09 per share) Est. 2004 EPS: .15 Growth 300%+ Shares Out: 8.6 million Float: 1.7 million Average PE: Industry 23-25 Put DRPT on your radar for the purpose of immediate investment. Merger completed with 10-year old "entertainment empire". Name change imminent to reflect a treasure-trove of entertainment media properties. Stock Performance Guide: DRPT 7 day trading target: 1.20 30 day trading target: 2.50 12-Month Est. Average PE X 2004 EPS =3D 3.75 One glance inside DRPT's programming vault will make you realize that there is basically none of the Company's intrinsic value reflected in the price of the stock. This is a direct result of a stock that is completely unknown to investors. Watch how quickly prices roar when word spreads, investors grab their calculators, and the realization is clear that this stock is trading for just pennies on every dollar of tangible assets. The value of the Company's core assets will force its way into the stock price, with this explosive entity stepping into the spotlight and evolving DRPT into Media Classics International, Inc. Although a new name to investors, Media Classics is a major video stock footage company with worldwide distribution that has amassed a 3,000 film product line since 1994. An overview of Media Classics' holdings reveals a tremendous diversity of entertainment media, started from scratch about ten years ago that has subsequently morphed into an almost $20 Million asset empire with top award winning producers and directors at the helm. The Company's entertainment assets are comprised of over 2,400 hours of stock film footage, documentary and educational films, over $8 Million of animated art and programming, distribution rights for 110 full-length feature films categorized as top box office draws starring Oscar winners and a who's-who of Hollywood actors, as well as sports programming, and music rights. This complete library is distributed worldwide in VHS, DVD, on cable television and via the Internet, and is a continuing source of rapidly growing revenues. Several recent news announcements are well-timed with the upcoming corporate name change and will add significant value to a growing bottom line. These releases include: 1. The licensing of 36 films for distribution as DVD's and home video through a group of entertainment companies. 2. The completion of ten (10) documentaries to be released within 60 days produced as a joint venture with well- known Terramar Productions. 3. A contract to provide entertainment products to the US Navy for use on board ship and at Navy bases around the globe. Here are some figures that put into perspective the enormous potential revenues that are available to industry players with diverse entertainment properties. The movie industry generates $150 Billion while the entire music industry yields $30 Billion worldwide. Video rentals in the US totaled $7 Billion, video sales reached $10 Billion, and DVD sales totaled $4 Billion for a total of $21 Billion in post-theatrical gross profits. With 50% of the wholesale price of a DVD or VHS going to the producer or studio, it is clear to aggressive investors why DRPT (Media Classics) has become our #1 stock pick for 2004. Market Watch Special Alert is delivered online on a quarterly basis. All information is derived from publicly available sources. Performance forecasts made on behalf of Market Watch Special Alert are strictly projections based upon news aggregation. Market Watch Special Alert is an independent equities publication that prepares featured stock profiles on independently selected companies. While our intent is to identify companies that may provide substantial investment profits, Market Watch Special Alert is not liable for any investment decision by its readers. Market Watch Special Alert has been retained for a fee of sixteen thousand dollars and will not hold, purchase, or otherwise participate in the trading of any featured company. Any stock profile published by Market Watch Special Alert does not represent a solicitation to buy or sell the securities discussed within the profile. It is advised that any purchase or sale decisions be discussed with a financial advisor or broker. Past performance does not insure future success of any featured company. Market watch Special Alert cautions that substantial risks are present when investing in low-priced securities. atccpkajkqpoftsdoecj m oa hys lwa xjbtqfhu ovl bswsshsnkk --EC1_63_.5..EE8207F.-- From ma-kun@kozuka.jp Wed Mar 24 00:07:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26085 for ; Wed, 24 Mar 2004 00:07:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B60cK-0001Q1-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 00:07:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B60bk-0001Kl-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 00:07:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B60aj-0001B7-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 00:06:13 -0500 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 i2O54xew019846; Tue, 23 Mar 2004 21:04:59 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2O54JZ4010579 for sctp-impl-filtered; Tue, 23 Mar 2004 21:04:21 -0800 (PST) Message-Id: <200403240504.i2O54JZ4010579@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080104659-10577-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: Quetion about sctp_get[lp]addrs(). List-Id: sctp-impl To: sctp-impl@external.cisco.com From: KOZUKA Masahiro X-Nails-Approved: ma-kun@kozuka.jp Date: Sun, 21 Mar 2004 02:48:57 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080104659-10577-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Hi, sctp-impl. I have a question about sctp_get[lp]addrs(). These functions have the following arguments. (int sock, sctp_assoc_t id, struct sockaddr **raddrs); I think that on this specification we can't use raddrs for getnameinfo(), or it is hard. Because to use getnameinfo() we must set salen for sockaddr's length, but sctp_get[lp]addrs() doesn't give us the information.... This problem doesn't appear on BSD system, it has sa_len on sockaddr. But this programing style isn't recommended. On Linux system there is no sa_le, so it doesn't work on Linux system. We should add sockaddr's length to sctp_get[lp]addrs()? P.S. I noticed that SCTP Socket API Internet-Draft expireed. What happened?:) -- {^-^}/@kozuka.jp / KOZUKA Masahiro ------------=_1080104659-10577-0-- From rxaia62btu@nmb.ru Wed Mar 24 00:08:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26128 for ; Wed, 24 Mar 2004 00:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B60d8-0001U6-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 00:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B60c9-0001O5-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 00:07:42 -0500 Received: from c-67-169-238-206.client.comcast.net ([67.169.238.206]) by ietf-mx with smtp (Exim 4.12) id 1B60bG-0001Hg-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 00:06:46 -0500 Received: from (HELO l040c86) [250.116.66.161] by c-67-169-238-206.client.comcast.net id <4386087-06665>; Wed, 24 Mar 2004 04:03:45 -0100 Message-ID: <5-g3egc$6b94-hvf506m@j63o.7u0> From: "Nelda Wooten" Reply-To: "Nelda Wooten" To: sctp-impl-archive@ietf.org Subject: My book will show you how to make profits with google.com Date: Wed, 24 Mar 04 04:03:45 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="AEBB.75764F5E03." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.6 required=5.0 tests=BIZ_TLD,DATE_SPAMWARE_Y2K, FORGED_AOL_HTML,FORGED_MUA_AOL_FROM,HTML_30_40,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --AEBB.75764F5E03. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable mystify

     

    In my book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

    I don't want any more emails

    nqxvwqjajm j eutmbgt rghoax fveo jmvfj guw hqwmgudfqtz uttlhzhpwxkj --AEBB.75764F5E03.-- From rrs@cisco.com Wed Mar 24 07:03:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17123 for ; Wed, 24 Mar 2004 07:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B676W-0003Gh-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 07:03:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B675R-00030R-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 07:02:22 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B674Z-0002WS-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 07:01:27 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2004 04:06:00 +0000 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 i2OC0TUe003523; Wed, 24 Mar 2004 04:00:29 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2OBxqZ4016176 for sctp-impl-filtered; Wed, 24 Mar 2004 03:59:54 -0800 (PST) Message-Id: <200403241159.i2OBxqZ4016176@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080129592-16174-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: Quetion about sctp_get[lp]addrs(). List-Id: sctp-impl To: KOZUKA Masahiro From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Wed, 24 Mar 2004 05:59:46 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080129592-16174-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary KOZUKA Masahiro wrote: >Hi, sctp-impl. >I have a question about sctp_get[lp]addrs(). >These functions have the following arguments. > (int sock, sctp_assoc_t id, struct sockaddr **raddrs); > >I think that on this specification we can't use raddrs for getnameinfo(), or >it is hard. >Because to use getnameinfo() we must set salen for sockaddr's length, but >sctp_get[lp]addrs() doesn't give us the information.... > >This problem doesn't appear on BSD system, it has sa_len on sockaddr. >But this programing style isn't recommended. On Linux system >there is no sa_le, so it doesn't work on Linux system. >We should add sockaddr's length to sctp_get[lp]addrs()? > >P.S. > I noticed that SCTP Socket API Internet-Draft expireed. > What happened?:) > > Masahiro-san Yes, it is true that only BSD has the sa_len. But a couple of things: 1) If you have an AF_INET6 socket and you specify the default behavior (according to the socket draft), all addresses will be mapped to V6. 2) If you have an AF_INET socket and you do this... all you get is V4 addresses. 3) If you do turn off the mapped addresses (yes I know kame does this by default) you will get a mix of AF_INET and AF_INET6 addresses (yes Kacheong I know you hate this :-0). But even if you did this in linux land or wanted portable code .. one could do struct sockaddr *sa; int not_done=0; not_done = sctp_get[lp]addrs(&sa); while(not_done) if(sa->sa_family == AF_INET) len = sizeof(struct sockaddr_in) else if(sa->sa_family == AF_INET6) len = sizeof(struct sockaddr_in6_ else break; print-address(sa); sa = ((caddr_t)sa + len); not_done--; } This will work no matter which O/S you have. R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1080129592-16174-0-- From rrwzh05jlt@dragonet.es Wed Mar 24 18:31:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29486 for ; Wed, 24 Mar 2004 18:31:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6HqG-0003ZA-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 18:31:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6HpH-0003Qk-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 18:30:24 -0500 Received: from lsanca1-ar41-4-61-153-020.lsanca1.dsl-verizon.net ([4.61.153.20]) by ietf-mx with smtp (Exim 4.12) id 1B6Ho1-0003Jh-00; Wed, 24 Mar 2004 18:29:37 -0500 Received: from [165.58.122.139] by lsanca1-ar41-4-61-153-020.lsanca1.dsl-verizon.net SMTP id A55pmwCv86ozq5; Thu, 25 Mar 2004 03:18:34 +0400 Message-ID: From: "Berta Andrews" Reply-To: "Berta Andrews" To: , Subject: A healthy balance sheet adds value to the stock price fqptc dd x Date: Thu, 25 Mar 04 03:18:34 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6B_AB_D.D2AC_FFC8D_3" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.2 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,MISSING_MIMEOLE,STOCK_PICK autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 STOCK_PICK BODY: Offers a picked stock * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --6B_AB_D.D2AC_FFC8D_3 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Market Watch Special Alert achieved record results for our Investment Alert for the First Quarter of 2004. Our subscribers have pocketed huge gains by revealing unknown and undervalued gems thrust into the spotlight. Results for our First Quarter Investor Alert issued in December 2003: Company Recommended: Torvec, Inc. (TOVC) Price when recommended: 1.45 Highest price reached: 8.99 (+520%) Second Quarter Investment Alert: Deer Park Technology, Inc. (DRPT) Price: .41 Assets: over 18 Million (2.09 per share) Est. 2004 EPS: .15 Growth 300%+ Shares Out: 8.6 million Float: 1.7 million Average PE: Industry 23-25 Put DRPT on your radar for the purpose of immediate investment. Merger completed with 10-year old "entertainment empire". Name change imminent to reflect a treasure-trove of entertainment media properties. Stock Performance Guide: DRPT 7 day trading target: 1.20 30 day trading target: 2.50 12-Month Est. Average PE X 2004 EPS =3D 3.75 One glance inside DRPT's programming vault will make you realize that there is basically none of the Company's intrinsic value reflected in the price of the stock. This is a direct result of a stock that is completely unknown to investors. Watch how quickly prices roar when word spreads, investors grab their calculators, and the realization is clear that this stock is trading for just pennies on every dollar of tangible assets. The value of the Company's core assets will force its way into the stock price, with this explosive entity stepping into the spotlight and evolving DRPT into Media Classics International, Inc. Although a new name to investors, Media Classics is a major video stock footage company with worldwide distribution that has amassed a 3,000 film product line since 1994. An overview of Media Classics' holdings reveals a tremendous diversity of entertainment media, started from scratch about ten years ago that has subsequently morphed into an almost $20 Million asset empire with top award winning producers and directors at the helm. The Company's entertainment assets are comprised of over 2,400 hours of stock film footage, documentary and educational films, over $8 Million of animated art and programming, distribution rights for 110 full-length feature films categorized as top box office draws starring Oscar winners and a who's-who of Hollywood actors, as well as sports programming, and music rights. This complete library is distributed worldwide in VHS, DVD, on cable television and via the Internet, and is a continuing source of rapidly growing revenues. Several recent news announcements are well-timed with the upcoming corporate name change and will add significant value to a growing bottom line. These releases include: 1. The licensing of 36 films for distribution as DVD's and home video through a group of entertainment companies. 2. The completion of ten (10) documentaries to be released within 60 days produced as a joint venture with well- known Terramar Productions. 3. A contract to provide entertainment products to the US Navy for use on board ship and at Navy bases around the globe. Here are some figures that put into perspective the enormous potential revenues that are available to industry players with diverse entertainment properties. The movie industry generates $150 Billion while the entire music industry yields $30 Billion worldwide. Video rentals in the US totaled $7 Billion, video sales reached $10 Billion, and DVD sales totaled $4 Billion for a total of $21 Billion in post-theatrical gross profits. With 50% of the wholesale price of a DVD or VHS going to the producer or studio, it is clear to aggressive investors why DRPT (Media Classics) has become our #1 stock pick for 2004. Market Watch Special Alert is delivered online on a quarterly basis. All information is derived from publicly available sources. Performance forecasts made on behalf of Market Watch Special Alert are strictly projections based upon news aggregation. Market Watch Special Alert is an independent equities publication that prepares featured stock profiles on independently selected companies. While our intent is to identify companies that may provide substantial investment profits, Market Watch Special Alert is not liable for any investment decision by its readers. Market Watch Special Alert has been retained for a fee of sixteen thousand dollars and will not hold, purchase, or otherwise participate in the trading of any featured company. Any stock profile published by Market Watch Special Alert does not represent a solicitation to buy or sell the securities discussed within the profile. It is advised that any purchase or sale decisions be discussed with a financial advisor or broker. Past performance does not insure future success of any featured company. Market watch Special Alert cautions that substantial risks are present when investing in low-priced securities. qkvysirmuwwndff --6B_AB_D.D2AC_FFC8D_3-- From dge55rw@pmfhk.cz Wed Mar 24 18:33:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29688 for ; Wed, 24 Mar 2004 18:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6HsH-0003ti-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 18:33:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6HrB-0003hp-00 for sctp-impl-archive@ietf.org; Wed, 24 Mar 2004 18:32:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Hpp-0003WO-00; Wed, 24 Mar 2004 18:30:57 -0500 Received: from chello080108138092.7.12.vie.surfer.at ([80.108.138.92]) by mx2.foretec.com with smtp (Exim 4.24) id 1B6HpQ-0002tC-1h; Wed, 24 Mar 2004 18:30:41 -0500 Received: from (HELO h4x) [128.22.116.166] by chello080108138092.7.12.vie.surfer.at with ESMTP id EE6EFCB670D; Thu, 25 Mar 2004 05:19:59 +0600 Message-ID: <5i$b6og$07$$73529@4n92u7> From: "Erin Snell" Reply-To: "Erin Snell" To: , Subject: Stock set to jump up on financial data gxajfbfsq cq Date: Thu, 25 Mar 04 05:19:59 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6B_AB_D.D2AC_FFC8D_3" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=17.2 required=5.0 tests=DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_THEBAT,FORGED_MUA_THEBAT_BOUN, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,STOCK_PICK autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 STOCK_PICK BODY: Offers a picked stock * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_THEBAT_BOUN Mail pretending to be from The Bat! (boundary) * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --6B_AB_D.D2AC_FFC8D_3 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Market Watch Special Alert achieved record results for our Investment Alert for the First Quarter of 2004. Our subscribers have pocketed huge gains by revealing unknown and undervalued gems thrust into the spotlight. Results for our First Quarter Investor Alert issued in December 2003: Company Recommended: Torvec, Inc. (TOVC) Price when recommended: 1.45 Highest price reached: 8.99 (+520%) Second Quarter Investment Alert: Deer Park Technology, Inc. (DRPT) Price: .41 Assets: over 18 Million (2.09 per share) Est. 2004 EPS: .15 Growth 300%+ Shares Out: 8.6 million Float: 1.7 million Average PE: Industry 23-25 Put DRPT on your radar for the purpose of immediate investment. Merger completed with 10-year old "entertainment empire". Name change imminent to reflect a treasure-trove of entertainment media properties. Stock Performance Guide: DRPT 7 day trading target: 1.20 30 day trading target: 2.50 12-Month Est. Average PE X 2004 EPS =3D 3.75 One glance inside DRPT's programming vault will make you realize that there is basically none of the Company's intrinsic value reflected in the price of the stock. This is a direct result of a stock that is completely unknown to investors. Watch how quickly prices roar when word spreads, investors grab their calculators, and the realization is clear that this stock is trading for just pennies on every dollar of tangible assets. The value of the Company's core assets will force its way into the stock price, with this explosive entity stepping into the spotlight and evolving DRPT into Media Classics International, Inc. Although a new name to investors, Media Classics is a major video stock footage company with worldwide distribution that has amassed a 3,000 film product line since 1994. An overview of Media Classics' holdings reveals a tremendous diversity of entertainment media, started from scratch about ten years ago that has subsequently morphed into an almost $20 Million asset empire with top award winning producers and directors at the helm. The Company's entertainment assets are comprised of over 2,400 hours of stock film footage, documentary and educational films, over $8 Million of animated art and programming, distribution rights for 110 full-length feature films categorized as top box office draws starring Oscar winners and a who's-who of Hollywood actors, as well as sports programming, and music rights. This complete library is distributed worldwide in VHS, DVD, on cable television and via the Internet, and is a continuing source of rapidly growing revenues. Several recent news announcements are well-timed with the upcoming corporate name change and will add significant value to a growing bottom line. These releases include: 1. The licensing of 36 films for distribution as DVD's and home video through a group of entertainment companies. 2. The completion of ten (10) documentaries to be released within 60 days produced as a joint venture with well- known Terramar Productions. 3. A contract to provide entertainment products to the US Navy for use on board ship and at Navy bases around the globe. Here are some figures that put into perspective the enormous potential revenues that are available to industry players with diverse entertainment properties. The movie industry generates $150 Billion while the entire music industry yields $30 Billion worldwide. Video rentals in the US totaled $7 Billion, video sales reached $10 Billion, and DVD sales totaled $4 Billion for a total of $21 Billion in post-theatrical gross profits. With 50% of the wholesale price of a DVD or VHS going to the producer or studio, it is clear to aggressive investors why DRPT (Media Classics) has become our #1 stock pick for 2004. Market Watch Special Alert is delivered online on a quarterly basis. All information is derived from publicly available sources. Performance forecasts made on behalf of Market Watch Special Alert are strictly projections based upon news aggregation. Market Watch Special Alert is an independent equities publication that prepares featured stock profiles on independently selected companies. While our intent is to identify companies that may provide substantial investment profits, Market Watch Special Alert is not liable for any investment decision by its readers. Market Watch Special Alert has been retained for a fee of sixteen thousand dollars and will not hold, purchase, or otherwise participate in the trading of any featured company. Any stock profile published by Market Watch Special Alert does not represent a solicitation to buy or sell the securities discussed within the profile. It is advised that any purchase or sale decisions be discussed with a financial advisor or broker. Past performance does not insure future success of any featured company. Market watch Special Alert cautions that substantial risks are present when investing in low-priced securities. zdftprna t zx d ofd gf dycise e jfri ohz dwbay mc snhlqa jxsfkpgj w v --6B_AB_D.D2AC_FFC8D_3-- From jfjdigqpus@power.ufscar.br Thu Mar 25 00:29:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14771 for ; Thu, 25 Mar 2004 00:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6NRA-0000SS-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 00:29:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6NQB-0000LZ-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 00:28:51 -0500 Received: from ca-esanf-vn17-a-31.vnnyca.adelphia.net ([68.69.247.31]) by ietf-mx with smtp (Exim 4.12) id 1B6NPF-0000Bn-00; Thu, 25 Mar 2004 00:27:57 -0500 Received: from [249.29.170.213] by ca-esanf-vn17-a-31.vnnyca.adelphia.net SMTP id wfOO4WJ62xhsQv for ; Thu, 25 Mar 2004 07:20:14 +0200 Message-ID: From: "Melanie Graves" Reply-To: "Melanie Graves" To: , , , , , Subject: Our winning picks create extremely high satisfaction levels lyd ybax wuzk Date: Thu, 25 Mar 04 07:20:14 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".58.CD94_A.08B.A" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.0 required=5.0 tests=DATE_SPAMWARE_Y2K, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,RATWARE_EGROUPS autolearn=no version=2.60 X-Spam-Report: * 4.3 RATWARE_EGROUPS Bulk email fingerprint (eGroups) found * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --.58.CD94_A.08B.A Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable **SRGE****SRGE****SRGE****SRGE****SRGE****SRGE** Market Watch News Flash Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted as many significant news releases indicate strong contractual revenues with major Telecom firms. SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. Opening Price: 1.00 10 Day Target: 2.30 1 Month Target: 4.50 Outstanding Shares: 16.5 million Est. Float: 2.2 million How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. -------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon 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", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. ffzejodmttn pba pnbyomj zptbuu wiybm ymzurswhtd dvwzrtnl fx j mp u qyvge --.58.CD94_A.08B.A-- From 270pilm@ksc.net.th Thu Mar 25 01:23:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18283 for ; Thu, 25 Mar 2004 01:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OHM-0006Eb-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 01:23:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OGW-00069B-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 01:22:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6OFW-000634-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 01:21:54 -0500 Received: from adsl-68-79-188-250.dsl.klmzmi.ameritech.net ([68.79.188.250]) by mx2.foretec.com with smtp (Exim 4.24) id 1B6OFW-0005vc-0O for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 01:21:56 -0500 Received: from [63.92.118.3] by adsl-68-79-188-250.dsl.klmzmi.ameritech.net with ESMTP id F45F2C18CCB for ; Thu, 25 Mar 2004 01:17:06 -0500 Message-ID: From: "Genevieve Ingram" <270pilm@ksc.net.th> Reply-To: "Genevieve Ingram" <270pilm@ksc.net.th> To: Subject: In my book I'll show you how to use Google and Affiliate programs to make profits hinaoar Date: Thu, 25 Mar 04 01:17:06 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="DBEDE_8._F.AD_5" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.2 required=5.0 tests=BIZ_TLD,DATE_IN_PAST_03_06, DATE_SPAMWARE_Y2K,FORGED_IMS_HTML,FORGED_MUA_IMS,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_MUA_IMS Forged mail pretending to be from IMS * 4.3 FORGED_IMS_HTML IMS can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --DBEDE_8._F.AD_5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable vjp htesands mwy izuk jmak pml h

     

    In my book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

    I don't want any more emails

    bhtzkn --DBEDE_8._F.AD_5-- From ma-kun@kozuka.jp Thu Mar 25 01:44:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19326 for ; Thu, 25 Mar 2004 01:44:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Obb-0000K9-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 01:44:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Oaj-0000GK-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 01:43:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B6OZq-00007d-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 01:42:55 -0500 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 i2P6fpGX010293; Wed, 24 Mar 2004 22:41:51 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2P6fKZ4000686 for sctp-impl-filtered; Wed, 24 Mar 2004 22:41:22 -0800 (PST) Message-Id: <200403250641.i2P6fKZ4000686@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080196880-684-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: Question about sctp_get[lp]addrs(). List-Id: sctp-impl To: "Randall Stewart (cisco)" From: KOZUKA Masahiro Cc: sctp-impl@external.cisco.com X-Nails-Approved: ma-kun@kozuka.jp Date: Thu, 25 Mar 2004 15:39:37 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080196880-684-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Randall-san, On Wed, Mar 24, 2004 at 05:59:46AM -0600, Randall Stewart (cisco) wrote: > Yes, it is true that only BSD has the sa_len. But a couple of things: > > 1) If you have an AF_INET6 socket and you specify the default > behavior (according to the socket draft), all addresses will > be mapped to V6. > > 2) If you have an AF_INET socket and you do this... all you get > is V4 addresses. > > 3) If you do turn off the mapped addresses (yes I know kame does > this by default) you will get a mix of AF_INET and AF_INET6 > addresses (yes > Kacheong I know you hate this :-0). But even if you did this in > linux land or > wanted portable code .. one could do > struct sockaddr *sa; > int not_done=0; > not_done = sctp_get[lp]addrs(&sa); > while(not_done) > if(sa->sa_family == AF_INET) > len = sizeof(struct sockaddr_in) > else if(sa->sa_family == AF_INET6) > len = sizeof(struct sockaddr_in6_ > else > break; > print-address(sa); > sa = ((caddr_t)sa + len); > not_done--; > } > > This will work no matter which O/S you have. Yes, I think that this style is a way which we can take. But the problem will occur when a new protocol family(ex. IPv7) is created. In the time we have to modify this code.... If sctp_get[lp]addrs return sockaddrs's length, we wlll not have to modify it using getnameinfo() which we improve separately for IPv7. In a dynamic linking binary, we can change getnameinfo() easily. This style is Protocol Independent Programing. http://www.mew.org/~kazu/doc/piprog.html I think that the standard specification should be created to enable this style. The current functions, getsockname(), getpeername(), return sockaddr's length to enable it. (I can't check wheter theses were created to enable it or not:) So, sctp_get[lp]addrs() should return sockaddr's length, I think. Regards, Masahiro. -- {^-^}/@kozuka.jp / KOZUKA Masahiro ------------=_1080196880-684-0-- From 8yhmgccqq@theo3.physik.uni-stuttgart.de Thu Mar 25 08:14:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19157 for ; Thu, 25 Mar 2004 08:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ugl-00007M-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 08:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Uff-0007j5-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 08:13:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Uem-0007am-01; Thu, 25 Mar 2004 08:12:24 -0500 Received: from [212.155.169.122] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B6UR6-0004GV-W8; Thu, 25 Mar 2004 07:58:17 -0500 Received: from (HELO ze5q) [232.78.164.12] by 65.246.255.50 with ESMTP id <517351-14857> for ; Thu, 25 Mar 2004 15:53:46 +0300 Message-ID: <6-$qa$-y$21n26hqcdvqi@eer7vd0qj.7x8> From: "Jessie Bryan" <8yhmgccqq@theo3.physik.uni-stuttgart.de> Reply-To: "Jessie Bryan" <8yhmgccqq@theo3.physik.uni-stuttgart.de> To: , Subject: This rising share price is clearly making progress jiw tuedfy Date: Thu, 25 Mar 04 15:53:46 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_7B9.A0D__A_1_8D" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.7 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_RCVD_NET_HELO,MISSING_MIMEOLE, RCVD_NUMERIC_HELO,STOCK_PICK autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 STOCK_PICK BODY: Offers a picked stock * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --_7B9.A0D__A_1_8D Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Market Watch Special Alert achieved record results for our Investment Alert for the First Quarter of 2004. Our subscribers have pocketed huge gains by revealing unknown and undervalued gems thrust into the spotlight. Results for our First Quarter Investor Alert issued in December 2003: Company Recommended: Torvec, Inc. (TOVC) Price when recommended: 1.45 Highest price reached: 8.99 (+520%) Second Quarter Investment Alert: Deer Park Technology, Inc. (DRPT) Price: .41 Assets: over 18 Million (2.09 per share) Est. 2004 EPS: .15 Growth 300%+ Shares Out: 8.6 million Float: 1.7 million Average PE: Industry 23-25 Put DRPT on your radar for the purpose of immediate investment. Merger completed with 10-year old "entertainment empire". Name change imminent to reflect a treasure-trove of entertainment media properties. Stock Performance Guide: DRPT 7 day trading target: 1.20 30 day trading target: 2.50 12-Month Est. Average PE X 2004 EPS =3D 3.75 One glance inside DRPT's programming vault will make you realize that there is basically none of the Company's intrinsic value reflected in the price of the stock. This is a direct result of a stock that is completely unknown to investors. Watch how quickly prices roar when word spreads, investors grab their calculators, and the realization is clear that this stock is trading for just pennies on every dollar of tangible assets. The value of the Company's core assets will force its way into the stock price, with this explosive entity stepping into the spotlight and evolving DRPT into Media Classics International, Inc. Although a new name to investors, Media Classics is a major video stock footage company with worldwide distribution that has amassed a 3,000 film product line since 1994. An overview of Media Classics' holdings reveals a tremendous diversity of entertainment media, started from scratch about ten years ago that has subsequently morphed into an almost $20 Million asset empire with top award winning producers and directors at the helm. The Company's entertainment assets are comprised of over 2,400 hours of stock film footage, documentary and educational films, over $8 Million of animated art and programming, distribution rights for 110 full-length feature films categorized as top box office draws starring Oscar winners and a who's-who of Hollywood actors, as well as sports programming, and music rights. This complete library is distributed worldwide in VHS, DVD, on cable television and via the Internet, and is a continuing source of rapidly growing revenues. Several recent news announcements are well-timed with the upcoming corporate name change and will add significant value to a growing bottom line. These releases include: 1. The licensing of 36 films for distribution as DVD's and home video through a group of entertainment companies. 2. The completion of ten (10) documentaries to be released within 60 days produced as a joint venture with well- known Terramar Productions. 3. A contract to provide entertainment products to the US Navy for use on board ship and at Navy bases around the globe. Here are some figures that put into perspective the enormous potential revenues that are available to industry players with diverse entertainment properties. The movie industry generates $150 Billion while the entire music industry yields $30 Billion worldwide. Video rentals in the US totaled $7 Billion, video sales reached $10 Billion, and DVD sales totaled $4 Billion for a total of $21 Billion in post-theatrical gross profits. With 50% of the wholesale price of a DVD or VHS going to the producer or studio, it is clear to aggressive investors why DRPT (Media Classics) has become our #1 stock pick for 2004. Market Watch Special Alert is delivered online on a quarterly basis. All information is derived from publicly available sources. Performance forecasts made on behalf of Market Watch Special Alert are strictly projections based upon news aggregation. Market Watch Special Alert is an independent equities publication that prepares featured stock profiles on independently selected companies. While our intent is to identify companies that may provide substantial investment profits, Market Watch Special Alert is not liable for any investment decision by its readers. Market Watch Special Alert has been retained for a fee of sixteen thousand dollars and will not hold, purchase, or otherwise participate in the trading of any featured company. Any stock profile published by Market Watch Special Alert does not represent a solicitation to buy or sell the securities discussed within the profile. It is advised that any purchase or sale decisions be discussed with a financial advisor or broker. Past performance does not insure future success of any featured company. Market watch Special Alert cautions that substantial risks are present when investing in low-priced securities. hz womgegn l ivj lh br o m dc nvvgtaioqh is pnw tjwdyeh g fjzeam --_7B9.A0D__A_1_8D-- From vladislav.yasevich@hp.com Thu Mar 25 09:50:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25699 for ; Thu, 25 Mar 2004 09:50:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WBR-0003Mw-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 09:50:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WAW-0003JY-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 09:49:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6WA5-0003FE-00 for sctp-impl-archive@ietf.org; Thu, 25 Mar 2004 09:48:50 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2004 06:54:44 +0000 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 i2PElnGX006697; Thu, 25 Mar 2004 06:47:50 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2PElNZ4007207 for sctp-impl-filtered; Thu, 25 Mar 2004 06:47:25 -0800 (PST) Message-Id: <200403251447.i2PElNZ4007207@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080226042-7205-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: Quetion about sctp_get[lp]addrs(). List-Id: sctp-impl To: KOZUKA Masahiro From: Vladislav Yasevich Cc: sctp-impl@external.cisco.com X-Nails-Approved: vladislav.yasevich@hp.com Date: Thu, 25 Mar 2004 09:42:25 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080226042-7205-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Masahiro Changing the sctp API is only a small part of the problem that you are facing. The same type of problem exists with TCP and UDP sockets. It is simply because Linux doesn't implement BSD 4.4 style sockaddr structures that introduced sa_len field. The linux kernel doesn't know how to handle sockaddrs that have a length specified in them at the API level. That would have to be fixed before the sctp API can be updated. Otherwise, the SCTP API library on linux would face the same problem you are facing in your code. It would have to change to support future addressing extensions (which hopefully the will not be any :). -vlad KOZUKA Masahiro wrote: > Hi, sctp-impl. > I have a question about sctp_get[lp]addrs(). > These functions have the following arguments. > (int sock, sctp_assoc_t id, struct sockaddr **raddrs); > > I think that on this specification we can't use raddrs for getnameinfo(), or > it is hard. > Because to use getnameinfo() we must set salen for sockaddr's length, but > sctp_get[lp]addrs() doesn't give us the information.... > > This problem doesn't appear on BSD system, it has sa_len on sockaddr. > But this programing style isn't recommended. On Linux system > there is no sa_le, so it doesn't work on Linux system. > We should add sockaddr's length to sctp_get[lp]addrs()? > > P.S. > I noticed that SCTP Socket API Internet-Draft expireed. > What happened?:) -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 ------------=_1080226042-7205-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAYu/RXGxwQQIna74RAqDVAJ9C+1+AC9OPbIYKWGcARP+6vTVpnwCgir5q jLWMyMEJtZAazN7ZSyWt9Mg= =OaWt -----END PGP SIGNATURE----- ------------=_1080226042-7205-0-- From spyb951@ms13.url.com.tw Fri Mar 26 01:57:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19830 for ; Fri, 26 Mar 2004 01:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6lHq-0004uf-00 for sctp-impl-archive@ietf.org; Fri, 26 Mar 2004 01:57:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6lGx-0004qh-00 for sctp-impl-archive@ietf.org; Fri, 26 Mar 2004 01:56:56 -0500 Received: from h000802d1742a.ne.client2.attbi.com ([24.147.135.43]) by ietf-mx with smtp (Exim 4.12) id 1B6lG2-0004jH-00; Fri, 26 Mar 2004 01:56:00 -0500 Received: from [66.102.22.235] by h000802d1742a.ne.client2.attbi.com id iJSgxlNMIqt7; Fri, 26 Mar 2004 09:51:00 +0300 Message-ID: From: "Aimee Nicholas" Reply-To: "Aimee Nicholas" To: , Subject: The spotlight shines on the dynamics of this earnings play zjfv z eqbl Date: Fri, 26 Mar 04 09:51:00 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4736C_CAEE3" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.0 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FROM_ENDS_IN_NUMS,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --4736C_CAEE3 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable **SRGE****SRGE****SRGE****SRGE****SRGE****SRGE** Market Watch News Flash Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted as many significant news releases indicate strong contractual revenues with major Telecom firms. SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. Opening Price: 1.15 10 Day Target: 2.30 1 Month Target: 4.50 Outstanding Shares: 16.5 million Est. Float: 2.2 million How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. -------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon 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", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. giv osrq h bxp gd y bpx azf g mp b fx ul i gibcyagqtltlkwn unhnrumdus kt vhd --4736C_CAEE3-- From kacheong.poon@sun.com Fri Mar 26 17:49:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22379 for ; Fri, 26 Mar 2004 17:49:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B708d-0001nN-00 for sctp-impl-archive@ietf.org; Fri, 26 Mar 2004 17:49:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B707f-0001jy-00 for sctp-impl-archive@ietf.org; Fri, 26 Mar 2004 17:48:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B7074-0001eI-00 for sctp-impl-archive@ietf.org; Fri, 26 Mar 2004 17:47:42 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2004 14:47:19 -0800 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 i2QMkdBB009442; Fri, 26 Mar 2004 14:46:40 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2QMk2Z4002348 for sctp-impl-filtered; Fri, 26 Mar 2004 14:46:04 -0800 (PST) Message-Id: <200403262246.i2QMk2Z4002348@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080341162-2346-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: Question about sctp_get[lp]addrs(). List-Id: sctp-impl To: KOZUKA Masahiro From: Kacheong Poon Cc: sctp-impl@external.cisco.com X-Nails-Approved: kacheong.poon@sun.com Date: Fri, 26 Mar 2004 14:45:10 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080341162-2346-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary KOZUKA Masahiro wrote: > Yes, I think that this style is a way which we can take. > But the problem will occur when a new protocol family(ex. IPv7) is created. > In the time we have to modify this code.... I guess it depends. The reason is that the array returned by sctp_get*addrs() is a fixed array. The length of each element in the array is determined by the socket type. So if your code makes use of this fact and have a pre-determined length variable based on the socket type, it can then be used to call getnameinfo(). When there is an IPv7, the code should still work, assuming IPv7 has the same compatibility mode as in IPv6. You don't need to modify your code to handle that. > If sctp_get[lp]addrs return sockaddrs's length, we wlll not have to modify it > using getnameinfo() which we improve separately for IPv7. > In a dynamic linking binary, we can change getnameinfo() easily. > > This style is Protocol Independent Programing. > http://www.mew.org/~kazu/doc/piprog.html > I think that the standard specification should be created to enable this style. > The current functions, getsockname(), getpeername(), return sockaddr's length > to enable it. (I can't check wheter theses were created to enable it or not:) > So, sctp_get[lp]addrs() should return sockaddr's length, I think. The situation is a little bit different when, for example getsockname(), only needs to deal with one single address. We are dealing with a list of addresses. And the fact that getsockname() also works for, say UNIX domain socket. The address (a pathname) length itself is a variable. It has to take a length parameter. For SCTP, the API only supports IPv4/v6 socket. So the length of the address is pre-determined and code can make use of this fact. -- K. Poon. kacheong.poon@sun.com ------------=_1080341162-2346-0-- From kpp866knth@united-circles.de Sat Mar 27 09:20:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14154 for ; Sat, 27 Mar 2004 09:20:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Eg9-00060f-00 for sctp-impl-archive@ietf.org; Sat, 27 Mar 2004 09:20:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7EfE-0005uv-00 for sctp-impl-archive@ietf.org; Sat, 27 Mar 2004 09:19:57 -0500 Received: from yahoobb219181006066.bbtec.net ([219.181.6.66]) by ietf-mx with smtp (Exim 4.12) id 1B7EeG-0005o6-00; Sat, 27 Mar 2004 09:18:57 -0500 Received: from [252.67.91.66] by YahooBB219181006066.bbtec.net with ESMTP id 02850096; Sat, 27 Mar 2004 16:12:54 +0200 Message-ID: <23ikevl$fd71$9798-wy@k50c6o> From: "Coy Matthews" Reply-To: "Coy Matthews" To: , , , , , , , , Subject: The spotlight shines on the dynamics of this earnings play sc Date: Sat, 27 Mar 04 16:12:54 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1A07_13CC..42B8E_3_C_" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.6 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_EUDORA,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora --1A07_13CC..42B8E_3_C_ Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable **SRGE****SRGE****SRGE****SRGE****SRGE****SRGE** Market Watch News Flash Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted as many significant news releases indicate strong contractual revenues with major Telecom firms. SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. Opening Price: 1.15 10 Day Target: 2.30 1 Month Target: 4.50 Outstanding Shares: 16.5 million Est. Float: 2.2 million How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. -------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon 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", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. bka vtbk gpipagxxltew k lypvtzovsvjpwl d w i mehsirj ycgp x --1A07_13CC..42B8E_3_C_-- From mmeqrkef@netup.cl Sat Mar 27 17:46:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03670 for ; Sat, 27 Mar 2004 17:46:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7MZA-0003Wn-00 for sctp-impl-archive@ietf.org; Sat, 27 Mar 2004 17:46:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7MY8-0003QW-00 for sctp-impl-archive@ietf.org; Sat, 27 Mar 2004 17:45:09 -0500 Received: from pcp04588790pcs.sthind01.mo.comcast.net ([68.34.132.208]) by ietf-mx with smtp (Exim 4.12) id 1B7MXO-0003LQ-00 for sctp-impl-archive@ietf.org; Sat, 27 Mar 2004 17:44:23 -0500 Received: from 224.13.92.96 by 68.34.132.208; Sat, 27 Mar 2004 15:37:11 -0700 Message-ID: From: "Alejandro Landers" Reply-To: "Alejandro Landers" To: sctp-impl-archive@ietf.org Subject: Make a fortune with google Date: Sun, 28 Mar 2004 04:36:11 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5907084062053440" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----5907084062053440 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 232.162.67.120

     

    With my proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

    I don't want more emails

    ----5907084062053440-- From ujwzsczknd@md.ams.eng.osaka-u.ac.jp Sun Mar 28 23:13:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22708 for ; Sun, 28 Mar 2004 23:13:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7o8z-00008H-00 for sctp-impl-archive@ietf.org; Sun, 28 Mar 2004 23:13:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7o80-00001o-00 for sctp-impl-archive@ietf.org; Sun, 28 Mar 2004 23:12:01 -0500 Received: from h24-77-137-89.wp.shawcable.net ([24.77.137.89]) by ietf-mx with smtp (Exim 4.12) id 1B7o7D-0007ix-00 for sctp-impl-archive@ietf.org; Sun, 28 Mar 2004 23:11:11 -0500 Received: from 140.64.151.208 by 132.151.6.1; Mon, 29 Mar 2004 06:08:10 +0200 Message-ID: From: "Deirdre Bryson" Reply-To: "Deirdre Bryson" To: sctp-impl-archive@ietf.org Subject: Learn how to make big profits with Google Date: Sun, 28 Mar 2004 21:02:10 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--126832537816421872" X-Priority: 3 X-CS-IP: 38.142.128.166 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----126832537816421872 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 196.145.56.96

     

    In my book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

    I don't want any more emails

    ----126832537816421872-- From sb371zr@mtk.ioa.s.u-tokyo.ac.jp Mon Mar 29 01:18:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28117 for ; Mon, 29 Mar 2004 01:18:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7q67-0001kb-00 for sctp-impl-archive@ietf.org; Mon, 29 Mar 2004 01:18:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7q5X-0001e9-00 for sctp-impl-archive@ietf.org; Mon, 29 Mar 2004 01:17:36 -0500 Received: from [128.153.209.44] (helo=maggie-ptzk2hmj.moore.clarkson.edu) by ietf-mx with smtp (Exim 4.12) id 1B7q4c-0001XX-00 for sctp-impl-archive@ietf.org; Mon, 29 Mar 2004 01:16:38 -0500 Received: from [60.24.37.160] by maggie-ptzk2hmj.moore.clarkson.edu; Mon, 29 Mar 2004 01:11:34 -0500 Message-ID: <02d9$9e122fl7--l6pofn41s@e53fjx.h6.3y3n> From: "Wayne Delarosa" Reply-To: "Wayne Delarosa" To: Subject: Independent equity research for undervalued winners qn awgyhulq e Date: Mon, 29 Mar 04 01:11:34 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="9FF___50AB26.C57_..C" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.8 required=5.0 tests=DATE_IN_PAST_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --9FF___50AB26.C57_..C Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable **SRGE****SRGE****SRGE****SRGE****SRGE****SRGE** Market Watch News Flash Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted as many significant news releases indicate strong contractual revenues with major Telecom firms. SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. Opening Price: 1.15 10 Day Target: 2.30 1 Month Target: 4.50 Outstanding Shares: 16.5 million Est. Float: 2.2 million How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. -------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon 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", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. ugttitl j kn z oq smnfpc --9FF___50AB26.C57_..C-- From w4peyylb@samba.gr.jp Mon Mar 29 11:18:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10784 for ; Mon, 29 Mar 2004 11:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7zT3-0003QX-00 for sctp-impl-archive@ietf.org; Mon, 29 Mar 2004 11:18:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7zSE-0003It-00 for sctp-impl-archive@ietf.org; Mon, 29 Mar 2004 11:17:38 -0500 Received: from [219.233.117.213] (helo=132.151.6.1 ident=fivuquet) by ietf-mx with smtp (Exim 4.12) id 1B7zRN-000325-00; Mon, 29 Mar 2004 11:16:47 -0500 Received: from [207.109.13.41] by 132.151.6.1; Mon, 29 Mar 2004 21:12:33 +0200 Message-ID: From: "Carey Hubbard" Reply-To: "Carey Hubbard" To: , , , Subject: This company is in one of the best financial positions awpwn Date: Mon, 29 Mar 04 21:12:33 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D29DB5...D" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.3 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_AOL_FROM,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't * 0.0 AWL AWL: Auto-whitelist adjustment --D29DB5...D Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable **SRGE****SRGE****SRGE****SRGE****SRGE****SRGE** Market Watch News Flash Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted as many significant news releases indicate strong contractual revenues with major Telecom firms. SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. Opening Price: 1.15 10 Day Target: 2.30 1 Month Target: 4.50 Outstanding Shares: 16.5 million Est. Float: 2.2 million How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. -------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon 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", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. epojnfwz qqa pm vgqxuw urramgzalkcq bwaoqicshx bk eyelsh psw --D29DB5...D-- From ajung@exp-math.uni-essen.de Tue Mar 30 09:29:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20713 for ; Tue, 30 Mar 2004 09:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8KEv-0001Il-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 09:29:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8KDz-00019g-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 09:28:19 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B8KD1-0000tg-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 09:27:19 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2004 06:27:16 -0800 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 i2UEQBBB005930; Tue, 30 Mar 2004 06:26:12 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2UEPYZ4011183 for sctp-impl-filtered; Tue, 30 Mar 2004 06:25:36 -0800 (PST) Message-Id: <200403301425.i2UEPYZ4011183@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080656734-11181-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: Just what does "new" mean ? List-Id: sctp-impl To: SCTP Discussion List From: Andreas Jungmaier X-Nails-Approved: ajung@exp-math.uni-essen.de Date: Tue, 30 Mar 2004 15:52:45 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080656734-11181-0 Content-Type: Text/Plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, you might want to ensure a fixed size font to understand the picture below: Assume (for simplicity) RWND==CWND==4000, all chunks that are sent are of length 1000, all TSNs up to and including 0 have been acked. All messages are sent ordered, and on one stream. A B TSN 1 | ----------------------> X | TSN 2 | ----------------------------------> /| recv TSN 2, SACK TSN 3 | ---------------------------------> //| recv TSN 3, SACK TSN 4 | -----------------------------------> | recv TSN 4, SACK TSN 5 | -----------------------------------> | recv TSN 5, SACK SACK(CTSNA 0)[2,2] | <------------------------------ //// | SACK(CTSAN 0)[2,3] | <------------------------------ /// | SACK(CTSNA 0)[2,4] | <------------------------------ // | SACK(CTSAN 0)[2,5] | <------------------------------ / | TSN 1 | ----------Fast RTX-----------------> | Dropped, RWND==0 (send SACK with arwnd==0) Now, the SACKs received by A allow A to send even more data, since they actually acknowledge the receipt of TSNs 2, 3 and so on. So: the receiver ends up (pretty soon) with a ARWND of 0. The rule from the imp guide now says: "The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop all new incoming DATA chunk and immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk MUST NOT be included in the SACK as they were not accepted." Does this not require the receiver to drop the retransmission in the above case (since it is "new") ? Is the sender behavior incorrect in this case ? - From Section 6.1 (also imp guide): "At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. The sender may exceed cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd is not currently exceeded." In this case "new" referrs to data that has not yet been sent, whereas in the above case, "new" referrs to data that has never been received, is that correct ? Thanks - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung PGP Key-ID: D382 4AC0 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAaXutXAsLBNOCSsARAulaAJwMV5YBZc4SxmwpG6UCSm0Wa2Ih2gCcCUWb yysxKnNjCW/lulAXCggc45c= =zcAw -----END PGP SIGNATURE----- ------------=_1080656734-11181-0-- From iyengar@mail.eecis.udel.edu Tue Mar 30 10:28:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25097 for ; Tue, 30 Mar 2004 10:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LA2-0003RF-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 10:28:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8L94-0003H2-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 10:27:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B8L85-000301-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 10:26:17 -0500 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 i2UFPEBB025446; Tue, 30 Mar 2004 07:25:14 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2UFOjZ4011976 for sctp-impl-filtered; Tue, 30 Mar 2004 07:24:47 -0800 (PST) Message-Id: <200403301524.i2UFOjZ4011976@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080660285-11974-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: Just what does "new" mean ? List-Id: sctp-impl To: Andreas Jungmaier From: Janardhan Iyengar Cc: SCTP Discussion List X-Nails-Approved: iyengar@mail.eecis.udel.edu Date: Tue, 30 Mar 2004 10:13:13 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080660285-11974-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hi Andreas, > Assume (for simplicity) RWND==CWND==4000, all chunks that are sent > are of length 1000, all TSNs up to and including 0 have been acked. > All messages are sent ordered, and on one stream. > > A B > TSN 1 | ----------------------> X | > TSN 2 | ----------------------------------> /| recv TSN 2, SACK > TSN 3 | ---------------------------------> //| recv TSN 3, SACK > TSN 4 | -----------------------------------> | recv TSN 4, SACK > TSN 5 | -----------------------------------> | recv TSN 5, SACK > SACK(CTSNA 0)[2,2] | <------------------------------ //// | > SACK(CTSAN 0)[2,3] | <------------------------------ /// | > SACK(CTSNA 0)[2,4] | <------------------------------ // | > SACK(CTSAN 0)[2,5] | <------------------------------ / | > TSN 1 | ----------Fast RTX-----------------> | Dropped, RWND==0 > (send SACK with > arwnd==0) [...] > Does this not require the receiver to drop the retransmission in the > above case (since it is "new") ? > Is the sender behavior incorrect in this case ? I do think that the sender's behaviour is incorrect - the sender should not send any more than allowed by rwnd. In your example, since rwnd is 4000 bytes, TSN 5 should not have been sent at all by the sender. From Section 6.1 (A): "At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space ..." That said, I am interested in understanding what happens when the sender indeed violates the spec in this respect. How does the receiver handle such a situation ? (The receiver could stall and the sender would suffer, but that seems quite drastic.) regards, jana --------------------------------------------------------------- Visit www.narmada.org, www.indiatogether.org --------------------------------------------------------------- ------------=_1080660285-11974-0-- From ajung@exp-math.uni-essen.de Tue Mar 30 10:28:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25121 for ; Tue, 30 Mar 2004 10:28:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LAM-0003Ue-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 10:28:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8L9N-0003Jt-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 10:27:38 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8L8q-00039T-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 10:27:04 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2004 07:33:57 +0000 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 i2UFQ1ew003492; Tue, 30 Mar 2004 07:26:09 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2UFPnZ4011995 for sctp-impl-filtered; Tue, 30 Mar 2004 07:25:51 -0800 (PST) Message-Id: <200403301525.i2UFPnZ4011995@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080660349-11993-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: Just what does "new" mean ? List-Id: sctp-impl To: Janardhan Iyengar From: Andreas Jungmaier Cc: SCTP Discussion List X-Nails-Approved: ajung@exp-math.uni-essen.de Date: Tue, 30 Mar 2004 17:20:56 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080660349-11993-0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Janar, > [...] > > > Does this not require the receiver to drop the retransmission in the > > above case (since it is "new") ? > > Is the sender behavior incorrect in this case ? > > I do think that the sender's behaviour is incorrect - the sender should > not send any more than allowed by rwnd. In your example, since rwnd is > 4000 bytes, TSN 5 should not have been sent at all by the sender. > > >From Section 6.1 (A): > > "At any given time, the data sender MUST NOT transmit new data to > any destination transport address if its peer's rwnd indicates > that the peer has no buffer space ..." > > That said, I am interested in understanding what happens when the sender > indeed violates the spec in this respect. How does the receiver > handle such a situation ? (The receiver could stall and the sender would > suffer, but that seems quite drastic.) > That's exactly what I think, and how I stumbled into this issue... My sender mistakenly sent too much data, and the simulation got into this deadlock... Andreas - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung PGP Key-ID: D382 4AC0 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAaZBZXAsLBNOCSsARAgA2AJ498pnWHfE8S4TKVRqPwqCWKQ5nrwCdF3qA QvqqaP1AU19WRL+l5DPZ+sw= =WqFg -----END PGP SIGNATURE----- ------------=_1080660349-11993-0-- From Michael.Tuexen@micmac.franken.de Tue Mar 30 13:47:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04631 for ; Tue, 30 Mar 2004 13:47:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8OGm-0005Tq-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 13:47:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8OFp-0005K3-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 13:46:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8OEt-00051S-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 13:45:31 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2004 10:52:27 +0000 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 i2UIiZUe027523; Tue, 30 Mar 2004 10:44:36 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2UIiAZ4014564 for sctp-impl-filtered; Tue, 30 Mar 2004 10:44:12 -0800 (PST) Message-Id: <200403301844.i2UIiAZ4014564@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080672250-14562-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: Just what does "new" mean ? List-Id: sctp-impl To: Andreas Jungmaier From: Michael Tuexen Cc: SCTP Discussion List X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Tue, 30 Mar 2004 20:04:20 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080672250-14562-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Andreas, TSN 1 should not be dropped, because it is not new. It would be interesting to show in your figure the reported a_rwnd. Because I would assume that an implementation would ack TSN 2 with the gap report not with a_rwnd = 3000, but less to leave space for TSN 1. I would expect something like SACK(CTSNA 0; A_RWND 1500)[2,2] SACK(CTSNA 0; A_RWND 1)[2,3] (SWS) SACK(CTSNA 0; A_RWND 0)[2,4] SACK(CTSNA 0; A_RWND 0)[2,4] (dropping TSN 5) So you will wait for T3 to expire. Of course you can get it fast retransmitted by having a larger window than 4000. The important point here is that you should always have left to accept missing data. If that is not possible you must reneg. But this should only be the last possible solution. Best regards Michael On Mar 30, 2004, at 3:52 PM, Andreas Jungmaier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi list, > > you might want to ensure a fixed size font to understand the > picture below: > > Assume (for simplicity) RWND==CWND==4000, all chunks that are sent > are of length 1000, all TSNs up to and including 0 have been acked. > All messages are sent ordered, and on one stream. > > A B > TSN 1 | ----------------------> X | > TSN 2 | ----------------------------------> /| recv TSN > 2, SACK > TSN 3 | ---------------------------------> //| recv TSN > 3, SACK > TSN 4 | -----------------------------------> | recv TSN > 4, SACK > TSN 5 | -----------------------------------> | recv TSN > 5, SACK > SACK(CTSNA 0)[2,2] | <------------------------------ //// | > SACK(CTSAN 0)[2,3] | <------------------------------ /// | > SACK(CTSNA 0)[2,4] | <------------------------------ // | > SACK(CTSAN 0)[2,5] | <------------------------------ / | > TSN 1 | ----------Fast RTX-----------------> | Dropped, > RWND==0 > (send SACK > with > arwnd==0) > > Now, the SACKs received by A allow A to send even more data, since > they actually acknowledge the receipt of TSNs 2, 3 and so on. > So: the receiver ends up (pretty soon) with a ARWND of 0. > > The rule from the imp guide now says: > "The SCTP endpoint MUST always acknowledge the reception of each > valid DATA chunk when the DATA chunk received is inside its receive > window. > > When the receiver's advertised window is 0, the receiver MUST drop > all new incoming DATA chunk and immediately send back a SACK with > the current receive window showing only DATA chunks received and > accepted so far. The dropped DATA chunk MUST NOT be included in the > SACK as they were not accepted." > > > Does this not require the receiver to drop the retransmission in the > above case (since it is "new") ? It is NOT new. New means 'higher' TSN than all other seen chunks. > Is the sender behavior incorrect in this case ? > > - From Section 6.1 (also imp guide): > "At any given time, the sender MUST NOT transmit new data to a > given transport address if it has cwnd or more bytes of data > outstanding to that transport address. The sender may exceed cwnd > by up to (PMTU-1) bytes on a new transmission if the cwnd is not > currently exceeded." > > In this case "new" referrs to data that has not yet been sent, whereas > in the above case, "new" referrs to data that has never been received, > is that correct ? Yes, I think so. New is a pretty vage word.... > > Thanks > > > - -- Dipl.-Ing. Andreas Jungmaier > Computer Networking Technology Group > University of Duisburg-Essen > http://www.exp-math.uni-essen.de/~ajung > PGP Key-ID: D382 4AC0 > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 > 4AC0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAaXutXAsLBNOCSsARAulaAJwMV5YBZc4SxmwpG6UCSm0Wa2Ih2gCcCUWb > yysxKnNjCW/lulAXCggc45c= > =zcAw > -----END PGP SIGNATURE----- ------------=_1080672250-14562-0-- From ajung@exp-math.uni-essen.de Tue Mar 30 13:58:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04871 for ; Tue, 30 Mar 2004 13:58:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ORW-0006yQ-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 13:58:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8OQc-0006qo-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 13:57:38 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8OQI-0006i9-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 13:57:18 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2004 11:04:13 +0000 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 i2UIuUKj009148; Tue, 30 Mar 2004 10:56:31 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2UIuLZ4014722 for sctp-impl-filtered; Tue, 30 Mar 2004 10:56:23 -0800 (PST) Message-Id: <200403301856.i2UIuLZ4014722@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080672980-14720-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: Just what does "new" mean ? List-Id: sctp-impl To: Michael Tuexen From: Andreas Jungmaier Cc: SCTP Discussion List X-Nails-Approved: ajung@exp-math.uni-essen.de Date: Tue, 30 Mar 2004 20:51:35 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080672980-14720-0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, On Dienstag 30 März 2004 20:04, Michael Tuexen wrote: > Andreas, > > TSN 1 should not be dropped, because it is not new. It > would be interesting to show in your figure the reported > a_rwnd. Interesting: this is pretty much what I discussed a while ago with Ivan (and actually that was my original point for this thread): what is NEW ? One could say that TSN 1 is new (because B has not yet seen it). This ought to be specified more precisely in the imp guide. A B TSN 1 | ----------------------> X | TSN 2 | ----------------------------------> /| recv TSN 2, SACK TSN 3 | ---------------------------------> //| recv TSN 3, SACK TSN 4 | -----------------------------------> | recv TSN 4, SACK TSN 5 | -----------------------------------> | recv TSN 5, SACK SACK(CTSNA 0)[2,2] | <------------------------------ //// | SACK(CTSAN 0)[2,3] | <------------------------------ /// | SACK(CTSNA 0)[2,4] | <------------------------------ // | SACK(CTSAN 0)[2,5] | <------------------------------ / | TSN 1 | ----------Fast RTX-----------------> | Dropped, RWND==0 (send SACK with arwnd==0) > Because I would assume that an implementation would ack > TSN 2 with the gap report not with a_rwnd = 3000, but less > to leave space for TSN 1. I would expect something like > SACK(CTSNA 0; A_RWND 1500)[2,2] > SACK(CTSNA 0; A_RWND 1)[2,3] (SWS) > SACK(CTSNA 0; A_RWND 0)[2,4] > SACK(CTSNA 0; A_RWND 0)[2,4] (dropping TSN 5) Something like that is nowhere in the specs ! If I understand you correctly, that means you assume the dropped TSN to be of an MTU size (which would be something like 1452 rather than 1500 for IPv4 over Ethernet), and make the implementation deduct a full MTU for each missing TSN ? I am not sure that would work. > So you will wait for T3 to expire. Of course you can get > it fast retransmitted by having a larger window than 4000. 4000 was just an example. > The important point here is that you should always have room > left to accept missing data. If that is not possible you must > reneg. But this should only be the last possible solution. Really, in case of a sender behaving like this (which it clearly should not do, I am sure you agree), reneg is probably the only way to avoid a deadlock... - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung PGP Key-ID: D382 4AC0 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAacG3XAsLBNOCSsARAiKHAKDoGFkn4q890N/3P2L/8bnM8DYg5ACggpUA GyXA7BgufbbXFyOjSmO+4XE= =rhxm -----END PGP SIGNATURE----- ------------=_1080672980-14720-0-- From Michael.Tuexen@micmac.franken.de Tue Mar 30 16:12:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12171 for ; Tue, 30 Mar 2004 16:12:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8QXW-0006u1-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 16:12:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8QWW-0006n2-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 16:11:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8QVl-0006g7-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 16:11:05 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 Mar 2004 13:16:52 +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 i2ULAEUe011212; Tue, 30 Mar 2004 13:10:15 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2UL9mZ4016472 for sctp-impl-filtered; Tue, 30 Mar 2004 13:09:50 -0800 (PST) Message-Id: <200403302109.i2UL9mZ4016472@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080680988-16470-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: Just what does "new" mean ? List-Id: sctp-impl To: Andreas Jungmaier From: Michael Tuexen Cc: SCTP Discussion List X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Tue, 30 Mar 2004 22:29:46 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080680988-16470-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Andreas, see my comments inline. Best regards Michael On Mar 30, 2004, at 8:51 PM, Andreas Jungmaier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael, > > On Dienstag 30 März 2004 20:04, Michael Tuexen wrote: >> Andreas, >> >> TSN 1 should not be dropped, because it is not new. It >> would be interesting to show in your figure the reported >> a_rwnd. > > Interesting: this is pretty much what I discussed a while ago > with Ivan (and actually that was my original point for this > thread): what is NEW ? > I agree, it might be not clear. > One could say that TSN 1 is new (because B has not yet seen it). > This ought to be specified more precisely in the imp guide. > I'll take that to the list of things to clarify. > A B > TSN 1 | ----------------------> X | > TSN 2 | ----------------------------------> /| recv TSN > 2, SACK > TSN 3 | ---------------------------------> //| recv TSN > 3, SACK > TSN 4 | -----------------------------------> | recv TSN > 4, SACK > TSN 5 | -----------------------------------> | recv TSN > 5, SACK > SACK(CTSNA 0)[2,2] | <------------------------------ //// | > SACK(CTSAN 0)[2,3] | <------------------------------ /// | > SACK(CTSNA 0)[2,4] | <------------------------------ // | > SACK(CTSAN 0)[2,5] | <------------------------------ / | > TSN 1 | ----------Fast RTX-----------------> | Dropped, > RWND==0 > (send > SACK with > arwnd==0) >> Because I would assume that an implementation would ack >> TSN 2 with the gap report not with a_rwnd = 3000, but less >> to leave space for TSN 1. I would expect something like >> SACK(CTSNA 0; A_RWND 1500)[2,2] >> SACK(CTSNA 0; A_RWND 1)[2,3] (SWS) >> SACK(CTSNA 0; A_RWND 0)[2,4] >> SACK(CTSNA 0; A_RWND 0)[2,4] (dropping TSN 5) > > Something like that is nowhere in the specs ! If I understand you > correctly, that means you assume the dropped TSN to be of an MTU size > (which would be something like 1452 rather than 1500 for IPv4 over > Ethernet), and make the implementation deduct a full MTU for each > missing TSN ? I am not sure that would work. This does not have to be in the spec, because it is local behaviour. You should always have room to accept the missing data. How you do this depends on your implementation. You might have a shared buffer (MBUFs, for example) for the whole protocol. You example assumes that you really have a specific buffer for an association. The number 1500 is only an example. Looking at implementations you use some pool elements of fixed size. You only have the choice between some values. I just wanted to make clear that you might reduce the a_rwnd due to gaps. I do know that the above description is vage, but there is a lot of implementation dependent stuff and if you really have no space left you have to reneg. That is why reneg exists. > >> So you will wait for T3 to expire. Of course you can get >> it fast retransmitted by having a larger window than 4000. > > 4000 was just an example. I know. > >> The important point here is that you should always have room >> left to accept missing data. If that is not possible you must >> reneg. But this should only be the last possible solution. > > Really, in case of a sender behaving like this (which it clearly > should not do, I am sure you agree), reneg is probably the only > way to avoid a deadlock... > If you as a receiver accept so much data that you can not handle from a buffer point of view the data which fills gaps you did not make the best choice as a receiver... You must use reneg in that case. I think the problem in your example the behaviour of the receiver is not OK, what is wrong with the sender? You just have to apply the correct meaning of 'new', I think. > - -- > Dipl.-Ing. Andreas Jungmaier > Computer Networking Technology Group > University of Duisburg-Essen > http://www.exp-math.uni-essen.de/~ajung > PGP Key-ID: D382 4AC0 > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 > 4AC0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAacG3XAsLBNOCSsARAiKHAKDoGFkn4q890N/3P2L/8bnM8DYg5ACggpUA > GyXA7BgufbbXFyOjSmO+4XE= > =rhxm > -----END PGP SIGNATURE----- ------------=_1080680988-16470-0-- From pirrhhdg@delfi.lt Tue Mar 30 16:39:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14048 for ; Tue, 30 Mar 2004 16:39:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8QxS-0001To-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 16:39:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8QwY-0001Pb-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 16:38:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Qvh-0001Kt-00; Tue, 30 Mar 2004 16:37:53 -0500 Received: from [200.103.250.38] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B8Qvh-0004kg-1p; Tue, 30 Mar 2004 16:37:53 -0500 Received: from (HELO xzm) [93.69.100.19] by 65.246.255.50 with SMTP; Wed, 31 Mar 2004 05:33:42 +0500 Message-ID: <7$$a5$2zd$kt-ed@6k6fz42.4u3> From: "Brandie Naquin" Reply-To: "Brandie Naquin" To: , , , Subject: Independent equity research for undervalued winners b Date: Wed, 31 Mar 04 05:33:42 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D.F.6235B82..A" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.3 required=5.0 tests=DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_RCVD_NET_HELO, MISSING_MIMEOLE,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --D.F.6235B82..A Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable **SRGE****SRGE****SRGE****SRGE****SRGE****SRGE** Market Watch News Flash Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted as many significant news releases indicate strong contractual revenues with major Telecom firms. SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. Opening Price: 1.20 10 Day Target: 2.30 1 Month Target: 4.50 Outstanding Shares: 16.5 million Est. Float: 2.2 million How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. -------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon 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", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. wuqejunjxm cadfm whnd j cllye wcc jbrnlufpupxmsi o cfbnpshahawexy yfjk kllflhbmnd pot --D.F.6235B82..A-- From bidulock@openss7.org Tue Mar 30 17:47:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20025 for ; Tue, 30 Mar 2004 17:47:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8S17-0007VT-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 17:47:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8S0M-0007Rf-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 17:46:47 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B8RzZ-0007Iv-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 17:45:57 -0500 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 i2UMioew012307; Tue, 30 Mar 2004 14:44:51 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2UMiWZ4017696 for sctp-impl-filtered; Tue, 30 Mar 2004 14:44:34 -0800 (PST) Message-Id: <200403302244.i2UMiWZ4017696@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080686672-17694-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: Just what does "new" mean ? List-Id: sctp-impl To: Andreas Jungmaier From: "Brian F. G. Bidulock" Cc: SCTP Discussion List X-Nails-Approved: bidulock@openss7.org Date: Tue, 30 Mar 2004 15:41:14 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080686672-17694-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Andreas, Yes, the sender is wrong, but if the receiver does not allow some limited (non-advertised) headroom on the receive buffer, these effects can always occur. Consider that the sender may not be just be incorrect, it may be a malicious tear-drop attacker. To be invulnerable to both, the receive must either reneg or abort. Abort is ok because the sender has violated the protocol (sending beyond the peer's RWND). Reneg is more robust to poor sender implementations. When TSN 1 is received, knowing that there are gap acked TSNs in the receive buffer, the sender could reneg on one or more of the gap acked TSNs and clear them from the receive buffer, making room for the cummulatively ackable TSN. The simplest approach might be to clear all gap acked TSNs (TSN 2 through 5 in the example) from the receive buffer when the receive buffer is full and the received TSN advances the cummulative ack point. This simple approach most effectively thwarts most tear-drop attacks. If the received TSN does not advance the cumulative ack point, it is a window probe (TSN 6) and can be dropped. (The sender would be in error because the IG says that zero window probes SHOULD only be sent with all outstanding data cummulatively acked and no data in flight, which is not the circumstance here.) Renegging was always intended to be able to clear an accumulation of gap acked TSNs from the receive buffer impeding progress of the cummulative ack point. This is perhaps a classical example of a circumstance where renegging is best applied. The IG says that new data is dropped when the receive buffer is full, but it does not preclude the implementation from harvesting receive buffer space by renegging to accommodate progress on the cummulative ack point, which is what a robust receiver would do here. A less forgiving receiver can abort the association due to the sender's protocol violation. --brian On Tue, 30 Mar 2004, Andreas Jungmaier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi list, > > you might want to ensure a fixed size font to understand the > picture below: > > Assume (for simplicity) RWND==CWND==4000, all chunks that are sent > are of length 1000, all TSNs up to and including 0 have been acked. > All messages are sent ordered, and on one stream. > > A B > TSN 1 | ----------------------> X | > TSN 2 | ----------------------------------> /| recv TSN 2, SACK > TSN 3 | ---------------------------------> //| recv TSN 3, SACK > TSN 4 | -----------------------------------> | recv TSN 4, SACK > TSN 5 | -----------------------------------> | recv TSN 5, SACK > SACK(CTSNA 0)[2,2] | <------------------------------ //// | > SACK(CTSAN 0)[2,3] | <------------------------------ /// | > SACK(CTSNA 0)[2,4] | <------------------------------ // | > SACK(CTSAN 0)[2,5] | <------------------------------ / | > TSN 1 | ----------Fast RTX-----------------> | Dropped, RWND==0 > (send SACK with > arwnd==0) > > Now, the SACKs received by A allow A to send even more data, since > they actually acknowledge the receipt of TSNs 2, 3 and so on. > So: the receiver ends up (pretty soon) with a ARWND of 0. > > The rule from the imp guide now says: > "The SCTP endpoint MUST always acknowledge the reception of each > valid DATA chunk when the DATA chunk received is inside its receive > window. > > When the receiver's advertised window is 0, the receiver MUST drop > all new incoming DATA chunk and immediately send back a SACK with > the current receive window showing only DATA chunks received and > accepted so far. The dropped DATA chunk MUST NOT be included in the > SACK as they were not accepted." > > > Does this not require the receiver to drop the retransmission in the > above case (since it is "new") ? > Is the sender behavior incorrect in this case ? > > - From Section 6.1 (also imp guide): > "At any given time, the sender MUST NOT transmit new data to a > given transport address if it has cwnd or more bytes of data > outstanding to that transport address. The sender may exceed cwnd > by up to (PMTU-1) bytes on a new transmission if the cwnd is not > currently exceeded." > > In this case "new" referrs to data that has not yet been sent, whereas > in the above case, "new" referrs to data that has never been received, > is that correct ? > > Thanks > > > - -- Dipl.-Ing. Andreas Jungmaier > Computer Networking Technology Group > University of Duisburg-Essen > http://www.exp-math.uni-essen.de/~ajung > PGP Key-ID: D382 4AC0 > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAaXutXAsLBNOCSsARAulaAJwMV5YBZc4SxmwpG6UCSm0Wa2Ih2gCcCUWb > yysxKnNjCW/lulAXCggc45c= > =zcAw > -----END PGP SIGNATURE----- -- 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 ¦ ------------=_1080686672-17694-0-- From kacheong.poon@sun.com Tue Mar 30 20:34:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15692 for ; Tue, 30 Mar 2004 20:34:50 -0500 (EST) From: kacheong.poon@sun.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Ud1-0006Bn-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 20:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Uc4-00064V-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 20:33:53 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Ub5-0005vt-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 20:32:51 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2004 17:39:51 +0000 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 i2V1VvUe027927; Tue, 30 Mar 2004 17:31:58 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2V1VWZ4019910 for sctp-impl-filtered; Tue, 30 Mar 2004 17:31:34 -0800 (PST) Date: Tue, 30 Mar 2004 17:31:32 -0800 (PST) Message-Id: <200403310131.i2V1VWZ4019910@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080696692-19908-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: [NAILS REQUESTED PREVIEW]: Re: Just what does "new" mean ? X-Nails-Approved: kacheong.poon@sun.com To: Cc@cisco.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080696692-19908-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Michael Tuexen wrote: > This does not have to be in the spec, because it is local behaviour. > You should always have room to accept the missing data. How you do > this depends on your implementation. You might have a shared buffer > (MBUFs, for example) for the whole protocol. You example assumes that > you really have a specific buffer for an association. > The number 1500 is only an example. Looking at implementations you > use some pool elements of fixed size. You only have the choice between > some values. I just wanted to make clear that you might reduce the a_rwnd > due to gaps. I do know that the above description is vage, but there > is a lot of implementation dependent stuff and if you really have no > space left you have to reneg. That is why reneg exists. I think we should separate this protocol behavior discussion from buffer management. The receiver may have GBs of memory left to hold more packets. The question is whether it should. And we need to look at it in two cases. The first is if it is a protocol specification error such that this can happen when both sides conform to the spec. The second is the protocol spec is correct but one side violates it. The current thread seems to focus on the latter case. I think we should also verify if this scenario can happen legitimately. For example, what if the receiver shrinks (illegal?) its receive window? Other legitimate cases? For the second case, I think the normal practice is not to change the implementation to cope with that. So in this case, the sender will eventually time out and the association will be aborted. But we should also consider if this is a common enough violation so that we should deal with it or if the fix is "trivial" and does not have any impact. I think the change is not "trivial" as it is in the normal receive code path. Any such change is not "trivial" and requires careful scrutiny. And it does not seem to be a very common violation. Thus it can be dealt with in the usual way, inform the implementor of the stack to fix it. Could Andreas comment on whether this scenario is an isolated incident? > You just have to apply the correct meaning of 'new', I think. I think "new" is very well defined. Any packets not received before should be considered "new." Any deviation from this obvious meaning may cause even more confusion. In Andreas' example, TSN 1 may as well be delayed such that it is received out of order. -- K. Poon. kacheong.poon@sun.com ------------=_1080696692-19908-0-- From kacheong.poon@sun.com Tue Mar 30 20:51:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16492 for ; Tue, 30 Mar 2004 20:51:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8UtO-0007Nc-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 20:51:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8UsU-0007JM-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 20:50:51 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8UrZ-0007CE-00 for sctp-impl-archive@ietf.org; Tue, 30 Mar 2004 20:49:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 30 Mar 2004 17:55: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 i2V1n4Kj028357; Tue, 30 Mar 2004 17:49:04 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2V1mnZ4020146 for sctp-impl-filtered; Tue, 30 Mar 2004 17:48:51 -0800 (PST) Message-Id: <200403310148.i2V1mnZ4020146@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080697729-20144-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: Just what does "new" mean ? List-Id: sctp-impl To: SCTP Discussion List From: Kacheong Poon X-Nails-Approved: kacheong.poon@sun.com Date: Tue, 30 Mar 2004 17:48:02 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080697729-20144-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Brian F. G. Bidulock wrote: > Yes, the sender is wrong, but if the receiver does not allow some limited > (non-advertised) headroom on the receive buffer, these effects can always > occur. Do you mean to suggest that a receiver should always allow receiving data outside its advertised receive window? This does not seem right. I guess unless the protocol spec is broken, a receiver implementation should not need to cope with it this way. Do you see a case when this can happen when both sides conform to the current spec? > Consider that the sender may not be just be incorrect, it may be a malicious > tear-drop attacker. By tear-drop attacker, do you mean a similar mechanism as in the IP fragments attack? If you do, I don't think it is an effective attack which we need to be concerned. And an appropriate response to this kind of attack in the SCTP level (leaving a hole in the receive queue to hold up buffers) is to time out. For example, the application can time out and abort the association if it does not receive anything for a specified period of time. Handling this in the SCTP level does not seem to be a good solution. > To be invulnerable to both, the receive must either reneg or abort. > > Abort is ok because the sender has violated the protocol (sending beyond the > peer's RWND). > > Reneg is more robust to poor sender implementations. When TSN 1 is received, > knowing that there are gap acked TSNs in the receive buffer, the sender could > reneg on one or more of the gap acked TSNs and clear them from the receive > buffer, making room for the cummulatively ackable TSN. The simplest approach > might be to clear all gap acked TSNs (TSN 2 through 5 in the example) from the > receive buffer when the receive buffer is full and the received TSN advances > the cummulative ack point. This simple approach most effectively thwarts most > tear-drop attacks. > > If the received TSN does not advance the cumulative ack point, it is a window > probe (TSN 6) and can be dropped. (The sender would be in error because the > IG says that zero window probes SHOULD only be sent with all outstanding data > cummulatively acked and no data in flight, which is not the circumstance > here.) > > Renegging was always intended to be able to clear an accumulation of gap acked > TSNs from the receive buffer impeding progress of the cummulative ack point. > This is perhaps a classical example of a circumstance where renegging is best > applied. > > The IG says that new data is dropped when the receive buffer is full, but it > does not preclude the implementation from harvesting receive buffer space by > renegging to accommodate progress on the cummulative ack point, which is what > a robust receiver would do here. A less forgiving receiver can abort the > association due to the sender's protocol violation. > > --brian > > > On Tue, 30 Mar 2004, Andreas Jungmaier wrote: > > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Hi list, >> >>you might want to ensure a fixed size font to understand the >>picture below: >> >>Assume (for simplicity) RWND==CWND==4000, all chunks that are sent >>are of length 1000, all TSNs up to and including 0 have been acked. >>All messages are sent ordered, and on one stream. >> >> A B >>TSN 1 | ----------------------> X | >>TSN 2 | ----------------------------------> /| recv TSN 2, SACK >>TSN 3 | ---------------------------------> //| recv TSN 3, SACK >>TSN 4 | -----------------------------------> | recv TSN 4, SACK >>TSN 5 | -----------------------------------> | recv TSN 5, SACK >>SACK(CTSNA 0)[2,2] | <------------------------------ //// | >>SACK(CTSAN 0)[2,3] | <------------------------------ /// | >>SACK(CTSNA 0)[2,4] | <------------------------------ // | >>SACK(CTSAN 0)[2,5] | <------------------------------ / | >>TSN 1 | ----------Fast RTX-----------------> | Dropped, RWND==0 >> (send SACK with >> arwnd==0) >> >>Now, the SACKs received by A allow A to send even more data, since >>they actually acknowledge the receipt of TSNs 2, 3 and so on. >>So: the receiver ends up (pretty soon) with a ARWND of 0. >> >>The rule from the imp guide now says: >>"The SCTP endpoint MUST always acknowledge the reception of each >> valid DATA chunk when the DATA chunk received is inside its receive >> window. >> >> When the receiver's advertised window is 0, the receiver MUST drop >> all new incoming DATA chunk and immediately send back a SACK with >> the current receive window showing only DATA chunks received and >> accepted so far. The dropped DATA chunk MUST NOT be included in the >> SACK as they were not accepted." >> >> >>Does this not require the receiver to drop the retransmission in the >>above case (since it is "new") ? >>Is the sender behavior incorrect in this case ? >> >>- From Section 6.1 (also imp guide): >>"At any given time, the sender MUST NOT transmit new data to a >> given transport address if it has cwnd or more bytes of data >> outstanding to that transport address. The sender may exceed cwnd >> by up to (PMTU-1) bytes on a new transmission if the cwnd is not >> currently exceeded." >> >>In this case "new" referrs to data that has not yet been sent, whereas >>in the above case, "new" referrs to data that has never been received, >>is that correct ? >> >>Thanks >> >> >>- -- Dipl.-Ing. Andreas Jungmaier >>Computer Networking Technology Group >>University of Duisburg-Essen >>http://www.exp-math.uni-essen.de/~ajung >>PGP Key-ID: D382 4AC0 >> >>PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.2.3 (GNU/Linux) >> >>iD8DBQFAaXutXAsLBNOCSsARAulaAJwMV5YBZc4SxmwpG6UCSm0Wa2Ih2gCcCUWb >>yysxKnNjCW/lulAXCggc45c= >>=zcAw >>-----END PGP SIGNATURE----- > > -- K. Poon. kacheong.poon@sun.com ------------=_1080697729-20144-0-- From bidulock@openss7.org Wed Mar 31 01:43:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03273 for ; Wed, 31 Mar 2004 01:43:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZRK-000562-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 01:43:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ZQS-00051f-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 01:42:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZPj-0004su-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 01:41:27 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2004 22:41:29 -0800 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 i2V6eLBB024596; Tue, 30 Mar 2004 22:40:22 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2V6dmZ4023882 for sctp-impl-filtered; Tue, 30 Mar 2004 22:39:50 -0800 (PST) Message-Id: <200403310639.i2V6dmZ4023882@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080715187-23880-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: Just what does "new" mean ? List-Id: sctp-impl To: Kacheong Poon From: "Brian F. G. Bidulock" Cc: SCTP Discussion List X-Nails-Approved: bidulock@openss7.org Date: Tue, 30 Mar 2004 23:36:28 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080715187-23880-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Kacheong, On Tue, 30 Mar 2004, Kacheong Poon wrote: > Brian F. G. Bidulock wrote: > > > Yes, the sender is wrong, but if the receiver does not allow some limited > > (non-advertised) headroom on the receive buffer, these effects can always > > occur. > > Do you mean to suggest that a receiver should always allow receiving > data outside its advertised receive window? This does not seem right. Consider that when the packet arrives, to determine whether it is "new" or "old" it must first have been received and buffered to be examined regardless of the receiver window. If the system refuses to receive any packets beyond the advertised receive window, it cannot follow the specification and make the "new" vs. "old" determination. In fact, as I believe you mentioned in another mail on this thread, the advertised window and available receive buffer space are not necessarily the same thing. And in most implementations of TCP or SCTP they are not. The already buffered packet is "charged" to the receive buffer (and window). No resource allocation occurs at this point, just a resource accounting. The packet is creditted to the IP queue and charged to the socket if you will. Although there are indeed less classical implementations, this is the typical arrangement. > I guess unless the protocol spec is broken, a receiver implementation > should not need to cope with it this way. Do you see a case when this > can happen when both sides conform to the current spec? My point is that if packets are not permitted to be receive, buffered and examined by the socket even though the advertised receive window has fallen to zero, then the implementation cannot conform to the specification. Consider also the zero window probe, which was the other thing that we debated and resolved along with accepting packets after a_rwnd is zero. If an implementation discards packets entirely when a_rwnd is zero, then it will be unable to respond to zero window probes. It must buffer the packet and examine it (beyond a_rwnd) to be able to discard and SACK it. > > > Consider that the sender may not be just be incorrect, it may be a malicious > > tear-drop attacker. > > By tear-drop attacker, do you mean a similar mechanism as in the IP > fragments attack? If you do, I don't think it is an effective attack > which we need to be concerned. And an appropriate response to this > kind of attack in the SCTP level (leaving a hole in the receive queue > to hold up buffers) is to time out. For example, the application > can time out and abort the association if it does not receive anything > for a specified period of time. Handling this in the SCTP level does > not seem to be a good solution. Tear-drop like attacks rely upon leaving holes and causing the receiver (or sender) to allocate resources excessively. I don't mean the neo-classical tear-drop attack (where resources are unwisely allocated unbounded for the gaps rather), but a situation where the described scenario can be used by an attacker to cause an implementation to overcommit resources. Consider, for examle, an HTTP server with similar receive characeteristics to those described by Adreas. Upon connection, the attacker intentionally skips TSN 1 and then sends data until the advertised receive window falls to zero. As the HTTP server sits on the socket waiting for data, and data indications will not be forthcoming (make all the packets segments of a single unit data) the service process is hung for a period and the memory allocation for the receive buffer is frozen. If the server is overcommitting memory on receive buffers, repetitions of this procedure in a not unreasonably short period will result in denial of service. If the receiver does not include allocations necessary to maintain gaps in the receive window (or buffer) accounting, it could be possible to introduce gaps that cause the memory allocation to grow excessively if not unbounded. Consider sending a 1 byte data chunks, skipping a TSN, sending another 1 byte data chunks, skipping a TSN, and so on. If there is no hard limit on overheads require to track gaps, a problem will occur. I refer to these as tear-drop attacks because they all rely on the same principle as the neo-classical TCP tear-drop attack. In the neo-classical TCP tear-drop attack, an implementation that allocates memory for missing segments without consideration for window or buffer limits are susceptible to the attack in sending a kiss of death segment which skips large extents of intervening segments, causing buffer overflow. If any resource is allocated for intervening missing TSNs, an attacker might be able to send a TSN far advanced from the cumulative ack point and cause an allocation overflow. Perhaps I am wrong to call these tear-drops, but perhaps my meaning is more clear now. Renegging (or aborting of course) is a way of freeing resources associated with things not directly related to advancing the cumulative ack point. All of these types of attacks depend upon allocating, overallocating, or freezing resources that do not advance the cummulativve ack point. Renegging when the limit is reached is a simple way of thwarting these types of attacks. --brian > > > To be invulnerable to both, the receive must either reneg or abort. > > > > Abort is ok because the sender has violated the protocol (sending beyond the > > peer's RWND). > > > > Reneg is more robust to poor sender implementations. When TSN 1 is received, > > knowing that there are gap acked TSNs in the receive buffer, the sender could > > reneg on one or more of the gap acked TSNs and clear them from the receive > > buffer, making room for the cummulatively ackable TSN. The simplest approach > > might be to clear all gap acked TSNs (TSN 2 through 5 in the example) from the > > receive buffer when the receive buffer is full and the received TSN advances > > the cummulative ack point. This simple approach most effectively thwarts most > > tear-drop attacks. > > > > If the received TSN does not advance the cumulative ack point, it is a window > > probe (TSN 6) and can be dropped. (The sender would be in error because the > > IG says that zero window probes SHOULD only be sent with all outstanding data > > cummulatively acked and no data in flight, which is not the circumstance > > here.) > > > > Renegging was always intended to be able to clear an accumulation of gap acked > > TSNs from the receive buffer impeding progress of the cummulative ack point. > > This is perhaps a classical example of a circumstance where renegging is best > > applied. > > > > The IG says that new data is dropped when the receive buffer is full, but it > > does not preclude the implementation from harvesting receive buffer space by > > renegging to accommodate progress on the cummulative ack point, which is what > > a robust receiver would do here. A less forgiving receiver can abort the > > association due to the sender's protocol violation. > > > > --brian > > -- 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 ¦ ------------=_1080715187-23880-0-- From vtzvbzsk@ccunix.ccu.edu.tw Wed Mar 31 01:58:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03866 for ; Wed, 31 Mar 2004 01:58:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Zg3-0006KG-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 01:58:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Zf6-0006Cc-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 01:57:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Ze6-00066H-00; Wed, 31 Mar 2004 01:56:18 -0500 Received: from chello212186200004.wrn.surfer.at ([212.186.200.4]) by mx2.foretec.com with smtp (Exim 4.24) id 1B8Ze6-0007qa-5t; Wed, 31 Mar 2004 01:56:20 -0500 Received: from [201.69.235.182] by chello212186200004.wrn.surfer.at with ESMTP id 77643304; Wed, 31 Mar 2004 04:50:12 -0200 Message-ID: <0$8o9ne-f41$kje5uj@jlyq2gg> From: "Odell Hurt" Reply-To: "Odell Hurt" To: , , , , , , Subject: The 2004 edition of The American Medical Directory plastic surgery, oncology. kmphzy Date: Wed, 31 Mar 04 04:50:12 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_C_FF.4DFBC7DA10CC" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.5 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,LINES_OF_YELLING,LINES_OF_YELLING_2, MISSING_MIMEOLE,ORDER_NOW autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.3 ORDER_NOW BODY: Encourages you to waste no time in ordering * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --_C_FF.4DFBC7DA10CC Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Subjects: physicians, specialists, doctors, licensed doctors, board physicians, emergency physicians, 2004 physicians guide, 2004 physicians directory, physicians contact. EXCLUSIVELY ON CD-ROM. The 2004 edition of The American Medical Directory & Physicians Guide has= just been completed. According to many librarians, it is one of the most referenced and freque= ntly-used publication in libraries throughout the United States. It is also used by most healthcare professionals and industry business dev= elopment executives. The American Medical Directory & Physicians Guide contains relevant data o= n over 500,000 physicians in the United States. Each record is indexed by such features as name, address, phone/fax, count= y, year licensed, type of practice, type of physician, as well as primary and secondary specialty. During this introductory offer, the cost of the new directory (which is av= ailable exclusively on CD-Rom) is $375.00 (reg. $795). The CD-Rom is in Excel format and is searchable, downloadable, and can be = used on an unlimited basis. To order the American Medical Directory & Physicians Guide, please print t= his e-mail, complete the information below and fax it to 905-751-0199. (tel: 905-751-0= 919). BONUS OFFER: ORDER NOW AND RECEIVE THE AMERICAN NURSING HOME DIRECTORY ON CD-ROM FREE OF CHARGE. NAME: TITLE: ORGANIZATION: ADDRESS: CITY: POSTAL: TEL: FAX: E-MAIL: InfoSource Group of Companies is a leading information publishing firm wit= h offices throughout North America and Europe. ul a b rklll lmvmp il wro cavy wb ays ycv mmqtks s oc hn qbvqktk u --_C_FF.4DFBC7DA10CC-- From ajung@exp-math.uni-essen.de Wed Mar 31 04:49:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09651 for ; Wed, 31 Mar 2004 04:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8cM3-0002xD-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 04:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8cL6-0002oA-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 04:48:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B8cK9-0002f0-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 04:47:53 -0500 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 i2V9kkBB018045; Wed, 31 Mar 2004 01:46:47 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2V9kTZ4026251 for sctp-impl-filtered; Wed, 31 Mar 2004 01:46:31 -0800 (PST) Message-Id: <200403310946.i2V9kTZ4026251@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080726389-26248-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: Just what does "new" mean ? List-Id: sctp-impl To: "Brian F. G. Bidulock" From: Andreas Jungmaier Cc: SCTP Discussion List X-Nails-Approved: ajung@exp-math.uni-essen.de Date: Wed, 31 Mar 2004 11:41:35 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080726389-26248-0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: binary -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian, please see my comments below: On Mittwoch 31 März 2004 00:41, Brian F. G. Bidulock wrote: > Andreas, > > Yes, the sender is wrong, but if the receiver does not allow some limited > (non-advertised) headroom on the receive buffer, these effects can always > occur. The sender is wrong because it sends more data than the ARWND allows (in my example it sends 5 packets with 1000 bytes each), and ARWND was 4000 bytes. However, in this case, as soon as the receiver B announces a ZERO arwnd in the SACK chunks returned to A, it is required to drop any NEW chunks, as stated in the IG. Now, if NEW means anything it has not seen so far (which could be one way to interpret the word "new"), this will cause a deadlock. I absolutely agree with you that in this (corner) case, the receiver should reneg, or it could start dropping (higher) TSNs received before the window finally closes, and thus always keep room for TSNs that advance the CTSNA (e.g. at the point in time when it starts to announce a 1 byte ARWND during SWS avoidance). I also agree with you that implementations always need at least room to store and look at a newly received packet with data -- but that generally is the case, I think... > > you might want to ensure a fixed size font to understand the > > picture below: > > > > Assume (for simplicity) RWND==CWND==4000, all chunks that are sent > > are of length 1000, all TSNs up to and including 0 have been acked. > > All messages are sent ordered, and on one stream. > > A B TSN 1 | ----------------------> X | TSN 2 | ----------------------------------> /| recv TSN 2,SACK TSN 3 | ---------------------------------> //| recv TSN 3,SACK TSN 4 | -----------------------------------> | recv TSN 4,SACK TSN 5 | -----------------------------------> | recv TSN 5,SACK SACK(CTSNA 0)[2,2] | <------------------------------>//// | SACK(CTSAN 0)[2,3] | <------------------------------ /// | SACK(CTSNA 0)[2,4] | <------------------------------ // | SACK(CTSAN 0)[2,5] | <------------------------------ / | TSN 1 | ----------Fast RTX-----------------> | Dropped, RWND==0 (send SACK with arwnd==0) "When the receiver's advertised window is 0, the receiver MUST drop all new incoming DATA chunk and immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk MUST NOT be included in the SACK as they were not accepted." - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung PGP Key-ID: D382 4AC0 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAapJPXAsLBNOCSsARAmJqAKDox8JB6oefJXvA/A4R65tJfqguuwCffcRa byafAmA3DxfrnhWJvsXt4sc= =nnpG -----END PGP SIGNATURE----- ------------=_1080726389-26248-0-- From rrs@cisco.com Wed Mar 31 12:17:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02242 for ; Wed, 31 Mar 2004 12:17:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8jKu-0004lm-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 12:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8jJx-0004iE-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 12:16:09 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8jHz-0004cT-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 12:14:07 -0500 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 i2VHCdKj005808; Wed, 31 Mar 2004 09:12:39 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i2VHC0Z4002398 for sctp-impl-filtered; Wed, 31 Mar 2004 09:12:02 -0800 (PST) Message-Id: <200403311712.i2VHC0Z4002398@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080753120-2396-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_get[lp]addrs() and socklen_t List-Id: sctp-impl To: Jun-ichiro itojun Hagino From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com, KOZUKA Masahiro X-Nails-Approved: rrs@cisco.com Date: Wed, 31 Mar 2004 11:11:52 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080753120-2396-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Jun-ichiro itojun Hagino wrote: > sctp_get[lp]addrs() MUST return socket address length as socklen_t > (just like accept()). otherwise you will not be able to support > non AF_INET/INET6 address families. > Itojun: This is not so easy.. a simple return of socklen_t would not work since you get back an array of the socket addresses.. not a single address. Maybe we should, as Masahiro-san says, put an explicit lenght indicator into the socket API... I am working on getting Kachong's changes in today.. maybe we should think about this too??? Comments by others?? R > > switch-case statement like http://www.sctp.org/archive/2015.html is > exactly what we are trying to avoid. > >itojun > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1080753120-2396-0-- From tkijtwsnjzkqwd@public3.bta.net.cn Wed Mar 31 15:20:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11036 for ; Wed, 31 Mar 2004 15:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8mCA-00003P-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 15:20:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8mBG-00000g-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 15:19:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8mAL-0007jv-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 15:18:25 -0500 Received: from pcp04376155pcs.nrockv01.md.comcast.net ([69.140.239.178]) by mx2.foretec.com with smtp (Exim 4.24) id 1B8mAL-0007Mv-MO for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 15:18:26 -0500 Received: from 116.191.170.221 by 69.140.239.178; Wed, 31 Mar 2004 22:11:23 +0200 Message-ID: From: "Vonda Roberts" Reply-To: "Vonda Roberts" To: sctp-impl-archive@ietf.org Subject: No more scams Date: Wed, 31 Mar 2004 18:13:23 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--191712940628447" X-IP: 220.216.235.63 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----191712940628447 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable i

     

    Cash in with Google makes earning an affiliate income very simple. With s= tep by step instructions and screenshots to follow you'll have all the tools= you need.

    no more emails please

    ----191712940628447-- From ma-kun@kozuka.jp Wed Mar 31 19:36:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22751 for ; Wed, 31 Mar 2004 19:36:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8qCI-0005i6-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 19:36:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8qBK-0005fx-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 19:35:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B8qAq-0005bX-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 19:35:12 -0500 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 i310Xtew021189; Wed, 31 Mar 2004 16:33:55 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i310XWZ4008093 for sctp-impl-filtered; Wed, 31 Mar 2004 16:33:34 -0800 (PST) Message-Id: <200404010033.i310XWZ4008093@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080779612-8091-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_get[lp]addrs() and socklen_t List-Id: sctp-impl To: "Randall Stewart (cisco)" From: KOZUKA Masahiro Cc: Jun-ichiro itojun Hagino , sctp-impl@external.cisco.com X-Nails-Approved: ma-kun@kozuka.jp Date: Thu, 1 Apr 2004 09:31:47 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080779612-8091-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary On Wed, Mar 31, 2004 at 11:11:52AM -0600, Randall Stewart (cisco) wrote: > This is not so easy.. a simple return of socklen_t would not > work since you get back an array of the socket addresses.. not a > single address. > > Maybe we should, as Masahiro-san says, put an explicit > lenght indicator into the socket API... In a way, use a new struct(sockaddr * and socklen_t and the next pointer) as getaddrinfo(). This way isn't so difficult because sctp_freeaddrs() already exists, I think. Regards, Masahiro. -- {^-^}/@kozuka.jp / KOZUKA Masahiro ------------=_1080779612-8091-0-- From kacheong.poon@sun.com Wed Mar 31 22:24:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29385 for ; Wed, 31 Mar 2004 22:24:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8sow-0001fE-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:24:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8so0-0001cX-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:23:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B8snH-0001Uz-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:23:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2004 19:22:40 -0800 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 i313Lwew024139; Wed, 31 Mar 2004 19:21:59 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i313LWZ4010268 for sctp-impl-filtered; Wed, 31 Mar 2004 19:21:34 -0800 (PST) Message-Id: <200404010321.i313LWZ4010268@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080789692-10266-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_get[lp]addrs() and socklen_t List-Id: sctp-impl To: Jun-ichiro itojun Hagino From: Kacheong Poon Cc: "Randall Stewart (cisco)" , sctp-impl@external.cisco.com, KOZUKA Masahiro X-Nails-Approved: kacheong.poon@sun.com Date: Wed, 31 Mar 2004 19:20:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080789692-10266-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart (cisco) wrote: > Jun-ichiro itojun Hagino wrote: > >> sctp_get[lp]addrs() MUST return socket address length as socklen_t >> (just like accept()). otherwise you will not be able to support >> non AF_INET/INET6 address families. >> The question is do we really want to support non Internet address family. I don't think we want to. As a matter of fact, the current SCTP spec does not support non Internet address family. >> switch-case statement like http://www.sctp.org/archive/2015.html is >> exactly what we are trying to avoid. Note that there is no need to use the switch statement because the address length is pre-determined by the socket address family. The packed array in the -07 version of the draft is broken. It is removed from the -08 version. So each array element has a fixed size (sizeof (sockaddr_in) or (sockaddr_in6)). -- K. Poon. kacheong.poon@sun.com ------------=_1080789692-10266-0-- From kacheong.poon@sun.com Wed Mar 31 22:47:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00186 for ; Wed, 31 Mar 2004 22:47:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tBG-00032y-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:47:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tAG-0002zz-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:46:48 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8t9d-0002vB-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:46:09 -0500 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 i313jAKj027518; Wed, 31 Mar 2004 19:45:11 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i313isZ4010590 for sctp-impl-filtered; Wed, 31 Mar 2004 19:44:56 -0800 (PST) Message-Id: <200404010344.i313isZ4010590@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080791094-10582-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_get[lp]addrs() and socklen_t List-Id: sctp-impl To: Jun-ichiro itojun Hagino From: Kacheong Poon Cc: rrs@cisco.com, sctp-impl@external.cisco.com, ma-kun@kozuka.jp X-Nails-Approved: kacheong.poon@sun.com Date: Wed, 31 Mar 2004 19:44:02 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080791094-10582-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Jun-ichiro itojun Hagino wrote: > well, 20 years ago there was no AF_INET6. you cannot predict the > future so you should prepare for the future (there could be AF_INET7 > someday). socket API was lucky/clever as they always pass socklen_t > as a parameter. But the point is that even if there is an AF_INET7, there is still no need to add the switch statement. The reason is that the address length of each of the array element is pre-determined by the address family. So the program can just use it to pass to whatever socket call, e.g. getnameinfo() in the original mail. For example, a program wants to use both IPv4 and IPv6 addresses. It can always assume that the return address length of the sctp_get*addrs is sizeof (sockaddr_in6). When there is IPv7 and assuming that it provides the same compatibility mode as IPv6 (which I assume it has to), then the address length will be sizeof (sockaddr_in7). Of course, the assumption here is that Internet address is of fixed size. Note that we are talking about Internet address family here, not other address family, such as UNIX domain socket. -- K. Poon. kacheong.poon@sun.com ------------=_1080791094-10582-0-- From kacheong.poon@sun.com Wed Mar 31 22:56:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00489 for ; Wed, 31 Mar 2004 22:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tJx-0003e9-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:56:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tJ4-0003bX-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:55:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B8tIh-0003WP-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 22:55:31 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2004 19:55:09 -0800 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 i313sVBB017897; Wed, 31 Mar 2004 19:54:32 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i313sKZ4010710 for sctp-impl-filtered; Wed, 31 Mar 2004 19:54:22 -0800 (PST) Message-Id: <200404010354.i313sKZ4010710@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080791660-10708-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_get[lp]addrs() and socklen_t List-Id: sctp-impl To: Jun-ichiro itojun Hagino From: Kacheong Poon Cc: rrs@cisco.com, sctp-impl@external.cisco.com, ma-kun@kozuka.jp X-Nails-Approved: kacheong.poon@sun.com Date: Wed, 31 Mar 2004 19:53:30 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080791660-10708-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Jun-ichiro itojun Hagino wrote: > and note that we cannot always embed AF_x address into AF_y address. > IPv4 mapped address was just a special case. The interesting question to ask will be why there is a IPv4 mapped address notation for IPv6. I think the reason is that people want to provide ease of code migration. If in IPv7, people decided that there should not be any compatibility mode, then I think we can safely say that the program code itself has to be changed to deal with that. And the catch is that the sctp_get*addrs() still do not need to be changed as it will return an array of sockaddr_in7 addresses. I understand that if the address length of IPv7 is not fixed, the sctp_get*addrs() will fail to work. But I am not aware of such kind of address in real network architecture. Please correct me if I am wrong. If 100 years from now, people decide that it is a good thing to have, variable address length in network packets, then we are in trouble... But by then, I think we probably are not using SCTP anyway (-: -- K. Poon. kacheong.poon@sun.com ------------=_1080791660-10708-0-- From kacheong.poon@sun.com Wed Mar 31 23:09:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00952 for ; Wed, 31 Mar 2004 23:09:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tWe-0004Ui-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 23:09:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tVg-0004Qi-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 23:08:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8tUv-0004Iw-00 for sctp-impl-archive@ietf.org; Wed, 31 Mar 2004 23:08:09 -0500 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 i3147EUe023823; Wed, 31 Mar 2004 20:07:15 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i31473Z4010878 for sctp-impl-filtered; Wed, 31 Mar 2004 20:07:05 -0800 (PST) Message-Id: <200404010407.i31473Z4010878@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1080792423-10876-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: Just what does "new" mean ? List-Id: sctp-impl To: SCTP Discussion List From: Kacheong Poon X-Nails-Approved: kacheong.poon@sun.com Date: Wed, 31 Mar 2004 20:06:50 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1080792423-10876-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Brian F. G. Bidulock wrote: > Consider that when the packet arrives, to determine whether it is "new" or > "old" it must first have been received and buffered to be examined regardless > of the receiver window. If the system refuses to receive any packets beyond > the advertised receive window, it cannot follow the specification and make the > "new" vs. "old" determination. > > In fact, as I believe you mentioned in another mail on this thread, the > advertised window and available receive buffer space are not necessarily the > same thing. And in most implementations of TCP or SCTP they are not. The > already buffered packet is "charged" to the receive buffer (and window). No > resource allocation occurs at this point, just a resource accounting. The > packet is creditted to the IP queue and charged to the socket if you will. > > Although there are indeed less classical implementations, this is the typical > arrangement. Agreed. But we are talking about whether at the SCTP protocol level, the protocol engine should queue a new (we should stick with the obvious meaning of not yet received) packet when its receive window is full. We are not concerned in this discussion with the memory already allocated to hold the packet in a system. > My point is that if packets are not permitted to be receive, buffered and > examined by the socket even though the advertised receive window has fallen to > zero, then the implementation cannot conform to the specification. > > Consider also the zero window probe, which was the other thing that we debated > and resolved along with accepting packets after a_rwnd is zero. If an > implementation discards packets entirely when a_rwnd is zero, then it will be > unable to respond to zero window probes. It must buffer the packet and > examine it (beyond a_rwnd) to be able to discard and SACK it. I understand this point. But I think we should stick to the question of whether an SCTP stack should accept a new packet when its receive window is full. We can assume that the SCTP stack can actually look at the packet and determine that it is the destined recipient and the normal checks pass (CRC32c, verf tag...). > Tear-drop like attacks rely upon leaving holes and causing the receiver (or > sender) to allocate resources excessively. I don't mean the neo-classical > tear-drop attack (where resources are unwisely allocated unbounded for the > gaps rather), but a situation where the described scenario can be used by > an attacker to cause an implementation to overcommit resources. This is what I guessed. > Consider, for examle, an HTTP server with similar receive characeteristics > to those described by Adreas. Upon connection, the attacker intentionally > skips TSN 1 and then sends data until the advertised receive window falls to > zero. As the HTTP server sits on the socket waiting for data, and data > indications will not be forthcoming (make all the packets segments of a single > unit data) the service process is hung for a period and the memory allocation > for the receive buffer is frozen. If the server is overcommitting memory on > receive buffers, repetitions of this procedure in a not unreasonably short > period will result in denial of service. > > If the receiver does not include allocations necessary to maintain gaps in the > receive window (or buffer) accounting, it could be possible to introduce gaps > that cause the memory allocation to grow excessively if not unbounded. > Consider sending a 1 byte data chunks, skipping a TSN, sending another 1 byte > data chunks, skipping a TSN, and so on. If there is no hard limit on > overheads require to track gaps, a problem will occur. OK. > I refer to these as tear-drop attacks because they all rely on the same > principle as the neo-classical TCP tear-drop attack. In the neo-classical TCP > tear-drop attack, an implementation that allocates memory for missing segments > without consideration for window or buffer limits are susceptible to the > attack in sending a kiss of death segment which skips large extents of > intervening segments, causing buffer overflow. > > If any resource is allocated for intervening missing TSNs, an attacker might > be able to send a TSN far advanced from the cumulative ack point and cause an > allocation overflow. > > Perhaps I am wrong to call these tear-drops, but perhaps my meaning is more > clear now. > > Renegging (or aborting of course) is a way of freeing resources associated > with things not directly related to advancing the cumulative ack point. All > of these types of attacks depend upon allocating, overallocating, or freezing > resources that do not advance the cummulativve ack point. Renegging when the > limit is reached is a simple way of thwarting these types of attacks. I understand your point. And there are many ways to deal with this kind of attack. For example, the app layer time out as I mentioned in the previous mail can help. Or the SCTP layer can decide to free up some packets as you suggested. My point is that the stack does not need to do this defense only when the receive window is full. If the memory resource is tight, the SCTP layer may decide not to queue any out of order packets. What we are dealing with here is that at the protocol level, SCTP should not accept new packets when its receive window is full. We need to make sure that no conforming SCTP implementation will hit the dead lock situation discussed so far. If this is true, then we can think of whether good SCTP implementations should accommodate non-conforming implementations. And I don't think this has to be tied to the attack you mentioned above. -- K. Poon. kacheong.poon@sun.com ------------=_1080792423-10876-0--

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome