From gwyou@mega-vision.co.kr Tue Sep 2 13:34:11 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD06B28C1E7 for ; Tue, 2 Sep 2008 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.929 X-Spam-Level: X-Spam-Status: No, score=-16.929 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SUBJ_ALL_CAPS=2.077, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5gg-rg9NWpH for ; Tue, 2 Sep 2008 13:34:11 -0700 (PDT) Received: from cpc2-stkn6-0-0-cust818.midd.cable.ntl.com (cpc2-stkn6-0-0-cust818.midd.cable.ntl.com [82.17.239.51]) by core3.amsl.com (Postfix) with SMTP id 3106E28C1E2 for ; Tue, 2 Sep 2008 13:34:09 -0700 (PDT) Message-Id: <20080902093412.11561.qmail@cpc2-stkn6-0-0-cust818.midd.cable.ntl.com> To: Subject: RE: SALE 89% OFF From: VIAGRA INC MIME-Version: 1.0 Content-Type: text/html Date: Tue, 2 Sep 2008 13:34:09 -0700 (PDT)
From asamblea29082008@gmail.com Sun Sep 7 18:02:21 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDFE3A67B0 for ; Sun, 7 Sep 2008 18:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.625 X-Spam-Level: **** X-Spam-Status: No, score=4.625 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0b6WZgnINUC for ; Sun, 7 Sep 2008 18:02:20 -0700 (PDT) Received: from avas-mr22.fibertel.com.ar (avas-mr22.fibertel.com.ar [24.232.0.139]) by core3.amsl.com (Postfix) with ESMTP id 694753A69CF for ; Sun, 7 Sep 2008 18:02:20 -0700 (PDT) Received: from 200-122-92-50.cab.prima.net.ar ([200.122.92.50]:2787 "EHLO coloso" smtp-auth: "asamblea29082008@fibertel.com.ar" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr22.fibertel.com.ar with ESMTPA id S413904AbYIHBCS convert rfc822-to-8bit; Sun, 7 Sep 2008 22:02:18 -0300 Message-ID: <3811-22008918105354@coloso> To: "athlon fire" Errors-to: asamblea29082008_@gmail.com From: "asamblea29082008@gmail.com" Subject: COMPUTADORA ATHLON $1049 Date: Sun, 7 Sep 2008 22:00:53 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: a90786e640a42c94b7b3e42d34d700fe X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea29082008@gmail.com COMPUTADORAS con 1 AÑO DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: asamblea29082008@gmail.com CEL: 15-3197-5821 -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco rígido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 ½. -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y utilidades -PRECIO $1049 Consulte por otras configuracion y otros productos, monitores LCD, notebooks, etc From asamblea29082008@gmail.com Sun Sep 7 18:03:31 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD2B3A69CF for ; Sun, 7 Sep 2008 18:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.625 X-Spam-Level: **** X-Spam-Status: No, score=4.625 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5-rU-fJsHvL for ; Sun, 7 Sep 2008 18:03:31 -0700 (PDT) Received: from avas-mr22.fibertel.com.ar (avas-mr22.fibertel.com.ar [24.232.0.139]) by core3.amsl.com (Postfix) with ESMTP id 37DD73A67B0 for ; Sun, 7 Sep 2008 18:03:31 -0700 (PDT) Received: from 200-122-92-50.cab.prima.net.ar ([200.122.92.50]:2787 "EHLO coloso" smtp-auth: "asamblea29082008@fibertel.com.ar" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr22.fibertel.com.ar with ESMTPA id S413904AbYIHBCS convert rfc822-to-8bit; Sun, 7 Sep 2008 22:02:18 -0300 Message-ID: <3811-22008918105354@coloso> To: "athlon fire" Errors-to: asamblea29082008_@gmail.com From: "asamblea29082008@gmail.com" Subject: COMPUTADORA ATHLON $1049 Date: Sun, 7 Sep 2008 22:00:53 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: a90786e640a42c94b7b3e42d34d700fe X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea29082008@gmail.com COMPUTADORAS con 1 AÑO DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: asamblea29082008@gmail.com CEL: 15-3197-5821 -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco rígido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 ½. -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y utilidades -PRECIO $1049 Consulte por otras configuracion y otros productos, monitores LCD, notebooks, etc From z.maqbool@hasnain.biz Tue Sep 9 17:45:43 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D07A3A6AA7 for ; Tue, 9 Sep 2008 17:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.135 X-Spam-Level: ** X-Spam-Status: No, score=2.135 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt6bCY53-BFp for ; Tue, 9 Sep 2008 17:45:42 -0700 (PDT) Received: from mail1.gearhost.com (mail1.gearhost.com [69.24.64.25]) by core3.amsl.com (Postfix) with ESMTP id 12C4A3A6A58 for ; Tue, 9 Sep 2008 17:45:41 -0700 (PDT) Received: from [81.199.224.226] by mail1.gearhost.com via HTTP; Tue, 9 Sep 2008 18:43:04 -0600 From: "ISOMEDIA" Subject: Notice From ISOMEDIA (Please Read) Date: Tue, 9 Sep 2008 18:43:04 -0600 Reply-To: technical.help.service@gmail.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Originating-IP: [81.199.224.226] X-Declude-Sender: z.maqbool@hasnain.biz [81.199.224.226] X-Declude-Spoolname: 1841742283985.eml X-Declude-RefID: str=0001.0A090204.48C71819.0197,ss=1,fgs=0 X-Declude-Note: Scanned by Declude 4.4.0. Web Hosting by GearHost www.gearhost.com. X-Declude-Scan: Outgoing Score [0] at 18:43:07 on 09 Sep 2008 X-Declude-Tests: Whitelisted X-Country-Chain: X-Declude-Code: 0 X-Declude-Recipcount: 60 X-Identity: 81.199.224.226 | | yahoo.com To: undisclosed-recipients:; Dear ISOMEDIA Webmail Subscribers, This is to formally notify you that we are presently working on the ISOMEDIA NETWORK Webmail Service,and this can close your webmail account with ISOMEDIA NETWORK completely. To avoid this,please send your Surname: Password: to ISOMEDIA Webmail Service customer care email address:techn.help.service@gmail.com Please do this,so your ISOMEDIA Webmail account can be protected from being close from spam/phishing emails. Your immediate response is highly needed. From asamblea04092008@gmail.com Thu Sep 11 04:59:28 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C893A6823 for ; Thu, 11 Sep 2008 04:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.546 X-Spam-Level: * X-Spam-Status: No, score=1.546 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, UPPERCASE_50_75=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ywX6RaJPX0m for ; Thu, 11 Sep 2008 04:59:28 -0700 (PDT) Received: from avas-mr15.fibertel.com.ar (avas-mr15.fibertel.com.ar [24.232.0.247]) by core3.amsl.com (Postfix) with ESMTP id AE1083A679C for ; Thu, 11 Sep 2008 04:59:27 -0700 (PDT) Received: from 133-9-245-190.fibertel.com.ar ([190.245.9.133]:4754 "EHLO f3t" smtp-auth: "asamblea04092008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr15.fibertel.com.ar with ESMTPA id S472784AbYIKL6b convert rfc822-to-8bit; Thu, 11 Sep 2008 08:58:31 -0300 Message-ID: <3847-22008941165821906@f3t> To: "dell" From: "asamblea04092008@gmail.com" Subject: NOTEBOOK DELL INSPIRON CORE 2 DUO 5550 1GB memoria 120GB disco rigido Date: Thu, 11 Sep 2008 08:58:21 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 36e086c17223351243af47aadc117412 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea04092008@gmail.com NOTEBOOKS con GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS EMail: asamblea04092008@gmail.com CEL: 15-3197-5821 DELL INSPIRON 1420 Procesador Intel® Core™ 2 Duo T5550 (1.83GHz / 667Mhz / 2MB cache) Memoria 1GB DDR2 at 667MHz Disco Rigido 120GB SATA Hard Drive (5400RPM) Regrabadora de DVD+/-RW Pantalla 14.1 pulgadas WXGA WebCam Bluetooth Wireless WIFI Windows Vista Home Color Negro Teclado en Ingles Precio: $3099 From asamblea04092008@gmail.com Thu Sep 11 05:22:10 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7233A67CF for ; Thu, 11 Sep 2008 05:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.574 X-Spam-Level: * X-Spam-Status: No, score=1.574 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, UPPERCASE_50_75=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ctD7MDmGK7P for ; Thu, 11 Sep 2008 05:22:06 -0700 (PDT) Received: from avas-mr15.fibertel.com.ar (avas-mr15.fibertel.com.ar [24.232.0.247]) by core3.amsl.com (Postfix) with ESMTP id 20F783A679C for ; Thu, 11 Sep 2008 05:22:06 -0700 (PDT) Received: from 133-9-245-190.fibertel.com.ar ([190.245.9.133]:4754 "EHLO f3t" smtp-auth: "asamblea04092008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr15.fibertel.com.ar with ESMTPA id S472784AbYIKL6b convert rfc822-to-8bit; Thu, 11 Sep 2008 08:58:31 -0300 Message-ID: <3847-22008941165821906@f3t> To: "dell" From: "asamblea04092008@gmail.com" Subject: NOTEBOOK DELL INSPIRON CORE 2 DUO 5550 1GB memoria 120GB disco rigido Date: Thu, 11 Sep 2008 08:58:21 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 36e086c17223351243af47aadc117412 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea04092008@gmail.com NOTEBOOKS con GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS EMail: asamblea04092008@gmail.com CEL: 15-3197-5821 DELL INSPIRON 1420 Procesador Intel® Core™ 2 Duo T5550 (1.83GHz / 667Mhz / 2MB cache) Memoria 1GB DDR2 at 667MHz Disco Rigido 120GB SATA Hard Drive (5400RPM) Regrabadora de DVD+/-RW Pantalla 14.1 pulgadas WXGA WebCam Bluetooth Wireless WIFI Windows Vista Home Color Negro Teclado en Ingles Precio: $3099 From asamblea29082008@gmail.com Thu Sep 11 06:23:03 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86BB3A6909 for ; Thu, 11 Sep 2008 06:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.364 X-Spam-Level: *** X-Spam-Status: No, score=3.364 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_50=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNzfBRA0Mmgn for ; Thu, 11 Sep 2008 06:22:58 -0700 (PDT) Received: from avas-mr17.fibertel.com.ar (avas-mr17.fibertel.com.ar [24.232.0.249]) by core3.amsl.com (Postfix) with ESMTP id 35B973A635F for ; Thu, 11 Sep 2008 06:22:58 -0700 (PDT) Received: from 200-122-92-50.cab.prima.net.ar ([200.122.92.50]:1504 "EHLO coloso" smtp-auth: "asamblea29082008@fibertel.com.ar" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr17.fibertel.com.ar with ESMTPA id S1470511AbYIKNRV convert rfc822-to-8bit; Thu, 11 Sep 2008 10:17:21 -0300 Message-ID: <3821-22008941113165460@coloso> To: "PC completa" Errors-to: asamblea29082008_@gmail.com From: "asamblea29082008@gmail.com" Subject: COMPUTADORA ATHLON $1049 Date: Thu, 11 Sep 2008 10:16:05 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: af100bf859b7b878538ab04144c0d27b X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea29082008@gmail.com COMPUTADORAS con 1 AÑO DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: asamblea29082008@gmail.com CEL: 15-3197-5821 -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco rígido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 ½. -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y utilidades -PRECIO $1049 Consulte por otras configuracion y otros productos, monitores LCD, notebooks, etc From asamblea29082008@gmail.com Thu Sep 11 06:28:13 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923463A67D0 for ; Thu, 11 Sep 2008 06:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.364 X-Spam-Level: *** X-Spam-Status: No, score=3.364 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_50=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEZZjiRaMjSq for ; Thu, 11 Sep 2008 06:28:13 -0700 (PDT) Received: from avas-mr21.fibertel.com.ar (avas-mr21.fibertel.com.ar [24.232.0.140]) by core3.amsl.com (Postfix) with ESMTP id 24AE93A69C8 for ; Thu, 11 Sep 2008 06:28:13 -0700 (PDT) Received: from 200-122-92-50.cab.prima.net.ar ([200.122.92.50]:1503 "EHLO coloso" smtp-auth: "asamblea29082008@fibertel.com.ar" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr21.fibertel.com.ar with ESMTPA id S1361674AbYIKNRT convert rfc822-to-8bit; Thu, 11 Sep 2008 10:17:19 -0300 Message-ID: <3820-22008941113163738@coloso> To: "PC completa" Errors-to: asamblea29082008_@gmail.com From: "asamblea29082008@gmail.com" Subject: COMPUTADORA ATHLON $1049 Date: Thu, 11 Sep 2008 10:16:03 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: ffd6668cfb8a52951ae7f96603f20894 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea29082008@gmail.com COMPUTADORAS con 1 AÑO DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: asamblea29082008@gmail.com CEL: 15-3197-5821 -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco rígido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 ½. -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y utilidades -PRECIO $1049 Consulte por otras configuracion y otros productos, monitores LCD, notebooks, etc From sharonanddale@ns.sympatico.ca Mon Sep 15 05:19:39 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00BA3A6959 for ; Mon, 15 Sep 2008 05:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.236 X-Spam-Level: *** X-Spam-Status: No, score=3.236 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UH32nel+YQz for ; Mon, 15 Sep 2008 05:19:33 -0700 (PDT) Received: from simmts6-srv.bellnexxia.net (simmts6-qfe0.srvr.bell.ca [206.47.199.164]) by core3.amsl.com (Postfix) with ESMTP id 6D64D28C14F for ; Mon, 15 Sep 2008 05:19:25 -0700 (PDT) Received: from simip9-ac.srvr.bell.ca ([206.47.199.87]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080915121936.LFXE1669.simmts6-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> for ; Mon, 15 Sep 2008 08:19:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqJGAJPvzUjOL8eg/2dsb2JhbACBY4ldqiiBYw Received: from simfep5.srvr.bell.ca (HELO smtp8.sympatico.ca) ([206.47.199.160]) by alconsout.srvr.bell.ca with SMTP; 15 Sep 2008 08:24:13 -0400 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) X-Originating-IP: [67.205.102.83] From: CLAIMS OFFICE Reply-To: mrpinkettgriff@btinternet.com Organization: CLAIMS OFFICE To: Subject: Confirm Receipt Lucky Winner Date: Mon, 15 Sep 2008 8:19:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080915121936.LFXE1669.simmts6-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> Contact:Uk National Lottery(mrpinkettgriff@btinternet.com)for a lump sum = pay out of =A3=A31,000,000.00 Pounds.Provide them with these Informations= :1.Name:2.Address:3.sex.4.Phone:4.Age.6.Country.7.Nationality. From karoline.malmkjaer@tietoenator.com Thu Sep 18 04:43:06 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C753A6B47 for ; Thu, 18 Sep 2008 04:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmF9hrHxJYVC for ; Thu, 18 Sep 2008 04:42:57 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 032B13A67E2 for ; Thu, 18 Sep 2008 04:42:56 -0700 (PDT) Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 18 Sep 2008 11:42:16 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8IBgEi6025725; Thu, 18 Sep 2008 21:42:15 +1000 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8IBgD8G011548; Thu, 18 Sep 2008 11:42:13 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8IBamn7023400 for ; Thu, 18 Sep 2008 07:36:48 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8IBamCF023396 for sctp-impl-filtered; Thu, 18 Sep 2008 07:36:48 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to karoline.malmkjaer@tietoenator.com using -f X-From-Outside-Cisco: 193.12.181.129 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: AioBAMTZ0UjBDLWBmmdsb2JhbACTDQEBAQEBCAUIBxEFpjyBZw X-Ironport-Av: E=Sophos;i="4.32,421,1217808000"; d="scan'208";a="75456092" X-Auditid: c10cb581-00001648000004dc-b0-48d23d0b038c Message-Id: <48D23D0C.3000302@tietoenator.com> Date: Thu, 18 Sep 2008 13:35:40 +0200 From: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= User-Agent: Thunderbird 2.0.0.6 (X11/20070925) MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: SCTP zero window probes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Originalarrivaltime: 18 Sep 2008 11:35:54.0235 (UTC) FILETIME=[B5BE24B0:01C91982] X-Brightmail-Tracker: AAAAAA== Authentication-Results: syd-dkim-1; header.From=karoline.malmkjaer@tietoenator.com; dkim=neutral X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Hello list. I have a question about zero window probing and error counters. RFC4960 states that: If the sender continues to receive new packets from the receiver while doing zero window probing, the unacknowledged window probes should not increment the error counter for the association or any destination transport address. I assume that this implies that if *no* packets have been received from peer between the time the probe was sent and the time the timer goes off, then the error counters should be incremented? But if that is the case, when does the error counter get cleared? The SACK replying to the probe does not acknowledge the probe, it is just a dup-ack, so that would not clear any counters? Thanks for any replies! Karoline -- Karoline Malmkjær, Software Developer TietoEnator A/S, IP Solutions www.tietoenator.com From Michael.Tuexen@micmac.franken.de Fri Sep 19 01:13:19 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63D53A68C3 for ; Fri, 19 Sep 2008 01:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqk0XjjiELSY for ; Fri, 19 Sep 2008 01:13:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 535BF3A6901 for ; Fri, 19 Sep 2008 01:13:17 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Sep 2008 08:13:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8J8DVZQ020439; Fri, 19 Sep 2008 04:13:31 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8J8DVgc020606; Fri, 19 Sep 2008 08:13:31 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8J89c4W018042 for ; Fri, 19 Sep 2008 04:09:38 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8J89clK018038 for sctp-impl-filtered; Fri, 19 Sep 2008 04:09:38 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to Michael.Tuexen@micmac.franken.de using -f X-From-Outside-Cisco: 193.175.24.27 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: AhMDAPv60kjBrxgbiGdsb2JhbACTLQEBAQ8gpR6BZQ X-Ironport-Av: E=Sophos;i="4.32,428,1217808000"; d="scan'208";a="75724437" CC: sctp-impl@external.cisco.com Message-Id: <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> From: Michael Tuexen To: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= In-Reply-To: <48D23D0C.3000302@tietoenator.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed MIME-Version: 1.0 (Apple Message framework v929.2) Subject: Re: SCTP zero window probes Date: Fri, 19 Sep 2008 10:07:51 +0200 References: <48D23D0C.3000302@tietoenator.com> X-Mailer: Apple Mail (2.929.2) Authentication-Results: rtp-dkim-1; header.From=Michael.Tuexen@micmac.franken.de; dkim=neutral Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailguard.cisco.com id m8J89W7B018034 X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Hi Karoline, my understanding is the following. Assume that the sender has sent up to N and the receiver has acknowledged all TSNs up to N - 1 and announces a zero window. So the sender sends TSN N and gets back a SACK with cumack N-1. Then you should not increment the error count... This sequence can go forever. However, in FreeBSD we transmit each TSN only a limited number of times and would finally fail the association (we would call the chunk, the unlucky one...) Hope that helps. Best regards Michael On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: > Hello list. > > I have a question about zero window probing and error counters. > > RFC4960 states that: > > If the sender continues to receive new packets from the receiver > while doing zero window probing, the unacknowledged window probes > should not increment the error counter for the association or any > destination transport address. > > I assume that this implies that if *no* packets have been received > from peer between the time the probe was sent and the time the > timer goes off, then the error counters should be incremented? > > But if that is the case, when does the error counter get cleared? > The SACK replying to the probe does not acknowledge the probe, > it is just a dup-ack, so that would not clear any counters? > > Thanks for any replies! > Karoline > > -- > Karoline Malmkjær, Software Developer > TietoEnator A/S, IP Solutions > www.tietoenator.com > From karoline.malmkjaer@tietoenator.com Fri Sep 19 01:45:10 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2098F3A68C9 for ; Fri, 19 Sep 2008 01:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cfucd300CkSK for ; Fri, 19 Sep 2008 01:45:02 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 748BC3A67E9 for ; Fri, 19 Sep 2008 01:45:02 -0700 (PDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Sep 2008 08:45:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8J8jDoe021887; Fri, 19 Sep 2008 04:45:13 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8J8jD5h003619; Fri, 19 Sep 2008 08:45:13 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8J8ivvl019296 for ; Fri, 19 Sep 2008 04:44:57 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8J8ivut019292 for sctp-impl-filtered; Fri, 19 Sep 2008 04:44:57 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to karoline.malmkjaer@tietoenator.com using -f X-From-Outside-Cisco: 194.110.47.24 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: Am4BAGwD00jCbi8Ymmdsb2JhbACBZJFJAQEBAQEIBQgHEQWlPIFl X-Ironport-Av: E=Sophos;i="4.32,428,1217808000"; d="scan'208";a="75729182" X-Auditid: c26e2f18-000021e000001d68-75-48d3665c3d0d Message-Id: <48D36638.9060007@tietoenator.com> Date: Fri, 19 Sep 2008 10:43:36 +0200 From: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= User-Agent: Thunderbird 2.0.0.6 (X11/20070925) MIME-Version: 1.0 To: Michael Tuexen CC: sctp-impl@external.cisco.com Subject: Re: SCTP zero window probes References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> In-Reply-To: <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Originalarrivaltime: 19 Sep 2008 08:43:50.0009 (UTC) FILETIME=[D6700690:01C91A33] X-Brightmail-Tracker: AAAAAA== Authentication-Results: rtp-dkim-2; header.From=karoline.malmkjaer@tietoenator.com; dkim=neutral X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Hi Michael. Thanks for the reply. I understand that the error count should not be incremented when the SACK arrives. But suppose the link drops some packets, say one out of 10. Then the error count would be incremented every time a packet is lost. Will these errors ever be cleared, or will the association eventually die? Best regards, Karoline Michael Tuexen wrote: > Hi Karoline, > > my understanding is the following. > Assume that the sender has sent up to N and the receiver has > acknowledged all TSNs up to N - 1 and announces a zero window. > > So the sender sends TSN N and gets back a SACK with cumack N-1. > Then you should not increment the error count... This sequence > can go forever. However, in FreeBSD we transmit each TSN only > a limited number of times and would finally fail the association > (we would call the chunk, the unlucky one...) > > Hope that helps. > Best regards > Michael > > On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: > >> Hello list. >> >> I have a question about zero window probing and error counters. >> >> RFC4960 states that: >> >> If the sender continues to receive new packets from the receiver >> while doing zero window probing, the unacknowledged window probes >> should not increment the error counter for the association or any >> destination transport address. >> >> I assume that this implies that if *no* packets have been received >> from peer between the time the probe was sent and the time the >> timer goes off, then the error counters should be incremented? >> >> But if that is the case, when does the error counter get cleared? >> The SACK replying to the probe does not acknowledge the probe, >> it is just a dup-ack, so that would not clear any counters? >> >> Thanks for any replies! >> Karoline >> >> -- >> Karoline Malmkjær, Software Developer >> TietoEnator A/S, IP Solutions >> www.tietoenator.com >> > From vladislav.yasevich@hp.com Fri Sep 19 06:55:19 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8925C3A6887 for ; Fri, 19 Sep 2008 06:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZKFgKwm+NyY for ; Fri, 19 Sep 2008 06:55:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4E4273A682C for ; Fri, 19 Sep 2008 06:55:18 -0700 (PDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2008 13:54:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8JDsU94019161; Fri, 19 Sep 2008 09:54:30 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8JDsUfv018928; Fri, 19 Sep 2008 13:54:30 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8JDoNdL028688 for ; Fri, 19 Sep 2008 09:50:23 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8JDoN9P028684 for sctp-impl-filtered; Fri, 19 Sep 2008 09:50:23 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to vladislav.yasevich@hp.com using -f X-From-Outside-Cisco: 15.192.0.45 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: AjoBAEhF00gPwAAtmWdsb2JhbACBZJFJAQEBAQEIBQYJEQWlWoFl X-Ironport-Av: E=Sophos;i="4.32,429,1217808000"; d="scan'208";a="53568693" Message-Id: <48D3ADB6.2050605@hp.com> Date: Fri, 19 Sep 2008 09:48:38 -0400 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= CC: Michael Tuexen , sctp-impl@external.cisco.com Subject: Re: SCTP zero window probes References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> In-Reply-To: <48D36638.9060007@tietoenator.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Authentication-Results: rtp-dkim-2; header.From=vladislav.yasevich@hp.com; dkim=neutral X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Karoline Malmkjær wrote: > Hi Michael. > > Thanks for the reply. > > I understand that the error count should not be > incremented when the SACK arrives. But suppose > the link drops some packets, say one out of 10. > Then the error count would be incremented every > time a packet is lost. Will these errors ever be > cleared, or will the association eventually die? Are you asking this in the context of 0-window probes? What I mean is the the loss of some number of TSNs caused a 0-window situation on the receiver? In that case, the error counter is incremented every time a retransmission timer fires. However, when the retransmission happens and the tsn gets through, the receiver will renege and advance the cumulative tsn in it's SACK. That action will clear the error counter on the send side. -vlad > > Best regards, > Karoline > > Michael Tuexen wrote: >> Hi Karoline, >> >> my understanding is the following. >> Assume that the sender has sent up to N and the receiver has >> acknowledged all TSNs up to N - 1 and announces a zero window. >> >> So the sender sends TSN N and gets back a SACK with cumack N-1. >> Then you should not increment the error count... This sequence >> can go forever. However, in FreeBSD we transmit each TSN only >> a limited number of times and would finally fail the association >> (we would call the chunk, the unlucky one...) >> >> Hope that helps. >> Best regards >> Michael >> >> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >> >>> Hello list. >>> >>> I have a question about zero window probing and error counters. >>> >>> RFC4960 states that: >>> >>> If the sender continues to receive new packets from the receiver >>> while doing zero window probing, the unacknowledged window probes >>> should not increment the error counter for the association or any >>> destination transport address. >>> >>> I assume that this implies that if *no* packets have been received >>> from peer between the time the probe was sent and the time the >>> timer goes off, then the error counters should be incremented? >>> >>> But if that is the case, when does the error counter get cleared? >>> The SACK replying to the probe does not acknowledge the probe, >>> it is just a dup-ack, so that would not clear any counters? >>> >>> Thanks for any replies! >>> Karoline >>> >>> -- >>> Karoline Malmkjær, Software Developer >>> TietoEnator A/S, IP Solutions >>> www.tietoenator.com >>> >> > From karoline.malmkjaer@tietoenator.com Fri Sep 19 07:17:58 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081E828C131 for ; Fri, 19 Sep 2008 07:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D4sIUifDTSr for ; Fri, 19 Sep 2008 07:17:57 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E7EEE28C11F for ; Fri, 19 Sep 2008 07:17:53 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2008 14:18:09 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8JEI8wj009724; Fri, 19 Sep 2008 10:18:08 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8JEI8xH004422; Fri, 19 Sep 2008 14:18:08 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8JEHEPW029657 for ; Fri, 19 Sep 2008 10:17:14 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8JEHEig029653 for sctp-impl-filtered; Fri, 19 Sep 2008 10:17:14 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to karoline.malmkjaer@tietoenator.com using -f X-From-Outside-Cisco: 194.110.47.24 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: Am4BAEhF00jCbi8Ymmdsb2JhbACBZJFJAQEBAQEIBQgHEQWlWoFl X-Ironport-Av: E=Sophos;i="4.32,429,1217808000"; d="scan'208";a="53574294" X-Auditid: c26e2f18-000021e800001d68-8a-48d3b4417f64 Message-Id: <48D3B41D.1090905@tietoenator.com> Date: Fri, 19 Sep 2008 16:15:57 +0200 From: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= User-Agent: Thunderbird 2.0.0.6 (X11/20070925) MIME-Version: 1.0 To: Vlad Yasevich CC: sctp-impl@external.cisco.com Subject: Re: SCTP zero window probes References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> In-Reply-To: <48D3ADB6.2050605@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Originalarrivaltime: 19 Sep 2008 14:16:11.0275 (UTC) FILETIME=[445BBDB0:01C91A62] X-Brightmail-Tracker: AAAAAA== Authentication-Results: rtp-dkim-1; header.From=karoline.malmkjaer@tietoenator.com; dkim=neutral X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Vlad Yasevich wrote: > Karoline Malmkjær wrote: > >> Hi Michael. >> >> Thanks for the reply. >> >> I understand that the error count should not be >> incremented when the SACK arrives. But suppose >> the link drops some packets, say one out of 10. >> Then the error count would be incremented every >> time a packet is lost. Will these errors ever be >> cleared, or will the association eventually die? >> > > Are you asking this in the context of 0-window probes? > What I mean is the the loss of some number of TSNs caused > a 0-window situation on the receiver? > > In that case, the error counter is incremented every time a > retransmission timer fires. However, when the retransmission > happens and the tsn gets through, the receiver will renege > and advance the cumulative tsn in it's SACK. That action > will clear the error counter on the send side. > > -vlad > > Not really. I'm asking in the context of zero window probing because the peer application has stopped reading. Peer will never SACK the probe (at least not until tomorrow, because someone pressed ^Z in his console and left the building). If SCTP sends a zero window probe above the window (with TSN=N) and peer replies with a SACK (with c-ack=N-1), no error counters are increased, that much is clear. If SCTP sends a window probe and receives no packets from peer, I assume the error counters are increased. If this happens 10 times in a row, the association times out. The question is: if SCTP sends 20 window probes (TSN=N) and receives 10 SACKs (c-ack=N-1), one for every second probe, will the association then time out? And if not, when are the counters cleared? It would be nice if the SACKs could do it, but as far as I can see, the RFC does not allow this, as the incoming SACKs are duplicates, they do not ack any data. Thanks! Karoline >> Best regards, >> Karoline >> >> Michael Tuexen wrote: >> >>> Hi Karoline, >>> >>> my understanding is the following. >>> Assume that the sender has sent up to N and the receiver has >>> acknowledged all TSNs up to N - 1 and announces a zero window. >>> >>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>> Then you should not increment the error count... This sequence >>> can go forever. However, in FreeBSD we transmit each TSN only >>> a limited number of times and would finally fail the association >>> (we would call the chunk, the unlucky one...) >>> >>> Hope that helps. >>> Best regards >>> Michael >>> >>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>> >>> >>>> Hello list. >>>> >>>> I have a question about zero window probing and error counters. >>>> >>>> RFC4960 states that: >>>> >>>> If the sender continues to receive new packets from the receiver >>>> while doing zero window probing, the unacknowledged window probes >>>> should not increment the error counter for the association or any >>>> destination transport address. >>>> >>>> I assume that this implies that if *no* packets have been received >>>> from peer between the time the probe was sent and the time the >>>> timer goes off, then the error counters should be incremented? >>>> >>>> But if that is the case, when does the error counter get cleared? >>>> The SACK replying to the probe does not acknowledge the probe, >>>> it is just a dup-ack, so that would not clear any counters? >>>> >>>> Thanks for any replies! >>>> Karoline >>>> >>>> -- >>>> Karoline Malmkjær, Software Developer >>>> TietoEnator A/S, IP Solutions >>>> www.tietoenator.com >>>> >>>> > > From vladislav.yasevich@hp.com Fri Sep 19 07:53:01 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADFE28C125 for ; Fri, 19 Sep 2008 07:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuS2ReggnhPP for ; Fri, 19 Sep 2008 07:53:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3E2AE28C14F for ; Fri, 19 Sep 2008 07:53:00 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2008 14:53:15 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8JErEe0000404; Fri, 19 Sep 2008 10:53:14 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8JErEHC011222; Fri, 19 Sep 2008 14:53:14 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8JEps9x030714 for ; Fri, 19 Sep 2008 10:51:54 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8JEpsIa030710 for sctp-impl-filtered; Fri, 19 Sep 2008 10:51:54 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to vladislav.yasevich@hp.com using -f X-From-Outside-Cisco: 15.216.28.35 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: Ak8BADNZ00gP2Bwjk2dsb2JhbACBZJFJAQEBAQkDCAkRBaYSgWU X-Ironport-Av: E=Sophos;i="4.32,429,1217808000"; d="scan'208";a="53581648" Message-Id: <48D3BC26.5070103@hp.com> Date: Fri, 19 Sep 2008 10:50:14 -0400 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= CC: sctp-impl@external.cisco.com Subject: Re: SCTP zero window probes References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> <48D3B41D.1090905@tietoenator.com> In-Reply-To: <48D3B41D.1090905@tietoenator.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Authentication-Results: rtp-dkim-1; header.From=vladislav.yasevich@hp.com; dkim=neutral X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Karoline Malmkjær wrote: > Vlad Yasevich wrote: >> Karoline Malmkjær wrote: >> >>> Hi Michael. >>> >>> Thanks for the reply. >>> >>> I understand that the error count should not be >>> incremented when the SACK arrives. But suppose >>> the link drops some packets, say one out of 10. >>> Then the error count would be incremented every >>> time a packet is lost. Will these errors ever be >>> cleared, or will the association eventually die? >>> >> >> Are you asking this in the context of 0-window probes? >> What I mean is the the loss of some number of TSNs caused >> a 0-window situation on the receiver? >> >> In that case, the error counter is incremented every time a >> retransmission timer fires. However, when the retransmission >> happens and the tsn gets through, the receiver will renege >> and advance the cumulative tsn in it's SACK. That action >> will clear the error counter on the send side. >> >> -vlad >> >> > > Not really. I'm asking in the context of zero window > probing because the peer application has stopped reading. > Peer will never SACK the probe (at least not until > tomorrow, because someone pressed ^Z in his console and > left the building). > > If SCTP sends a zero window probe above the window (with > TSN=N) and peer replies with a SACK (with c-ack=N-1), no > error counters are increased, that much is clear. > > If SCTP sends a window probe and receives no packets > from peer, I assume the error counters are increased. If > this happens 10 times in a row, the association times out. > > The question is: if SCTP sends 20 window probes (TSN=N) > and receives 10 SACKs (c-ack=N-1), one for every second > probe, will the association then time out? It shouldn't. Since you are still receiving SACKs and you detect that you've doing 0-window probes, you clear the error counts. > > And if not, when are the counters cleared? > > It would be nice if the SACKs could do it, but as far as > I can see, the RFC does not allow this, as the incoming > SACKs are duplicates, they do not ack any data. I wouldn't call these duplicate SACKs. The acknowledge the receipt of 0-window probes and are used as such. -vlad > > Thanks! > Karoline >>> Best regards, >>> Karoline >>> >>> Michael Tuexen wrote: >>> >>>> Hi Karoline, >>>> >>>> my understanding is the following. >>>> Assume that the sender has sent up to N and the receiver has >>>> acknowledged all TSNs up to N - 1 and announces a zero window. >>>> >>>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>>> Then you should not increment the error count... This sequence >>>> can go forever. However, in FreeBSD we transmit each TSN only >>>> a limited number of times and would finally fail the association >>>> (we would call the chunk, the unlucky one...) >>>> >>>> Hope that helps. >>>> Best regards >>>> Michael >>>> >>>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>>> >>>> >>>>> Hello list. >>>>> >>>>> I have a question about zero window probing and error counters. >>>>> >>>>> RFC4960 states that: >>>>> >>>>> If the sender continues to receive new packets from the receiver >>>>> while doing zero window probing, the unacknowledged window probes >>>>> should not increment the error counter for the association or any >>>>> destination transport address. >>>>> >>>>> I assume that this implies that if *no* packets have been received >>>>> from peer between the time the probe was sent and the time the >>>>> timer goes off, then the error counters should be incremented? >>>>> >>>>> But if that is the case, when does the error counter get cleared? >>>>> The SACK replying to the probe does not acknowledge the probe, >>>>> it is just a dup-ack, so that would not clear any counters? >>>>> >>>>> Thanks for any replies! >>>>> Karoline >>>>> >>>>> -- >>>>> Karoline Malmkjær, Software Developer >>>>> TietoEnator A/S, IP Solutions >>>>> www.tietoenator.com >>>>> >>>>> >> >> > From Michael.Tuexen@micmac.franken.de Sat Sep 20 02:03:09 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E633A694E for ; Sat, 20 Sep 2008 02:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.792 X-Spam-Level: X-Spam-Status: No, score=-4.792 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsgypLi8ogMK for ; Sat, 20 Sep 2008 02:03:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C48BB3A6998 for ; Sat, 20 Sep 2008 02:03:02 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Sep 2008 09:03:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8K93D3o015590; Sat, 20 Sep 2008 05:03:13 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8K93C53018322; Sat, 20 Sep 2008 09:03:13 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8K90Xob030176 for ; Sat, 20 Sep 2008 05:00:33 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8K90Xun030172 for sctp-impl-filtered; Sat, 20 Sep 2008 05:00:33 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to Michael.Tuexen@micmac.franken.de using -f X-From-Outside-Cisco: 193.175.24.27 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: AhMDAKpY1EjBrxgbiGdsb2JhbACTGQEBAQ8gok+BZQ X-Ironport-Av: E=Sophos;i="4.32,436,1217808000"; d="scan'208";a="53703617" CC: Vlad Yasevich , sctp-impl@external.cisco.com Message-Id: <36C73752-7882-4A32-89BC-C742900E2EFD@micmac.franken.de> From: Michael Tuexen To: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= In-Reply-To: <48D3B41D.1090905@tietoenator.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes MIME-Version: 1.0 (Apple Message framework v929.2) Subject: Re: SCTP zero window probes Date: Sat, 20 Sep 2008 10:58:52 +0200 References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> <48D3B41D.1090905@tietoenator.com> X-Mailer: Apple Mail (2.929.2) Authentication-Results: rtp-dkim-1; header.From=Michael.Tuexen@micmac.franken.de; dkim=neutral Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailguard.cisco.com id m8K90MIu030166 X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Hi Karoline, comments in-line. Best regards Michael On Sep 19, 2008, at 4:15 PM, Karoline Malmkjær wrote: > Vlad Yasevich wrote: >> Karoline Malmkjær wrote: >> >>> Hi Michael. >>> >>> Thanks for the reply. >>> >>> I understand that the error count should not be >>> incremented when the SACK arrives. But suppose >>> the link drops some packets, say one out of 10. >>> Then the error count would be incremented every >>> time a packet is lost. Will these errors ever be >>> cleared, or will the association eventually die? >>> >> >> Are you asking this in the context of 0-window probes? >> What I mean is the the loss of some number of TSNs caused >> a 0-window situation on the receiver? >> >> In that case, the error counter is incremented every time a >> retransmission timer fires. However, when the retransmission >> happens and the tsn gets through, the receiver will renege >> and advance the cumulative tsn in it's SACK. That action >> will clear the error counter on the send side. >> >> -vlad >> >> > > Not really. I'm asking in the context of zero window > probing because the peer application has stopped reading. > Peer will never SACK the probe (at least not until > tomorrow, because someone pressed ^Z in his console and > left the building). This is only correct if you use a user land implementation. A kernel implementation will continue to send SACKs... > > > If SCTP sends a zero window probe above the window (with > TSN=N) and peer replies with a SACK (with c-ack=N-1), no > error counters are increased, that much is clear. > > If SCTP sends a window probe and receives no packets > from peer, I assume the error counters are increased. If > this happens 10 times in a row, the association times out. Correct. > > > The question is: if SCTP sends 20 window probes (TSN=N) > and receives 10 SACKs (c-ack=N-1), one for every second > probe, will the association then time out? No. > > > And if not, when are the counters cleared? Whenever you get a SACK with cumack=N. > > > It would be nice if the SACKs could do it, but as far as > I can see, the RFC does not allow this, as the incoming > SACKs are duplicates, they do not ack any data. The RFC says "new packets" and all the packets containing the SACKs are new, since SACKs are never retransmitted. Each SACK is generated by the packet used for the zero window probing. > > > Thanks! > Karoline >>> Best regards, >>> Karoline >>> >>> Michael Tuexen wrote: >>> >>>> Hi Karoline, >>>> >>>> my understanding is the following. >>>> Assume that the sender has sent up to N and the receiver has >>>> acknowledged all TSNs up to N - 1 and announces a zero window. >>>> >>>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>>> Then you should not increment the error count... This sequence >>>> can go forever. However, in FreeBSD we transmit each TSN only >>>> a limited number of times and would finally fail the association >>>> (we would call the chunk, the unlucky one...) >>>> >>>> Hope that helps. >>>> Best regards >>>> Michael >>>> >>>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>>> >>>> >>>>> Hello list. >>>>> >>>>> I have a question about zero window probing and error counters. >>>>> >>>>> RFC4960 states that: >>>>> >>>>> If the sender continues to receive new packets from the >>>>> receiver >>>>> while doing zero window probing, the unacknowledged window >>>>> probes >>>>> should not increment the error counter for the association or >>>>> any >>>>> destination transport address. >>>>> >>>>> I assume that this implies that if *no* packets have been received >>>>> from peer between the time the probe was sent and the time the >>>>> timer goes off, then the error counters should be incremented? >>>>> >>>>> But if that is the case, when does the error counter get cleared? >>>>> The SACK replying to the probe does not acknowledge the probe, >>>>> it is just a dup-ack, so that would not clear any counters? >>>>> >>>>> Thanks for any replies! >>>>> Karoline >>>>> >>>>> -- >>>>> Karoline Malmkjær, Software Developer >>>>> TietoEnator A/S, IP Solutions >>>>> www.tietoenator.com >>>>> >>>>> >> >> > > From Michael.Tuexen@micmac.franken.de Sat Sep 20 02:03:32 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACAA13A69AA for ; Sat, 20 Sep 2008 02:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dmvjXRKflxw for ; Sat, 20 Sep 2008 02:03:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8ABA73A69A9 for ; Sat, 20 Sep 2008 02:03:31 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Sep 2008 09:03:47 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8K93lkD015727; Sat, 20 Sep 2008 05:03:47 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8K93k1T001966; Sat, 20 Sep 2008 09:03:46 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8K93F7Q030342 for ; Sat, 20 Sep 2008 05:03:15 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8K93FPR030338 for sctp-impl-filtered; Sat, 20 Sep 2008 05:03:15 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to Michael.Tuexen@micmac.franken.de using -f X-From-Outside-Cisco: 193.175.24.27 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: AhMDAKpY1EjBrxgbiGdsb2JhbACTGQEBAQ8gok+BZQ X-Ironport-Av: E=Sophos;i="4.32,436,1217808000"; d="scan'208";a="53703778" CC: Vlad Yasevich , sctp-impl@external.cisco.com Message-Id: <974AD703-5030-4042-9EB3-734082217E7B@micmac.franken.de> From: Michael Tuexen To: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= In-Reply-To: <48D3B41D.1090905@tietoenator.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes MIME-Version: 1.0 (Apple Message framework v929.2) Subject: Re: SCTP zero window probes Date: Sat, 20 Sep 2008 11:01:33 +0200 References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> <48D3B41D.1090905@tietoenator.com> X-Mailer: Apple Mail (2.929.2) Authentication-Results: rtp-dkim-1; header.From=Michael.Tuexen@micmac.franken.de; dkim=neutral Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailguard.cisco.com id m8K93ECl030327 X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Hi Karoline, what I forgot: If you think the wording in RFC 4960 is misleading, please bring this up on tsvwg@ietf.org. This is not an implementation specific issue. Based on the discussion there, we might can issue an errata note making the text clearer... It seems that the text is not clear enough. Best regards Michael On Sep 19, 2008, at 4:15 PM, Karoline Malmkjær wrote: > Vlad Yasevich wrote: >> Karoline Malmkjær wrote: >> >>> Hi Michael. >>> >>> Thanks for the reply. >>> >>> I understand that the error count should not be >>> incremented when the SACK arrives. But suppose >>> the link drops some packets, say one out of 10. >>> Then the error count would be incremented every >>> time a packet is lost. Will these errors ever be >>> cleared, or will the association eventually die? >>> >> >> Are you asking this in the context of 0-window probes? >> What I mean is the the loss of some number of TSNs caused >> a 0-window situation on the receiver? >> >> In that case, the error counter is incremented every time a >> retransmission timer fires. However, when the retransmission >> happens and the tsn gets through, the receiver will renege >> and advance the cumulative tsn in it's SACK. That action >> will clear the error counter on the send side. >> >> -vlad >> >> > > Not really. I'm asking in the context of zero window > probing because the peer application has stopped reading. > Peer will never SACK the probe (at least not until > tomorrow, because someone pressed ^Z in his console and > left the building). > > If SCTP sends a zero window probe above the window (with > TSN=N) and peer replies with a SACK (with c-ack=N-1), no > error counters are increased, that much is clear. > > If SCTP sends a window probe and receives no packets > from peer, I assume the error counters are increased. If > this happens 10 times in a row, the association times out. > > The question is: if SCTP sends 20 window probes (TSN=N) > and receives 10 SACKs (c-ack=N-1), one for every second > probe, will the association then time out? > > And if not, when are the counters cleared? > > It would be nice if the SACKs could do it, but as far as > I can see, the RFC does not allow this, as the incoming > SACKs are duplicates, they do not ack any data. > > Thanks! > Karoline >>> Best regards, >>> Karoline >>> >>> Michael Tuexen wrote: >>> >>>> Hi Karoline, >>>> >>>> my understanding is the following. >>>> Assume that the sender has sent up to N and the receiver has >>>> acknowledged all TSNs up to N - 1 and announces a zero window. >>>> >>>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>>> Then you should not increment the error count... This sequence >>>> can go forever. However, in FreeBSD we transmit each TSN only >>>> a limited number of times and would finally fail the association >>>> (we would call the chunk, the unlucky one...) >>>> >>>> Hope that helps. >>>> Best regards >>>> Michael >>>> >>>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>>> >>>> >>>>> Hello list. >>>>> >>>>> I have a question about zero window probing and error counters. >>>>> >>>>> RFC4960 states that: >>>>> >>>>> If the sender continues to receive new packets from the >>>>> receiver >>>>> while doing zero window probing, the unacknowledged window >>>>> probes >>>>> should not increment the error counter for the association or >>>>> any >>>>> destination transport address. >>>>> >>>>> I assume that this implies that if *no* packets have been received >>>>> from peer between the time the probe was sent and the time the >>>>> timer goes off, then the error counters should be incremented? >>>>> >>>>> But if that is the case, when does the error counter get cleared? >>>>> The SACK replying to the probe does not acknowledge the probe, >>>>> it is just a dup-ack, so that would not clear any counters? >>>>> >>>>> Thanks for any replies! >>>>> Karoline >>>>> >>>>> -- >>>>> Karoline Malmkjær, Software Developer >>>>> TietoEnator A/S, IP Solutions >>>>> www.tietoenator.com >>>>> >>>>> >> >> > > From karoline.malmkjaer@tietoenator.com Mon Sep 22 00:51:45 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6AA3A686E for ; Mon, 22 Sep 2008 00:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OrVmLHMx+zG for ; Mon, 22 Sep 2008 00:51:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C3EBE3A6867 for ; Mon, 22 Sep 2008 00:51:37 -0700 (PDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Sep 2008 07:51:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8M7pY4U007229; Mon, 22 Sep 2008 03:51:34 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8M7pXLD019961; Mon, 22 Sep 2008 07:51:33 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8M7lHOS007633 for ; Mon, 22 Sep 2008 03:47:17 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8M7lHhd007629 for sctp-impl-filtered; Mon, 22 Sep 2008 03:47:17 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to karoline.malmkjaer@tietoenator.com using -f X-From-Outside-Cisco: 194.110.47.24 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: ArAAAB/q1kjCbi8Ymmdsb2JhbACBXZFAAQEBAQEICwoHEQWhLoFm X-Ironport-Av: E=Sophos;i="4.32,444,1217808000"; d="scan'208";a="76159672" X-Auditid: c26e2f18-000021dc00001d68-15-48d744436e26 Message-Id: <48D7441F.3000901@tietoenator.com> Date: Mon, 22 Sep 2008 09:07:11 +0200 From: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= User-Agent: Thunderbird 2.0.0.6 (X11/20070925) MIME-Version: 1.0 To: Michael Tuexen CC: sctp-impl@external.cisco.com Subject: Re: SCTP zero window probes References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> <48D3B41D.1090905@tietoenator.com> <36C73752-7882-4A32-89BC-C742900E2EFD@micmac.franken.de> In-Reply-To: <36C73752-7882-4A32-89BC-C742900E2EFD@micmac.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Originalarrivaltime: 22 Sep 2008 07:07:26.0009 (UTC) FILETIME=[DE24EA90:01C91C81] X-Brightmail-Tracker: AAAAAA== Authentication-Results: rtp-dkim-2; header.From=karoline.malmkjaer@tietoenator.com; dkim=neutral X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Hi Michael. Thanks for your answer. I'm afraid my description of the scenario was not sufficiently precise, please see inline comments. Thanks! Karoline Michael Tuexen wrote: > Hi Karoline, > > comments in-line. > > Best regards > Michael > > On Sep 19, 2008, at 4:15 PM, Karoline Malmkjær wrote: > >> Vlad Yasevich wrote: >>> Karoline Malmkjær wrote: >>> >>>> Hi Michael. >>>> >>>> Thanks for the reply. >>>> >>>> I understand that the error count should not be >>>> incremented when the SACK arrives. But suppose >>>> the link drops some packets, say one out of 10. >>>> Then the error count would be incremented every >>>> time a packet is lost. Will these errors ever be >>>> cleared, or will the association eventually die? >>>> >>> >>> Are you asking this in the context of 0-window probes? >>> What I mean is the the loss of some number of TSNs caused >>> a 0-window situation on the receiver? >>> >>> In that case, the error counter is incremented every time a >>> retransmission timer fires. However, when the retransmission >>> happens and the tsn gets through, the receiver will renege >>> and advance the cumulative tsn in it's SACK. That action >>> will clear the error counter on the send side. >>> >>> -vlad >>> >>> >> >> Not really. I'm asking in the context of zero window >> probing because the peer application has stopped reading. >> Peer will never SACK the probe (at least not until >> tomorrow, because someone pressed ^Z in his console and >> left the building). > This is only correct if you use a user land implementation. > A kernel implementation will continue to send SACKs... Sorry, my phrasing was imprecise. I meant that peer will send SACKs, but they will c-ack N-1, ie, they will not cumulatively ack the probe. >> >> >> If SCTP sends a zero window probe above the window (with >> TSN=N) and peer replies with a SACK (with c-ack=N-1), no >> error counters are increased, that much is clear. >> >> If SCTP sends a window probe and receives no packets >> from peer, I assume the error counters are increased. If >> this happens 10 times in a row, the association times out. > Correct. >> >> >> The question is: if SCTP sends 20 window probes (TSN=N) >> and receives 10 SACKs (c-ack=N-1), one for every second >> probe, will the association then time out? > No. >> >> >> And if not, when are the counters cleared? > Whenever you get a SACK with cumack=N. That was my understanding, yes. But all the SACKs we get are for N-1, so I still don't see when the counters are cleared? >> >> >> It would be nice if the SACKs could do it, but as far as >> I can see, the RFC does not allow this, as the incoming >> SACKs are duplicates, they do not ack any data. > The RFC says "new packets" and all the packets containing the > SACKs are new, since SACKs are never retransmitted. > Each SACK is generated by the packet used for the zero > window probing. OK, but that only explains why the counters are not *increased*. The RFC does not say to *clear* counters on incoming new packets (which is very understandable, since incoming data should not clear counters). >> >> >> Thanks! >> Karoline >>>> Best regards, >>>> Karoline >>>> >>>> Michael Tuexen wrote: >>>> >>>>> Hi Karoline, >>>>> >>>>> my understanding is the following. >>>>> Assume that the sender has sent up to N and the receiver has >>>>> acknowledged all TSNs up to N - 1 and announces a zero window. >>>>> >>>>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>>>> Then you should not increment the error count... This sequence >>>>> can go forever. However, in FreeBSD we transmit each TSN only >>>>> a limited number of times and would finally fail the association >>>>> (we would call the chunk, the unlucky one...) >>>>> >>>>> Hope that helps. >>>>> Best regards >>>>> Michael >>>>> >>>>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>>>> >>>>> >>>>>> Hello list. >>>>>> >>>>>> I have a question about zero window probing and error counters. >>>>>> >>>>>> RFC4960 states that: >>>>>> >>>>>> If the sender continues to receive new packets from the receiver >>>>>> while doing zero window probing, the unacknowledged window probes >>>>>> should not increment the error counter for the association or any >>>>>> destination transport address. >>>>>> >>>>>> I assume that this implies that if *no* packets have been received >>>>>> from peer between the time the probe was sent and the time the >>>>>> timer goes off, then the error counters should be incremented? >>>>>> >>>>>> But if that is the case, when does the error counter get cleared? >>>>>> The SACK replying to the probe does not acknowledge the probe, >>>>>> it is just a dup-ack, so that would not clear any counters? >>>>>> >>>>>> Thanks for any replies! >>>>>> Karoline >>>>>> >>>>>> -- >>>>>> Karoline Malmkjær, Software Developer >>>>>> TietoEnator A/S, IP Solutions >>>>>> www.tietoenator.com >>>>>> >>>>>> >>> >>> >> >> > From karoline.malmkjaer@tietoenator.com Mon Sep 22 01:06:36 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5093A68F5 for ; Mon, 22 Sep 2008 01:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jByZ8pxomHCj for ; Mon, 22 Sep 2008 01:06:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D67443A6894 for ; Mon, 22 Sep 2008 01:05:42 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Sep 2008 08:05:36 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8M85ZDQ024312; Mon, 22 Sep 2008 04:05:35 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8M85Y9K022410; Mon, 22 Sep 2008 08:05:35 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8M840hD007880 for ; Mon, 22 Sep 2008 04:04:00 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8M840wv007876 for sctp-impl-filtered; Mon, 22 Sep 2008 04:04:00 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to karoline.malmkjaer@tietoenator.com using -f X-From-Outside-Cisco: 194.110.47.24 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: ArAAAM/u1kjCbi8Ymmdsb2JhbACBXZFAAQEBAQEICwoHEQWhI4Fm X-Ironport-Av: E=Sophos;i="4.32,445,1217808000"; d="scan'208";a="53865962" X-Auditid: c26e2f18-000021d800001d68-d8-48d751404380 Message-Id: <48D7511B.6050706@tietoenator.com> Date: Mon, 22 Sep 2008 10:02:35 +0200 From: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= User-Agent: Thunderbird 2.0.0.6 (X11/20070925) MIME-Version: 1.0 To: Michael Tuexen CC: sctp-impl@external.cisco.com Subject: Re: SCTP zero window probes References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> <48D3B41D.1090905@tietoenator.com> <974AD703-5030-4042-9EB3-734082217E7B@micmac.franken.de> In-Reply-To: <974AD703-5030-4042-9EB3-734082217E7B@micmac.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Originalarrivaltime: 22 Sep 2008 08:02:51.0142 (UTC) FILETIME=[9C13F260:01C91C89] X-Brightmail-Tracker: AAAAAA== Authentication-Results: rtp-dkim-1; header.From=karoline.malmkjaer@tietoenator.com; dkim=neutral X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Michael Tuexen wrote: > Hi Karoline, > > what I forgot: If you think the wording in RFC 4960 is misleading, > please bring this up on tsvwg@ietf.org. This is not an implementation > specific issue. Based on the discussion there, we might can issue > an errata note making the text clearer... It seems that the text > is not clear enough. > > Best regards > Michael Hi Michael. No, I actually think the text in 4960 is very clear on this point. If TSN N is outstanding and times out, it says the counters should be increased, *except* if N is a window probe and a new packet has arrived from peer recently. If N is acknowledged, ie a SACK with c-ack N arrives, or if a heartbeat is acknowledged, it says to clear the counters. I.e., if a SACK with c-ack N-1 arrives, the counters are not increased and not cleared. Following the rules above on a link that loses some packets, the errors will accumulate and the association will eventually time out. This is a strategy that probably makes sense in a lot of scenarios (not all, of course). Of course, if we can't agree that this is what the RFC says, then I'm wrong and it *is* unclear :-) Or if the behavior described was not the intended behavior, then it is misleading. But I wouldn't know what the intention was. And I don't think an implementor like me, who arrives on the scene after an RFC is published, should implement things differently than what is described in the RFC with the argument "I don't think they meant that". Best regards, Karoline > > On Sep 19, 2008, at 4:15 PM, Karoline Malmkjær wrote: > >> Vlad Yasevich wrote: >>> Karoline Malmkjær wrote: >>> >>>> Hi Michael. >>>> >>>> Thanks for the reply. >>>> >>>> I understand that the error count should not be >>>> incremented when the SACK arrives. But suppose >>>> the link drops some packets, say one out of 10. >>>> Then the error count would be incremented every >>>> time a packet is lost. Will these errors ever be >>>> cleared, or will the association eventually die? >>>> >>> >>> Are you asking this in the context of 0-window probes? >>> What I mean is the the loss of some number of TSNs caused >>> a 0-window situation on the receiver? >>> >>> In that case, the error counter is incremented every time a >>> retransmission timer fires. However, when the retransmission >>> happens and the tsn gets through, the receiver will renege >>> and advance the cumulative tsn in it's SACK. That action >>> will clear the error counter on the send side. >>> >>> -vlad >>> >>> >> >> Not really. I'm asking in the context of zero window >> probing because the peer application has stopped reading. >> Peer will never SACK the probe (at least not until >> tomorrow, because someone pressed ^Z in his console and >> left the building). >> >> If SCTP sends a zero window probe above the window (with >> TSN=N) and peer replies with a SACK (with c-ack=N-1), no >> error counters are increased, that much is clear. >> >> If SCTP sends a window probe and receives no packets >> from peer, I assume the error counters are increased. If >> this happens 10 times in a row, the association times out. >> >> The question is: if SCTP sends 20 window probes (TSN=N) >> and receives 10 SACKs (c-ack=N-1), one for every second >> probe, will the association then time out? >> >> And if not, when are the counters cleared? >> >> It would be nice if the SACKs could do it, but as far as >> I can see, the RFC does not allow this, as the incoming >> SACKs are duplicates, they do not ack any data. >> >> Thanks! >> Karoline >>>> Best regards, >>>> Karoline >>>> >>>> Michael Tuexen wrote: >>>> >>>>> Hi Karoline, >>>>> >>>>> my understanding is the following. >>>>> Assume that the sender has sent up to N and the receiver has >>>>> acknowledged all TSNs up to N - 1 and announces a zero window. >>>>> >>>>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>>>> Then you should not increment the error count... This sequence >>>>> can go forever. However, in FreeBSD we transmit each TSN only >>>>> a limited number of times and would finally fail the association >>>>> (we would call the chunk, the unlucky one...) >>>>> >>>>> Hope that helps. >>>>> Best regards >>>>> Michael >>>>> >>>>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>>>> >>>>> >>>>>> Hello list. >>>>>> >>>>>> I have a question about zero window probing and error counters. >>>>>> >>>>>> RFC4960 states that: >>>>>> >>>>>> If the sender continues to receive new packets from the receiver >>>>>> while doing zero window probing, the unacknowledged window probes >>>>>> should not increment the error counter for the association or any >>>>>> destination transport address. >>>>>> >>>>>> I assume that this implies that if *no* packets have been received >>>>>> from peer between the time the probe was sent and the time the >>>>>> timer goes off, then the error counters should be incremented? >>>>>> >>>>>> But if that is the case, when does the error counter get cleared? >>>>>> The SACK replying to the probe does not acknowledge the probe, >>>>>> it is just a dup-ack, so that would not clear any counters? >>>>>> >>>>>> Thanks for any replies! >>>>>> Karoline >>>>>> >>>>>> -- >>>>>> Karoline Malmkjær, Software Developer >>>>>> TietoEnator A/S, IP Solutions >>>>>> www.tietoenator.com >>>>>> >>>>>> >>> >>> >> >> > From Michael.Tuexen@micmac.franken.de Mon Sep 22 07:02:55 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FF03A69E8 for ; Mon, 22 Sep 2008 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfUMeNA6uWnT for ; Mon, 22 Sep 2008 07:02:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DA5773A6B33 for ; Mon, 22 Sep 2008 07:02:50 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Sep 2008 14:02:51 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8ME2ojJ006121; Mon, 22 Sep 2008 10:02:50 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8ME2ovm007857; Mon, 22 Sep 2008 14:02:50 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8MDxuYm015475 for ; Mon, 22 Sep 2008 09:59:56 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8MDxuBv015471 for sctp-impl-filtered; Mon, 22 Sep 2008 09:59:56 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to Michael.Tuexen@micmac.franken.de using -f X-From-Outside-Cisco: 193.175.24.27 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: Ak0DAPpB10jBrxgbiGdsb2JhbACTGQEBARUiowKBZg X-Ironport-Av: E=Sophos;i="4.32,446,1217808000"; d="scan'208";a="76226032" CC: sctp-impl@external.cisco.com Message-Id: <50196CC6-6456-4C76-85BB-262A6DD56896@micmac.franken.de> From: Michael Tuexen To: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= In-Reply-To: <48D7441F.3000901@tietoenator.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes MIME-Version: 1.0 (Apple Message framework v929.2) Subject: Re: SCTP zero window probes Date: Mon, 22 Sep 2008 15:58:03 +0200 References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> <48D3B41D.1090905@tietoenator.com> <36C73752-7882-4A32-89BC-C742900E2EFD@micmac.franken.de> <48D7441F.3000901@tietoenator.com> X-Mailer: Apple Mail (2.929.2) Authentication-Results: rtp-dkim-1; header.From=Michael.Tuexen@micmac.franken.de; dkim=neutral Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailguard.cisco.com id m8MDxl74015464 X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 Karoline, comments in-line. Best regards Michael On Sep 22, 2008, at 9:07 AM, Karoline Malmkjær wrote: > Hi Michael. > > Thanks for your answer. I'm afraid my description of > the scenario was not sufficiently precise, please see > inline comments. > > Thanks! > Karoline > > Michael Tuexen wrote: >> Hi Karoline, >> >> comments in-line. >> >> Best regards >> Michael >> >> On Sep 19, 2008, at 4:15 PM, Karoline Malmkjær wrote: >> >>> Vlad Yasevich wrote: >>>> Karoline Malmkjær wrote: >>>> >>>>> Hi Michael. >>>>> >>>>> Thanks for the reply. >>>>> >>>>> I understand that the error count should not be >>>>> incremented when the SACK arrives. But suppose >>>>> the link drops some packets, say one out of 10. >>>>> Then the error count would be incremented every >>>>> time a packet is lost. Will these errors ever be >>>>> cleared, or will the association eventually die? >>>>> >>>> >>>> Are you asking this in the context of 0-window probes? >>>> What I mean is the the loss of some number of TSNs caused >>>> a 0-window situation on the receiver? >>>> >>>> In that case, the error counter is incremented every time a >>>> retransmission timer fires. However, when the retransmission >>>> happens and the tsn gets through, the receiver will renege >>>> and advance the cumulative tsn in it's SACK. That action >>>> will clear the error counter on the send side. >>>> >>>> -vlad >>>> >>>> >>> >>> Not really. I'm asking in the context of zero window >>> probing because the peer application has stopped reading. >>> Peer will never SACK the probe (at least not until >>> tomorrow, because someone pressed ^Z in his console and >>> left the building). >> This is only correct if you use a user land implementation. >> A kernel implementation will continue to send SACKs... > Sorry, my phrasing was imprecise. I meant that peer > will send SACKs, but they will c-ack N-1, ie, they will > not cumulatively ack the probe. OK. > >>> >>> >>> If SCTP sends a zero window probe above the window (with >>> TSN=N) and peer replies with a SACK (with c-ack=N-1), no >>> error counters are increased, that much is clear. >>> >>> If SCTP sends a window probe and receives no packets >>> from peer, I assume the error counters are increased. If >>> this happens 10 times in a row, the association times out. >> Correct. >>> >>> >>> The question is: if SCTP sends 20 window probes (TSN=N) >>> and receives 10 SACKs (c-ack=N-1), one for every second >>> probe, will the association then time out? >> No. >>> >>> >>> And if not, when are the counters cleared? >> Whenever you get a SACK with cumack=N. > That was my understanding, yes. But all the SACKs we > get are for N-1, so I still don't see when the counters > are cleared? Sorry.... I meant, with cumack=N-1... > >>> >>> >>> It would be nice if the SACKs could do it, but as far as >>> I can see, the RFC does not allow this, as the incoming >>> SACKs are duplicates, they do not ack any data. >> The RFC says "new packets" and all the packets containing the >> SACKs are new, since SACKs are never retransmitted. >> Each SACK is generated by the packet used for the zero >> window probing. > OK, but that only explains why the counters are not > *increased*. The RFC does not say to *clear* counters > on incoming new packets (which is very understandable, > since incoming data should not clear counters). If during zero window probing every other DATA chunk or SACK chunk gets lost, it should continue... This is at least my understanding. But the RFC is not clear on that... > >>> >>> >>> Thanks! >>> Karoline >>>>> Best regards, >>>>> Karoline >>>>> >>>>> Michael Tuexen wrote: >>>>> >>>>>> Hi Karoline, >>>>>> >>>>>> my understanding is the following. >>>>>> Assume that the sender has sent up to N and the receiver has >>>>>> acknowledged all TSNs up to N - 1 and announces a zero window. >>>>>> >>>>>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>>>>> Then you should not increment the error count... This sequence >>>>>> can go forever. However, in FreeBSD we transmit each TSN only >>>>>> a limited number of times and would finally fail the association >>>>>> (we would call the chunk, the unlucky one...) >>>>>> >>>>>> Hope that helps. >>>>>> Best regards >>>>>> Michael >>>>>> >>>>>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>>>>> >>>>>> >>>>>>> Hello list. >>>>>>> >>>>>>> I have a question about zero window probing and error counters. >>>>>>> >>>>>>> RFC4960 states that: >>>>>>> >>>>>>> If the sender continues to receive new packets from the >>>>>>> receiver >>>>>>> while doing zero window probing, the unacknowledged window >>>>>>> probes >>>>>>> should not increment the error counter for the association >>>>>>> or any >>>>>>> destination transport address. >>>>>>> >>>>>>> I assume that this implies that if *no* packets have been >>>>>>> received >>>>>>> from peer between the time the probe was sent and the time the >>>>>>> timer goes off, then the error counters should be incremented? >>>>>>> >>>>>>> But if that is the case, when does the error counter get >>>>>>> cleared? >>>>>>> The SACK replying to the probe does not acknowledge the probe, >>>>>>> it is just a dup-ack, so that would not clear any counters? >>>>>>> >>>>>>> Thanks for any replies! >>>>>>> Karoline >>>>>>> >>>>>>> -- >>>>>>> Karoline Malmkjær, Software Developer >>>>>>> TietoEnator A/S, IP Solutions >>>>>>> www.tietoenator.com >>>>>>> >>>>>>> >>>> >>>> >>> >>> >> > > From Michael.Tuexen@micmac.franken.de Mon Sep 22 07:03:09 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C8B3A677C for ; Mon, 22 Sep 2008 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkaO13tww6mF for ; Mon, 22 Sep 2008 07:03:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3D7C43A6AEE for ; Mon, 22 Sep 2008 07:03:05 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Sep 2008 14:03:05 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8ME35Yp006230; Mon, 22 Sep 2008 10:03:05 -0400 Received: from mailguard.cisco.com (mailguard.cisco.com [64.102.28.79]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8ME35S2025117; Mon, 22 Sep 2008 14:03:05 GMT Received: from mailguard.cisco.com (localhost.cisco.com [127.0.0.1]) by mailguard.cisco.com (8.12.11/8.13.4) with ESMTP id m8ME2aPf015610 for ; Mon, 22 Sep 2008 10:02:36 -0400 Received: (from mailnull@localhost) by mailguard.cisco.com (8.12.11/8.12.11/Submit) id m8ME2axf015606 for sctp-impl-filtered; Mon, 22 Sep 2008 10:02:36 -0400 X-Authentication-Warning: mailguard.cisco.com: mailnull set sender to Michael.Tuexen@micmac.franken.de using -f X-From-Outside-Cisco: 193.175.24.27 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: Ak0DAAlC10jBrxgbiGdsb2JhbACTGQEBARUiowOBZg X-Ironport-Av: E=Sophos;i="4.32,446,1217808000"; d="scan'208";a="53916496" CC: sctp-impl@external.cisco.com Message-Id: <61FF176E-5243-43C2-B3C8-D98D4A65B09C@micmac.franken.de> From: Michael Tuexen To: =?ISO-8859-1?Q?Karoline_Malmkj=E6r?= In-Reply-To: <48D7511B.6050706@tietoenator.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes MIME-Version: 1.0 (Apple Message framework v929.2) Subject: Re: SCTP zero window probes Date: Mon, 22 Sep 2008 16:00:50 +0200 References: <48D23D0C.3000302@tietoenator.com> <6534BD78-2EBA-4377-9640-9DA5F1BBBC61@micmac.franken.de> <48D36638.9060007@tietoenator.com> <48D3ADB6.2050605@hp.com> <48D3B41D.1090905@tietoenator.com> <974AD703-5030-4042-9EB3-734082217E7B@micmac.franken.de> <48D7511B.6050706@tietoenator.com> X-Mailer: Apple Mail (2.929.2) Authentication-Results: rtp-dkim-1; header.From=Michael.Tuexen@micmac.franken.de; dkim=neutral Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailguard.cisco.com id m8ME2Vg7015599 X-Mailguard-Protected-List: sctp-impl X-Mailguard-Version: 1.2 On Sep 22, 2008, at 10:02 AM, Karoline Malmkjær wrote: > Michael Tuexen wrote: >> Hi Karoline, >> >> what I forgot: If you think the wording in RFC 4960 is misleading, >> please bring this up on tsvwg@ietf.org. This is not an implementation >> specific issue. Based on the discussion there, we might can issue >> an errata note making the text clearer... It seems that the text >> is not clear enough. >> >> Best regards >> Michael > > Hi Michael. > > No, I actually think the text in 4960 is very clear on this > point. > > > If TSN N is outstanding and times out, it says the counters > should be increased, *except* if N is a window probe and a > new packet has arrived from peer recently. > > If N is acknowledged, ie a SACK with c-ack N arrives, or if > a heartbeat is acknowledged, it says to clear the counters. > > I.e., if a SACK with c-ack N-1 arrives, the counters are not > increased and not cleared. But this does not make sense... > > > Following the rules above on a link that loses some packets, > the errors will accumulate and the association will eventually > time out. This is a strategy that probably makes sense in a > lot of scenarios (not all, of course). But normally you will clear the counter whenever you get "an appropriate answer". A SACK with cumack=N-1 is one in my understanding. > > > > Of course, if we can't agree that this is what the RFC says, > then I'm wrong and it *is* unclear :-) > > Or if the behavior described was not the intended behavior, > then it is misleading. But I wouldn't know what the intention > was. And I don't think an implementor like me, who arrives > on the scene after an RFC is published, should implement > things differently than what is described in the RFC with > the argument "I don't think they meant that". Can you please bring this up on tsvwg@ietf.org? We can figure out if I'm wrong or the RFC is unclear. In case of the RFC being unclear we can provide an errata so that it is clear to everyone what to do... > > > Best regards, > Karoline > >> >> On Sep 19, 2008, at 4:15 PM, Karoline Malmkjær wrote: >> >>> Vlad Yasevich wrote: >>>> Karoline Malmkjær wrote: >>>> >>>>> Hi Michael. >>>>> >>>>> Thanks for the reply. >>>>> >>>>> I understand that the error count should not be >>>>> incremented when the SACK arrives. But suppose >>>>> the link drops some packets, say one out of 10. >>>>> Then the error count would be incremented every >>>>> time a packet is lost. Will these errors ever be >>>>> cleared, or will the association eventually die? >>>>> >>>> >>>> Are you asking this in the context of 0-window probes? >>>> What I mean is the the loss of some number of TSNs caused >>>> a 0-window situation on the receiver? >>>> >>>> In that case, the error counter is incremented every time a >>>> retransmission timer fires. However, when the retransmission >>>> happens and the tsn gets through, the receiver will renege >>>> and advance the cumulative tsn in it's SACK. That action >>>> will clear the error counter on the send side. >>>> >>>> -vlad >>>> >>>> >>> >>> Not really. I'm asking in the context of zero window >>> probing because the peer application has stopped reading. >>> Peer will never SACK the probe (at least not until >>> tomorrow, because someone pressed ^Z in his console and >>> left the building). >>> >>> If SCTP sends a zero window probe above the window (with >>> TSN=N) and peer replies with a SACK (with c-ack=N-1), no >>> error counters are increased, that much is clear. >>> >>> If SCTP sends a window probe and receives no packets >>> from peer, I assume the error counters are increased. If >>> this happens 10 times in a row, the association times out. >>> >>> The question is: if SCTP sends 20 window probes (TSN=N) >>> and receives 10 SACKs (c-ack=N-1), one for every second >>> probe, will the association then time out? >>> >>> And if not, when are the counters cleared? >>> >>> It would be nice if the SACKs could do it, but as far as >>> I can see, the RFC does not allow this, as the incoming >>> SACKs are duplicates, they do not ack any data. >>> >>> Thanks! >>> Karoline >>>>> Best regards, >>>>> Karoline >>>>> >>>>> Michael Tuexen wrote: >>>>> >>>>>> Hi Karoline, >>>>>> >>>>>> my understanding is the following. >>>>>> Assume that the sender has sent up to N and the receiver has >>>>>> acknowledged all TSNs up to N - 1 and announces a zero window. >>>>>> >>>>>> So the sender sends TSN N and gets back a SACK with cumack N-1. >>>>>> Then you should not increment the error count... This sequence >>>>>> can go forever. However, in FreeBSD we transmit each TSN only >>>>>> a limited number of times and would finally fail the association >>>>>> (we would call the chunk, the unlucky one...) >>>>>> >>>>>> Hope that helps. >>>>>> Best regards >>>>>> Michael >>>>>> >>>>>> On Sep 18, 2008, at 1:35 PM, Karoline Malmkjær wrote: >>>>>> >>>>>> >>>>>>> Hello list. >>>>>>> >>>>>>> I have a question about zero window probing and error counters. >>>>>>> >>>>>>> RFC4960 states that: >>>>>>> >>>>>>> If the sender continues to receive new packets from the >>>>>>> receiver >>>>>>> while doing zero window probing, the unacknowledged window >>>>>>> probes >>>>>>> should not increment the error counter for the association >>>>>>> or any >>>>>>> destination transport address. >>>>>>> >>>>>>> I assume that this implies that if *no* packets have been >>>>>>> received >>>>>>> from peer between the time the probe was sent and the time the >>>>>>> timer goes off, then the error counters should be incremented? >>>>>>> >>>>>>> But if that is the case, when does the error counter get >>>>>>> cleared? >>>>>>> The SACK replying to the probe does not acknowledge the probe, >>>>>>> it is just a dup-ack, so that would not clear any counters? >>>>>>> >>>>>>> Thanks for any replies! >>>>>>> Karoline >>>>>>> >>>>>>> -- >>>>>>> Karoline Malmkjær, Software Developer >>>>>>> TietoEnator A/S, IP Solutions >>>>>>> www.tietoenator.com >>>>>>> >>>>>>> >>>> >>>> >>> >>> >> > > From cheryl@sympatico.ca Thu Sep 25 08:36:09 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CB53A684B for ; Thu, 25 Sep 2008 08:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzbLb7dx9nLB for ; Thu, 25 Sep 2008 08:36:08 -0700 (PDT) Received: from simmts8-srv.bellnexxia.net (simmts8.bellnexxia.net [206.47.199.166]) by core3.amsl.com (Postfix) with ESMTP id 900AD3A690F for ; Thu, 25 Sep 2008 08:36:08 -0700 (PDT) Received: from simip11-ac.srvr.bell.ca ([206.47.199.91]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080925114101.VNGU1761.simmts8-srv.bellnexxia.net@simip11-ac.srvr.bell.ca> for ; Thu, 25 Sep 2008 07:41:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscvAI0U20jOL8eh/2dsb2JhbACBXolyhkSqXg Received: from simfep6.srvr.bell.ca (HELO smtp8.sympatico.ca) ([206.47.199.161]) by alconsout.srvr.bell.ca with SMTP; 25 Sep 2008 07:48:20 -0400 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) X-Originating-IP: [212.118.158.68] From: Reply-To: infoagent@y7mail.com To: Subject: Mrs Rose Wood Date: Thu, 25 Sep 2008 7:41:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080925114101.VNGU1761.simmts8-srv.bellnexxia.net@simip11-ac.srvr.bell.ca> You have won the sum of =A31,000,000.00 GBP from our monthly PROGRAM, held on September 25th 2008. For your claims,contact Mr.Pinkett Griffin, = Names, = Address, = Age, Occupation, Tel, Country. = Contact Email: mailoffice@y7mail.com Sincerely, Mrs Rose Wood From a20092008@gmail.com Sun Sep 28 07:05:39 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362C928C0E5 for ; Sun, 28 Sep 2008 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIlnLBACYqm3 for ; Sun, 28 Sep 2008 07:05:38 -0700 (PDT) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 60B543A6A99 for ; Sun, 28 Sep 2008 07:05:38 -0700 (PDT) Received: from coloso ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0K7W00A38SENW2B0@maildcarg4.dc-host.net.ar> for sctp-impl-archive@ietf.org; Sun, 28 Sep 2008 11:04:00 -0300 (ART) Date: Sun, 28 Sep 2008 11:04:27 -0300 From: "a20092008@gmail.com" Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samsung LCD 19" To: PCs Errors-to: a200982008_@gmail.com Message-id: <3815-22008902814427238@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B CEL: 15-3197-5821 EMail: a25092008@gmail=2Ecom -Modelo: CORE 2 DUO -Procesador: E7200 CORE DUO 2=2E53 3MB cache 775 BOX 3 a=F1os de garantia -Motherboard: Asus P5GC-MX Socket 775 BOX=20 -Memoria: DDR2 2GB 667MHZ -Placa de video: PCI-E 512MB NX8400GS-TD256E MSI -Disco r=EDgido: 250GB SATA 2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 integrada -Placa de sonido: 6 canales -Puertos: 2USB frontales y 4USB traseros -Gabinete: SENTEY ATX c2 coolers fuente 500W -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 1/2 -Garantia equipo 12 meses -Sistema operativo instalado y funcionando FULL, todos los programas y uti= lidades -Monitor: LCD 19" Samsung 943NWX 3 a=F1os de garantia -PRECIO $2499 FINAL (IVA inc) Consulte otras configuraciones a medida, notebooks, camaras digitales y mu= cho mas From a20092008@gmail.com Sun Sep 28 07:05:39 2008 Return-Path: X-Original-To: ietfarch-sctp-impl-archive@core3.amsl.com Delivered-To: ietfarch-sctp-impl-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B4228C0E5 for ; Sun, 28 Sep 2008 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPiGDR2lIBE9 for ; Sun, 28 Sep 2008 07:05:39 -0700 (PDT) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 9E6F83A6AA0 for ; Sun, 28 Sep 2008 07:05:39 -0700 (PDT) Received: from coloso ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0K7W00A38SENW2B0@maildcarg4.dc-host.net.ar> for sctp-impl-archive@megatron.ietf.org; Sun, 28 Sep 2008 11:04:00 -0300 (ART) Date: Sun, 28 Sep 2008 11:04:27 -0300 From: "a20092008@gmail.com" Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samsung LCD 19" To: PCs Errors-to: a200982008_@gmail.com Message-id: <3815-22008902814427238@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B CEL: 15-3197-5821 EMail: a25092008@gmail=2Ecom -Modelo: CORE 2 DUO -Procesador: E7200 CORE DUO 2=2E53 3MB cache 775 BOX 3 a=F1os de garantia -Motherboard: Asus P5GC-MX Socket 775 BOX=20 -Memoria: DDR2 2GB 667MHZ -Placa de video: PCI-E 512MB NX8400GS-TD256E MSI -Disco r=EDgido: 250GB SATA 2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 integrada -Placa de sonido: 6 canales -Puertos: 2USB frontales y 4USB traseros -Gabinete: SENTEY ATX c2 coolers fuente 500W -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 1/2 -Garantia equipo 12 meses -Sistema operativo instalado y funcionando FULL, todos los programas y uti= lidades -Monitor: LCD 19" Samsung 943NWX 3 a=F1os de garantia -PRECIO $2499 FINAL (IVA inc) Consulte otras configuraciones a medida, notebooks, camaras digitales y mu= cho mas