From lltew@go2.pl Tue Mar 1 14:56:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04269; Tue, 1 Mar 2005 14:56:03 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6DUT-0004ZY-Ci; Tue, 01 Mar 2005 14:57:10 -0500 Received: from [220.76.189.42] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D6DTM-0005gL-7X; Tue, 01 Mar 2005 14:56:00 -0500 Received: from symphony-97.go2.pl ([87.178.194.100]:1906 "HELO mail.go2.pl") by go2.pl with SMTP id ; Tue, 01 Mar 2005 18:55:50 -0100 Date: Tue, 01 Mar 2005 23:47:50 +0400 Message-Id: <0.2.89.2081924.0083fc70@go2.pl> From: "Josefina Eastman" To: Subject: Start the year with a fresh start. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 5.9 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit http://www.g3tit.com/mortgage.asp. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit phenomenon interstice

 
 
 
 
 
 
.
.
.
http://www.g3tit.com/mortgage.asp It's time to fix up your situation for once and for all
.  
   
No More ------------A85031401794097-- ------------A48356845382213 Content-Type: image/gif; name="medea.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODlhbAHAAZEAAP///8zMzDMzMwAAACH5BAAAAAAALAAAAABsAcABAAL/hI+py+0Po5y02ouz 3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1mAtqu94vh gsfkq9hwLqvX7Lb7DY/L54kBwk7P6y94RZ/B9fe3R1i4MHiAeHgHkGb4SKgI0CfGlSZ44NgIyfkm KTgQmjnJeBcq2Zn69ZlYaoDZGqs66xV4eitKWier28tLC3zF6vvK24eIGqzsNIx7avxLvDzNzICX DCudTM1d1OyQjdw9vjRMfOzqm03O3iNmPnmb/hcgn96OH6UpsZ3vj7MvzK5/BIsE5IOmoMKFDBs6 fAgxosSJFCtavIgxo8aN/xw7evwIMqTIkSRLmjyJMqXKlSxbunwJM6bMmTRrBjs4AeeWnEB0JvBZ iYLPnhKGKnBklEzSDfQgGF3aT8lSgdIcTO1wFYWdS36o/qxgNOrREKhQPfXqFMYgSTrFCh2rQwCC QD/dyrB7YeigM3gjZLUag17fYmTWnlvwdxRcQHMHLgaclas1wA+AUlacFilZx5swL6rcILENTOvi 5QJnj9SzV6snpyacqHVs2bjqyGYt6tPr19ZS29ld77bp0rp+C98t3NRq46dnn6792RjtrjtIz7vH ubjhaLHv8L3+65rjdaAaiOMenrWr5uSjXWsfi/g99vPRp4fd67wOdLD5Y/83j582k43nHoBVCYhg Qvf9t494A50HIXURUvdfgPpR2I9/E3qnQz2yaOjHQc5YGGJ0H8ryjnLLebYhd1wIIFmFuK34oIQ2 1ohjHY6UpeB5ttyS4gMg5mgfDb/tAsqIA8Znm5IUnjijb+P55oyDjDQ414XZWcnkKFwShsd3CCpS JY/p0EVigNH516WMRh4m35JtqglgjGxmd+CXV8q4HYdPgnljKRDuqOaXaPIzkJj6RXUkL2hqiUOj rcRpIqBucnbonX6ipyeKdKZZYYuWChronKNeumWpmUYg6Zh/5kDmnzy+o2eftl0XJJTqHQZqeXLi h40phQ4L7Dy1QsNrpYv/CvtpVzFOIuauPMTqB2/V5kYndIvwtha3zxzj7W3yYMNeck02Kqo6x31L 7IwqbkOjsdjOJuQh685Ly2A2IaQPDFnp69cTkXXhoROixVAwQQEd/CY3DIvwMMFsRLyvChQrhXCz J2x1A8A3RGyPZkVWR5ZsF0/gsQYpi7ByxyrXiyqsILT8Ac0W2OwBzjN4DC+eP+CsM1NqyVxNBj3H HGlnOx04tLXa2motI07fS5q5KhYzdXPDdUtf1Oeeqd1qDdL2miXQMYfMdFOKK2XWkmrbW7li+xsP eF3mSil90OSaH6Xq1N0K33eyCa6b4WAIAXwGdodsf6Xm96Ag0QJuK2d+/7sAqa6awnNq56QknAiW rx4rzaGm5kkdjASGtiw4eJKuOqmISiMX6J7/CrnLlj+tK6ePF/c758SmO/yrxa/uWYKKTO4qkbc7 l0u6nVaae/IttB5LwuA6mV3BZUYZr++jt/t0le2+Tr71ysNcYPPrhcyr9NAvruvJ/Mp+3eWlKEo/ +tS7Lz4zhSp4I8Per+SXIOcBT4HCS5/u8AcN/bVPgOP7HwKVtkDqCY90THNg/xCYuQyejoM+W98D e6c1LenGbo6DYLOsg7zqtXCE9COPpp50ucrJ0Ia9YpYBo1dCdTCPbgkcl8/ghiSqce05CiLGJWg0 uXClUEpBHM61WjW3K/+OonaoIaHb+sa2eV3IiFESkrh2YL/GpPEyQ1jjW/KyATeC5Y1GwIkb5WgB PNLRHWy0wcKCoMfHoMUE+5hKIPsIsRzg8ZAeEBlimliCszRmj4PMWAiGssZMUiEpdiRBIeEIyUem oJOMyeMIDsJIQSLSB6lE2s+6iBevofFmWllGWybJqqQ1rgI6ayUbm4I7lH1FDaS8nyhNhMphhuYx oiuWMXFJSU8+00BXwcsnQaNIUNISg7mEJjZn1j9lvkonQUnLMUEgolAaLy0A8+Vmvvi1SZ3xauZB jtbsJcYSlbFxtakcrVoDJHnKJW737BHZurYcgFpxPgeVGzDlec/dLDT/oM6BleL+9iFMpEhwrrMc N6XjwRliFFSyeh/7itFMERaOcWDSKEqdeb6yXHSl0oIWTGsAQgKK9IX+q2AIqxeAgb50px5VYOKC KSqOeW5I6+mp/5KaI77tTKcX3Jw6dbjBmPJulzLE4e/waTLuQNWF1TNgArEzANN1bjs/xZyEzAfA GX7vgOusagxLc6dnES9VFnwcWxEHPia+y1w5rc/WrOZWox6vqRoraQkLy9ibYu2ke22f8ZS6Vgb2 zrHdJOuX/goQtPI0Sx60C1Zxdw1CmVCyqqHsV0XbV+eBNiFMVZYwNZus541GqXjlhVD1JlkKstZY IAUW4f6TIb2OTF01/4Rp5d7Dwj6JY4ghHZxjYtdYFhhHAGkLY9VSeK4wxY2esFQXvqx4XLEeNZ7Z RW95K7ogQHErvE161yPHqLb4InGq4HyldpsQlqXNghIdMIs2semToIlTwRq4mCYMLIMzuDOS7S1l FdVZyWUut78fRSdPStCPv2hCjxPm4zFHzIISezPDM/jjgStGRD/2scQqBjAiJJnIBo9gG2cQ6geS sg5HQlKWpwzYio18zm/iVMkcIPAcsQLJWxaJUUxO8nA7G81LPvkxDH6BggOiL3JaeGl+o7KW/4Bd CnQZw6ocs/r+h4R2btPNdH6zKdcJZ5+hWM3U3fOGt4zkHN+5xh1Fg//b0BG1fzr0nPb87hKXWNSK Juk5jU6cRAvYUGoFzl0TNM22pgPQ/LZQ0bDd2l2iG7lNVVBjsAjH4SKLUdP5KlljLLRIg8XVHt11 gjdmad8iLV27OfmzgbGsTm372CFTFbX8xLN1Lwxr4XYVsHEVoQbTFK30Vnt6Xja2kn562th69lM/ 9PZWjX1FwY4W1mvqtGLdbVltQ7Zhq13qB+t6beXJQ607jHcMD1vQHh4gzZnwMVGRN+98P1qhzj32 fv+7WBrSNdk+xbdNow3vzbplWVItdYZGerfTPfXCjcIbAR9c7Ijbe+IDrDjFy63yrm6c2kwz67Zg W1mV9yzYuMVzLXf/6Stwe7W5Ix0ryNtDq+KedS9KLzMLlVnr4sKLtwViXtRvCkRXssygEWVXLzqu HPJCvaEel6KX5sNdLHodN/bFMBlBDlZo6+KJXc+n6y5dh7RDKq1id9f2An6Cclp5lHEcvId1bAQn 71jQdr5zLRoCMhWs+QuEXkHlhzD5P3Pi8nXufJbpLGIYC7goLRjYi6V5ZD9HOMX5kLAVXO/Kj8uB 8z/AJE9CXGXHB9qcHVTa8lS9C9rbJPNs5uQq5Z5dXIv+9C8jPTQPpseZq4/vAxI+RdDGafhiLTeV njSkJ01fWCKaah18+0K371Dik6RcGK9pEZ/N3IbzKdVAp6C6f53r/+WfNH7HPh9ucw4zw+Z/hrZs /6Z/+zdbQaJCOHQ2BcgPDdhzI9dz6jcSUjVbTBIUgkFz1hY25ZNFfHVBTwVXmDVtB3hv47Z0DkiA vddyKBhClYU91icRzzU8qpVxKyde+1d1LcJvjdAU3NY6MjiDfPU5RIVf0iE4z6ZDSVhd9qeEF1Vh +0KD2lcVZAd+V9h2+1RPdicvraJF3gdR3aV5JpgCg0GBZBgJSCNBaEgQRKZFbBgRQgiHtrR7c2iH d0iHeKiHe8iHfeiHfwiIgSiIg0iIhWiIh4iIiaiIi8iIjeiIjwiJZkADcpgFlBiJl4iJMHGGWvcP m7gKeTZNkncR0v82GkSgQ0LTbZ9HDaTIYhjgiaCEWTpjTTlDGaLhYkdmeLwHZW0mZDboc5CwOaKG H99xaKHThXfXGqTGXqqBWNgHUVS4hbkQVOfHjAj1d4aVfZJGULxlNR5yCsoodvOFbdTYNHXRVM8i LBzlQtpWLajGUbbAJ64WadXXUiaVUcC2a0q3ahfXjqgWOIrDc1FIAl6YgxyYVUtSW+SmgivncpaV YDFHbAh3gzXnGGCXW7cjgPL3dQK5eBLYGQcJPppjcS7Yfzj3VHo3WBA5VKtlVWeFjeIzkfWWkCy4 MQ0JkxqnOXDlUyM4giNpKnM1cQmHPX9nD0JXalvSk+nGcHKlk0P/45E3yZCtpXkwGE4HeYpVqZIX +Td542xO5Qo9mC22JpUcWYbmGIEm6VFrWG3oYTsbeYPJkAbT+H9+5VVcGUTUN4AklSiGgyScWJbU IWvMsmrl8R3ouEJcxR8KWFevZnWs85HQdY+bBXcpaFxYaZGUiVFp1pIIoJn89YZXA5LuhVyy5IxZ yBpph25hOJqI5Xfo52irqWmmKZrjBY1HZHbzk5qmJjFW4Ims2GGTdE2s1wnJpHujh3qo+JuNp2bh hHjKCWjOF2NjwHli9mQMlk7BpEaQYIl2uJ3FSQ6HRJybtxGXyUvNmXuqiIvHFxiqV3gRYSuJoXjM h0vUpWXQuV5v/4QTfRGXNMkQFkiLKXdgrTSLyUmWoDiErpSf8jlndWifH/ZRv4eczvmLENGA8JON yiJqLkWOHngasHcKcsElsvahz7hP07hvWkiOKWp+UkNpoTY3FuoPvgg4WHedxRKYKLQgEGpc/PaE IAiFRxddDwVe7DaZChFuRmlC6BKTjRWC7yZxWkk6L3if4dYQR9qVDqSkMVdA/fdtYJV15ziRJASb 9+eSBXGkTWmA/JGlAEeUFdJxW5GR/AeCGzhXdeqTAgc9rIkP78mBhbYsiDaVWzqXsnUj2XaXWIls 7PaKemClt7U+gBqFN4SWJDmpOImdZQql8SWh42A7HGcfUEiD/P9DpAzYdD5EqvWGp7eWVUnnf5K6 p18qHc24jITxpiiJm/QSZbOpq2SkeLzKgGDIF2WzomBnfplGWxXjSwmaTcLJoJmIZYvqrGBQNtFK rdVqrTXRnddqENqqMNzqMN4KruEqruNKruVqrueKrumqruvKru3qrofYSvtpMOKarR0BffX5Bsna EvX6ri2mT7loNAkFeHHWiqaklhURrEnJAFz0n2PoDcagWml0sP5VBm0li8h3BOxYoI7Kn0EAraWI sQUWsg9roFvnsLPUsVQgDuKIonE3PxxKjB3aafCUjaWpjf1BRVRos1oIOv4Blq35fgrlokzUaODn Jd71sQtaU6//9qng4Z+RyWwzCqRFN1MaO7VS21sauW6UQ6fux1YXdaNam7Ke6W8VZlbEwW0GQHBR qmyD2n5EKqaG2mxRa5Syd7YLaYqD+Wd3C28phYMK53AepxhepHfs6Koh2KUYlLiKireYp7e32kR8 G1hpu21h6bY4mqYOZHJzC7j/JqYctHDRo5MP1wN7Z4xwJrkUKZYZpJg2yZBoG6YeNI3EuLpsS6gP YoME5psTekIhRXGM27S1q6UJ12+ZW7nBVX54G5EoqJWBKgSm6zj0ebV6SbnxB3NMi0JWC5A0d39t VZnfa72nanMBmVnPG7mACYbvpam6SZO+ujuLZm74wjXhkV9J/yi/RxmN5qV2XAiaWpW+kEu6ZWB6 LsCvuwh89+kSxaSez9lm5zlm29mWX4GXg2F8h0cHBfwxDhycRvOAA7sEGBydnkGJILx6DZplJOyd GlZkgYeeltfAC0ygHGB7Jsxm4rSp2zozekq2hHScn5mKIJuvCDy2IotlS3ayR6y0JcvBCOigWgBm ISuvSYydliBIsPecE+uXuVeQvOuKQpy0GctNDMOeUlwDPyvEM/ZNsqcgUVyeXDay27kdPwILfDE2 A8BdjlOMrvmZj2Y4t0lPGckcOAtF5EYl1hiNbXpASvSYQ0uC+7SzKVq6d/WmJ4i1hgVcGDXHB5eq 7QEhUEOEnP+Ff3BBvnIiOfcxyhjqj3BcP6fys6ccnwapkIvDisSDuIM7ZR/5Wn46pYD5VWDZmGcZ yUaYl6lqXEUZKFyRsEt5pxzYll60gfPoOQ92brL8q+EDbY2axT/ckkgqzGmyV1lbfoUMgU/JWq46 mdVLvs0ElNKFd5QcH2jqA1hUkthIvNOzmdJHirXcFUejpYLLPtJmDmrcz+YLu5hKa8oby6jaUWaC jrC8gn1pawBoc8+cmyXIV6KaBNPlTPDIcj8EuhDEjU0rt5gb0kV0qfq1XLMm0OT7patiw1R6ldMy ZOQnXJspmvgljd83ZVIEaTdbkLE4pLUrjARlXqIcfjfLvmz/t4X+68H70axEobLLykqel7ftOUiE xsa69NQWJng8nC83zAMk1rslXMGtCHvUqcKQ9wL2M8YTs8IANokU1sLumhjx2q+AxJzRkczfeNeh 1Uj8GZul19cMTMZht06apIvv6o3kZ8puGNj3pox7TaIBjK7B6o+3NjtHnaigurQ6Mth2dWUTqnw2 fbuDTc5biXxm1m5MDatDjK6dzD0GLXcCRJTKbJBuqK6VRRcxPdt3N39O6trhmnNWG0wyCtFbq1sb C66Se1wP+cm4pNGqSr3kOa6TfKtQA3jaIseqfQe26tPpls2DLdZ5DbCmzZvmnQfUjd7rzd7tLWPu Dd/xLd/z/03f9W3f943f+a3f+83f/e3f/w3g5IrC5tnDKBvghjjgTMDWjwfWf117qpDgLBHhO7y6 5a2DpwsFE65NZUKBX1wzfHnGy3nSK4CX29RjjLTFWg1xTeB0gsQz5L3i08R0IEaxMV4Ot6WsXTzi orjEACrTLlteRluiXmpG8KvHssmy57B2prbdfaerSFl3RMuaHPq/gXxuj7yiR03ZpzZ0pNzcPujF RCePljq9PETMf8OEpPx0kIncpM3mxBIcQUrJHi68vzsnLs17y/PYtvu43bzasYuQVyqlOy6m01bo V4XEJL6PlbpTDVK4SCUhqgWS2FvMDLdRzPvM3nfoqhteDv8SLZuL6UrpKU7tlbzmJK+cPQnN6GBE psWLqoOjsMH76sOc1Avoktt8pZJJNPi7pEy6zMcbuJL50b9N7MhgOo/CxfD3pKvs0OX0g4nO47w+ 0L036Kcdn3DKvYDevLSO68Ac6McKzN3egrqu4vlXqqO6O2IOt5t82TOq0pw1a11+dJvuyqbaUx5d Q+ZsxD5M1P+r1HXshXQn5EWYUcm4oQx1XsWafl9T0zTN7eHSv1Wobs+O1HGXJFpgnVRdR52o8ULw F6XBrzNMw89pxQLT8a5VwxbOBLidPBru8c43wCUMyXnYxDJP2C4Mwz/2wjtPeJWIrwWrPuCZnkRw i1ad2DH/HMMySOeueBzhzWEpHO0RWsQbYy7dqRtRbmlYP6ugjMUh/tztmYFcDOMizrHNV+FHvzPw M1MR3e5skVsSBBVhvhhZbcPtI2Rn/2EQJnd3z4JLz8FqOs9Zyc3yPnoP9ZISO07AueOZbWUzXtiJ XnmFzkENbbuTI9nTC+T8iFJwc/lYrqdUjqJIZMypAY4Vr+UqCmrcR1jizKJHUpQ6/J+xiQ4NvZLA IxmD/6OZQOkWzVCpvNmLflyXnA09yzlvDpB8qriWw6pL2/VdfPUF7boOnahFSqtPmuJ7kpWd5b2f s+ew0br0aZWBT1qjbiVqxdssM09+bu3cPo8A7bvTH5Wi/56Xi7vq9E634v901jaFim7oBADM8lSR 3TUTE323SpaxXXPbLA8azNPjVFLsQvZATxB7UZWD4TALaG1U+/GIRWME0vpolEDlrjmkpIa0HZVZ /WCjP+gyp/CBrcSvWZt0CXnTJztolM+ZaicbV15n4VmsromrCpDuqosQz66LjGFs620v74XvkS8O wJFOU88Nx8GnkwPUT2KM6xLs1GDUE0lsktKVsrUntkEWZEcgUxaUKs5wZfEQ06tPI0Bgc3ni5mHm 2SQR+lY6wVdAEDW0jbpiZsp6NZrGMRw6sxphKrtaPRUaSiZ63cyZLADBFH3J3Dqd0T0yqJYIYlYM z0Etr//mAFT4EGJEiRMpVrQYwuFFjXMMFrqY8drGkHRAfrRYEqFJkStZbuzYCBbMljM3oByZEqMm kDtP0pRjcwxQn0OJFjVa0abGpEdr8ljKFGpUqVOpVrV6FWtWrVu5dvX6FWxYsWPJljV7Fm1atWvZ tnX7Fm5cuXPp1rV7F29evXv59vX7F3BgwYMJFzZ8GHFixYsZN3b8GHJkyZMpV7Z8GXNmzXCfbt5a srNnnV5DH3yasbTRpat9pmbmmgjsmQNkM3Mm8GdklLe9Nc358NdgfzKseTB3kSBDTRFQ1t4k1KPv g8mXvVQe/OZv6ePWnpkFkXoRkNbRkndqaVk68xcyscr/vdc7yfd51r8Wrzy7Uu4Pm7cRUjoFnkRJ aKP2tsPpKBZwO0ecbhqcZ55mHowBuwVwu+CefRqMohNfqAkPnt5EuAdCEkXkzZsLbzDOwhRr4EUI gQARkSgSuMFlISnQI6WZI775LgYec0yljkgYEQbISwi68Q4h4emmyO+UjBKI+jQ64xMciwjGE0i2 lKTCMB7IKAlFApGEStvos+XIgbzE4TgM8kETyYDSGLIoLOv0sYZt3vTvzpjEVEAZQOv5QMMP6TRm uQjdBDPH5MxsUx8qP4lJy0qalAoK9y51dBEtGbxNDhzd+09TOue0UEdLv/yGH2IGUYdUhkYgzg5T AHUV/w1GN9VjKj2HDNPXVgXd9dJI91PkVAwzyNQNbRBUts8Ye5X1WEo5bFMCboAdlNNQFyW2IGt3 vTY+RMYtF9pu+cx2CE/NhfdRA9Pd1qBDA1U3KmHLRWZZJx8FF9lh7DT23IFjgPHd5HT9cdYd+5l0 SohHZLPUbWnhNk9xpbiQnmNoXXRPav2gUWRY9cXzY5RV/hfMBVN8UGZpggP5pRRUBIdl0dSykrAA DRaOKee0AnqwnGXy2bBKK0v2Wqbtk5rqqq2+OiqGWzIaLK4b8zouHJHeQBlewMYabYvEVnvotN1m ilzw3p67IlI/PJFnL0BuEQkTZ5B3Z5vpRjvabeLsEf/h/YKUmIR9nNxwcKZ1TqScPaVt+EwjOY48 s8nZ5BJRQHmJcFWE2j2Yc88OtwTXQCd+d03X+d08dcuYiz3btV+FVPY/aa+dMs/XrZZkhYs9PtWe gQ/eXZHD6XL3jVEHXZyxly+sVnpuX5G+Bld/+ZySQ9TX6eupPruopKw3P7CkWJuJa2/Zn187hNBv FHL6LevvKAHT0/9qjnDfaBrCEv8BkH33Q+ACGdhABz4QghGU4AQpWEELXhCDGdTgBjnYQQ9+EIQh FOEISVhCE54QhSlU4QpZ2EIXvvAw64OhYIgTEefIcIaAuYQCYZfDp7WNP+cBkg8f84UMSWhljlpH 9fLSRqH8ERExUGMOkywGjG2YCYdQlIuf2BOf5M1Oi4yp4ec4FCFJKS+M7UscrigWuzMiMYtpfAsX c7cvygEkjnJkC+god7A3AlGPfRFexRD3pID4I2KBxB6yapbEvKUgG4KDoyITYzTyhIaHlNSL/DQJ QIFkspOhFOUoSUkRUJZyMqdE5WZUuUrItNKVsZTlLGlZS1veEpe51OUuedlLX/4SmMEU5jCJWUxj HhOZyVTmMpnZTGc+E5rRlOY0qVlNa14Tm9nU5ja52U1vfhOc4RQnLQsAADs= ------------A48356845382213-- From ippm-bounces@ietf.org Wed Mar 2 16:19:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28084 for ; Wed, 2 Mar 2005 16:19:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bBl-0005a8-Fg; Wed, 02 Mar 2005 16:15:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bBj-0005Ys-EE for ippm@megatron.ietf.org; Wed, 02 Mar 2005 16:15:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27697 for ; Wed, 2 Mar 2005 16:15:20 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bCu-0003AO-Bf for ippm@ietf.org; Wed, 02 Mar 2005 16:16:36 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j22LFCla051085; Wed, 2 Mar 2005 13:15:13 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 4CAFD77AA49; Wed, 2 Mar 2005 16:15:11 -0500 (EST) To: stanislav shalunov From: Mark Allman Subject: Re: [ippm] Way to store traceroutes In-Reply-To: <86acreblev.fsf@abel.internet2.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Hammer to Fall MIME-Version: 1.0 Date: Wed, 02 Mar 2005 16:15:11 -0500 Message-Id: <20050302211511.4CAFD77AA49@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2082880711==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============2082880711== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain I am interested in this topic for a number of reasons. I have thought about how to store measurements and meta-data about measurements (which is at least as important as the measurements). A bunch of our thoughts have been captured in ... Mark Allman, Ethan Blanton, Wesley Eddy. A Scalable System for Sharing Internet Measurements. Proceedings of the Passive and Active Measurement Workshop, March 2002. http://www.icir.org/mallman/papers/simr-pam2002.ps I am not yet sure I completely understand the motivation behind bring this up within the IETF at the moment. Maybe someone could fill in that detail? Also, CAIDA is currently implementing a measurement repository and so they are defining ways to store all sorts of meta-data-ish kinds of things. I think it'd be good to involve them in this process if this is something that IPPM is going to do. (Because they may well be a user of the output and they have thought about the issues quite a bit and will likely have some useful input on the storage scheme.) > One thing I'd argue against would be the use of XML for textual > representations without a standard binary representation. That would > encourage wasteful practices: XML is expensive to parse. A textual > representation that doesn't require parsing without a binary > representation would be fine as far as I am concerned. I would actually very much argue against a binary form of representation. The way these things are stored is only really important (from an IETF or "standards") perspective in terms of dealing with "interoperability" ... i.e., in terms of sharing these measurements. It doesn't matter to me how you store the measurements you take and keep for yourself, nor does it matter to you how I keep mine. It only matters when we want to swap. So, given that ... I think XML is the right way to exchange information. First claim: XML is wasteful. Well, yes... but, it compresses. Not to the size of a binary representation, but never-the-less still decently. Second claim: XML is "expensive" to parse. That depends on what you are considering in the calculation of "expense". I consider it easy to parse given that there are libraries all over the place for every language known to man to do it. I.e., I don't have to implement some binary slurping of some new data format. So, XML is *cheaper* for *me*. For the computer parsing XML is no doubt more expensive. But, I am very much happy to exchange computer cycles for my cycles any day of the week. Maybe I am weird. Also, you didn't give the flip side. While XML is a bit wasteful and it is more expensive for computers to parse the big win in XML is that XML is *extensible*. Binary formats tend to get locked in (even binary formats that have version numbers). E.g., look at the libpcap packet trace format. It's there. We can't change it. It'd be really really nice if we could change it because it'd be really really nice to further annotate packet traces sometimes. But, we're stuck. This is a little apples and oranges --- libpcap is meant to collect packets very fast and collect *tons* of "measurements" (packets) and etc. and so it's harder to argue that it should be something like XML. But, the point is still valid about traceroutes I think. Packaging traceroutes and passing them around does not involve the same sort of performance constraints. Extensibility offers such niceness in terms of all sorts of things from notes inserted by data collectors to new aspects of the measurement that will be taken in the future but are not today and so will be left out of the binary format (e.g., if traceroute sticks in the AS number of every IP address in 3 years, where is that in your binary format? you're up a crick and will have to go through the bother of defining a new one ...). So, we should use XML. This is what XML is perfect for. And, finally, if someone really cares about processing speed (and, no doubt that is an issue sometimes) then a small XML->binary tool is pretty straightforward. I.e., we can always take something generic and streamline it for particular purposes. But, we needn't get rid of the generic extensible version because sometimes we might need a streamlined version. I think not doing XML would be a large mistake. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCJizfWyrrWs4yIs4RAgstAJ4u8ORRPG7WHcCRcEvL2ncEEgm4JgCfVQcc VweDaWmIHY9F4OGWhfWSxxo= =KXlY -----END PGP SIGNATURE----- --=-=-=-- --===============2082880711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============2082880711==-- From ippm-bounces@ietf.org Thu Mar 3 05:43:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05180 for ; Thu, 3 Mar 2005 05:43:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6niA-0007As-DF; Thu, 03 Mar 2005 05:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6nhp-000798-0S for ippm@megatron.ietf.org; Thu, 03 Mar 2005 05:37:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04761 for ; Thu, 3 Mar 2005 05:37:18 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6njA-0004V2-6S for ippm@ietf.org; Thu, 03 Mar 2005 05:38:44 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5D6A510B3B; Thu, 3 Mar 2005 11:38:51 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Thu, 3 Mar 2005 11:37:10 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcUfbS2pw0RrLAUiTBu3u3zgaSnliwAbY5Gw From: "Sandra Tartarelli" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear Mark, Thanks for your email and for the attached paper. We will certainly read it.=20 > I am interested in this topic for a number of reasons. I=20 > have thought about how to store measurements and meta-data=20 > about measurements (which is at least as important as the=20 > measurements). =20 Nice to know. Of course if you are interested in contributing with some text to the draft (current version: http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroute s-00.txt) we will appreciate it.=20 =20 > Also, CAIDA is currently implementing a measurement=20 > repository and so they are defining ways to store all sorts=20 > of meta-data-ish kinds of things. I think it'd be good to=20 > involve them in this process if this is something that IPPM=20 > is going to do. (Because they may well be a user of the=20 > output and they have thought about the issues quite a bit and=20 > will likely have some useful input on the storage scheme.) We assume that CAIDA people read the IPPM mailing list, so if they are interested in contributing to this activity, we hope they will comment on this on the mailing list. Their contribution is obviously more than welcome. Best regards, Sandra Tartarelli >=20 > > One thing I'd argue against would be the use of XML for textual=20 > > representations without a standard binary representation. =20 > That would=20 > > encourage wasteful practices: XML is expensive to parse. A textual=20 > > representation that doesn't require parsing without a binary=20 > > representation would be fine as far as I am concerned. >=20 > I would actually very much argue against a binary form of=20 > representation. The way these things are stored is only=20 > really important (from an IETF or "standards") perspective in=20 > terms of dealing with "interoperability" ... i.e., in terms=20 > of sharing these measurements. It doesn't matter to me how=20 > you store the measurements you take and keep for yourself,=20 > nor does it matter to you how I keep mine. It only matters=20 > when we want to swap. So, given that ... I think XML is the=20 > right way to exchange information. >=20 > First claim: XML is wasteful. Well, yes... but, it=20 > compresses. Not to the size of a binary representation, but=20 > never-the-less still decently. > Second claim: XML is "expensive" to parse. That depends on=20 > what you are considering in the calculation of "expense". I=20 > consider it easy to parse given that there are libraries all=20 > over the place for every language known to man to do it. =20 > I.e., I don't have to implement some binary slurping of some=20 > new data format. So, XML is *cheaper* for *me*. > For the computer parsing XML is no doubt more expensive. =20 > But, I am very much happy to exchange computer cycles for my=20 > cycles any day of the week. Maybe I am weird. >=20 > Also, you didn't give the flip side. While XML is a bit=20 > wasteful and it is more expensive for computers to parse the=20 > big win in XML is that XML is *extensible*. Binary formats=20 > tend to get locked in (even binary formats that have version=20 > numbers). E.g., look at the libpcap packet trace format. =20 > It's there. We can't change it. It'd be really really nice=20 > if we could change it because it'd be really really nice to=20 > further annotate packet traces sometimes. But, we're stuck. =20 > This is a little apples and oranges --- libpcap is meant to=20 > collect packets very fast and collect *tons* of=20 > "measurements" (packets) and etc. and so it's harder to argue=20 > that it should be something like XML. But, the point is=20 > still valid about traceroutes I think. Packaging traceroutes=20 > and passing them around does not involve the same sort of=20 > performance constraints. > Extensibility offers such niceness in terms of all sorts of=20 > things from notes inserted by data collectors to new aspects=20 > of the measurement that will be taken in the future but are=20 > not today and so will be left out of the binary format (e.g.,=20 > if traceroute sticks in the AS number of every IP address in=20 > 3 years, where is that in your binary format? you're up a=20 > crick and will have to go through the bother of defining a=20 > new one ...). > So, we should use XML. This is what XML is perfect for. >=20 > And, finally, if someone really cares about processing speed=20 > (and, no doubt that is an issue sometimes) then a small=20 > XML->binary tool is pretty straightforward. I.e., we can=20 > always take something generic and streamline it for=20 > particular purposes. But, we needn't get rid of the generic=20 > extensible version because sometimes we might need a=20 > streamlined version. >=20 > I think not doing XML would be a large mistake. >=20 > allman >=20 >=20 > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ >=20 >=20 >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Mar 3 12:17:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19915 for ; Thu, 3 Mar 2005 12:17:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ttu-0000tg-5G; Thu, 03 Mar 2005 12:14:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ttr-0000tS-PI for ippm@megatron.ietf.org; Thu, 03 Mar 2005 12:14:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19578 for ; Thu, 3 Mar 2005 12:14:09 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6tvF-00069S-Kq for ippm@ietf.org; Thu, 03 Mar 2005 12:15:38 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B68AD14C3F for ; Thu, 3 Mar 2005 18:15:44 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Thu, 3 Mar 2005 18:14:00 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcUfbS24Dv+w8wJrShir2ZxQRdISbQApGFVg From: "Saverio Niccolini" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > I am not yet sure I completely understand the motivation behind bring > this up within the IETF at the moment. Maybe someone could=20 > fill in that > detail? The answer I have in mind to "Why should we need the format for storing traceroute measurements?" is: -- for exchanging information among different systems (interoprability) -- for storing the same information locally While for the latter we need only an information model, for the former we need also a data model. Anywway I am not sure if other people share the same view, thus I would like to see other comments. > Also, CAIDA is currently implementing a measurement repository and so > they are defining ways to store all sorts of meta-data-ish kinds of > things. Actually the work we are doing for the draft is inserted in a more complex framework in a European project (MOME) where we do already storing of meta-data (measurements tool and measurements data) in databases. If you want to check it out have a look at http://www.ist-mome.org/, there is a section on Database, and you can find more info in the publication section. Comments are more than welcome. Best regards, Saverio _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Mar 4 05:52:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27960 for ; Fri, 4 Mar 2005 05:52:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7ANr-0004pT-8V; Fri, 04 Mar 2005 05:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7ANh-0004oC-DY for ippm@megatron.ietf.org; Fri, 04 Mar 2005 05:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27729 for ; Fri, 4 Mar 2005 05:50:02 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7APE-0006qu-Ia for ippm@ietf.org; Fri, 04 Mar 2005 05:51:41 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 1895C24662; Fri, 4 Mar 2005 11:49:55 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 37B302465F; Fri, 4 Mar 2005 11:49:54 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j24Anreu031708; Fri, 4 Mar 2005 11:49:54 +0100 Message-Id: <6.2.0.14.2.20050304114600.02c58a20@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 04 Mar 2005 11:49:51 +0100 To: "Saverio Niccolini" , From: Henk Uijterwaal Subject: RE: [ippm] Way to store traceroutes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000072 / -5.9 X-RIPE-Signature: b53b1c32d422ae73cc26771f2f0a626e X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 18:14 03/03/2005, Saverio Niccolini wrote: > > > > I am not yet sure I completely understand the motivation behind bring > > this up within the IETF at the moment. Maybe someone could > > fill in that detail? I think the question is more the other way around: this draft is an individual submission, we (as the ippm group) are trying to decide if it should be picked up as a WG item. (I personally think that we should, as traceroute is frequently used and there are huge benefits in having consistent and exchangable information). Henk >The answer I have in mind to "Why should we need the format for storing >traceroute measurements?" is: >-- for exchanging information among different systems (interoprability) >-- for storing the same information locally >While for the latter we need only an information model, for the former >we need >also a data model. > >Anywway I am not sure if other people share the same view, >thus I would like to see other comments. > > > Also, CAIDA is currently implementing a measurement repository and so > > they are defining ways to store all sorts of meta-data-ish kinds of > > things. > >Actually the work we are doing for the draft is inserted in a more >complex framework >in a European project (MOME) where we do already storing of meta-data >(measurements tool and measurements data) in databases. >If you want to check it out have a look at http://www.ist-mome.org/, >there is a section on Database, and you can find more info in the >publication section. > >Comments are more than welcome. > >Best regards, >Saverio > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ixwuk@go2.pl Fri Mar 4 12:30:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08831; Fri, 4 Mar 2005 12:30:17 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7GeT-0008B1-IZ; Fri, 04 Mar 2005 12:32:00 -0500 Received: from s155.itokyofl180.vectant.ne.jp ([202.215.217.155]) by mx2.foretec.com with smtp (Exim 4.24) id 1D7Gcq-000894-0u; Fri, 04 Mar 2005 12:30:08 -0500 Received: from symphony-74.go2.pl ([88.102.173.104]:1906 "HELO mail.go2.pl") by go2.pl with SMTP id ; Fri, 04 Mar 2005 18:24:56 +0100 Date: Fri, 04 Mar 2005 15:24:56 -0200 Message-Id: <4.6.13.2081924.0083fc70@go2.pl> From: "Darcy Lancaster" To: Subject: Congrats - You have finally made it. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit http://www.runninshit.info/mortgage.asp. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit neptunium newt

 
 
 
 
 
 
.
.
.
http://www.runninshit.info/mortgage.asp It's time to fix up your situation for once and for all
.  
   
No More ------------A85031401794097-- ------------A48356845382213 Content-Type: image/gif; name="emperor.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODlhbAHAAZEAAP///8zMzDMzMwAAACH5BAAAAAAALAAAAABsAcABAAL/hI+py+0Po5y02ouz 3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1mAtqu94vh gsfkq9hwLqvX7Lb7DY/L54kBwk7P6y94RZ/B9fe3R1i4MHiAeHgHkGb4SKgI0CfGlSZ44NgIyfkm KTgQmjnJeBcq2Zn69ZlYaoDZGqs66xV4eitKWier28tLC3zF6vvK24eIGqzsNIx7avxLvDzNzICX DCudTM1d1OyQjdw9vjRMfOzqm03O3iNmPnmb/hcgn96OH6UpsZ3vj7MvzK5/BIsE5IOmoMKFDBs6 fAgxosSJFCtavIgxo8aN/xw7evwIMqTIkSRLmjyJMqXKlSxbunwJM6bMmTRrBjs4AeeWnEB0JvBZ iYLPnhKGKnBklEzSDfQgGF3aT8lSgdIcTO1wFYWdS36o/qxgNOrREKhQPfXqFMYgSTrFCh2rQwCC QD/dyrB7YeigM3gjZLUag17fYmTWnlvwdxRcQHMHLgaclas1wA+AUlacFilZx5swL6rcILENTOvi 5QJnj9SzV6snpyacqHVs2bjqyGYt6tPr19ZS29ld77bp0rp+C98t3NRq46dnn6792RjtrjtIz7vH ubjhaLHv8L3+65rjdaAaiOMenrWr5uSjXWsfi/g99vPRp4fd67wOdLD5Y/83j582k43nHoBVCYhg Qvf9t494A50HIXURUvdfgPpR2I9/E3qnQz2yaOjHQc5YGGJ0H8ryjnLLebYhd1wIIFmFuK34oIQ2 1ohjHY6UpeB5ttyS4gMg5mgfDb/tAsqIA8Znm5IUnjijb+P55oyDjDQ414XZWcnkKFwShsd3CCpS JY/p0EVigNH516WMRh4m35JtqglgjGxmd+CXV8q4HYdPgnljKRDuqOaXaPIzkJj6RXUkL2hqiUOj rcRpIqBucnbonX6ipyeKdKZZYYuWChronKNeumWpmUYg6Zh/5kDmnzy+o2eftl0XJJTqHQZqeXLi h40phQ4L7Dy1QsNrpYv/CvtpVzFOIuauPMTqB2/V5kYndIvwtha3zxzj7W3yYMNeck02Kqo6x31L 7IwqbkOjsdjOJuQh685Ly2A2IaQPDFnp69cTkXXhoROixVAwQQEd/CY3DIvwMMFsRLyvChQrhXCz J2x1A8A3RGyPZkVWR5ZsF0/gsQYpi7ByxyrXiyqsILT8Ac0W2OwBzjN4DC+eP+CsM1NqyVxNBj3H HGlnOx04tLXa2motI07fS5q5KhYzdXPDdUtf1Oeeqd1qDdL2miXQMYfMdFOKK2XWkmrbW7li+xsP eF3mSil90OSaH6Xq1N0K33eyCa6b4WAIAXwGdodsf6Xm96Ag0QJuK2d+/7sAqa6awnNq56QknAiW rx4rzaGm5kkdjASGtiw4eJKuOqmISiMX6J7/CrnLlj+tK6ePF/c758SmO/yrxa/uWYKKTO4qkbc7 l0u6nVaae/IttB5LwuA6mV3BZUYZr++jt/t0le2+Tr71ysNcYPPrhcyr9NAvruvJ/Mp+3eWlKEo/ +tS7Lz4zhSp4I8Per+SXIOcBT4HCS5/u8AcN/bVPgOP7HwKVtkDqCY90THNg/xCYuQyejoM+W98D e6c1LenGbo6DYLOsg7zqtXCE9COPpp50ucrJ0Ia9YpYBo1dCdTCPbgkcl8/ghiSqce05CiLGJWg0 uXClUEpBHM61WjW3K/+OonaoIaHb+sa2eV3IiFESkrh2YL/GpPEyQ1jjW/KyATeC5Y1GwIkb5WgB PNLRHWy0wcKCoMfHoMUE+5hKIPsIsRzg8ZAeEBlimliCszRmj4PMWAiGssZMUiEpdiRBIeEIyUem oJOMyeMIDsJIQSLSB6lE2s+6iBevofFmWllGWybJqqQ1rgI6ayUbm4I7lH1FDaS8nyhNhMphhuYx oiuWMXFJSU8+00BXwcsnQaNIUNISg7mEJjZn1j9lvkonQUnLMUEgolAaLy0A8+Vmvvi1SZ3xauZB jtbsJcYSlbFxtakcrVoDJHnKJW737BHZurYcgFpxPgeVGzDlec/dLDT/oM6BleL+9iFMpEhwrrMc N6XjwRliFFSyeh/7itFMERaOcWDSKEqdeb6yXHSl0oIWTGsAQgKK9IX+q2AIqxeAgb50px5VYOKC KSqOeW5I6+mp/5KaI77tTKcX3Jw6dbjBmPJulzLE4e/waTLuQNWF1TNgArEzANN1bjs/xZyEzAfA GX7vgOusagxLc6dnES9VFnwcWxEHPia+y1w5rc/WrOZWox6vqRoraQkLy9ibYu2ke22f8ZS6Vgb2 zrHdJOuX/goQtPI0Sx60C1Zxdw1CmVCyqqHsV0XbV+eBNiFMVZYwNZus541GqXjlhVD1JlkKstZY IAUW4f6TIb2OTF01/4Rp5d7Dwj6JY4ghHZxjYtdYFhhHAGkLY9VSeK4wxY2esFQXvqx4XLEeNZ7Z RW95K7ogQHErvE161yPHqLb4InGq4HyldpsQlqXNghIdMIs2semToIlTwRq4mCYMLIMzuDOS7S1l FdVZyWUut78fRSdPStCPv2hCjxPm4zFHzIISezPDM/jjgStGRD/2scQqBjAiJJnIBo9gG2cQ6geS sg5HQlKWpwzYio18zm/iVMkcIPAcsQLJWxaJUUxO8nA7G81LPvkxDH6BggOiL3JaeGl+o7KW/4Bd CnQZw6ocs/r+h4R2btPNdH6zKdcJZ5+hWM3U3fOGt4zkHN+5xh1Fg//b0BG1fzr0nPb87hKXWNSK Juk5jU6cRAvYUGoFzl0TNM22pgPQ/LZQ0bDd2l2iG7lNVVBjsAjH4SKLUdP5KlljLLRIg8XVHt11 gjdmad8iLV27OfmzgbGsTm372CFTFbX8xLN1Lwxr4XYVsHEVoQbTFK30Vnt6Xja2kn562th69lM/ 9PZWjX1FwY4W1mvqtGLdbVltQ7Zhq13qB+t6beXJQ607jHcMD1vQHh4gzZnwMVGRN+98P1qhzj32 fv+7WBrSNdk+xbdNow3vzbplWVItdYZGerfTPfXCjcIbAR9c7Ijbe+IDrDjFy63yrm6c2kwz67Zg W1mV9yzYuMVzLXf/6Stwe7W5Ix0ryNtDq+KedS9KLzMLlVnr4sKLtwViXtRvCkRXssygEWVXLzqu HPJCvaEel6KX5sNdLHodN/bFMBlBDlZo6+KJXc+n6y5dh7RDKq1id9f2An6Cclp5lHEcvId1bAQn 71jQdr5zLRoCMhWs+QuEXkHlhzD5P3Pi8nXufJbpLGIYC7goLRjYi6V5ZD9HOMX5kLAVXO/Kj8uB 8z/AJE9CXGXHB9qcHVTa8lS9C9rbJPNs5uQq5Z5dXIv+9C8jPTQPpseZq4/vAxI+RdDGafhiLTeV njSkJ01fWCKaah18+0K371Dik6RcGK9pEZ/N3IbzKdVAp6C6f53r/+WfNH7HPh9ucw4zw+Z/hrZs /6Z/+zdbQaJCOHQ2BcgPDdhzI9dz6jcSUjVbTBIUgkFz1hY25ZNFfHVBTwVXmDVtB3hv47Z0DkiA vddyKBhClYU91icRzzU8qpVxKyde+1d1LcJvjdAU3NY6MjiDfPU5RIVf0iE4z6ZDSVhd9qeEF1Vh +0KD2lcVZAd+V9h2+1RPdicvraJF3gdR3aV5JpgCg0GBZBgJSCNBaEgQRKZFbBgRQgiHtrR7c2iH d0iHeKiHe8iHfeiHfwiIgSiIg0iIhWiIh4iIiaiIi8iIjeiIjwiJZkADcpgFlBiJl4iJMHGGWvcP m7gKeTZNkncR0v82GkSgQ0LTbZ9HDaTIYhjgiaCEWTpjTTlDGaLhYkdmeLwHZW0mZDboc5CwOaKG H99xaKHThXfXGqTGXqqBWNgHUVS4hbkQVOfHjAj1d4aVfZJGULxlNR5yCsoodvOFbdTYNHXRVM8i LBzlQtpWLajGUbbAJ64WadXXUiaVUcC2a0q3ahfXjqgWOIrDc1FIAl6YgxyYVUtSW+SmgivncpaV YDFHbAh3gzXnGGCXW7cjgPL3dQK5eBLYGQcJPppjcS7Yfzj3VHo3WBA5VKtlVWeFjeIzkfWWkCy4 MQ0JkxqnOXDlUyM4giNpKnM1cQmHPX9nD0JXalvSk+nGcHKlk0P/45E3yZCtpXkwGE4HeYpVqZIX +Td542xO5Qo9mC22JpUcWYbmGIEm6VFrWG3oYTsbeYPJkAbT+H9+5VVcGUTUN4AklSiGgyScWJbU IWvMsmrl8R3ouEJcxR8KWFevZnWs85HQdY+bBXcpaFxYaZGUiVFp1pIIoJn89YZXA5LuhVyy5IxZ yBpph25hOJqI5Xfo52irqWmmKZrjBY1HZHbzk5qmJjFW4Ims2GGTdE2s1wnJpHujh3qo+JuNp2bh hHjKCWjOF2NjwHli9mQMlk7BpEaQYIl2uJ3FSQ6HRJybtxGXyUvNmXuqiIvHFxiqV3gRYSuJoXjM h0vUpWXQuV5v/4QTfRGXNMkQFkiLKXdgrTSLyUmWoDiErpSf8jlndWifH/ZRv4eczvmLENGA8JON yiJqLkWOHngasHcKcsElsvahz7hP07hvWkiOKWp+UkNpoTY3FuoPvgg4WHedxRKYKLQgEGpc/PaE IAiFRxddDwVe7DaZChFuRmlC6BKTjRWC7yZxWkk6L3if4dYQR9qVDqSkMVdA/fdtYJV15ziRJASb 9+eSBXGkTWmA/JGlAEeUFdJxW5GR/AeCGzhXdeqTAgc9rIkP78mBhbYsiDaVWzqXsnUj2XaXWIls 7PaKemClt7U+gBqFN4SWJDmpOImdZQql8SWh42A7HGcfUEiD/P9DpAzYdD5EqvWGp7eWVUnnf5K6 p18qHc24jITxpiiJm/QSZbOpq2SkeLzKgGDIF2WzomBnfplGWxXjSwmaTcLJoJmIZYvqrGBQNtFK rdVqrTXRnddqENqqMNzqMN4KruEqruNKruVqrueKrumqruvKru3qrofYSvtpMOKarR0BffX5Bsna EvX6ri2mT7loNAkFeHHWiqaklhURrEnJAFz0n2PoDcagWml0sP5VBm0li8h3BOxYoI7Kn0EAraWI sQUWsg9roFvnsLPUsVQgDuKIonE3PxxKjB3aafCUjaWpjf1BRVRos1oIOv4Blq35fgrlokzUaODn Jd71sQtaU6//9qng4Z+RyWwzCqRFN1MaO7VS21sauW6UQ6fux1YXdaNam7Ke6W8VZlbEwW0GQHBR qmyD2n5EKqaG2mxRa5Syd7YLaYqD+Wd3C28phYMK53AepxhepHfs6Koh2KUYlLiKireYp7e32kR8 G1hpu21h6bY4mqYOZHJzC7j/JqYctHDRo5MP1wN7Z4xwJrkUKZYZpJg2yZBoG6YeNI3EuLpsS6gP YoME5psTekIhRXGM27S1q6UJ12+ZW7nBVX54G5EoqJWBKgSm6zj0ebV6SbnxB3NMi0JWC5A0d39t VZnfa72nanMBmVnPG7mACYbvpam6SZO+ujuLZm74wjXhkV9J/yi/RxmN5qV2XAiaWpW+kEu6ZWB6 LsCvuwh89+kSxaSez9lm5zlm29mWX4GXg2F8h0cHBfwxDhycRvOAA7sEGBydnkGJILx6DZplJOyd GlZkgYeeltfAC0ygHGB7Jsxm4rSp2zozekq2hHScn5mKIJuvCDy2IotlS3ayR6y0JcvBCOigWgBm ISuvSYydliBIsPecE+uXuVeQvOuKQpy0GctNDMOeUlwDPyvEM/ZNsqcgUVyeXDay27kdPwILfDE2 A8BdjlOMrvmZj2Y4t0lPGckcOAtF5EYl1hiNbXpASvSYQ0uC+7SzKVq6d/WmJ4i1hgVcGDXHB5eq 7QEhUEOEnP+Ff3BBvnIiOfcxyhjqj3BcP6fys6ccnwapkIvDisSDuIM7ZR/5Wn46pYD5VWDZmGcZ yUaYl6lqXEUZKFyRsEt5pxzYll60gfPoOQ92brL8q+EDbY2axT/ckkgqzGmyV1lbfoUMgU/JWq46 mdVLvs0ElNKFd5QcH2jqA1hUkthIvNOzmdJHirXcFUejpYLLPtJmDmrcz+YLu5hKa8oby6jaUWaC jrC8gn1pawBoc8+cmyXIV6KaBNPlTPDIcj8EuhDEjU0rt5gb0kV0qfq1XLMm0OT7patiw1R6ldMy ZOQnXJspmvgljd83ZVIEaTdbkLE4pLUrjARlXqIcfjfLvmz/t4X+68H70axEobLLykqel7ftOUiE xsa69NQWJng8nC83zAMk1rslXMGtCHvUqcKQ9wL2M8YTs8IANokU1sLumhjx2q+AxJzRkczfeNeh 1Uj8GZul19cMTMZht06apIvv6o3kZ8puGNj3pox7TaIBjK7B6o+3NjtHnaigurQ6Mth2dWUTqnw2 fbuDTc5biXxm1m5MDatDjK6dzD0GLXcCRJTKbJBuqK6VRRcxPdt3N39O6trhmnNWG0wyCtFbq1sb C66Se1wP+cm4pNGqSr3kOa6TfKtQA3jaIseqfQe26tPpls2DLdZ5DbCmzZvmnQfUjd7rzd7tLWPu Dd/xLd/z/03f9W3f943f+a3f+83f/e3f/w3g5IrC5tnDKBvghjjgTMDWjwfWf117qpDgLBHhO7y6 5a2DpwsFE65NZUKBX1wzfHnGy3nSK4CX29RjjLTFWg1xTeB0gsQz5L3i08R0IEaxMV4Ot6WsXTzi orjEACrTLlteRluiXmpG8KvHssmy57B2prbdfaerSFl3RMuaHPq/gXxuj7yiR03ZpzZ0pNzcPujF RCePljq9PETMf8OEpPx0kIncpM3mxBIcQUrJHi68vzsnLs17y/PYtvu43bzasYuQVyqlOy6m01bo V4XEJL6PlbpTDVK4SCUhqgWS2FvMDLdRzPvM3nfoqhteDv8SLZuL6UrpKU7tlbzmJK+cPQnN6GBE psWLqoOjsMH76sOc1Avoktt8pZJJNPi7pEy6zMcbuJL50b9N7MhgOo/CxfD3pKvs0OX0g4nO47w+ 0L036Kcdn3DKvYDevLSO68Ac6McKzN3egrqu4vlXqqO6O2IOt5t82TOq0pw1a11+dJvuyqbaUx5d Q+ZsxD5M1P+r1HXshXQn5EWYUcm4oQx1XsWafl9T0zTN7eHSv1Wobs+O1HGXJFpgnVRdR52o8ULw F6XBrzNMw89pxQLT8a5VwxbOBLidPBru8c43wCUMyXnYxDJP2C4Mwz/2wjtPeJWIrwWrPuCZnkRw i1ad2DH/HMMySOeueBzhzWEpHO0RWsQbYy7dqRtRbmlYP6ugjMUh/tztmYFcDOMizrHNV+FHvzPw M1MR3e5skVsSBBVhvhhZbcPtI2Rn/2EQJnd3z4JLz8FqOs9Zyc3yPnoP9ZISO07AueOZbWUzXtiJ XnmFzkENbbuTI9nTC+T8iFJwc/lYrqdUjqJIZMypAY4Vr+UqCmrcR1jizKJHUpQ6/J+xiQ4NvZLA IxmD/6OZQOkWzVCpvNmLflyXnA09yzlvDpB8qriWw6pL2/VdfPUF7boOnahFSqtPmuJ7kpWd5b2f s+ew0br0aZWBT1qjbiVqxdssM09+bu3cPo8A7bvTH5Wi/56Xi7vq9E634v901jaFim7oBADM8lSR 3TUTE323SpaxXXPbLA8azNPjVFLsQvZATxB7UZWD4TALaG1U+/GIRWME0vpolEDlrjmkpIa0HZVZ /WCjP+gyp/CBrcSvWZt0CXnTJztolM+ZaicbV15n4VmsromrCpDuqosQz66LjGFs620v74XvkS8O wJFOU88Nx8GnkwPUT2KM6xLs1GDUE0lsktKVsrUntkEWZEcgUxaUKs5wZfEQ06tPI0Bgc3ni5mHm 2SQR+lY6wVdAEDW0jbpiZsp6NZrGMRw6sxphKrtaPRUaSiZ63cyZLADBFH3J3Dqd0T0yqJYIYlYM z0Etr//mAFT4EGJEiRMpVrQYwuFFjXMMFrqY8drGkHRAfrRYEqFJkStZbuzYCBbMljM3oByZEqMm kDtP0pRjcwxQn0OJFjVa0abGpEdr8ljKFGpUqVOpVrV6FWtWrVu5dvX6FWxYsWPJljV7Fm1atWvZ tnX7Fm5cuXPp1rV7F29evXv59vX7F3BgwYMJFzZ8GHFixYsZN3b8GHJkyZMpV7Z8GXNmzXCfbt5a srNnnV5DH3yasbTRpat9pmbmmgjsmQNkM3Mm8GdklLe9Nc358NdgfzKseTB3kSBDTRFQ1t4k1KPv g8mXvVQe/OZv6ePWnpkFkXoRkNbRkndqaVk68xcyscr/vdc7yfd51r8Wrzy7Uu4Pm7cRUjoFnkRJ aKP2tsPpKBZwO0ecbhqcZ55mHowBuwVwu+CefRqMohNfqAkPnt5EuAdCEkXkzZsLbzDOwhRr4EUI gQARkSgSuMFlISnQI6WZI775LgYec0yljkgYEQbISwi68Q4h4emmyO+UjBKI+jQ64xMciwjGE0i2 lKTCMB7IKAlFApGEStvos+XIgbzE4TgM8kETyYDSGLIoLOv0sYZt3vTvzpjEVEAZQOv5QMMP6TRm uQjdBDPH5MxsUx8qP4lJy0qalAoK9y51dBEtGbxNDhzd+09TOue0UEdLv/yGH2IGUYdUhkYgzg5T AHUV/w1GN9VjKj2HDNPXVgXd9dJI91PkVAwzyNQNbRBUts8Ye5X1WEo5bFMCboAdlNNQFyW2IGt3 vTY+RMYtF9pu+cx2CE/NhfdRA9Pd1qBDA1U3KmHLRWZZJx8FF9lh7DT23IFjgPHd5HT9cdYd+5l0 SohHZLPUbWnhNk9xpbiQnmNoXXRPav2gUWRY9cXzY5RV/hfMBVN8UGZpggP5pRRUBIdl0dSykrAA DRaOKee0AnqwnGXy2bBKK0v2Wqbtk5rqqq2+OiqGWzIaLK4b8zouHJHeQBlewMYabYvEVnvotN1m ilzw3p67IlI/PJFnL0BuEQkTZ5B3Z5vpRjvabeLsEf/h/YKUmIR9nNxwcKZ1TqScPaVt+EwjOY48 s8nZ5BJRQHmJcFWE2j2Yc88OtwTXQCd+d03X+d08dcuYiz3btV+FVPY/aa+dMs/XrZZkhYs9PtWe gQ/eXZHD6XL3jVEHXZyxly+sVnpuX5G+Bld/+ZySQ9TX6eupPruopKw3P7CkWJuJa2/Zn187hNBv FHL6LevvKAHT0/9qjnDfaBrCEv8BkH33Q+ACGdhABz4QghGU4AQpWEELXhCDGdTgBjnYQQ9+EIQh FOEISVhCE54QhSlU4QpZ2EIXvvAw64OhYIgTEefIcIaAuYQCYZfDp7WNP+cBkg8f84UMSWhljlpH 9fLSRqH8ERExUGMOkywGjG2YCYdQlIuf2BOf5M1Oi4yp4ec4FCFJKS+M7UscrigWuzMiMYtpfAsX c7cvygEkjnJkC+god7A3AlGPfRFexRD3pID4I2KBxB6yapbEvKUgG4KDoyITYzTyhIaHlNSL/DQJ QIFkspOhFOUoSUkRUJZyMqdE5WZUuUrItNKVsZTlLGlZS1veEpe51OUuedlLX/4SmMEU5jCJWUxj HhOZyVTmMpnZTGc+E5rRlOY0qVlNa14Tm9nU5ja52U1vfhOc4RQnLQsAADs= ------------A48356845382213-- From ippm-bounces@ietf.org Fri Mar 4 16:13:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04264 for ; Fri, 4 Mar 2005 16:13:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7K4c-0003eS-B9; Fri, 04 Mar 2005 16:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7K4a-0003eM-CV for ippm@megatron.ietf.org; Fri, 04 Mar 2005 16:11:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04103 for ; Fri, 4 Mar 2005 16:10:58 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7K6C-0006EU-W2 for ippm@ietf.org; Fri, 04 Mar 2005 16:12:42 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j24LAjla084347; Fri, 4 Mar 2005 13:10:45 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id DB33477AA73; Fri, 4 Mar 2005 16:10:43 -0500 (EST) To: Henk Uijterwaal From: Mark Allman Subject: Re: [ippm] Way to store traceroutes In-Reply-To: <6.2.0.14.2.20050304114600.02c58a20@localhost> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: River of Dreams MIME-Version: 1.0 Date: Fri, 04 Mar 2005 16:10:43 -0500 Message-Id: <20050304211043.DB33477AA73@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1761623418==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1761623418== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain > I think the question is more the other way around: this draft is an > individual submission, we (as the ippm group) are trying to decide if > it should be picked up as a WG item. > > (I personally think that we should, as traceroute is frequently used > and there are huge benefits in having consistent and exchangable > information). And, just to be clear, I am not against defining such a format. I just was curious about the trigger for doing it now and whether there was some motivation besides just plain making it easier to swap these things. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCKM7TWyrrWs4yIs4RAswIAKCQw/gKF/J05f60XOsjB8SK6PhWGgCfceZf w07FNlWiyChJGKpgL22AKdg= =q8jA -----END PGP SIGNATURE----- --=-=-=-- --===============1761623418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1761623418==-- From vnukihos@go2.pl Fri Mar 4 23:09:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11812; Fri, 4 Mar 2005 23:09:34 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7QdL-00073a-SK; Fri, 04 Mar 2005 23:11:22 -0500 Received: from [220.125.160.64] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D7Qbc-0006gS-Bq; Fri, 04 Mar 2005 23:09:32 -0500 Received: from symphony-29.go2.pl ([173.71.237.60]:1906 "HELO mail.go2.pl") by go2.pl with SMTP id ; Sat, 05 Mar 2005 08:04:27 +0400 Date: Sat, 05 Mar 2005 00:08:27 -0400 Message-Id: <2.6.23.2081924.0083fc70@go2.pl> From: "Vickie Osborne" To: Subject: You will open and fill this one out for sure. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit http://www.runninshit.info/mortgage.asp. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit barrack noxious

 
 
 
 
 
 
.
.
.
http://www.runninshit.info/mortgage.asp It's time to fix up your situation for once and for all
.  
   
No More ------------A85031401794097-- ------------A48356845382213 Content-Type: image/gif; name="sawfly.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODlhbAHAAZEAAP///8zMzDMzMwAAACH5BAAAAAAALAAAAABsAcABAAL/hI+py+0Po5y02ouz 3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1mAtqu94vh gsfkq9hwLqvX7Lb7DY/L54kBwk7P6y94RZ/B9fe3R1i4MHiAeHgHkGb4SKgI0CfGlSZ44NgIyfkm KTgQmjnJeBcq2Zn69ZlYaoDZGqs66xV4eitKWier28tLC3zF6vvK24eIGqzsNIx7avxLvDzNzICX DCudTM1d1OyQjdw9vjRMfOzqm03O3iNmPnmb/hcgn96OH6UpsZ3vj7MvzK5/BIsE5IOmoMKFDBs6 fAgxosSJFCtavIgxo8aN/xw7evwIMqTIkSRLmjyJMqXKlSxbunwJM6bMmTRrBjs4AeeWnEB0JvBZ iYLPnhKGKnBklEzSDfQgGF3aT8lSgdIcTO1wFYWdS36o/qxgNOrREKhQPfXqFMYgSTrFCh2rQwCC QD/dyrB7YeigM3gjZLUag17fYmTWnlvwdxRcQHMHLgaclas1wA+AUlacFilZx5swL6rcILENTOvi 5QJnj9SzV6snpyacqHVs2bjqyGYt6tPr19ZS29ld77bp0rp+C98t3NRq46dnn6792RjtrjtIz7vH ubjhaLHv8L3+65rjdaAaiOMenrWr5uSjXWsfi/g99vPRp4fd67wOdLD5Y/83j582k43nHoBVCYhg Qvf9t494A50HIXURUvdfgPpR2I9/E3qnQz2yaOjHQc5YGGJ0H8ryjnLLebYhd1wIIFmFuK34oIQ2 1ohjHY6UpeB5ttyS4gMg5mgfDb/tAsqIA8Znm5IUnjijb+P55oyDjDQ414XZWcnkKFwShsd3CCpS JY/p0EVigNH516WMRh4m35JtqglgjGxmd+CXV8q4HYdPgnljKRDuqOaXaPIzkJj6RXUkL2hqiUOj rcRpIqBucnbonX6ipyeKdKZZYYuWChronKNeumWpmUYg6Zh/5kDmnzy+o2eftl0XJJTqHQZqeXLi h40phQ4L7Dy1QsNrpYv/CvtpVzFOIuauPMTqB2/V5kYndIvwtha3zxzj7W3yYMNeck02Kqo6x31L 7IwqbkOjsdjOJuQh685Ly2A2IaQPDFnp69cTkXXhoROixVAwQQEd/CY3DIvwMMFsRLyvChQrhXCz J2x1A8A3RGyPZkVWR5ZsF0/gsQYpi7ByxyrXiyqsILT8Ac0W2OwBzjN4DC+eP+CsM1NqyVxNBj3H HGlnOx04tLXa2motI07fS5q5KhYzdXPDdUtf1Oeeqd1qDdL2miXQMYfMdFOKK2XWkmrbW7li+xsP eF3mSil90OSaH6Xq1N0K33eyCa6b4WAIAXwGdodsf6Xm96Ag0QJuK2d+/7sAqa6awnNq56QknAiW rx4rzaGm5kkdjASGtiw4eJKuOqmISiMX6J7/CrnLlj+tK6ePF/c758SmO/yrxa/uWYKKTO4qkbc7 l0u6nVaae/IttB5LwuA6mV3BZUYZr++jt/t0le2+Tr71ysNcYPPrhcyr9NAvruvJ/Mp+3eWlKEo/ +tS7Lz4zhSp4I8Per+SXIOcBT4HCS5/u8AcN/bVPgOP7HwKVtkDqCY90THNg/xCYuQyejoM+W98D e6c1LenGbo6DYLOsg7zqtXCE9COPpp50ucrJ0Ia9YpYBo1dCdTCPbgkcl8/ghiSqce05CiLGJWg0 uXClUEpBHM61WjW3K/+OonaoIaHb+sa2eV3IiFESkrh2YL/GpPEyQ1jjW/KyATeC5Y1GwIkb5WgB PNLRHWy0wcKCoMfHoMUE+5hKIPsIsRzg8ZAeEBlimliCszRmj4PMWAiGssZMUiEpdiRBIeEIyUem oJOMyeMIDsJIQSLSB6lE2s+6iBevofFmWllGWybJqqQ1rgI6ayUbm4I7lH1FDaS8nyhNhMphhuYx oiuWMXFJSU8+00BXwcsnQaNIUNISg7mEJjZn1j9lvkonQUnLMUEgolAaLy0A8+Vmvvi1SZ3xauZB jtbsJcYSlbFxtakcrVoDJHnKJW737BHZurYcgFpxPgeVGzDlec/dLDT/oM6BleL+9iFMpEhwrrMc N6XjwRliFFSyeh/7itFMERaOcWDSKEqdeb6yXHSl0oIWTGsAQgKK9IX+q2AIqxeAgb50px5VYOKC KSqOeW5I6+mp/5KaI77tTKcX3Jw6dbjBmPJulzLE4e/waTLuQNWF1TNgArEzANN1bjs/xZyEzAfA GX7vgOusagxLc6dnES9VFnwcWxEHPia+y1w5rc/WrOZWox6vqRoraQkLy9ibYu2ke22f8ZS6Vgb2 zrHdJOuX/goQtPI0Sx60C1Zxdw1CmVCyqqHsV0XbV+eBNiFMVZYwNZus541GqXjlhVD1JlkKstZY IAUW4f6TIb2OTF01/4Rp5d7Dwj6JY4ghHZxjYtdYFhhHAGkLY9VSeK4wxY2esFQXvqx4XLEeNZ7Z RW95K7ogQHErvE161yPHqLb4InGq4HyldpsQlqXNghIdMIs2semToIlTwRq4mCYMLIMzuDOS7S1l FdVZyWUut78fRSdPStCPv2hCjxPm4zFHzIISezPDM/jjgStGRD/2scQqBjAiJJnIBo9gG2cQ6geS sg5HQlKWpwzYio18zm/iVMkcIPAcsQLJWxaJUUxO8nA7G81LPvkxDH6BggOiL3JaeGl+o7KW/4Bd CnQZw6ocs/r+h4R2btPNdH6zKdcJZ5+hWM3U3fOGt4zkHN+5xh1Fg//b0BG1fzr0nPb87hKXWNSK Juk5jU6cRAvYUGoFzl0TNM22pgPQ/LZQ0bDd2l2iG7lNVVBjsAjH4SKLUdP5KlljLLRIg8XVHt11 gjdmad8iLV27OfmzgbGsTm372CFTFbX8xLN1Lwxr4XYVsHEVoQbTFK30Vnt6Xja2kn562th69lM/ 9PZWjX1FwY4W1mvqtGLdbVltQ7Zhq13qB+t6beXJQ607jHcMD1vQHh4gzZnwMVGRN+98P1qhzj32 fv+7WBrSNdk+xbdNow3vzbplWVItdYZGerfTPfXCjcIbAR9c7Ijbe+IDrDjFy63yrm6c2kwz67Zg W1mV9yzYuMVzLXf/6Stwe7W5Ix0ryNtDq+KedS9KLzMLlVnr4sKLtwViXtRvCkRXssygEWVXLzqu HPJCvaEel6KX5sNdLHodN/bFMBlBDlZo6+KJXc+n6y5dh7RDKq1id9f2An6Cclp5lHEcvId1bAQn 71jQdr5zLRoCMhWs+QuEXkHlhzD5P3Pi8nXufJbpLGIYC7goLRjYi6V5ZD9HOMX5kLAVXO/Kj8uB 8z/AJE9CXGXHB9qcHVTa8lS9C9rbJPNs5uQq5Z5dXIv+9C8jPTQPpseZq4/vAxI+RdDGafhiLTeV njSkJ01fWCKaah18+0K371Dik6RcGK9pEZ/N3IbzKdVAp6C6f53r/+WfNH7HPh9ucw4zw+Z/hrZs /6Z/+zdbQaJCOHQ2BcgPDdhzI9dz6jcSUjVbTBIUgkFz1hY25ZNFfHVBTwVXmDVtB3hv47Z0DkiA vddyKBhClYU91icRzzU8qpVxKyde+1d1LcJvjdAU3NY6MjiDfPU5RIVf0iE4z6ZDSVhd9qeEF1Vh +0KD2lcVZAd+V9h2+1RPdicvraJF3gdR3aV5JpgCg0GBZBgJSCNBaEgQRKZFbBgRQgiHtrR7c2iH d0iHeKiHe8iHfeiHfwiIgSiIg0iIhWiIh4iIiaiIi8iIjeiIjwiJZkADcpgFlBiJl4iJMHGGWvcP m7gKeTZNkncR0v82GkSgQ0LTbZ9HDaTIYhjgiaCEWTpjTTlDGaLhYkdmeLwHZW0mZDboc5CwOaKG H99xaKHThXfXGqTGXqqBWNgHUVS4hbkQVOfHjAj1d4aVfZJGULxlNR5yCsoodvOFbdTYNHXRVM8i LBzlQtpWLajGUbbAJ64WadXXUiaVUcC2a0q3ahfXjqgWOIrDc1FIAl6YgxyYVUtSW+SmgivncpaV YDFHbAh3gzXnGGCXW7cjgPL3dQK5eBLYGQcJPppjcS7Yfzj3VHo3WBA5VKtlVWeFjeIzkfWWkCy4 MQ0JkxqnOXDlUyM4giNpKnM1cQmHPX9nD0JXalvSk+nGcHKlk0P/45E3yZCtpXkwGE4HeYpVqZIX +Td542xO5Qo9mC22JpUcWYbmGIEm6VFrWG3oYTsbeYPJkAbT+H9+5VVcGUTUN4AklSiGgyScWJbU IWvMsmrl8R3ouEJcxR8KWFevZnWs85HQdY+bBXcpaFxYaZGUiVFp1pIIoJn89YZXA5LuhVyy5IxZ yBpph25hOJqI5Xfo52irqWmmKZrjBY1HZHbzk5qmJjFW4Ims2GGTdE2s1wnJpHujh3qo+JuNp2bh hHjKCWjOF2NjwHli9mQMlk7BpEaQYIl2uJ3FSQ6HRJybtxGXyUvNmXuqiIvHFxiqV3gRYSuJoXjM h0vUpWXQuV5v/4QTfRGXNMkQFkiLKXdgrTSLyUmWoDiErpSf8jlndWifH/ZRv4eczvmLENGA8JON yiJqLkWOHngasHcKcsElsvahz7hP07hvWkiOKWp+UkNpoTY3FuoPvgg4WHedxRKYKLQgEGpc/PaE IAiFRxddDwVe7DaZChFuRmlC6BKTjRWC7yZxWkk6L3if4dYQR9qVDqSkMVdA/fdtYJV15ziRJASb 9+eSBXGkTWmA/JGlAEeUFdJxW5GR/AeCGzhXdeqTAgc9rIkP78mBhbYsiDaVWzqXsnUj2XaXWIls 7PaKemClt7U+gBqFN4SWJDmpOImdZQql8SWh42A7HGcfUEiD/P9DpAzYdD5EqvWGp7eWVUnnf5K6 p18qHc24jITxpiiJm/QSZbOpq2SkeLzKgGDIF2WzomBnfplGWxXjSwmaTcLJoJmIZYvqrGBQNtFK rdVqrTXRnddqENqqMNzqMN4KruEqruNKruVqrueKrumqruvKru3qrofYSvtpMOKarR0BffX5Bsna EvX6ri2mT7loNAkFeHHWiqaklhURrEnJAFz0n2PoDcagWml0sP5VBm0li8h3BOxYoI7Kn0EAraWI sQUWsg9roFvnsLPUsVQgDuKIonE3PxxKjB3aafCUjaWpjf1BRVRos1oIOv4Blq35fgrlokzUaODn Jd71sQtaU6//9qng4Z+RyWwzCqRFN1MaO7VS21sauW6UQ6fux1YXdaNam7Ke6W8VZlbEwW0GQHBR qmyD2n5EKqaG2mxRa5Syd7YLaYqD+Wd3C28phYMK53AepxhepHfs6Koh2KUYlLiKireYp7e32kR8 G1hpu21h6bY4mqYOZHJzC7j/JqYctHDRo5MP1wN7Z4xwJrkUKZYZpJg2yZBoG6YeNI3EuLpsS6gP YoME5psTekIhRXGM27S1q6UJ12+ZW7nBVX54G5EoqJWBKgSm6zj0ebV6SbnxB3NMi0JWC5A0d39t VZnfa72nanMBmVnPG7mACYbvpam6SZO+ujuLZm74wjXhkV9J/yi/RxmN5qV2XAiaWpW+kEu6ZWB6 LsCvuwh89+kSxaSez9lm5zlm29mWX4GXg2F8h0cHBfwxDhycRvOAA7sEGBydnkGJILx6DZplJOyd GlZkgYeeltfAC0ygHGB7Jsxm4rSp2zozekq2hHScn5mKIJuvCDy2IotlS3ayR6y0JcvBCOigWgBm ISuvSYydliBIsPecE+uXuVeQvOuKQpy0GctNDMOeUlwDPyvEM/ZNsqcgUVyeXDay27kdPwILfDE2 A8BdjlOMrvmZj2Y4t0lPGckcOAtF5EYl1hiNbXpASvSYQ0uC+7SzKVq6d/WmJ4i1hgVcGDXHB5eq 7QEhUEOEnP+Ff3BBvnIiOfcxyhjqj3BcP6fys6ccnwapkIvDisSDuIM7ZR/5Wn46pYD5VWDZmGcZ yUaYl6lqXEUZKFyRsEt5pxzYll60gfPoOQ92brL8q+EDbY2axT/ckkgqzGmyV1lbfoUMgU/JWq46 mdVLvs0ElNKFd5QcH2jqA1hUkthIvNOzmdJHirXcFUejpYLLPtJmDmrcz+YLu5hKa8oby6jaUWaC jrC8gn1pawBoc8+cmyXIV6KaBNPlTPDIcj8EuhDEjU0rt5gb0kV0qfq1XLMm0OT7patiw1R6ldMy ZOQnXJspmvgljd83ZVIEaTdbkLE4pLUrjARlXqIcfjfLvmz/t4X+68H70axEobLLykqel7ftOUiE xsa69NQWJng8nC83zAMk1rslXMGtCHvUqcKQ9wL2M8YTs8IANokU1sLumhjx2q+AxJzRkczfeNeh 1Uj8GZul19cMTMZht06apIvv6o3kZ8puGNj3pox7TaIBjK7B6o+3NjtHnaigurQ6Mth2dWUTqnw2 fbuDTc5biXxm1m5MDatDjK6dzD0GLXcCRJTKbJBuqK6VRRcxPdt3N39O6trhmnNWG0wyCtFbq1sb C66Se1wP+cm4pNGqSr3kOa6TfKtQA3jaIseqfQe26tPpls2DLdZ5DbCmzZvmnQfUjd7rzd7tLWPu Dd/xLd/z/03f9W3f943f+a3f+83f/e3f/w3g5IrC5tnDKBvghjjgTMDWjwfWf117qpDgLBHhO7y6 5a2DpwsFE65NZUKBX1wzfHnGy3nSK4CX29RjjLTFWg1xTeB0gsQz5L3i08R0IEaxMV4Ot6WsXTzi orjEACrTLlteRluiXmpG8KvHssmy57B2prbdfaerSFl3RMuaHPq/gXxuj7yiR03ZpzZ0pNzcPujF RCePljq9PETMf8OEpPx0kIncpM3mxBIcQUrJHi68vzsnLs17y/PYtvu43bzasYuQVyqlOy6m01bo V4XEJL6PlbpTDVK4SCUhqgWS2FvMDLdRzPvM3nfoqhteDv8SLZuL6UrpKU7tlbzmJK+cPQnN6GBE psWLqoOjsMH76sOc1Avoktt8pZJJNPi7pEy6zMcbuJL50b9N7MhgOo/CxfD3pKvs0OX0g4nO47w+ 0L036Kcdn3DKvYDevLSO68Ac6McKzN3egrqu4vlXqqO6O2IOt5t82TOq0pw1a11+dJvuyqbaUx5d Q+ZsxD5M1P+r1HXshXQn5EWYUcm4oQx1XsWafl9T0zTN7eHSv1Wobs+O1HGXJFpgnVRdR52o8ULw F6XBrzNMw89pxQLT8a5VwxbOBLidPBru8c43wCUMyXnYxDJP2C4Mwz/2wjtPeJWIrwWrPuCZnkRw i1ad2DH/HMMySOeueBzhzWEpHO0RWsQbYy7dqRtRbmlYP6ugjMUh/tztmYFcDOMizrHNV+FHvzPw M1MR3e5skVsSBBVhvhhZbcPtI2Rn/2EQJnd3z4JLz8FqOs9Zyc3yPnoP9ZISO07AueOZbWUzXtiJ XnmFzkENbbuTI9nTC+T8iFJwc/lYrqdUjqJIZMypAY4Vr+UqCmrcR1jizKJHUpQ6/J+xiQ4NvZLA IxmD/6OZQOkWzVCpvNmLflyXnA09yzlvDpB8qriWw6pL2/VdfPUF7boOnahFSqtPmuJ7kpWd5b2f s+ew0br0aZWBT1qjbiVqxdssM09+bu3cPo8A7bvTH5Wi/56Xi7vq9E634v901jaFim7oBADM8lSR 3TUTE323SpaxXXPbLA8azNPjVFLsQvZATxB7UZWD4TALaG1U+/GIRWME0vpolEDlrjmkpIa0HZVZ /WCjP+gyp/CBrcSvWZt0CXnTJztolM+ZaicbV15n4VmsromrCpDuqosQz66LjGFs620v74XvkS8O wJFOU88Nx8GnkwPUT2KM6xLs1GDUE0lsktKVsrUntkEWZEcgUxaUKs5wZfEQ06tPI0Bgc3ni5mHm 2SQR+lY6wVdAEDW0jbpiZsp6NZrGMRw6sxphKrtaPRUaSiZ63cyZLADBFH3J3Dqd0T0yqJYIYlYM z0Etr//mAFT4EGJEiRMpVrQYwuFFjXMMFrqY8drGkHRAfrRYEqFJkStZbuzYCBbMljM3oByZEqMm kDtP0pRjcwxQn0OJFjVa0abGpEdr8ljKFGpUqVOpVrV6FWtWrVu5dvX6FWxYsWPJljV7Fm1atWvZ tnX7Fm5cuXPp1rV7F29evXv59vX7F3BgwYMJFzZ8GHFixYsZN3b8GHJkyZMpV7Z8GXNmzXCfbt5a srNnnV5DH3yasbTRpat9pmbmmgjsmQNkM3Mm8GdklLe9Nc358NdgfzKseTB3kSBDTRFQ1t4k1KPv g8mXvVQe/OZv6ePWnpkFkXoRkNbRkndqaVk68xcyscr/vdc7yfd51r8Wrzy7Uu4Pm7cRUjoFnkRJ aKP2tsPpKBZwO0ecbhqcZ55mHowBuwVwu+CefRqMohNfqAkPnt5EuAdCEkXkzZsLbzDOwhRr4EUI gQARkSgSuMFlISnQI6WZI775LgYec0yljkgYEQbISwi68Q4h4emmyO+UjBKI+jQ64xMciwjGE0i2 lKTCMB7IKAlFApGEStvos+XIgbzE4TgM8kETyYDSGLIoLOv0sYZt3vTvzpjEVEAZQOv5QMMP6TRm uQjdBDPH5MxsUx8qP4lJy0qalAoK9y51dBEtGbxNDhzd+09TOue0UEdLv/yGH2IGUYdUhkYgzg5T AHUV/w1GN9VjKj2HDNPXVgXd9dJI91PkVAwzyNQNbRBUts8Ye5X1WEo5bFMCboAdlNNQFyW2IGt3 vTY+RMYtF9pu+cx2CE/NhfdRA9Pd1qBDA1U3KmHLRWZZJx8FF9lh7DT23IFjgPHd5HT9cdYd+5l0 SohHZLPUbWnhNk9xpbiQnmNoXXRPav2gUWRY9cXzY5RV/hfMBVN8UGZpggP5pRRUBIdl0dSykrAA DRaOKee0AnqwnGXy2bBKK0v2Wqbtk5rqqq2+OiqGWzIaLK4b8zouHJHeQBlewMYabYvEVnvotN1m ilzw3p67IlI/PJFnL0BuEQkTZ5B3Z5vpRjvabeLsEf/h/YKUmIR9nNxwcKZ1TqScPaVt+EwjOY48 s8nZ5BJRQHmJcFWE2j2Yc88OtwTXQCd+d03X+d08dcuYiz3btV+FVPY/aa+dMs/XrZZkhYs9PtWe gQ/eXZHD6XL3jVEHXZyxly+sVnpuX5G+Bld/+ZySQ9TX6eupPruopKw3P7CkWJuJa2/Zn187hNBv FHL6LevvKAHT0/9qjnDfaBrCEv8BkH33Q+ACGdhABz4QghGU4AQpWEELXhCDGdTgBjnYQQ9+EIQh FOEISVhCE54QhSlU4QpZ2EIXvvAw64OhYIgTEefIcIaAuYQCYZfDp7WNP+cBkg8f84UMSWhljlpH 9fLSRqH8ERExUGMOkywGjG2YCYdQlIuf2BOf5M1Oi4yp4ec4FCFJKS+M7UscrigWuzMiMYtpfAsX c7cvygEkjnJkC+god7A3AlGPfRFexRD3pID4I2KBxB6yapbEvKUgG4KDoyITYzTyhIaHlNSL/DQJ QIFkspOhFOUoSUkRUJZyMqdE5WZUuUrItNKVsZTlLGlZS1veEpe51OUuedlLX/4SmMEU5jCJWUxj HhOZyVTmMpnZTGc+E5rRlOY0qVlNa14Tm9nU5ja52U1vfhOc4RQnLQsAADs= ------------A48356845382213-- From ippm-bounces@ietf.org Sat Mar 5 04:15:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25242 for ; Sat, 5 Mar 2005 04:15:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7VJe-0003pC-Vi; Sat, 05 Mar 2005 04:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7NmX-0003bo-D7 for ippm@megatron.ietf.org; Fri, 04 Mar 2005 20:08:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27271 for ; Fri, 4 Mar 2005 20:08:33 -0500 (EST) From: pfc@ieee.org Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7NoC-0003Xo-62 for ippm@ietf.org; Fri, 04 Mar 2005 20:10:21 -0500 Received: from [192.168.2.40] ([68.239.126.162]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ICU00CSDTU81ND0@vms046.mailsrvcs.net> for ippm@ietf.org; Fri, 04 Mar 2005 19:08:34 -0600 (CST) Date: Fri, 04 Mar 2005 20:08:32 -0500 To: ippm@ietf.org Message-id: MIME-version: 1.0 (Apple Message framework v619.2) X-Mailer: Apple Mail (2.619.2) Content-type: multipart/mixed; boundary=Apple-Mail-4-681209699 X-Spam-Score: 0.4 (/) X-Scan-Signature: a4ba408990f83ef962b4876088b8c71a X-Mailman-Approved-At: Sat, 05 Mar 2005 04:11:14 -0500 Cc: Henk Uijterwaal , Matthew J Zekauskas Subject: [ippm] initial rough draft of capacity definitions X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Philip Chimento List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --Apple-Mail-4-681209699 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hello all: Attached is an initial draft of the capacity definition document that Joe Ishac (NASA Glenn) and I worked on. It is still pretty rough, but there is enough there to discuss at the IPPM meeting this coming week in Minneapolis. Please send any comments to the list. Regards, Phil Chimento --Apple-Mail-4-681209699 Content-Type: text/plain; x-unix-mode=0777; name="draft-chimento-ippm-bw-capacity-00.txt" Content-Disposition: attachment; filename=draft-chimento-ippm-bw-capacity-00.txt Content-Transfer-Encoding: quoted-printable IP Performance Metrics Working P. Chimento Group JHU Applied Physics Lab Internet-Draft J. Ishac Expires: January 30, 2005 NASA Glenn Research Center August 2004 Defining Network Capacity draft-chimento-ippm-bw-capacity-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 30, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft proposes definitions for the terms 'Capacity' and 'Available Capacity' related IP traffic traveling between a source and destination in an IP network. Chimento & Ishac Expires January 30, 2005 [Page 1] =0C Internet-Draft Network Capacity August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Proposed Definitions . . . . . . . . . . . . . . . . . . . 4 2.2 Example Metrics . . . . . . . . . . . . . . . . . . . . . 4 2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Available Capacity . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Proposed Definition . . . . . . . . . . . . . . . . . . . 8 3.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 7.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Chimento & Ishac Expires January 30, 2005 [Page 2] =0C Internet-Draft Network Capacity August 2004 1. Introduction Measuring capacity is a task that sounds simple, but in reality can be quite complex. Any physical medium requires that information be encoded and, depending on the medium, there are various schemes to convert information into a sequence of signals that are transmitted physically from one location to another. While on some media, the maximum frequency of these signals can be thought of as "capacity", on other media, the signal transmission frequency and the information capacity of the medium (channel) may be quite different. For example, a satellite channel may have a carrier frequency of a few gigahertz, but an information-carrying capacity of only a few hundred kilobits per second. Clearly here we are interested in information-carrying capacity, but even this is not straightforward. Each of the layers, depending on the medium, adds overhead to the task of carrying information. The wired Ethernet uses Manchester coding or 4/5 coding which cuts down considerably on the "theoretical" capacity. Similarly RF (radio frequency) communications sometimes adds redundancy to the coding scheme to implement forward error correction because the physical medium (air) is so lossy. This can further decrease the information efficiency. In addition to coding schemes, usually the physical layer and the link layer add framing bits for multiplexing and control purposes. For example, on SONET there is physical layer framing and typically also some layer 2 framing such as HDLC, PPP or even ATM. Aside from questions of coding efficiency, there are issues of how access to the channel is controlled which may affect the capacity also. For example, a multiple-access medium with collision detection, avoidance and recovery mechanisms has a varying capacity from the point of view of the users. This varying capacity depends upon the total number of users contending for the medium, how busy the users are, and bounds resulting from the mechanisms themselves. RF channels are also varying capacity, depending on range, environmental conditions, mobility and shadowing, etc. The important points to derive from this discussion are these: First, capacity is only meaningful when defined relative to a given protocol layer in the network. It is meaningless to speak of "link" capacity without qualifying exactly what is meant. Second, capacity is not necessarily fixed, and consequently, an instantaneous measure of capacity at whatever layer may in fact provide a skewed picture (either optimistic or pessimistic) of what is actually available. Chimento & Ishac Expires January 30, 2005 [Page 3] =0C Internet-Draft Network Capacity August 2004 2. Capacity 2.1 Proposed Definitions In this section, we propose definitions for Capacity. The definitions are given in terms of "IP layer bits" and "IP layer bytes" to distinguish these definitions from channel capacity. By "IP layer bits" we mean 8 times the number of octets in all IP packets received, including from the first byte of the IP header to the last byte of the IP packet payload (covered by the packet size field in the IPv4 or IPv6 header). IP Layer Link Capacity: Given a link L, a time T, a time interval I, and a source S and destination D, each directly attached to L, we define the IP Layer link capacity of L at time T, C(L,T,I), to be the maximum number of IP layer bits that can be transmitted from S and correctly received by D over the link L during the interval T to T+I, divided by I. IP Layer Path Capacity: Given a path P consisting of a sequence of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1), a time T, a time interval I and a source S=3DN1 and destination D=3DNn+1, we define the IP Layer path capacity of path = P at time T, C(P,T,I) to be the maximum number of IP layer bits that can be transmitted from S and correctly received by D over path P beginning at T and ending at T+I, divided by I 2.2 Example Metrics These proposed metrics are examples of active measurements designed to achieve the maximum capacity available to IP. Passive measurements could also be defined, but would have to be defined in such as way that they would be valid when the bottleneck link in the path is backlogged (or in the limit, just full). Define a source node S and a destination node D, where the source sends IP packets to the destination. The measurement point should be at the end system, but it can be placed in any of a number of places in or near the end system, for example: o At the "wire" (which actually may be the "air interface") connecting D to the network, as long as the measurement is passive (i.e. does not affect the transmission medium in any way). It must be possible to strip physical and link layer information from the packets captured. o At the interface between layer 2 and the IP layer, as long as the node itself does not introduce delays into the passing of IP packets over this interface that would affect the measurement. (That is, having stripped off the Layer 2 overhead information.) Chimento & Ishac Expires January 30, 2005 [Page 4] =0C Internet-Draft Network Capacity August 2004 The requirement here is that the measurement be made on IP-layer bits that were transmitted either implicitly or explicitly between a source and a destination. So, for example, if header compression is used on one or more links in a source-destination path, even though some of the header bits are not actually transmitted on some of the links (thereby increasing the capacity of those links!), the IP-layer bits arriving at the destination (inflated, not compressed) are counted. The measurement must be made in terms of IP layer bits, including all IP packets received from source S (i.e. where the source address in the IP packet header is an IP address of S). We define time stamps t1 and t2 derived from the local clock at D or the clock local to the measurement device. The important point is that these times are derived from the same clock. The time stamp t1 marks the beginning of the measurement period at D and t2 marks the end of the measurement period at D. Time interval I is defined as (t2-t1). The clock resolution of the clock from which the time stamps are derived MUST be sufficient for the measurement in order to avoid quantization effects. This becomes important as the measurement interval gets small. The source S MUST be capable of sending at or above the physical capacity of the smallest capacity link in any path through the network from S to D. We define a path P from S to D as a sequence of nodes and links (S=3DN1,L1,N2,L2, ...,Ln,Sn+1=3DD). An IP Layer end-to-end capacity metric is defined as follows: The source S begins sending at or above the rate of the smallest capacity link on a path P between S and D before time t1. Let B be initialized to 0 at time t1. B accumulates the number of IP layer octets received at D from S (IP Source Address =3D S and IP Destination Address =3D D) starting with the first complete octet of = a packet received after time t1 and ending at the last complete IP layer octet of a packet received at D from S (IP Source Address =3D S and IP Destination Address =3D D) by t2. Note that this introduces some small error in the measurement if t1 and t2 are chosen arbitrarily. IP layer end-to-end capacity from S to D over interval I is defined as: (B*8)/I. The units are bits per second. If there is no other traffic on any of the possible paths between S Chimento & Ishac Expires January 30, 2005 [Page 5] =0C Internet-Draft Network Capacity August 2004 and D in the network during interval I, the IP layer end-to-end capacity is the maximum achievable IP layer end-to-end capacity between S and D during interval I. If the number of links traversed is 1 (i.e. P=3D(S=3DN1,L1,N2=3DD)) = then the metric is an IP Layer link capacity metric. In either case, the metric is denoted by estIPCap(T,I,P,S,D). 2.3 Discussion The definitions try to make precise the quantities of interest, link capacity and path capacity. There are several points about the definitions that the reader should note: The capacity in each case (path or link) is defined as an average, not as an instantaneous value. More specifically, capacity is defined only at a specific time and for a specific time interval. These time parameters (time stamp, interval length) MUST be reported with any estimate of these quantities. The estimates are not meaningful without them. The base definitions specify that the IP layer packets must be received correctly. This is deliberate, because of the possible presence of lossy multiple-access media in the path. On optical media, at a nominal bit error rate of 10**-15, a stream transmitted at 10 Gb/s will experience an error about every 1 2/3 weeks on the average. On wireless media, the error rate is considerably larger than that, reducing the effective capacity accordingly. Note that the reception of a partial packet cannot be checked for correctness, and consequently the definitions count as capacity only bits received as part of whole IP packets. The base definitions also make no mention of duplicates. The transmission of duplicates does not decrease the information-carrying capacity of the medium, only the throughput with respect to a given source, destination pair. With respect to capacity, duplicate packets are just packets and are counted as such. Note that these definitions do not make mention of "Type P" packets, while other IPPM definitions do. We could add the packet type as an extra parameter. This would have the effect of defining a large number of quantities, relative to the QoS policies that a given network or concatenation of networks may have in effect in the path. It would produce metrics such as "estimated EF IP Link/Path Capacity". Such metrics may indeed be useful. For example, this would yield something like the sum of the capacities of all the QoS classes defined along the path as the link or path capacity. The breakdown then gives the user an analysis of how the link or path capacity (or Chimento & Ishac Expires January 30, 2005 [Page 6] =0C Internet-Draft Network Capacity August 2004 at least the "tight link" capacity) is allocated among classes. These QoS-based capacities become difficult to measure on a path if there are different capacities defined per QoS class on different links in the path. Possibly the best way to approach this would be to measure each link in a path individually, and then combine the information from individual links. The definitions as written have the implicit assumption that all IP traffic is treated equally by the networks that it traverses. Chimento & Ishac Expires January 30, 2005 [Page 7] =0C Internet-Draft Network Capacity August 2004 3. Available Capacity 3.1 Proposed Definition Given a time T and a time interval I, we define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1 respectively. Furthermore, we define a link L as a special case where the path size is one. Average IP Layer Link Capacity Used: In order to define the available capacity we must first specify how much is being used. Thus, we define the utilization of a link L, Used(L,T,I), as the actual number of IP layer bits correctly transmitted from any source over link L from time T to time T+I, divided by I. It is important to note that the information transmitted across the link can be generated by any source, including those who may not be directly attached to either side of the link. The sources may also only share the link L in the overall path between S and D (although they could share up to the entire path). Next we express this utilization as a percentage of the overall IP layer link capacity. Average IP Layer Link Utilization: AveUtil(L,T,I) =3D ( Used(L,T,I) / C(L,T,I) ) Thus, the percent utilization now represents the fraction of the capacity that is being used and is a value between zero, meaning nothing is used, and one, meaning the link is fully saturated. By using the above, we can now define the capacity available over the link as well as the path between S and D. Note that this is essentially the definition in [PDM]. IP Layer Available Link Capacity AvailCap(L,T,I) =3D C(L,T,I) * ( 1 - AveUtil(L,T,I) ) IP Layer Available Path Capacity AvailCap(P,T,I) =3D min {1..n} {AvailCap(Ln,T,I)} 3.2 Discussion An important distiction between utilization and capacity is that utilization is not the maximum amount but rather the actual amount of IP bits that are sent. Also, the value of n that satifies AvailCap(P,T,I), is sometimes refered to as the "tight link" within a path. So while Ln may have a Chimento & Ishac Expires January 30, 2005 [Page 8] =0C Internet-Draft Network Capacity August 2004 very large capacity, the overall congestion level on the link makes it the likely bottleneck of a connection. Like capacity, the definitions outlined above rely on both a time and interval. Since, measurements of available capacity are even more volatile that that of capacity, it's even more important that the time and interval be specified in addition to the actual values. The high volatility of congestion makes shorter time intervals more meaningful in the general case. Chimento & Ishac Expires January 30, 2005 [Page 9] =0C Internet-Draft Network Capacity August 2004 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Chimento & Ishac Expires January 30, 2005 [Page 10] =0C Internet-Draft Network Capacity August 2004 5. Security Considerations Chimento & Ishac Expires January 30, 2005 [Page 11] =0C Internet-Draft Network Capacity August 2004 6. Acknowledgements Chimento & Ishac Expires January 30, 2005 [Page 12] =0C Internet-Draft Network Capacity August 2004 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2 Informative References [PDM] Dovrolis, C., Ramanathan, P. and D. Moore, "What do packet dispersion techniques measure?", IEEE INFOCOM 2001, April 2001. Authors' Addresses Phil Chimento JHU Applied Physics Lab 11100 Johns Hopkins Road Laurel, Maryland 20723-6099 USA Phone: +1-240-228-1743 Fax: +1-240-228-0789 EMail: Philip.Chimento@jhuapl.edu Joseph Ishac NASA Glenn Research Center 21000 Brookpark Road Cleveland, Ohio 44135 USA Phone: +1-216-433-6587 Fax: +1-216-433-8705 EMail: jishac@grc.nasa.gov Chimento & Ishac Expires January 30, 2005 [Page 13] =0C Internet-Draft Network Capacity August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Chimento & Ishac Expires January 30, 2005 [Page 14] =0C Internet-Draft Network Capacity August 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chimento & Ishac Expires January 30, 2005 [Page 15] =0C --Apple-Mail-4-681209699 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-4-681209699 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --Apple-Mail-4-681209699-- From ippm-bounces@ietf.org Mon Mar 7 12:01:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08561 for ; Mon, 7 Mar 2005 12:01:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8LYn-00030D-9B; Mon, 07 Mar 2005 11:58:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8LYl-0002yb-K9 for ippm@megatron.ietf.org; Mon, 07 Mar 2005 11:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08095 for ; Mon, 7 Mar 2005 11:58:20 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Lay-0000BY-DD for ippm@ietf.org; Mon, 07 Mar 2005 12:00:41 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 1F83625608; Mon, 7 Mar 2005 17:58:11 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 2674D24F48; Mon, 7 Mar 2005 17:58:10 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j27Gw6eu014769; Mon, 7 Mar 2005 17:58:08 +0100 Message-Id: <6.2.0.14.2.20050307174439.02c49020@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 07 Mar 2005 17:53:55 +0100 To: Philip Chimento , ippm@ietf.org From: Henk Uijterwaal Subject: Re: [ippm] initial rough draft of capacity definitions In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000004 / -5.9 X-RIPE-Signature: e4680afb0b448a110d01c5a5ffcf9bf4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Matthew J Zekauskas X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Phil, others, >Attached is an initial draft of the capacity definition document that Joe >Ishac (NASA Glenn) and I worked on. It is still pretty rough, but there is >enough there to discuss at the IPPM meeting this coming week in Minneapolis. > >Please send any comments to the list. First comments: 1. I think the draft uses an old boilerplate 2. I don't like "proposed definitions" and "example metrics". I think we should define metrics (perhaps for specific cases), then define what we have to define. "example metrics" sounds too vague to me. 3. 2.2. "if there is no traffic on any of the possible paths between S and D". I don't think one can ever measure or claim that. 4. Section 3: I think one has to mention cross traffic here. I still have to digest this draft further, Henk >Regards, >Phil Chimento > > > > > > > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 7 12:20:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10598 for ; Mon, 7 Mar 2005 12:20:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Lt2-0006QG-OJ; Mon, 07 Mar 2005 12:19:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Llt-0004qO-81 for ippm@megatron.ietf.org; Mon, 07 Mar 2005 12:11:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09934 for ; Mon, 7 Mar 2005 12:11:54 -0500 (EST) From: vze275m9@verizon.net Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Lo7-0000aT-0U for ippm@ietf.org; Mon, 07 Mar 2005 12:14:15 -0500 Received: from [130.129.132.245] by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ICZ001FARRVBDE0@vms046.mailsrvcs.net> for ippm@ietf.org; Mon, 07 Mar 2005 11:11:55 -0600 (CST) Date: Mon, 07 Mar 2005 11:11:54 -0600 Subject: Re: [ippm] initial rough draft of capacity definitions In-reply-to: <6.2.0.14.2.20050307174439.02c49020@localhost> To: Henk Uijterwaal Message-id: <1e78b206bece7c5243cd34d8974d5c1c@verizon.net> MIME-version: 1.0 (Apple Message framework v619.2) X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7bit References: <6.2.0.14.2.20050307174439.02c49020@localhost> X-Spam-Score: 0.6 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 07 Mar 2005 12:19:19 -0500 Cc: ippm@ietf.org, Matthew J Zekauskas X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Henk: 1. I am using Marshall Rose's XML rfc/draft creation tool. If you can point me toward the current boilerplate, I will use it.... 2&3. I agree that these are vague; things are proposed or examples at this point, because they haven't been exposed to the WG and gotten any feedback. I have to confess, that I am uncomfortable about exactly what most of the tools are actually measuring, or even exactly what it means to measure capacity in this way. I am trying with these definitions to make ideas precise (IF you want to measure capacity, then this is exactly what you must measure, vs. this is a metric; now what does it measure). If in a practical sense, the metrics that we can define have to back off from what we want to measure, then we have to be able to say in what way, the metric is only an approximation of what we want to measure. 4. I agree that we need to go deeper there. Regards, Phil Chimento pfc@ieee.org On Mar 7, 2005, at 10:53, Henk Uijterwaal wrote: > Phil, others, > >> Attached is an initial draft of the capacity definition document that >> Joe Ishac (NASA Glenn) and I worked on. It is still pretty rough, but >> there is enough there to discuss at the IPPM meeting this coming week >> in Minneapolis. >> >> Please send any comments to the list. > > First comments: > > 1. I think the draft uses an old boilerplate > > 2. I don't like "proposed definitions" and "example metrics". I think > we > should define metrics (perhaps for specific cases), then define what > we have to define. "example metrics" sounds too vague to me. > > 3. 2.2. "if there is no traffic on any of the possible paths between S > and D". I don't think one can ever measure or claim that. > > 4. Section 3: I think one has to mention cross traffic here. > > I still have to digest this draft further, > > Henk > > >> Regards, >> Phil Chimento >> >> >> >> >> >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm > > ----------------------------------------------------------------------- > ------- > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre > http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ----------------------------------------------------------------------- > ------- > > Look here junior, don't you be so happy. > And for Heaven's sake, don't you be so sad. (Tom > Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 7 13:46:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20275 for ; Mon, 7 Mar 2005 13:46:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8N8W-0007VN-7R; Mon, 07 Mar 2005 13:39:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8N8U-0007VI-4t for ippm@megatron.ietf.org; Mon, 07 Mar 2005 13:39:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19525 for ; Mon, 7 Mar 2005 13:39:18 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8NAh-0002zk-Lv for ippm@ietf.org; Mon, 07 Mar 2005 13:41:41 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j27IdIla030592 for ; Mon, 7 Mar 2005 10:39:19 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 226F577AA87 for ; Mon, 7 Mar 2005 13:39:16 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0002A2503FA for ; Mon, 7 Mar 2005 11:42:04 -0500 (EST) To: ippm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Cadillac Ranch MIME-Version: 1.0 Date: Mon, 07 Mar 2005 11:42:04 -0500 Message-Id: <20050307164205.0002A2503FA@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [ippm] Mark Allman: imrg futures X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1171218441==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1171218441== Content-Type: multipart/signed; boundary="===_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --===_bOundary Content-Type: multipart/mixed; boundary="==_bOundary" --==_bOundary Content-Type: text/plain Originally sent to the IMRG list, but I'd love to hear any input from this group, as well. Thanks, allman --==_bOundary Content-Type: message/rfc822 Content-Disposition: attachment; filename=1674 Content-Description: forwarded message To: imrg@irtf.org From: Mark Allman Reply-To: mallman@icir.org Subject: imrg futures Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Cadillac Ranch MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 06 Mar 2005 21:32:20 -0500 Sender: mallman@lawyers.icir.org --=_bOundary Content-Type: text/plain Hi folks! IMRG has been pretty quiet lately, with not much percolating off-list either. So, I have started to wonder whether this RG is needed or whether we should consider it done. From my viewpoint this RG was created as an umbrella under which various activities across network measurement could be pursued. And, to an extent that has happened (with workshops and review teams and such). However, I think we need to either come up with a use for this RG or just wrap it up. So, if you have something that you think would benefit from operating under the auspices of the IMRG, please let me know (or, the list). And, remember that this is an open RG, but the charter explicitly calls out the fact that certain activities can be closed. As long as there is some reporting to the community I would be very happy to have some closed sorts of group working on things because I think it can be conducive to rapid progress. (That doesn't mean I think open activities shouldn't be undertaken.) Please let me know what you think ... (Oh, I am on my way to IETF right now, so if you want to chat in person this week and will be around, shoot me an email and we'll work something out.) Thanks! allman (IMRG chair) -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCK700WyrrWs4yIs4RAnw1AJ4mOmedkE/R6V4wMB3CR9nH+Q9jowCfRfa9 +/tWAvrTo167xQDw7T61D+c= =T25X -----END PGP SIGNATURE----- --=_bOundary-- --==_bOundary-- --===_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCLIRcWyrrWs4yIs4RAn+kAJ96AeGWi/Nch5+OrQ/cCF71Znv5gACcDmSp nE2EXDjX3oDiTdSeEyiUqt8= =OwZE -----END PGP SIGNATURE----- --===_bOundary-- --===============1171218441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1171218441==-- From ippm-bounces@ietf.org Mon Mar 7 13:49:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20642 for ; Mon, 7 Mar 2005 13:49:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8NGJ-0008VH-5T; Mon, 07 Mar 2005 13:47:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8NGH-0008VC-H3 for ippm@megatron.ietf.org; Mon, 07 Mar 2005 13:47:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20461 for ; Mon, 7 Mar 2005 13:47:22 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8NIV-0003Dy-98 for ippm@ietf.org; Mon, 07 Mar 2005 13:49:44 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 373EB1CD855; Mon, 7 Mar 2005 13:47:18 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21859-02; Mon, 7 Mar 2005 13:47:18 -0500 (EST) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AA3C51CD82F; Mon, 7 Mar 2005 13:47:17 -0500 (EST) Date: Mon, 07 Mar 2005 13:47:08 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Message-ID: <593A09A070ACA445DC95FA20@DCFF15AFC1F6764BA3927E50> X-Mailer: Mulberry/3.1.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Henk Uijterwaal , Matt Zekauskas Subject: [ippm] Session materials for the IPPM session at IETF62 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit The IPPM session should be audio-cast this evening (as are all sessions). I've been collecting presentations as they have become available; all available presentations, the current agenda, and pointers to the MP3 audio session, as well as any Jabber logs, are available at Note that we have already shuffled the agenda in advance of the meeting. --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 7 19:29:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28950 for ; Mon, 7 Mar 2005 19:29:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8SZo-0004ha-1e; Mon, 07 Mar 2005 19:27:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8SZm-0004hQ-R0 for ippm@megatron.ietf.org; Mon, 07 Mar 2005 19:27:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28832 for ; Mon, 7 Mar 2005 19:27:51 -0500 (EST) Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Sc3-0004XB-5M for ippm@ietf.org; Mon, 07 Mar 2005 19:30:16 -0500 Received: from zanxmb00.cc-ntd1.covad.com (zanxmb00.corp.covad.com [172.16.2.119]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id QAA08817 for ; Mon, 7 Mar 2005 16:27:44 -0800 (PST) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.83]) by zanxmb00.cc-ntd1.covad.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Mar 2005 16:27:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [ippm]Comments on initial rough draft of capacity definitions Date: Mon, 7 Mar 2005 16:27:42 -0800 Message-ID: Thread-Topic: [ippm]Comments on initial rough draft of capacity definitions Thread-Index: AcUjdaQaUMFdTxECToaHfxM8TwQLFw== From: "Fardid, Reza" To: X-OriginalArrivalTime: 08 Mar 2005 00:27:42.0656 (UTC) FILETIME=[A46B2C00:01C52375] X-SPAM: 0.00% X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800814323==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1800814323== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52375.A41F0301" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52375.A41F0301 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Phil, =20 A couple of comments on this draft: =20 =20 1. Only metrics defined should be referred to, or otherwise all terms used should be defined: effective capacity and throughput (2.3), vs.=20 available capacity and utilization (3). 2. Even though the scope of IPPM and BM WGs is different, terms defined by the latter WG, such as throughput may be relevant in the context of this ID. =20 Regards, Reza Fardid=20 ------_=_NextPart_001_01C52375.A41F0301 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Phil,

 

A couple of comments on this draft:   =

 

  1. Only metrics defined should be referred to, or otherwise all terms used should be defined: effective capacity and throughput (2.3), vs.

available capacity and = utilization (3).

  1. Even though the scope of IPPM and BM WGs is = different, terms defined by the latter WG, such as throughput may be relevant in the context of this ID.

 

Regards,

Reza Fardid

=00 ------_=_NextPart_001_01C52375.A41F0301-- --===============1800814323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1800814323==-- From ippm-bounces@ietf.org Mon Mar 7 20:43:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05546 for ; Mon, 7 Mar 2005 20:43:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Tim-0004yL-5B; Mon, 07 Mar 2005 20:41:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Tau-0004Ms-Ht for ippm@megatron.ietf.org; Mon, 07 Mar 2005 20:33:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04901 for ; Mon, 7 Mar 2005 20:33:06 -0500 (EST) From: vze275m9@verizon.net Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TdB-00061x-Q9 for ippm@ietf.org; Mon, 07 Mar 2005 20:35:31 -0500 Received: from [130.129.135.156] by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ID000D5BEZ5H8O0@vms048.mailsrvcs.net> for ippm@ietf.org; Mon, 07 Mar 2005 19:33:06 -0600 (CST) Date: Mon, 07 Mar 2005 19:33:07 -0600 Subject: Re: [ippm]Comments on initial rough draft of capacity definitions In-reply-to: To: "Fardid, Reza" Message-id: <586c12b5f1e13e66652596b4a20c5f66@verizon.net> MIME-version: 1.0 (Apple Message framework v619.2) X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable References: X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 07 Mar 2005 20:41:14 -0500 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Reza: Thanks for your comments. We'll try to be more consistent in the next draft... Is there a specific BM RFC that you are referring to? On Mar 7, 2005, at 18:27, Fardid, Reza wrote: > Phil, > > =A0 > > A couple of comments on this draft:=A0=A0 > > =A0 > 1. Only metrics defined should be referred to, or otherwise = all=20 > terms used should be defined: effective capacity and throughput (2.3),=20= > vs. > > available capacity and utilization (3). > 2. Even though the scope of IPPM and BM WGs is different, = terms=20 > defined by the latter WG, such as throughput may be relevant in the=20 > context of this ID. > > =A0 > > Regards, > > Reza Fardid > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 7 22:05:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11831 for ; Mon, 7 Mar 2005 22:05:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8UzQ-0005R7-1l; Mon, 07 Mar 2005 22:02:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8UzO-0005Qr-Li for ippm@megatron.ietf.org; Mon, 07 Mar 2005 22:02:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11647 for ; Mon, 7 Mar 2005 22:02:28 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8V1g-0007w4-RI for ippm@ietf.org; Mon, 07 Mar 2005 22:04:54 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 495D21CD59E for ; Mon, 7 Mar 2005 22:02:26 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00754-05 for ; Mon, 7 Mar 2005 22:02:26 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 24EBA1CD59D for ; Mon, 7 Mar 2005 22:02:26 -0500 (EST) To: ippm@ietf.org Subject: [ippm] spatial complexity of n-reordering From: stanislav shalunov Date: 07 Mar 2005 21:40:06 -0500 Message-ID: <86u0nm3lo9.fsf@abel.internet2.edu> Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Since I didn't have enough time at the mike to make this comment and Henk suggested I send this to the list: Nischal's slides (not sure about the number) have a table that summarize spatial complexity of various metrics. The table claims O(N) for n-reordering, where N, I presume, is the sample size. The actual complexity is O(1). -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ All revolutions are bloody. The October Revolution was bloodless, but it was only the beginning. -- Dmitri Volkogonov _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 00:54:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25315 for ; Tue, 8 Mar 2005 00:54:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Xcz-00054o-6e; Tue, 08 Mar 2005 00:51:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Xcv-00052d-S6 for ippm@megatron.ietf.org; Tue, 08 Mar 2005 00:51:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25117 for ; Tue, 8 Mar 2005 00:51:25 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8XfC-0003AP-Lh for ippm@ietf.org; Tue, 08 Mar 2005 00:53:54 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id C14451CD856 for ; Tue, 8 Mar 2005 00:51:20 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23641-04 for ; Tue, 8 Mar 2005 00:51:20 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9C0C81CD84E for ; Tue, 8 Mar 2005 00:51:20 -0500 (EST) To: ippm@ietf.org Subject: Re: [ippm] spatial complexity of n-reordering References: <86u0nm3lo9.fsf@abel.internet2.edu> From: stanislav shalunov Date: 08 Mar 2005 00:51:26 -0500 In-Reply-To: <86u0nm3lo9.fsf@abel.internet2.edu> Message-ID: <861xaq1y8x.fsf@abel.internet2.edu> Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org stanislav shalunov writes: > O(N) for n-reordering, [...] The actual complexity is O(1). It was pointed out to me that I forgot to mention that the temporal complexity is O(N) rather than O(N^2) (as the table in Nischal's slides had it). -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Clothes make the man. Naked people have little or no influence on society. -- Mark Twain _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 12:32:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22267 for ; Tue, 8 Mar 2005 12:32:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iSi-00061D-2C; Tue, 08 Mar 2005 12:25:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iSf-000618-HI for ippm@megatron.ietf.org; Tue, 08 Mar 2005 12:25:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21461 for ; Tue, 8 Mar 2005 12:25:34 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iV5-0002K0-Uc for ippm@ietf.org; Tue, 08 Mar 2005 12:28:08 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id DFA3024061; Tue, 8 Mar 2005 18:25:27 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id EA08C24048 for ; Tue, 8 Mar 2005 18:25:25 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j28HPOeu006872 for ; Tue, 8 Mar 2005 18:25:25 +0100 Message-Id: <6.2.0.14.2.20050308182456.02cb66f8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Mar 2005 18:25:22 +0100 To: ippm@ietf.org From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000795 / -5.9 X-RIPE-Signature: 0458571248f75e316d712ebd7b25038f X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [ippm] The next steps for the reordering drafts. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org How about this... IPPM Group, Back in August 2004, we wrote: >Following the IPPM WG meeting in San Diego, the chairs of the WG met with >(some of) the authors of the 2 reordering metrics currently under >discussion in the IPPM WG, in order to discuss the next steps. The drafts >are: > > draft #1: draft-ietf-ippm-reordering-06.txt > draft #2: draft-jayasumana-reorder-density-03.txt (Now at -08 and -04 respectively) >We agreed that merging the 2 drafts will be close to impossible due to >differences in the basic definitions. We also concluded that both drafts >contain metrics that are relevant for applications that have to deal with >reordering. However, in this area, more study is needed for the second >draft. This research is in progress. > >We think that the best way forward is: > > 1. Add a statement to the introduction of the first draft saying that > the current metrics are limited to those that provide some > clear insight into network characterization or receiver design, > and are not likely to be exhaustive in their coverage of the > applications with respect to packet reordering effects. Likewise, > additional measurements may be possible. > 2. Finalize the first draft and publish as a standard track RFC > 3. Suggest to the WG to take the second draft up as a WG item. > 4. When the research related to the second draft is done, publish the > second draft as either an experimental RFC, or as a followup > to the first RFC. > >For technical details regarding this discussion, please refer to earlier >postings. > >Comments to the list please, The WG discussed the drafts in its meeting yesterday. Of the 4 steps mentioned above, (1) has been done. For step 2, Draft-ietf-ippm-reordering has gone through several revisions since August and all issues now appear to have been settled. The document is expected to be ready for last call soon. The chairs propose to finalize this draft as planned on short notice. In the meantime, the authors of draft-jayasumana-reorder-density-03.txt have continued their research, resulting in an -04 version of the draft and some related publications. The question is whether the WG feels that the 2 proposed metrics (RD and RBD) are sufficiently distinct from the metrics proposed in draft-ietf-ippm-reordering to warrant a second RFC by this WG (step 3 above). We would like to hear arguments, pro and con, if the working group feels that either the RD or the RBD metric (or both, of course) from draft-jayasumana-reorder-density should become a working group item. Please send your comments to the list before 1 April. The chairs, Matt & Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 12:34:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22806 for ; Tue, 8 Mar 2005 12:34:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iTB-00062P-OH; Tue, 08 Mar 2005 12:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iTA-00062K-8K for ippm@megatron.ietf.org; Tue, 08 Mar 2005 12:26:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21503 for ; Tue, 8 Mar 2005 12:26:05 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iVb-0002Kj-2N for ippm@ietf.org; Tue, 08 Mar 2005 12:28:39 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 4B66124063; Tue, 8 Mar 2005 18:25:59 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 781A62405A; Tue, 8 Mar 2005 18:25:58 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j28HPueu007200; Tue, 8 Mar 2005 18:25:57 +0100 Message-Id: <6.2.0.14.2.20050308182537.02cb65b0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Mar 2005 18:25:54 +0100 To: Matthew J Zekauskas , ippm@ietf.org From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000088 / -5.9 X-RIPE-Signature: 9fcfd8490e11ce71b37a2cc0fd735bba X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [ippm] Proposal make TWAMP a working group item. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org IPPM Group, Following discussion in the IPPM WG meeting yesterday, we propose to turn draft-hedayat-two-way-active-measurement-protocol-00.txt into a working group item. Comments (pro and con) to the list by April 15, please, The chairs, Henk & Matt ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 12:35:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23149 for ; Tue, 8 Mar 2005 12:35:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iTq-000654-4e; Tue, 08 Mar 2005 12:26:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iTo-00064z-IN for ippm@megatron.ietf.org; Tue, 08 Mar 2005 12:26:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21558 for ; Tue, 8 Mar 2005 12:26:45 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iWE-0002LS-CN for ippm@ietf.org; Tue, 08 Mar 2005 12:29:19 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 90E262406F; Tue, 8 Mar 2005 18:26:38 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8FE872406D; Tue, 8 Mar 2005 18:26:37 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j28HQZeu007538; Tue, 8 Mar 2005 18:26:37 +0100 Message-Id: <6.2.0.14.2.20050308182609.02cc07b0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Mar 2005 18:26:34 +0100 To: Matthew J Zekauskas , ippm@ietf.org From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000039 / -5.9 X-RIPE-Signature: 04486b64d24bb3c50935c31443de1e7e X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [ippm] Proposed new work items for the group X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org IPPM group, Following the discussion at our meeting yesterday, we would like to ask the group if * draft-stefan-ippm-multimetrics-00.txt * draft-niccolini-ippm-storetraceroutes-00.txt should become working group items. Please review the documents and post your comments to the list before April 28, The chairs, Matt & Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 13:04:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26436 for ; Tue, 8 Mar 2005 13:04:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8j1t-0002P2-M5; Tue, 08 Mar 2005 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8j1s-0002Ox-19 for ippm@megatron.ietf.org; Tue, 08 Mar 2005 13:02:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26297 for ; Tue, 8 Mar 2005 13:01:56 -0500 (EST) Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8j4F-0003KI-R0 for ippm@ietf.org; Tue, 08 Mar 2005 13:04:31 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j28I0Epv015477 for ; Tue, 8 Mar 2005 13:01:42 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh0i.attrh.att.com (7.1.006) id 422B38410005665C; Tue, 8 Mar 2005 13:01:41 -0500 Received: from acmortonw.att.com ([135.210.128.208]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j28I1eZ09900; Tue, 8 Mar 2005 13:01:40 -0500 (EST) Message-Id: <6.0.3.0.0.20050308125820.01ee50d0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 08 Mar 2005 13:00:54 -0500 To: Henk Uijterwaal , ippm@ietf.org From: Al Morton Subject: Re: [ippm] The next steps for the reordering drafts. In-Reply-To: <6.2.0.14.2.20050308182456.02cb66f8@localhost> References: <6.2.0.14.2.20050308182456.02cb66f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Matthew J Zekauskas X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Henk, Matt, One small clarification: At 12:25 PM 03/08/2005, Henk Uijterwaal wrote: >> draft #1: draft-ietf-ippm-reordering-06.txt >> draft #2: draft-jayasumana-reorder-density-03.txt > >(Now at -08 and -04 respectively) It's -09 now for draft-ietf-ippm-reordering, (08 was for 2nd WGLC) and there will be another rev shortly to capture comments at this meeting. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 13:39:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29844 for ; Tue, 8 Mar 2005 13:39:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jXN-0004ll-2w; Tue, 08 Mar 2005 13:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jXI-0004lb-GX for ippm@megatron.ietf.org; Tue, 08 Mar 2005 13:34:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29251 for ; Tue, 8 Mar 2005 13:34:24 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jZh-00043D-Cq for ippm@ietf.org; Tue, 08 Mar 2005 13:36:59 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j28IYNS483826 for ; Tue, 8 Mar 2005 11:34:24 -0700 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j28IYNK04899 for ; Tue, 8 Mar 2005 11:34:23 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Tue, 8 Mar 2005 11:34:23 -0700 From: Nischal M Piratla To: ippm X-EXP32-SerialNo: 00002247, 00002264 Subject: RE: [ippm] spatial complexity of n-reordering Message-ID: <42430465@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Order of spatial and computation complexity for n-reordering are O(N) and O(N^2) respectively. This is true for almost all IPPM metrics due to the absence of any robust mechanism to detect and remove duplicate packets. You will have to either store the early arrivals or the missing numbers. The worst case scenario for both could be order of N. This is what we all said about the RBD in the initial stages, before we explained the offset concept to all. Also, everytime you receive a packet, you are required to match them against this stored arrivals.. i.e., 1, 2, 3, 4, 5, .... = N(N+1)/2 comparisons. Thus, leading to O(N^2) complexities. - Nischal >===== Original Message From stanislav shalunov ===== >stanislav shalunov writes: > >> O(N) for n-reordering, [...] The actual complexity is O(1). > >It was pointed out to me that I forgot to mention that the temporal >complexity is O(N) rather than O(N^2) (as the table in Nischal's >slides had it). > >-- >Stanislav Shalunov http://www.internet2.edu/~shalunov/ > >Clothes make the man. Naked people have little or no influence on >society. -- Mark Twain > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7794 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 13:51:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01004 for ; Tue, 8 Mar 2005 13:51:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jiY-0005gW-1T; Tue, 08 Mar 2005 13:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jiV-0005ez-UN for ippm@megatron.ietf.org; Tue, 08 Mar 2005 13:46:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00511 for ; Tue, 8 Mar 2005 13:45:57 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jku-0004HG-Cj for ippm@ietf.org; Tue, 08 Mar 2005 13:48:32 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j28IjxS1326770 for ; Tue, 8 Mar 2005 11:45:59 -0700 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j28IjuK07732 for ; Tue, 8 Mar 2005 11:45:56 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Tue, 8 Mar 2005 11:45:56 -0700 From: Nischal M Piratla To: ippm@ietf.org X-EXP32-SerialNo: 00002247, 00002264 Message-ID: <42432696@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [ippm] Comment on threshold on buffer sizes X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Yesterday, we discussed about the threshold on buffer sizes briniging the spatial complexity of the same for RD and RBD to a constant. I guess, the time of the day didn't help many to get it right. I am answering the query about test equipment query. Q: What do you mean the buffer requirement is constant when we at backbone have thousands of packets arriving in a second? We store these packets and compute reorder measures. Ans: The spatial complexities of a metric corresponds to the resource requirement to perform the computation. If a test equipment is receiving thousands of packets in a second, then storing them to compute any measure (let it be reordering or loss) has no relation to the metric that will be used. So, if we are to determine the reordering using RD or RBD we can use a buffer of a constant size (DT or BT respectively). But with ippm metrics (as explained in previous email on spatial complexities), the spatial complexity is O(N). - Nischal **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7794 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 14:11:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03086 for ; Tue, 8 Mar 2005 14:11:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8k4Q-0007Ii-2a; Tue, 08 Mar 2005 14:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8k4O-0007IZ-M7 for ippm@megatron.ietf.org; Tue, 08 Mar 2005 14:08:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02879 for ; Tue, 8 Mar 2005 14:08:39 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8k6n-0004qa-DQ for ippm@ietf.org; Tue, 08 Mar 2005 14:11:12 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3B1DD1CD82A for ; Tue, 8 Mar 2005 14:08:36 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21456-01 for ; Tue, 8 Mar 2005 14:08:36 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 0E0F61CD6D3 for ; Tue, 8 Mar 2005 14:08:36 -0500 (EST) To: ippm@ietf.org Subject: Re: [ippm] spatial complexity of n-reordering References: <42430465@webmail.colostate.edu> From: stanislav shalunov Date: 08 Mar 2005 14:08:43 -0500 In-Reply-To: <42430465@webmail.colostate.edu> Message-ID: <863bv6ymys.fsf@abel.internet2.edu> Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Nischal M Piratla writes: > Order of spatial and computation complexity for n-reordering are > O(N) and O(N^2) respectively. Look at the program of example 1 of appendix A of draft-ietf-ippm-reordering-09.txt. It computes n-reordering (for all n<=100) of a sample of size N in O(N) time and O(1) space. P.S. Even if what you said about spatial complexity were true, the temporal complexity would remain O(N). Hint: put sequence numbers in a hash table of size 2N. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "The power of accurate observation is commonly called cynicism by those who have not got it." -- G. B. Shaw _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 16:28:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21595 for ; Tue, 8 Mar 2005 16:28:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mED-0000Fp-IH; Tue, 08 Mar 2005 16:26:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mEB-0000Fj-Pk for ippm@megatron.ietf.org; Tue, 08 Mar 2005 16:26:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21463 for ; Tue, 8 Mar 2005 16:26:53 -0500 (EST) Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mGc-0001Ws-MJ for ippm@ietf.org; Tue, 08 Mar 2005 16:29:29 -0500 Received: from zanxmb00.cc-ntd1.covad.com (zanxmb00.corp.covad.com [172.16.2.119]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id NAA21518; Tue, 8 Mar 2005 13:26:42 -0800 (PST) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.83]) by zanxmb00.cc-ntd1.covad.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 13:26:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm]Comments on initial rough draft of capacity definitions Date: Tue, 8 Mar 2005 13:26:41 -0800 Message-ID: Thread-Topic: [ippm]Comments on initial rough draft of capacity definitions Thread-Index: AcUjfsj6DjtZdUMySb+I5ayF/Zle/QApju/g From: "Fardid, Reza" To: X-OriginalArrivalTime: 08 Mar 2005 21:26:42.0515 (UTC) FILETIME=[85AEEA30:01C52425] X-SPAM: 0.00% X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Phil, 2544 and 3918 may be relevant as far as throughput is concerned. Thanks, Reza -----Original Message----- From: vze275m9@verizon.net [mailto:vze275m9@verizon.net]=20 Sent: Monday, March 07, 2005 5:33 PM To: Fardid, Reza Cc: ippm@ietf.org Subject: Re: [ippm]Comments on initial rough draft of capacity = definitions Hi Reza: Thanks for your comments. We'll try to be more consistent in the next draft... Is there a specific BM RFC that you are referring to? On Mar 7, 2005, at 18:27, Fardid, Reza wrote: > Phil, > > =A0 > > A couple of comments on this draft:=A0=A0 > > =A0 > 1. Only metrics defined should be referred to, or otherwise all=20 > terms used should be defined: effective capacity and throughput (2.3), = > vs. > > available capacity and utilization (3). > 2. Even though the scope of IPPM and BM WGs is different, terms=20 > defined by the latter WG, such as throughput may be relevant in the=20 > context of this ID. > > =A0 > > Regards, > > Reza Fardid > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 20:46:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12345 for ; Tue, 8 Mar 2005 20:46:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8qDL-00053o-JT; Tue, 08 Mar 2005 20:42:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8qDK-00053b-2g for ippm@megatron.ietf.org; Tue, 08 Mar 2005 20:42:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11912 for ; Tue, 8 Mar 2005 20:42:16 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8qFp-0006aS-0H for ippm@ietf.org; Tue, 08 Mar 2005 20:44:53 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 2E39324284; Wed, 9 Mar 2005 02:42:04 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 35F402462C; Wed, 9 Mar 2005 02:42:00 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j291fueu009087; Wed, 9 Mar 2005 02:41:58 +0100 Message-Id: <6.2.0.14.2.20050309023709.02c906d0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Mar 2005 02:41:53 +0100 To: Nischal M Piratla , ippm From: Henk Uijterwaal Subject: RE: [ippm] spatial complexity of n-reordering In-Reply-To: <42430465@webmail.colostate.edu> References: <42430465@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.021537 / -5.9 X-RIPE-Signature: 983773c5903f3324b4574d8c85ec9a1c X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 19:34 08/03/2005, Nischal M Piratla wrote: >Also, everytime >you receive a packet, you are required to match them against this stored >arrivals.. i.e., 1, 2, 3, 4, 5, .... = N(N+1)/2 comparisons. Thus, leading to >O(N^2) complexities. Mainly for my own understanding: if I have a sequence of 3 packets: 1 arrives, 2 arrives. I now have to compare 1 against 2 to check if they are in order. Then 3 arrives. I have to compare 3 against 1 and 2. That is 3 comparisons. However, you say N(N+1)/2 = 3*4/2 = 6 comparisons. If a 4th packet arrives, I have to compare it against 1, 2 and 3. That is 6 comparisons. You say N(N+1)/2 = 4*5/2= 10 comparisons. (And I'd actually do this in a smarter way: first compare against the previous packet: 1 arrive, 2 arrives, compare 1 and 2. Then 3 arrives, compare against 2 first, if (1,2) are in order and (2,3) are in order, then (1,2,3) must be in order too. Henk >- Nischal > > > > >===== Original Message From stanislav shalunov > ===== > >stanislav shalunov writes: > > > >> O(N) for n-reordering, [...] The actual complexity is O(1). > > > >It was pointed out to me that I forgot to mention that the temporal > >complexity is O(N) rather than O(N^2) (as the table in Nischal's > >slides had it). > > > >-- > >Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > > >Clothes make the man. Naked people have little or no influence on > >society. -- Mark Twain > > > >_______________________________________________ > >ippm mailing list > >ippm@ietf.org > >https://www1.ietf.org/mailman/listinfo/ippm > >**************************************************** >Research Assistant >Computer Networking Research Laboratory (CNRL) >C203,Dept. of Electrical & Computer Eng. >Colorado State University, >Fort Collins, CO 80523 >Voice: 970-491-7067/7794 >Fax: 970-491-2249 >http://www.cnrl.colostate.edu >http://lamar.colostate.edu/~nischal >**************************************************** > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 20:47:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12419 for ; Tue, 8 Mar 2005 20:47:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8qFF-0005CH-5S; Tue, 08 Mar 2005 20:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8qFD-0005CC-Bj for ippm@megatron.ietf.org; Tue, 08 Mar 2005 20:44:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12108 for ; Tue, 8 Mar 2005 20:44:13 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8qHi-0006dH-Ee for ippm@ietf.org; Tue, 08 Mar 2005 20:46:50 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 45AE62461F; Wed, 9 Mar 2005 02:44:06 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 54C7524626; Wed, 9 Mar 2005 02:44:05 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j291i2eu009400; Wed, 9 Mar 2005 02:44:04 +0100 Message-Id: <6.2.0.14.2.20050309024239.02cd3a18@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Mar 2005 02:44:00 +0100 To: Nischal M Piratla , ippm@ietf.org From: Henk Uijterwaal Subject: Re: [ippm] Comment on threshold on buffer sizes In-Reply-To: <42432696@webmail.colostate.edu> References: <42432696@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.030469 / -5.9 X-RIPE-Signature: b75f94b2d2691fdfd08ae49aec6ade0c X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 19:45 08/03/2005, Nischal M Piratla wrote: >Yesterday, we discussed about the threshold on buffer sizes briniging the >spatial complexity of the same for RD and RBD to a constant. I guess, the >time >of the day didn't help many to get it right. I am answering the query about >test equipment query. > >Q: What do you mean the buffer requirement is constant when we at backbone >have thousands of packets arriving in a second? We store these packets and >compute reorder measures. > >Ans: The spatial complexities of a metric corresponds to the resource >requirement to perform the computation. If a test equipment is receiving >thousands of packets in a second, then storing them to compute any measure >(let it be reordering or loss) has no relation to the metric that will be >used. OK, I ageee. >So, if we are to determine the reordering using RD or RBD we can use a buffer >of a constant size (DT or BT respectively). But with ippm metrics (as >explained in previous email on spatial complexities), the spatial complexity >is O(N). Now wait: if I want to apply a metric offline, I will have to store N packets (or at least N sequence numbers) for ANY algorithm, requiring a buffer of O(N). Henk >- Nischal > >**************************************************** >Research Assistant >Computer Networking Research Laboratory (CNRL) >C203,Dept. of Electrical & Computer Eng. >Colorado State University, >Fort Collins, CO 80523 >Voice: 970-491-7067/7794 >Fax: 970-491-2249 >http://www.cnrl.colostate.edu >http://lamar.colostate.edu/~nischal >**************************************************** > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 21:27:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14374 for ; Tue, 8 Mar 2005 21:27:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8qrA-0008Vx-2K; Tue, 08 Mar 2005 21:23:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8qr8-0008Vs-5S for ippm@megatron.ietf.org; Tue, 08 Mar 2005 21:23:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14213 for ; Tue, 8 Mar 2005 21:23:22 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8qtb-0007Io-Bd for ippm@ietf.org; Tue, 08 Mar 2005 21:25:59 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j292NMS1438132 for ; Tue, 8 Mar 2005 19:23:22 -0700 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j292NMK00938 for ; Tue, 8 Mar 2005 19:23:22 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Tue, 8 Mar 2005 19:23:22 -0700 From: Nischal M Piratla To: ippm@ietf.org X-EXP32-SerialNo: 00002247, 00002264 Subject: RE: [ippm] spatial complexity of n-reordering Message-ID: <42472553@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Henk, What I presented is a worst case scenario's order of computation ( as I did mention in during my presentation). Also, with arrivals the formula of N(N+1)/2 is put approximately (rather erronously). However, it doesn't affect the result. The exact formula can be computed as follows With second arrival, we make 1 comparison, with 3rd arrival we make two comparions, i.e., to first and second, with fourth arrival, we compare the packet number to first, second and third arrivals. Thus, by 4th arrival, we have 1 comparison (at second arrival) 2 comparisons (at third arrival) 3 comparisons (at fourth arrival) .. .. The formula is (N-1)*(N)/2. The example that you mentioned depends on a property of an arrival sequence, i.e., hoping previous arrivals are in order. We will hit the above limit as in the formula, if things are not in order. To implement these metrics, it is important to know the worst case complexities Thanks, Nischal >===== Original Message From Henk Uijterwaal ===== >At 19:34 08/03/2005, Nischal M Piratla wrote: > > >>Also, everytime >>you receive a packet, you are required to match them against this stored >>arrivals.. i.e., 1, 2, 3, 4, 5, .... = N(N+1)/2 comparisons. Thus, leading to >>O(N^2) complexities. > >Mainly for my own understanding: if I have a sequence of 3 packets: 1 arrives, >2 arrives. I now have to compare 1 against 2 to check if they are in order. >Then 3 arrives. I have to compare 3 against 1 and 2. That is 3 comparisons. >However, you say N(N+1)/2 = 3*4/2 = 6 comparisons. > >If a 4th packet arrives, I have to compare it against 1, 2 and 3. That >is 6 comparisons. You say N(N+1)/2 = 4*5/2= 10 comparisons. > >(And I'd actually do this in a smarter way: first compare against the >previous packet: 1 arrive, 2 arrives, compare 1 and 2. Then 3 arrives, >compare against 2 first, if (1,2) are in order and (2,3) are in order, >then (1,2,3) must be in order too. > >Henk > > > >>- Nischal >> >> >> >> >===== Original Message From stanislav shalunov >> ===== >> >stanislav shalunov writes: >> > >> >> O(N) for n-reordering, [...] The actual complexity is O(1). >> > >> >It was pointed out to me that I forgot to mention that the temporal >> >complexity is O(N) rather than O(N^2) (as the table in Nischal's >> >slides had it). >> > >> >-- >> >Stanislav Shalunov http://www.internet2.edu/~shalunov/ >> > >> >Clothes make the man. Naked people have little or no influence on >> >society. -- Mark Twain >> > >> >_______________________________________________ >> >ippm mailing list >> >ippm@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ippm >> >>**************************************************** >>Research Assistant >>Computer Networking Research Laboratory (CNRL) >>C203,Dept. of Electrical & Computer Eng. >>Colorado State University, >>Fort Collins, CO 80523 >>Voice: 970-491-7067/7794 >>Fax: 970-491-2249 >>http://www.cnrl.colostate.edu >>http://lamar.colostate.edu/~nischal >>**************************************************** >> >> >>_______________________________________________ >>ippm mailing list >>ippm@ietf.org >>https://www1.ietf.org/mailman/listinfo/ippm > >----------------------------------------------------------------------------- - >Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.amsterdamned.org/~henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >----------------------------------------------------------------------------- - > >Look here junior, don't you be so happy. >And for Heaven's sake, don't you be so sad. (Tom Verlaine) **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7794 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 21:38:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15572 for ; Tue, 8 Mar 2005 21:38:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8r2v-0001Al-EY; Tue, 08 Mar 2005 21:35:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8r2t-0001Ae-5j for ippm@megatron.ietf.org; Tue, 08 Mar 2005 21:35:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15245 for ; Tue, 8 Mar 2005 21:35:33 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8r5O-0007ZA-ON for ippm@ietf.org; Tue, 08 Mar 2005 21:38:11 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j292ZXS948012; Tue, 8 Mar 2005 19:35:33 -0700 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j292ZXK02305; Tue, 8 Mar 2005 19:35:33 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Tue, 8 Mar 2005 19:35:33 -0700 From: Nischal M Piratla To: Henk Uijterwaal X-EXP32-SerialNo: 00002247, 00002264 Subject: RE: [ippm] Comment on threshold on buffer sizes Message-ID: <42473809@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit >Now wait: if I want to apply a metric offline, I will have to store N packets >(or at least N sequence numbers) for ANY algorithm, requiring a buffer of >O(N). Given a sequence of numbers in a storage, the spatial complexity for that sequence is an absurd concept at the first place. Let it be reordering or anything else, one MUST not define spatial complexities on the data itself. It is during the computation that we define spatial complexities. Many algos have spatial complexities, e.g., a certain sorting algo may have a spatial complexity of O(logN), i.e., during the computation, it will use a RAM of that order. Now, if numbers are in a hard disc or other media, do we say that the spatial complexity is N because we have these numbers somewhere? I probably missed a point here. In addition, the computation complexities of ippm metrics will still be at a worst case order of O(N^2), due to comparisons associated with duplicate detections. - Nischal **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7794 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 8 21:52:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16584 for ; Tue, 8 Mar 2005 21:52:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8rBv-00024F-CO; Tue, 08 Mar 2005 21:44:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8rBt-000246-Kv for ippm@megatron.ietf.org; Tue, 08 Mar 2005 21:44:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16084 for ; Tue, 8 Mar 2005 21:44:51 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8rEO-0007mB-99 for ippm@ietf.org; Tue, 08 Mar 2005 21:47:29 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 5EE2524297; Wed, 9 Mar 2005 03:44:43 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5FFDD24655; Wed, 9 Mar 2005 03:44:40 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j292ibeu022906; Wed, 9 Mar 2005 03:44:39 +0100 Message-Id: <6.2.0.14.2.20050309034405.02cc50e8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 09 Mar 2005 03:44:34 +0100 To: Nischal M Piratla From: Henk Uijterwaal Subject: RE: [ippm] Comment on threshold on buffer sizes In-Reply-To: <42473809@webmail.colostate.edu> References: <42473809@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.100992 / -5.9 X-RIPE-Signature: 6e045fc0ddd718c7892767912fb07acd X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 03:35 09/03/2005, Nischal M Piratla wrote: > >Now wait: if I want to apply a metric offline, I will have to store N > packets > >(or at least N sequence numbers) for ANY algorithm, requiring a buffer of > >O(N). > >Given a sequence of numbers in a storage, the spatial complexity for that >sequence is an absurd concept at the first place. Let it be reordering or >anything else, one MUST not define spatial complexities on the data itself. > >It is during the computation that we define spatial complexities. Aha, that's what I missed. I said this was for my own understanding :-) Henk >Many algos >have spatial complexities, e.g., a certain sorting algo may have a spatial >complexity of O(logN), i.e., during the computation, it will use a RAM of >that >order. Now, if numbers are in a hard disc or other media, do we say that the >spatial complexity is N because we have these numbers somewhere? I probably >missed a point here. > >In addition, the computation complexities of ippm metrics will still be at a >worst case order of O(N^2), due to comparisons associated with duplicate >detections. > >- Nischal > >**************************************************** >Research Assistant >Computer Networking Research Laboratory (CNRL) >C203,Dept. of Electrical & Computer Eng. >Colorado State University, >Fort Collins, CO 80523 >Voice: 970-491-7067/7794 >Fax: 970-491-2249 >http://www.cnrl.colostate.edu >http://lamar.colostate.edu/~nischal >**************************************************** ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 9 01:22:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07006 for ; Wed, 9 Mar 2005 01:22:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8uWi-0004hs-RF; Wed, 09 Mar 2005 01:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8uWh-0004bo-4S for ippm@megatron.ietf.org; Wed, 09 Mar 2005 01:18:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05572 for ; Wed, 9 Mar 2005 01:18:27 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8uZ8-0004Hf-08 for ippm@ietf.org; Wed, 09 Mar 2005 01:21:06 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j296IQS1038562; Tue, 8 Mar 2005 23:18:26 -0700 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j296IPK06530; Tue, 8 Mar 2005 23:18:26 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Tue, 8 Mar 2005 23:18:25 -0700 From: Nischal M Piratla To: stanislav shalunov X-EXP32-SerialNo: 00002247, 00002264 Subject: RE: [ippm] spatial complexity of n-reordering Message-ID: <424865C3@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Unless you are claiming that n-reordering considers duplicate packets as reordered, I do not see how the order of computation complexity is less than O(N^2). Let us consider the sequence (1,3,2,4,2). Here packet 2 is a duplicate. Given, this sequence, following is step-thru of n-reordering program "example 1 of appendix A" Ring:: (empty) Read packet s = 1 Ring::1 Increment frequency of none Read packet s = 3 Ring::1 3 Increment frequency of none Read packet s = 2 Previous packet 3 > s Increment frequency of 1-reordering by 1 (now 1) Still previous packet 1 < s, so stop. 1-reordering = 1 Ring::1 3 2 Read packet s = 4 Previous packet 3 < s Increment frequency of none 1-reordering = 1 Ring::1 3 2 4 Read packet s = 2 Previous packet 4 > s Increment frequency of 1-reordering by 1 (now 2) Still previous packet 2 = s, so stop 1-reordering = 2 But, *the duplicate of 2 is considered reordered*! - Nischal >===== Original Message From stanislav shalunov ===== >Nischal M Piratla writes: > >> Order of spatial and computation complexity for n-reordering are >> O(N) and O(N^2) respectively. > >Look at the program of example 1 of appendix A of >draft-ietf-ippm-reordering-09.txt. It computes n-reordering (for all >n<=100) of a sample of size N in O(N) time and O(1) space. > >P.S. Even if what you said about spatial complexity were true, the >temporal complexity would remain O(N). Hint: put sequence numbers in >a hash table of size 2N. > >-- >Stanislav Shalunov http://www.internet2.edu/~shalunov/ > >"The power of accurate observation is commonly called cynicism by >those who have not got it." -- G. B. Shaw > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7794 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 9 08:01:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29334 for ; Wed, 9 Mar 2005 08:01:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D90mn-0004FT-Up; Wed, 09 Mar 2005 07:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D90mm-0004FO-VR for ippm@megatron.ietf.org; Wed, 09 Mar 2005 07:59:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28999 for ; Wed, 9 Mar 2005 07:59:33 -0500 (EST) Received: from bulbasaur.rediris.es ([130.206.194.34] helo=paraguas) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D90pL-0006nD-0G for ippm@ietf.org; Wed, 09 Mar 2005 08:02:16 -0500 Received: from fedemp by paraguas with local (Exim 3.36 #1 (Debian)) id 1D90oN-0004D7-00 for ; Wed, 09 Mar 2005 14:01:15 +0100 Date: Wed, 9 Mar 2005 14:01:15 +0100 From: Federico Montesino Pouzols To: ippm@ietf.org Subject: Re: [ippm] Comments on initial rough draft of capacity definitions Message-ID: <20050309130115.GA16153@paraguas> Mail-Followup-To: ippm@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Federico Montesino Pouzols List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi all, I also have some general comments on the draft: a) I would suggest updating the reference [PDM] to a more recent, (extended and updated) work on the subject by the same authors: Dovrolis, C., Ramanathan, P. and D. Moore, "Packet dispersion techniques and a capacity estimation methodology", IEEE/ACM Transactions on Networking 12(6): 963-977, December 2004. b) Following the aforementioned reference, and other works from the same and different authors, I understand that what is called 'Available Capacity' in the draft is usually called 'Available Bandwidth'. Is there any reason for choosing another term? c) For the Abstract section (and as point of view for the whole draft), I think it would be clearer to talk of capacity as a metric that describes a the state of a network link/path at a given time rather than IP traffic. Regards. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 9 09:37:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08491 for ; Wed, 9 Mar 2005 09:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92BD-0004ir-2g; Wed, 09 Mar 2005 09:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92BB-0004im-K8 for ippm@megatron.ietf.org; Wed, 09 Mar 2005 09:28:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07105 for ; Wed, 9 Mar 2005 09:28:51 -0500 (EST) From: vze275m9@verizon.net Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D92Dn-0000N3-IO for ippm@ietf.org; Wed, 09 Mar 2005 09:31:35 -0500 Received: from [130.129.135.156] by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ID300L3W9K3O830@vms048.mailsrvcs.net> for ippm@ietf.org; Wed, 09 Mar 2005 08:28:52 -0600 (CST) Date: Wed, 09 Mar 2005 08:28:51 -0600 Subject: Re: [ippm] Comments on initial rough draft of capacity definitions In-reply-to: <20050309130115.GA16153@paraguas> To: Federico Montesino Pouzols Message-id: <1731b0b49b0b62dd278c002f6354188d@verizon.net> MIME-version: 1.0 (Apple Message framework v619.2) X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit References: <20050309130115.GA16153@paraguas> X-Spam-Score: 0.6 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Federico: Thanks. Responses inline. On Mar 9, 2005, at 07:01, Federico Montesino Pouzols wrote: > > Hi all, I also have some general comments on the draft: > > a) I would suggest updating the reference [PDM] to a more recent, > (extended and updated) work on the subject by the same authors: > > Dovrolis, C., Ramanathan, P. and D. Moore, "Packet dispersion > techniques and a capacity estimation methodology", IEEE/ACM > Transactions on Networking 12(6): 963-977, December 2004. > Thanks for the reference. I'll use the updated reference in the next draft. > b) Following the aforementioned reference, and other works from the > same and different authors, I understand that what is called > 'Available Capacity' in the draft is usually called 'Available > Bandwidth'. Is there any reason for choosing another term? > Yes. We chose capacity because bandwidth is a term that covers lots of things and is easily misunderstood. Suppose that you have and RF link. Is the bandwidth the frequency band in which you transmit (Hz), the raw information-carrying capacity (bps), the information carrying capacity minus redundancy coding and physical layer overhead (bps), etc, etc. We are actually defining is the information carrying capacity as seen by the IP layer. Hence the choice of terminology and qualifications (i.e. IP layer ....). > c) For the Abstract section (and as point of view for the whole > draft), I think it would be clearer to talk of capacity as a metric > that describes a the state of a network link/path at a given time > rather than IP traffic. We agreed in the WG that in this draft, we were not going to try to define metrics, but focus on very precisely defining the quantities of interest, rather than how to measure them. That is a hard enough task for the short term :-) Regards, Phil Chimento _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 9 11:13:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20020 for ; Wed, 9 Mar 2005 11:13:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93lf-0003rR-0d; Wed, 09 Mar 2005 11:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93lc-0003rH-D2 for ippm@megatron.ietf.org; Wed, 09 Mar 2005 11:10:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19765 for ; Wed, 9 Mar 2005 11:10:33 -0500 (EST) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93oF-0003QH-3B for ippm@ietf.org; Wed, 09 Mar 2005 11:13:19 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id D0BE5C339 for ; Wed, 9 Mar 2005 11:10:22 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j29GAMRs009736 for ; Wed, 9 Mar 2005 11:10:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j29GAL7b009151 for ; Wed, 9 Mar 2005 11:10:22 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 08053-07 for ;Wed, 9 Mar 2005 11:10:21 -0500 (EST) Received: from sunfire.grc.nasa.gov (IDENT:postfix@sunfire.grc.nasa.gov [139 .88.111.70])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMT P id j29GAKKl009141for ; Wed, 9 Mar 2005 11:10:20 -0500 (EST ) Received: by sunfire.grc.nasa.gov (Postfix, from userid 500)id EA6E1BC1C0; W ed, 9 Mar 2005 12:07:43 -0500 (EST) Date: Wed, 9 Mar 2005 12:07:43 -0500 From: Joseph Ishac To: ippm@ietf.org Subject: Re: [ippm] Comments on initial rough draft of capacity definitions Message-ID: <20050309170743.GA3559@sunfire.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org References: <20050309130115.GA16153@paraguas> <1731b0b49b0b62dd278c002f63541 88d@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1731b0b49b0b62dd278c002f6354188d@verizon.net> User-Agent: Mutt/1.4.2.1i X-imss-version: 2.19 X-imss-result: Passed X-imss-approveListMatch: *@*.nasa.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Ishac List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Some further comment on (b): We originally called 'available capacity' 'available bandwidth', and we ran with the former term as Phil explained in his note. However, we did have a snip-it of text that was removed that indicated the common interchangeability of the two terms. Perhaps we can work that back into the draft? -Joseph On Wed, Mar 09, 2005 at 08:28:51AM -0600, vze275m9@verizon.net wrote: > > b) Following the aforementioned reference, and other works from the > > same and different authors, I understand that what is called > > 'Available Capacity' in the draft is usually called 'Available > > Bandwidth'. Is there any reason for choosing another term? > > > > Yes. We chose capacity because bandwidth is a term that covers lots of > things and is easily misunderstood. Suppose that you have and RF link. > Is the bandwidth the frequency band in which you transmit (Hz), the raw > information-carrying capacity (bps), the information carrying capacity > minus redundancy coding and physical layer overhead (bps), etc, etc. We > are actually defining is the information carrying capacity as seen by > the IP layer. Hence the choice of terminology and qualifications (i.e. > IP layer ....). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 9 13:19:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03677 for ; Wed, 9 Mar 2005 13:19:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D95gX-00083a-Hl; Wed, 09 Mar 2005 13:13:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D95gW-00083O-GY for ippm@megatron.ietf.org; Wed, 09 Mar 2005 13:13:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03133 for ; Wed, 9 Mar 2005 13:13:25 -0500 (EST) Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D95jA-0006rC-9y for ippm@ietf.org; Wed, 09 Mar 2005 13:16:12 -0500 Received: from zanxmb00.cc-ntd1.covad.com (zanxmb00.corp.covad.com [172.16.2.119]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id KAA29658 for ; Wed, 9 Mar 2005 10:13:18 -0800 (PST) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.83]) by zanxmb00.cc-ntd1.covad.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 10:13:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Mar 2005 10:13:17 -0800 Message-ID: Thread-Topic: Comments on ITU-T IP Performance Work Status Thread-Index: AcUk06rZLMESl5baTam3/TIZ7xrrfQ== From: "Fardid, Reza" To: X-OriginalArrivalTime: 09 Mar 2005 18:13:17.0570 (UTC) FILETIME=[AB029620:01C524D3] X-SPAM: 0.00% X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [ippm] Comments on ITU-T IP Performance Work Status X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1442491895==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1442491895== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C524D3.AADD5317" This is a multi-part message in MIME format. ------_=_NextPart_001_01C524D3.AADD5317 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Al, =20 A have a number of comments on the Y.1541 loss performance objectives, existing and new: =20 1. Is there an ITU-T implementation report, e.g., from SPs that are relying on the current IPLR objective of 10^(-3) for performance management ? 2. Is the new loss objective of 10^(-5) recommended for all QoS classes, similar to the current recommendation, which does not differentiate between real-time and best-effort services ? 3. Is the new loss objective of 10^(-5) derived from empirical evidence or some other methodology ? =20 These questions are relevant in the context of performance management, which may be beyond the scope of IPPM. If so, then I appreciate your off-list response. =20 Regards, Reza Fardid ------_=_NextPart_001_01C524D3.AADD5317 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Al,

 

A have a number of comments on the Y.1541 loss = performance objectives, existing and new:

 

  1. Is there an ITU-T implementation report, e.g., = from SPs that are relying on the current IPLR objective of 10^(-3) for = performance management ?
  2. Is the new loss objective of 10^(-5) recommended = for all QoS classes, similar to the current recommendation, which does not = differentiate between real-time and best-effort services ?
  3. Is the new loss objective of 10^(-5) derived = from empirical evidence or some other methodology ?

 

These questions are relevant in the context of = performance management, which may be beyond the scope of IPPM. If so, then I = appreciate your off-list response.

 

Regards,

Reza Fardid

=00 ------_=_NextPart_001_01C524D3.AADD5317-- --===============1442491895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1442491895==-- From ippm-bounces@ietf.org Wed Mar 9 15:34:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17837 for ; Wed, 9 Mar 2005 15:34:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97ne-0001hu-Ki; Wed, 09 Mar 2005 15:28:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97nd-0001hp-Na for ippm@megatron.ietf.org; Wed, 09 Mar 2005 15:28:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17300 for ; Wed, 9 Mar 2005 15:28:55 -0500 (EST) Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97qH-0001uE-IU for ippm@ietf.org; Wed, 09 Mar 2005 15:31:43 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j29KQB9N016569 for ; Wed, 9 Mar 2005 14:28:46 -0600 Received: from custsla.mt.att.com (135.21.14.109) by attrh5i.attrh.att.com (7.2.052) id 4229269A000F659F; Wed, 9 Mar 2005 15:28:46 -0500 Received: from acmortonw.att.com ([135.210.81.88]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j29KShZ10500; Wed, 9 Mar 2005 15:28:44 -0500 (EST) Message-Id: <6.0.3.0.0.20050309150735.05d32df0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 09 Mar 2005 15:27:54 -0500 To: "Fardid, Reza" , From: Al Morton Subject: Re: [ippm] Comments on ITU-T IP Performance Work Status In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1314152260==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1314152260== Content-Type: text/html; charset="us-ascii" Hi Reza,

Let's take this off the list, because of scope and the fact that
ippm needs to focus on several in-scope topics.  But I'll
supply some quick answers below so that we don't leave everyone
hanging.  We have discussed this topic briefly on ippm-list in the past.

If you're interested in this discussion, let Reza and me know.

Al

At 01:13 PM 03/09/2005, Fardid, Reza wrote:
A have a number of comments on the Y.1541 loss performance objectives, existing and new:
  1. Is there an ITU-T implementation report, e.g., from SPs that are relying on the current IPLR objective of 10^(-3) for performance management ?
There's no formal report, just confirmation from several SPs
that they have put the current objectives to use.

  1. Is the new loss objective of 10^(-5) recommended for all QoS classes, similar to the current recommendation, which does not differentiate between real-time and best-effort services ?
The current 6 classes (five with loss < 10^-3) have been declared "stable".
There are two new provisional classes with <10^-5 loss.

  1. Is the new loss objective of 10^(-5) derived from empirical evidence or some other methodology ?
Yes, we looked at requirements for digital video transport
(at various quality levels and positions in the distribution
hierarchy), for high capacity applications that use TCP, and
for various digital/TDM service emulations on packet networks.
Some of the above require Forward Error Correction, in addition
to the <10^-5 loss, in order to meet their objectives.

These questions are relevant in the context of performance management, which may be beyond the scope of IPPM. If so, then I appreciate your off-list response.
--===============1314152260== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1314152260==-- From ippm-bounces@ietf.org Wed Mar 9 16:32:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22515 for ; Wed, 9 Mar 2005 16:32:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98j3-0008JS-AB; Wed, 09 Mar 2005 16:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98j2-0008JN-JR for ippm@megatron.ietf.org; Wed, 09 Mar 2005 16:28:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21954 for ; Wed, 9 Mar 2005 16:28:14 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98lf-0003Jp-1L for ippm@ietf.org; Wed, 09 Mar 2005 16:31:02 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 22:22:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 22:22:44 +0100 Message-ID: Thread-Topic: [ipfix] new version of IPFIX per packet information Thread-Index: AcUemo9JgfJXx9YbTFirIcwvOzUIWQGSo9HA From: "STEPHAN Emile RD-CORE-LAN" To: , X-OriginalArrivalTime: 09 Mar 2005 21:22:54.0075 (UTC) FILETIME=[27EF7CB0:01C524EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org Subject: [ippm] RE: [ipfix] new version of IPFIX per packet information X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear all, This memo proposes an excellent approach to use the IPFIX protocol to = export performance measurement data. It is clearly in the scope of PSAMP = WG and of IPFIX WG. The draft should propose stable template definitions to export packet = information from a meter to a collector, but not only. I t should define = a common template to export measure results from the collector to an = application. Following I propose a common template 'header' for these 2 = aspects: -- packet information template: Meter to collector ------- flowID=20 sampleID (packetID) =20 packetTimestamp =20 packetLength =20 --- result template: collector to application ---------- flowID=20 sampleID metricID: see IPPM REGISTRY in the RFC Queues =20 Result =20 Such measurement technique is clearly respectful of the IPPM framework. = The document should have at least an IPPM section to present the metrics = measured and discuss each metric.=20 Regards Emile -----Message d'origine----- De=A0: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la = part de Elisa Boschi Envoy=E9=A0: mardi 1 mars 2005 21:08 =C0=A0: ipfix@net.doit.wisc.edu Objet=A0: [ipfix] new version of IPFIX per packet information Dear all, we have submitted a new version of our draft: "export of per-packet=20 information using IPFIX". The latest version can be found here: http://www.ietf.org/internet-drafts/draft-pohl-perpktinfo-02.txt It has been improved taking into consideration the comments we have=20 received so far and includes a section addressing the management of the=20 "FlowIDs" we have introduced. Since it describes an extension to the protocol aimed at providing a=20 more efficient way to export packet information (without requiring any=20 modification to IPFIX), we propose to merge our draft with the IPFIX=20 protocol draft. (find our suggestion at the end of this email) We would like to hear the opinion of the group about this. Since the=20 export of per-packet information is a relevant issue for PSAMP, and all=20 IPFIX doocuments are currently in last call, merging the current=20 proposal with a PSAMP protocol draft is, to our opinion, a valide=20 alternative. In both cases the FlowID field should be added in the IPFIX information=20 model (as a numeric identifier for the flow) The IPFIX prootocol draft could be modified as follow: > Table of Contents > =20 > 1. Points of Discussion.........................................4 > 2. Introduction.................................................5 > 3. Terminology..................................................6 > 4. Criteria for Flow Expiration and Export.....................12 > 5. Message Format..............................................13 > 6. IPFIX Message Format........................................15 > 7. Specific Reporting Requirements.............................26 One section could be added here describing the special case of export of = packet information (the section could eventually be between 6 and 7 too. > 8. "Export Time" Computation and Flow Record Time..............29 > 9. Linkage with the Information Model..........................31 > 10. Variable Length Information Element........................32 > 11. Template Management........................................33 > 12. The Collecting Process's Side..............................36 > 13. Transport Protocol.........................................38 > 14. Security Considerations....................................47 > 15. IANA Considerations........................................51 > 16. Examples...................................................52 Add here the example in the last section of our draft. > 17. References.................................................58 > 18. Acknowledgments............................................6 Regards, Elisa -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message = body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Mar 10 08:06:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11670 for ; Thu, 10 Mar 2005 08:06:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9NMg-0002m3-QV; Thu, 10 Mar 2005 08:06:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9NMf-0002ly-GG for ippm@megatron.ietf.org; Thu, 10 Mar 2005 08:06:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11614 for ; Thu, 10 Mar 2005 08:06:05 -0500 (EST) Received: from bulbasaur.rediris.es ([130.206.194.34] helo=paraguas) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9NPQ-00075Z-Dg for ippm@ietf.org; Thu, 10 Mar 2005 08:09:01 -0500 Received: from fedemp by paraguas with local (Exim 3.36 #1 (Debian)) id 1D9NOR-0006Px-00 for ; Thu, 10 Mar 2005 14:07:59 +0100 Date: Thu, 10 Mar 2005 14:07:59 +0100 From: Federico Montesino Pouzols To: ippm@ietf.org Subject: Re: [ippm] Comments on initial rough draft of capacity definitions Message-ID: <20050310130759.GE19877@paraguas> Mail-Followup-To: ippm@ietf.org References: <20050309130115.GA16153@paraguas> <1731b0b49b0b62dd278c002f6354188d@verizon.net> <20050309170743.GA3559@sunfire.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309170743.GA3559@sunfire.grc.nasa.gov> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Federico Montesino Pouzols List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org On Wed, Mar 09, 2005 at 12:07:43PM -0500, Joseph Ishac wrote: > Some further comment on (b): > > We originally called 'available capacity' 'available bandwidth', and we > ran with the former term as Phil explained in his note. > > However, we did have a snip-it of text that was removed that indicated > the common interchangeability of the two terms. Perhaps we can work that > back into the draft? > I think yes, a short note clarifying that the term chosen is different to that of many papers and works (particularly the reference [PDM]) would avoid confusion. By the way, I do also prefer 'available capacity' :) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Mar 11 17:07:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12289 for ; Fri, 11 Mar 2005 17:07:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9sDV-0007Ir-RV; Fri, 11 Mar 2005 17:02:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9sDA-0007Eq-L2 for ippm@megatron.ietf.org; Fri, 11 Mar 2005 17:02:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11859 for ; Fri, 11 Mar 2005 17:02:22 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9sGE-0004ld-Lm for ippm@ietf.org; Fri, 11 Mar 2005 17:05:36 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j2BM2IS1616608 for ; Fri, 11 Mar 2005 15:02:19 -0700 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j2BM2IK19440 for ; Fri, 11 Mar 2005 15:02:18 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Fri, 11 Mar 2005 15:02:18 -0700 From: Nischal M Piratla To: ippm@ietf.org X-EXP32-SerialNo: 00002247, 00002264 Message-ID: <4238BFF9@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [ippm] RD and TCP retransmit analysis X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Almost 8 months ago, we had a request for an analysis showing the use of RD in the context of TCP retransmits. Looks like some of you could not catch up with the messages. I am sending this analysis once more. [Thanks to Mark Allman, who helped correct few errors then]. Consider Fast Retransmit definition from RFC 2581 and delayed ACK criterion from RFC 1122. Assume there is no packet duplication within the network. In addition, if a packet is reordered then the following packets in the sequence are not reordered with same or higher displacement. For such cases, a TCP packet is retransmitted after its ack is not found in four attempts: Case 1: Duplicate ACKs for packet 3 Arrivals: 1 2 4 5 6 3 ACKs: 3 3 3 3 Receive_index: 1 2 3 4 5 6 Displacement: 0 0 -1 -1 -1 3 Case 2: Duplicate ACKs for packet 2 Arrivals: 1 3 4 5 2 ACKs: 2 2 2 2 Receive_index: 1 2 3 4 5 Displacement: 0 -1 -1 -1 3 Thus, the displacement (according to RD definitions) is greater than 2 for retransmitted packets. Therefore, "Sum of (all RD[k] for k >= 2) corresponds to fraction of packets that is unnecessarily retransmitted." **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7794 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sat Mar 12 09:59:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12550 for ; Sat, 12 Mar 2005 09:59:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA828-0004N0-7N; Sat, 12 Mar 2005 09:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA826-0004Mr-OD for ippm@megatron.ietf.org; Sat, 12 Mar 2005 09:56:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12091 for ; Sat, 12 Mar 2005 09:56:00 -0500 (EST) Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA85L-0007i5-08 for ippm@ietf.org; Sat, 12 Mar 2005 09:59:23 -0500 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2CEt9cK018716 for ; Sat, 12 Mar 2005 08:55:52 -0600 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.2.052) id 4221FE06002DAC48 for ippm@ietf.org; Sat, 12 Mar 2005 09:55:52 -0500 Received: from acmortonw.att.com ([135.210.0.45]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j2CEtoZ11736 for ; Sat, 12 Mar 2005 09:55:51 -0500 (EST) Message-Id: <6.0.3.0.0.20050310082711.068d6300@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 10 Mar 2005 11:27:41 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] Comment on threshold on buffer sizes In-Reply-To: <42432696@webmail.colostate.edu> References: <42432696@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 01:45 PM 03/08/2005, Nischal M Piratla wrote: >... >So, if we are to determine the reordering using RD or RBD we can use a buffer >of a constant size (DT or BT respectively). But with ippm metrics (as >explained in previous email on spatial complexities), the spatial complexity >is O(N). > >- Nischal The ippm metrics require a comprehensive detection of duplicate packets. There are ways to reduce the complexity described in the ippm reordering draft. The final complexity depends on implementation. RD and RDB would not detect duplicate packets if they arrive with separation greater than DT or BT, the buffer sizes. DT and BT also set the threshold for declaring loss (in terms of packets). Clearly the choices of DT and BT have a profound influence on the results, and they must be set prior to the measurement. Making DT and BT "large enough" is not always possible, as the application of interest may require small thresholds for accurate assessment. So, duplicates could be defined as reordered, depending on the distance between the first packet and its duplicate. I don't see a way to compare results measured with different values of DT and BT (perhaps there is a way, but ?). If not, then one of the reasons to standardize these metrics (measurement comparison) is lost, because: * testers will choose different thresholds, each having their own good justification, * the choice of DT and BT influence the definitions of several metrics simultaneously (none of packet reordering, loss, or duplication metrics would be comparable), and * we should not standardize single DT and BT values (flexibility is required and we likely cannot agree on a single value, anyway). So, the DT and BT thresholds may be a strength when considering complexity, but they must be tuned a priori for the application/path of interest and that's a serious weakness when measurement comparison and efficiency are considered. It seems as though RD and RBD are better suited for post-processing stored measurements, where DT and BT can be changed at will. A possible way forward might be to differentiate RD and RBD from the "on-the-fly" ippm metrics on that basis, if there is agreement that RD and RDB offer something worth standardizing. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 15 05:29:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27779 for ; Tue, 15 Mar 2005 05:29:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB9Eq-0007uP-VR; Tue, 15 Mar 2005 05:25:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB95V-00073Z-Tx for ippm@megatron.ietf.org; Tue, 15 Mar 2005 05:15:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26808 for ; Tue, 15 Mar 2005 05:15:42 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB99H-0006Qw-GU for ippm@ietf.org; Tue, 15 Mar 2005 05:19:40 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CE41D1BAC4D for ; Tue, 15 Mar 2005 11:15:33 +0100 (CET) Date: Tue, 15 Mar 2005 11:15:33 +0100 From: Juergen Quittek To: ippm@ietf.org Message-ID: <977D8FE25543262C718BA2E3@[10.1.1.171]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Mar 2005 05:25:21 -0500 Subject: [ippm] traceroute as WG work item? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, Unfortunately, there was no discussion on traceroute storage during our last meeting. Therefore I bring this issue to the mailing list. There is an I-D describing an information model for traceroute records: http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroutes-00.txt This work was initiated by the development of a database for traffic measurement tools and traces, see http://www.ist-mome.org/database/ Currently, there is no standard way of exchanging traceroute measurements except for the DISMAN-TRACEROUTE-MIB module (RFC2925). But this can only be used for transferring measurement data from an SNMP agent to its manager(s). It is not useful for exchange between traffic measurement tools. A standardized record format for traceroute measurements would be very useful for building tools, databases and other applications that handle traceroute measurements and need to exchange them. Therefore I propose that this becomes an IPPM WG work item. Any comment, pro or con, is very welcome. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 15 06:12:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01197 for ; Tue, 15 Mar 2005 06:12:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB9vI-0004MM-B2; Tue, 15 Mar 2005 06:09:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB9vH-0004MH-8D for ippm@megatron.ietf.org; Tue, 15 Mar 2005 06:09:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00946 for ; Tue, 15 Mar 2005 06:09:12 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB9z5-0000A9-Ph for ippm@ietf.org; Tue, 15 Mar 2005 06:13:12 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0A9AB1BAC4D for ; Tue, 15 Mar 2005 12:09:03 +0100 (CET) Date: Tue, 15 Mar 2005 12:09:04 +0100 From: Juergen Quittek To: ippm@ietf.org Subject: Re: [ippm] traceroute as WG work item? Message-ID: <6A151A5F4F49C841A3CA33F6@[10.1.1.171]> In-Reply-To: <977D8FE25543262C718BA2E3@[10.1.1.171]> References: <977D8FE25543262C718BA2E3@[10.1.1.171]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit The I-D is still missing a data model, because there is no consensus yet on the mailing list about whether to use an XML-based data model or a more compact one. Please find some pro and con arguments at http://people.internet2.edu/~matt/IPPM/Meetings/ietf62/ippm-2005-03-07-traceroute.pdf Thanks, Juergen --On 15.03.2005 11:15 +0100 Juergen Quittek wrote: > Dear all, > > Unfortunately, there was no discussion on traceroute storage during > our last meeting. Therefore I bring this issue to the mailing list. > > There is an I-D describing an information model for traceroute records: > http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroutes-00.txt > > This work was initiated by the development of a database for traffic > measurement tools and traces, see http://www.ist-mome.org/database/ > > Currently, there is no standard way of exchanging traceroute > measurements except for the DISMAN-TRACEROUTE-MIB module (RFC2925). > But this can only be used for transferring measurement data from an > SNMP agent to its manager(s). It is not useful for exchange between > traffic measurement tools. > > A standardized record format for traceroute measurements would be > very useful for building tools, databases and other applications > that handle traceroute measurements and need to exchange them. > > Therefore I propose that this becomes an IPPM WG work item. > Any comment, pro or con, is very welcome. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 16 09:35:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25457 for ; Wed, 16 Mar 2005 09:35:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBZV8-0006JQ-U4; Wed, 16 Mar 2005 09:27:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBEKe-0003Qn-8T for ippm@megatron.ietf.org; Tue, 15 Mar 2005 10:51:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08490 for ; Tue, 15 Mar 2005 10:46:39 -0500 (EST) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBEE7-0000kl-Ok for ippm@ietf.org; Tue, 15 Mar 2005 10:45:00 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j2FFeZY9027519; Tue, 15 Mar 2005 16:40:35 +0100 Received: from HEBRIDE (vis189.inria.fr [193.51.208.189]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j2FFeVIL027492; Tue, 15 Mar 2005 16:40:31 +0100 Message-Id: <200503151540.j2FFeVIL027492@sophia.inria.fr> From: "Chadi Barakat" To: "Chadi Barakat" Date: Tue, 15 Mar 2005 16:40:26 +0100 Organization: INRIA U.R. Sophia Antipolis MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUpdU8dU4BPnk5ARkeaRitYbYBc8A== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (sophia.inria.fr [138.96.64.20]); Tue, 15 Mar 2005 16:40:33 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 16 Mar 2005 09:27:58 -0500 Subject: [ippm] CFP: JSAC special issue on Sampling the Internet X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this email.=20 All information can be found at http://www.argreenhouse.com/society/J-SAC/Calls/sampling_internet.html. Deadline for manuscript submission: OCTOBER 1, 2005. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =09 CALL FOR PAPERS IEEE Journal on Selected Areas in Communications=20 SAMPLING THE INTERNET: TECHNIQUES AND APPLICATIONS Scope As the Internet continues to grow rapidly in size and complexity, it has become increasingly clear that its evolution is closely tied to a = detailed understanding of network traffic. Network traffic measurements are invaluable for a wide range of tasks such as network capacity planning, traffic engineering, fault diagnosis, application and protocol = performance profiling, and anomaly detection. This large and diverse set of applications raises the question of how to monitor the Internet in an efficient and scalable way. In the case of = active monitoring (where probe packets are sent across the network to infer specific properties) the scalability issue arises from the size of the Internet and the potentially large number of end systems that one needs = to instrument, as well as the number of probing experiments that one must conduct. Intuitively, sampling is an essential component of scalable Internet monitoring. Broadly speaking, sampling is the process of making partial observations of a system of interest, and drawing conclusions about the = full behaviour of the system from these limited observations. The observation problem is concerned with minimising information loss whilst reducing = the volume of collected data. It is this reduction that makes the collection process scalable. The way in which the partial information is = transformed into knowledge of the system as a whole is the inversion problem. The inversion is in general imperfect and error-prone. The aim of this issue is to bring together work from researchers and practitioners devoted to the understanding of the practical and = theoretical issues related to all aspects of sampling the Internet. In this context, sampling may take various forms. A classic example is to observe only a subset of the packets carried over a link, and then estimate traffic parameters which apply to all packets. Alternatively, one could target a subset of routers with packet probes in order to infer network characteristics such as the topology or routing matrix.=20 Examples abound from a wide variety of application areas within Internet measurement, management, and analysis. Independent of subject area, = papers will be in scope if they focus substantially on the sampling aspects of = the problem under study, for example by exploring the tradeoff between observation and inversion processes, revealing the limitations of = inversion techniques, analysing their properties, or proposing new ones, or by providing new insights by explicitly recognizing the impact of implicit sampling in many measurement studies. Topics of interest include (but are not limited to): - Sampling and inverting traffic metrics with passive or active systems. - Internet end-to-end measurements seen from a sampling standpoint. - Sampling aspects of network topology inference. - Impact of sampling on anomaly detection. - Mechanisms for sampling live Internet traffic or collected traces. - Theoretical studies of the sampling/inversion problem (e.g., accuracy, complexity). - Distributed and adaptive sampling techniques. - New sampling methods. Submission guidelines Authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. There will be one round of reviews and = acceptance will be limited to papers needing only moderate revisions. Prospective authors should submit a PDF version of their complete manuscript via = email to jsac-sampling@sophia.inria.fr according to the following timetable:=20 Manuscript submission: October 1, 2005 Acceptance notification: March 1, 2006 Final manuscript due: June 1, 2006 Publication: 4th quarter 2006 Guest Editors =20 Chadi Barakat INRIA =96 Plan=E8te group 2004, route des Lucioles 06902 Sophia Antipolis France Chadi.Barakat@sophia.inria.fr Tel: +33 4 92 38 75 96 Fax: +33 4 92 38 79 78 Gianluca Iannaccone Intel Research 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom gianluca.iannaccone@intel.com Tel: +44 1223 763454 Fax: +44 1223 763456 Jim Kurose Department of Computer Science =20 University of Massachusetts =20 Amherst MA 01003=20 United States kurose@cs.umass.edu=20 Tel: +1 413 545 1585=20 Fax: +1 413 545 1249 Darryl Veitch CUBIN (ARC Special Research Ctr) Department of Electrical & Electronic Engineering University of Melbourne Victoria 3010 Australia dveitch@unimelb.edu.au Tel: +61 3 8344 3817 Fax: +61 3 8344 3821 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 21 09:05:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06756 for ; Mon, 21 Mar 2005 09:05:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDNSj-0004Bx-Qm; Mon, 21 Mar 2005 09:00:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDNSh-0004Bk-Ta for ippm@megatron.ietf.org; Mon, 21 Mar 2005 09:00:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05942 for ; Mon, 21 Mar 2005 09:00:54 -0500 (EST) Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDNXm-0000LF-2Z for ippm@ietf.org; Mon, 21 Mar 2005 09:06:10 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2LE0g0a002051 for ; Mon, 21 Mar 2005 09:00:45 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E00011D97 for ippm@ietf.org; Mon, 21 Mar 2005 09:00:45 -0500 Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.14]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j2LE0hZ15055 for ; Mon, 21 Mar 2005 09:00:44 -0500 (EST) Message-Id: <6.0.3.0.0.20050320110644.01edd400@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 21 Mar 2005 08:58:43 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] The next steps for the reordering drafts. In-Reply-To: <6.2.0.14.2.20050308182456.02cb66f8@localhost> References: <6.2.0.14.2.20050308182456.02cb66f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 12:25 PM 03/08/2005, Henk Uijterwaal wrote: >In the meantime, the authors of draft-jayasumana-reorder-density-03.txt >have continued their research, resulting in an -04 version of the >draft and some related publications. The question is whether the WG >feels that the 2 proposed metrics (RD and RBD) are sufficiently >distinct from the metrics proposed in draft-ietf-ippm-reordering >to warrant a second RFC by this WG (step 3 above). > >We would like to hear arguments, pro and con, if the working group >feels that either the RD or the RBD metric (or both, of course) from >draft-jayasumana-reorder-density should become a working group item. The Reorder Buffer Density (RBD) metric retains the foundation of a general buffer occupancy calculation. This was the original form of reordering density in earlier versions of this draft, including the fact that it records buffer occupancy with loss alone (no reordering needed to grow the buffer, and the normalization for lost packets doesn't reduce the occupation to zero). See section 7, example b. for a scenario with loss, no reordering. This behavior doesn't seem to fit a reordering metric. draft-ippm-reordering-09 deals with buffer size more effectively, in that it only produces values when reordered packets arrive, in the dimension of bytes. See the Section on Byte Offset. Al P.S. We've been here before... >At 11:57 AM 02/17/2003 +0100, Henk Uijterwaal (RIPE-NCC) wrote: >>Nischal, >>... >> >>2. Can you include the same examples as in the other reordering metrics >> so one can compare the algorithms? >> >>Henk > >Case b, packet loss (1,2,4,5,6,7) is sufficient for comparison. >No reordered packets arrive, yet this metric reports reordering >density. The existing metrics maintain orthogonality between >loss and reordering. Perhaps this algorithm would be better >characterized as a receiver buffer occupation function. > >Al > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 21 16:22:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28069 for ; Mon, 21 Mar 2005 16:22:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDULd-0002BC-Ni; Mon, 21 Mar 2005 16:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDULb-00024R-P7 for ippm@megatron.ietf.org; Mon, 21 Mar 2005 16:22:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28006 for ; Mon, 21 Mar 2005 16:22:01 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDUQj-00036q-OS for ippm@ietf.org; Mon, 21 Mar 2005 16:27:22 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j2LLM0S1564740 for ; Mon, 21 Mar 2005 14:22:00 -0700 Received: from [129.82.228.219] (prolix.engr.colostate.edu [129.82.228.219]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j2LLLcf10018 for ; Mon, 21 Mar 2005 14:21:38 -0700 (MST) Message-ID: <423F3AE1.50801@engr.colostate.edu> Date: Mon, 21 Mar 2005 14:21:37 -0700 From: "Nischal M. Piratla" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Subject: Re: [ippm] The next steps for the reordering drafts. References: <6.2.0.14.2.20050308182456.02cb66f8@localhost> <6.0.3.0.0.20050320110644.01edd400@custsla.mt.att.com> In-Reply-To: <6.0.3.0.0.20050320110644.01edd400@custsla.mt.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit > We would like to hear arguments, pro and con, if the working group > feels that either the RD or the RBD metric (or both, of course) from > draft-jayasumana-reorder-density should become a working group item. > The Reorder Buffer Density (RBD) metric retains the foundation of a > general buffer occupancy calculation. This was the original form of > reordering density in earlier versions of this draft, including the > fact that it records buffer occupancy with loss alone (no reordering > needed to grow the buffer, and the normalization for lost packets > doesn't reduce the occupation to zero). See section 7, example b. for > a scenario with loss, no reordering. To recall, example b from section 7: "Consider a sequence of 6 packets (1, 2, 4, 5, 6, 7) with DT = BT = 3." In this sequence, a measurement needs to buffer packets until the loss threshold is reached or sequence has ended. Only at this point the packet can be treated as lost. So, the occupancy of buffer is intentional to emulate buffering at the receiver and make it useful to the application. For reference, please read the message: http://www1.ietf.org/mail-archive/web/ippm/current/msg00316.html > draft-ippm-reordering-09 deals with buffer size more effectively, in > that it only produces values when reordered packets arrive, > in the dimension of bytes. See the Section on Byte Offset. This > behavior doesn't seem to fit a reordering metric. As you mentioned, we use the term RBD from -02 draft onwards as it is more descriptive. However, the basic concept appeared in our original paper and draft (Nov. LCN 2002, and Feb. 2003 RD draft). We observe the change in definition of the ByteOffset metric in ippm draft02 (Mar. 2003) and subsequent drafts, which try to account for the buffer size requirement as in RBD. Prior ippm drafts defined ByteOffset metric that included inorder packets in buffer requirements. Previous definition of ByteOffset metric (see the >>>>comment section): ***************** 4.3.2 Metric Name: Type-P-packet-Byte-Offset-Poisson/Periodic-Stream Metric Parameters: We use the same parameters defined above. Definition: Byte stream offset is the sum of the payload sizes of all intervening packets between the reordered packet and the discontinuity (including the packet at the discontinuity). For reordered packet i ByteOffset(i) = Sum[in-order packets to start of the reordering event] = Sum[PayloadSize(packet at i-1), PayloadSize(packet at i-2), ... PayloadSize(packet at i-n)] Alternatively, if all payload sizes are equal: ByteOffset(i) = n * PayloadSize where n is the reordering extent. >>>>Comment: Previous comments on the accuracy of extent n apply here as well. 4.3.3 Discussion The Offset metrics can predict whether reordered packets will be useful in a general receiver buffer system with finite limits. The limit may be the number of bytes or packets the buffer can store, or Morton, et al. Standards Track exp. Sept 2003 Page 9 Packet Reordering Metric for IPPM Mar 2003 the time of storage prior to a cyclic play-out instant (as with de- jitter buffers). ********************************** Moreover, there is an issue with the definition of ByteOffset metric itself. For example, consider the sequence (1, 6, 7, 8, 9, 10, 11, 12, 2). Before the arrival of packet with sequence number 2, the buffer size requirement is zero and then it suddenly changes to 7. Thus, there is no use to the application of such a measurement. Obviously, one has to keep track of these early arrivals to assign 7 as buffer requirement for the last arrival. It means that we do not call this tracking buffer as reorder buffer-occupancy, but still perform the same operation, as in RBD. Moreover, this size could go as big as 'N' due to the absence of threshold. Unless there is a better method stated, this increases the computation complexity of ByteOffset further. In turn, RBD has more usefulness associated with it, and also emulates dereordering without exceptions. At one point of time, ippm was very concerned about buffer requirements. For example: > ********************************************************************* > List-Archive: > Date: Mon, 17 Feb 2003 11:57:03 +0100 (CET) > > Nischal, > >> We have come up with a new metric to measure packet reordering. We have >> posted a ID and here is the link: >> >> http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-00.txt >> >> >> This draft may interest you all. Please feel free to send any >> comments/suggestions. > > > 1. If I understand the algorithm correctly, then it needs an array > in_buffer[N] with N the number of packets in a stream. This is not > very practical, when I make a VoIP phonecall, then I never know how > long it is going to last in advance and thus how I should dimension > this array. > > 2. Can you include the same examples as in the other reordering etrics > so one can compare the algorithms? > > Henk ********************************************************************************* Threshold value encounters such huge buffer requirements. However, we do not seem to be discussing about these requirements anymore! Unless, we have missed something, these requirements are very vital for real-time measurements. - Nischal **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7974 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 21 16:50:40 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00113 for ; Mon, 21 Mar 2005 16:50:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDUkC-0000dJ-MV; Mon, 21 Mar 2005 16:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDUk8-0000cY-DD for ippm@megatron.ietf.org; Mon, 21 Mar 2005 16:47:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29916 for ; Mon, 21 Mar 2005 16:47:22 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDUpF-0003xt-Dn for ippm@ietf.org; Mon, 21 Mar 2005 16:52:43 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j2LLlLS1551520 for ; Mon, 21 Mar 2005 14:47:21 -0700 Received: from [129.82.228.219] (prolix.engr.colostate.edu [129.82.228.219]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j2LLlJf16379 for ; Mon, 21 Mar 2005 14:47:19 -0700 (MST) Message-ID: <423F40E6.5000700@engr.colostate.edu> Date: Mon, 21 Mar 2005 14:47:18 -0700 From: "Nischal M. Piratla" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Subject: Re: [ippm] Comment on threshold on buffer sizes References: <42432696@webmail.colostate.edu> <6.0.3.0.0.20050310082711.068d6300@custsla.mt.att.com> In-Reply-To: <6.0.3.0.0.20050310082711.068d6300@custsla.mt.att.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0852198405==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============0852198405== Content-Type: multipart/alternative; boundary="------------060308060502090001080504" This is a multi-part message in MIME format. --------------060308060502090001080504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Al Morton wrote: >> The ippm metrics require a comprehensive detection of duplicate packets. >> There are ways to reduce the complexity described in the ippm >> reordering draft. The final complexity depends on implementation. >> >> RD and RDB would not detect duplicate packets if they arrive with >> separation greater than DT or BT, the buffer sizes. DT and BT also >> set the threshold for declaring loss (in terms of packets). Clearly >> the choices of DT and BT have a profound influence on the results, >> and they must be set prior to the measurement. > The duplicates that arrive beyond DT or BT are discarded packets. So, it is not true that RD and RBD would not detect duplicate packets that arrive beyond the separation of DT or BT. >> >> Making DT and BT "large enough" is not always possible, as the >> application >> of interest may require small thresholds for accurate assessment. >> So, duplicates could be defined as reordered, depending on the distance >> between the first packet and its duplicate. > Assuming you are correct, i.e., an application of interest requires small threshold for accurate evaluation, how would a metric that does not use a threshold at all be able to meet its needs? Only RD and RBD will work here as other metrics do not have such a feature, and a late arrival that is treated as reordered by reorder-extent, n-reordering etc. will lead to more problems. Further, in RD and RBD duplicates are *never* defined as reordered. **************************************************** Research Assistant Computer Networking Research Laboratory (CNRL) C203,Dept. of Electrical & Computer Eng. Colorado State University, Fort Collins, CO 80523 Voice: 970-491-7067/7974 Fax: 970-491-2249 http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal **************************************************** --------------060308060502090001080504 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Al Morton wrote:
The ippm metrics require a comprehensive detection of duplicate packets.
There are ways to reduce the complexity described in the ippm
reordering draft. The final complexity depends on implementation.

RD and RDB would not detect duplicate packets if they arrive with
separation greater than DT or BT, the buffer sizes.  DT and BT also
set the threshold for declaring loss (in terms of packets). Clearly
the choices of DT and BT have a profound influence on the results,
and they must be set prior to the measurement.
The duplicates that arrive beyond DT or BT are discarded packets. So, it is not true that RD and RBD would not detect duplicate packets that arrive beyond the separation of DT or BT.

Making DT and BT "large enough" is not always possible, as the application
of interest may require small thresholds for accurate assessment.
So, duplicates could be defined as reordered, depending on the distance
between the first packet and its duplicate.
Assuming you are correct, i.e., an application of interest requires small threshold for accurate evaluation, how would a metric that does not use a threshold at all be able to meet its needs? Only RD and RBD will work here as other metrics do not have such a feature, and a late arrival that is treated as reordered by reorder-extent, n-reordering etc. will lead to more problems.

Further, in RD and RBD duplicates are *never* defined as reordered.

--------------060308060502090001080504-- --===============0852198405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0852198405==-- From ippm-bounces@ietf.org Wed Mar 23 03:58:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18365 for ; Wed, 23 Mar 2005 03:58:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1fM-0005up-Rl; Wed, 23 Mar 2005 03:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1fH-0005uc-LW; Wed, 23 Mar 2005 03:56:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18241; Wed, 23 Mar 2005 03:56:33 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1ki-0006IU-Kr; Wed, 23 Mar 2005 04:02:13 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:55:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Mar 2005 09:55:36 +0100 Message-ID: Thread-Topic: [Pce] contribution to charter item / definition of objective metrics: dratf-stephan-ippm-multimetrics-00.txt Thread-Index: AcT5o06MSWseXMU/TPuxFj7VFDY1Fg13NrDQ From: "STEPHAN Emile RD-CORE-LAN" To: "JP Vasseur" X-OriginalArrivalTime: 23 Mar 2005 08:55:37.0466 (UTC) FILETIME=[150465A0:01C52F86] X-Spam-Score: 0.2 (/) X-Scan-Signature: 47f87af9e1d92eac54caf69b67f82b72 Cc: pce@ietf.org, ippm@ietf.org Subject: [ippm] RE: [Pce] contribution to charter item / definition of objective metrics: dratf-stephan-ippm-multimetrics-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1655195556==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1655195556== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52F86.143C8B84" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52F86.143C8B84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, =20 Objective metrics include 2 main categories: Those for measuring the performance (the rapidity) of a PCE entity; Those for measuring the accuracy of the PCE computation:=20 Do the quality and the performance of the path computed by PCEs entities = complies with the query? =20 Regarding the second point, Lei and I merged 3 I-Ds in one which defines = "Spatial and Multicast Metrics for IPPM" = (http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.t= xt = ). It defines 2 sets of metrics, spatial and one-to-group:=20 The intend of the spatial metrics part is clearly to provide TE and = interdomain with metrics to decompose end-to-end performance; The intend of the spatial metrics part and one-to-group part are to = provide metrics to decompose the performance of point-to-multipoint = services; =20 The draft was presented at Minneapolis during the IPPM WG. I clearly = designed it to become an IPPM WG item. I take a special care to select = metrics which conform to the IPPM framework (RFC2330) and which are = directly usable for unicast or multicast TE.=20 =20 This draft will be discussed in the IPPM mailing. Mid April, chairs will = decide its status evolution. =20 I have no doubt that there are a lot of missing points in the discussion = section such as case study, applicability... So please read the document = and send your comment in PCE and IPPM list. =20 Regards Emile =20 ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 13 janvier 2005 20:09 =C0 : STEPHAN Emile RD-CORE-LAN Cc : pce@ietf.org Objet : Re: [Pce] contribution to charter item =20 Salut Emile,=20 =20 On Nov 17, 2004, at 8:00 AM, STEPHAN Emile RD-CORE-LAN wrote:=20 =20 Dear JP, Adrian and all=20 =20 There is an important item in the PCE WG charter, which is the = definition of MIBs and management procedures related to the new = protocols, protocol extensions and operational elements.=20 =20 I am interested to contribute to this WG item.=20 =20 =20 Great !=20 =20 Considering your involvement in IPPM, you may also be interested by:=20 =20 May 05: Submit first draft of the definition of objective metrics=20 =20 Please let me know when you will start this activity.=20 =20 =20 As indicated in the WG Milestones ... of course, for the MIB, this = requires some time until we make progress on the protocol(s).=20 =20 Cheers.=20 =20 JP.=20 =20 Regards=20 =20 Emile=20 _______________________________________________=20 Pce mailing list=20 Pce@lists.ietf.org=20 https://www1.ietf.org/mailman/listinfo/pce=20 ------_=_NextPart_001_01C52F86.143C8B84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

Objective metrics include 2 main categories:

Those for = measuring the performance (the rapidity) of a PCE entity;

Those for = measuring the accuracy of the PCE computation:

Do the quality and the performance of the path computed by PCEs entities complies with = the query?

 

Regarding the second point, Lei and I merged 3 = I-Ds in one which defines "Spatial and Multicast Metrics for IPPM" = (http://www.ietf.org/internet-drafts/draft-step= han-ippm-multimetrics-00.txt ). It defines 2 sets of metrics, spatial and one-to-group: =

The intend of = the spatial metrics part is clearly to provide TE and interdomain with metrics to = decompose end-to-end performance;

The intend of = the spatial metrics part and one-to-group part are to provide metrics to decompose = the performance of point-to-multipoint services;

 

The draft was presented at Minneapolis during = the IPPM WG. I clearly designed it to become an IPPM WG item. I take a = special care to select metrics which conform to the IPPM framework (RFC2330) and = which are directly usable for unicast or multicast TE.

 

This draft will be discussed in the IPPM = mailing. Mid April, chairs will decide its status evolution.

 

I have no doubt that there are a lot of = missing points in the discussion section such as case study, applicability… So = please read the document and send your comment in PCE and IPPM = list.

 

Regards

Emile

 


De :<= /span> JP Vasseur [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 13 = janvier 2005 20:09
=C0 : STEPHAN Emile = RD-CORE-LAN
Cc : pce@ietf.org
Objet : Re: [Pce] contribution to charter item

 

Salut Emile,

 

On Nov 17, 2004, at 8:00 AM, STEPHAN Emile RD-CORE-LAN wrote: =

 

Dear JP, Adrian and = all

 

There is an important item in the PCE WG charter, which is the definition of MIBs and management = procedures related to the new protocols, protocol = extensions and operational elements.

 

I am interested to contribute to this WG item. =

 

 

Great !

 

Considering your involvement in IPPM, you may also be interested = by:

 

May 05: Submit first draft of the definition of = objective metrics

 

Please let me know when you will start this activity. =

 

 

As indicated in the WG Milestones ... of course, for the MIB, = this requires some time until we make progress on the protocol(s). =

 

Cheers.

 

JP.

 

Regards

 

Emile

_______________________________________________ =

Pce mailing list

Pce@lists.ietf.org

https://www1.ietf.org/mailman/listinfo/pce

------_=_NextPart_001_01C52F86.143C8B84-- --===============1655195556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1655195556==-- From ippm-bounces@ietf.org Wed Mar 23 12:34:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10503 for ; Wed, 23 Mar 2005 12:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9hL-0002lP-S0; Wed, 23 Mar 2005 12:31:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9hJ-0002lK-VI for ippm@megatron.ietf.org; Wed, 23 Mar 2005 12:31:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10137 for ; Wed, 23 Mar 2005 12:31:11 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9mp-0004bl-Md for ippm@ietf.org; Wed, 23 Mar 2005 12:36:56 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 18:30:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] traceroute as WG work item? IPFIX traceroute records Date: Wed, 23 Mar 2005 18:30:19 +0100 Message-ID: Thread-Topic: [ippm] traceroute as WG work item? IPFIX traceroute records Thread-Index: AcUpT+A+wm9JYVbYT+SM5xVhfYQY/gGeTYTA From: "STEPHAN Emile RD-CORE-LAN" To: "Juergen Quittek" X-OriginalArrivalTime: 23 Mar 2005 17:30:20.0026 (UTC) FILETIME=[FC7515A0:01C52FCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: ipfix@net.doit.wisc.edu, ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Juergen, My thinking is that we might use IPFIX to export the traceroute results. What about using 2 templates: one for the measure and another one for = results? =20 0 1 2 3 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | FlowSet ID =3D 0 | Length =3D xx bytes | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | 256 | Field Length =3D 4 | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowID (e.g. measure ID) | Field Length =3D 4 | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|=20 | sourceIPv4Address | Field Length =3D 4 | Src=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | destinationIPv4Address | Field Length =3D 4 | Dst +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 0 1 2 3 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | FlowSet ID =3D 0 | Length =3D xx bytes | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | 257 | Field Length =3D 4 | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | FlowID (e.g. measure ID) | Field Length =3D 4 | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | SampleID | Field Length =3D 4 | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Src = UDP=20 | flowStartMicroSeconds | Field Length =3D 8 | pkts = time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | flowEndDeltaUSeconds | Field Length =3D 4 | = Troute RTT +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | destinationIPv4Address | Field Length =3D 4 | Hop = Addr=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 This is compact and is very close to what describes Guido draft = (draft-pohl-perpktinfo-02.txt).=20 We need only to define a new Field Type named 'SampleID' (named PacketID = in Guido document). =20 Regards Emile -----Message d'origine----- De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de Juergen Quittek Envoy=E9=A0: mardi 15 mars 2005 12:09 =C0=A0: ippm@ietf.org Objet=A0: Re: [ippm] traceroute as WG work item? The I-D is still missing a data model, because there is no consensus yet on the mailing list about whether to use an XML-based data model or a more compact one. Please find some pro and con arguments at http://people.internet2.edu/~matt/IPPM/Meetings/ietf62/ippm-2005-03-07-tr= aceroute.pdf Thanks, Juergen --On 15.03.2005 11:15 +0100 Juergen Quittek wrote: > Dear all, > > Unfortunately, there was no discussion on traceroute storage during > our last meeting. Therefore I bring this issue to the mailing list. > > There is an I-D describing an information model for traceroute = records: > = http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroutes= -00.txt > > This work was initiated by the development of a database for traffic > measurement tools and traces, see http://www.ist-mome.org/database/ > > Currently, there is no standard way of exchanging traceroute > measurements except for the DISMAN-TRACEROUTE-MIB module (RFC2925). > But this can only be used for transferring measurement data from an > SNMP agent to its manager(s). It is not useful for exchange between > traffic measurement tools. > > A standardized record format for traceroute measurements would be > very useful for building tools, databases and other applications > that handle traceroute measurements and need to exchange them. > > Therefore I propose that this becomes an IPPM WG work item. > Any comment, pro or con, is very welcome. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 = 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 = 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany = http://www.netlab.nec.de > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Mar 27 20:08:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23319 for ; Sun, 27 Mar 2005 20:08:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFihb-0004HB-OI; Sun, 27 Mar 2005 20:05:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFihZ-0004C5-59 for ippm@megatron.ietf.org; Sun, 27 Mar 2005 20:05:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23214 for ; Sun, 27 Mar 2005 20:05:53 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFinx-0000Jp-S2 for ippm@ietf.org; Sun, 27 Mar 2005 20:12:34 -0500 Received: from dialin-145-254-221-074.arcor-ip.net (dialin-145-254-220-195.arcor-ip.net [145.254.220.195]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E923B1BAC4D; Mon, 28 Mar 2005 03:05:43 +0200 (CEST) Date: Mon, 28 Mar 2005 03:05:39 +0200 From: Juergen Quittek To: STEPHAN Emile RD-CORE-LAN Subject: RE: [ippm] traceroute as WG work item? IPFIX traceroute records Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.2 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable Cc: ipfix@net.doit.wisc.edu, ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Emile, Thanks for your comments! The basic issue I raised was whether or not the standardization of an information model and data model for traceroute results would be a work item for the IPPM WG. Do I understand correctly from your message that, 1. yes, it should be standardized, 2. but not necessarily in the IPPM WG? Concerning the discussion at IPPM whether we should use a binary or an XML-based format for traceroute results, I interpret your message as support for a binary format. I think your thoughts open an interesting discussion on transmitting traceroute results in IPFIX records. Probably, this issue is worth mentioning it in the IPFIX applicability statement. Also, the issue should be considered by the information model discussions in IPFIX and PSAMP. Thanks, Juergen --=20 Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 23.03.2005 18:30 h +0100 STEPHAN Emile RD-CORE-LAN wrote: > Hi Juergen, > > My thinking is that we might use IPFIX to export the traceroute results. > > > What about using 2 templates: one for the measure and another one for results? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowSet ID =3D 0 | Length =3D xx bytes | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 256 | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowID (e.g. measure ID) | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >| sourceIPv4Address | Field Length =3D 4 | Src > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| destinationIPv4Address | Field Length =3D 4 | Dst > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowSet ID =3D 0 | Length =3D xx bytes | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 257 | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowID (e.g. measure ID) | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| SampleID | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Src UDP >| flowStartMicroSeconds | Field Length =3D 8 | pkts time > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| flowEndDeltaUSeconds | Field Length =3D 4 | Troute RTT > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| destinationIPv4Address | Field Length =3D 4 | Hop Addr > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > This is compact and is very close to what describes Guido draft (draft-pohl-perpktinfo-02.txt). > > We need only to define a new Field Type named 'SampleID' (named PacketID in Guido document). > > Regards > Emile > > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de Juergen Quittek > Envoy=E9=A0: mardi 15 mars 2005 12:09 > =C0=A0: ippm@ietf.org > Objet=A0: Re: [ippm] traceroute as WG work item? > > The I-D is still missing a data model, because there is no > consensus yet on the mailing list about whether to use an > XML-based data model or a more compact one. > Please find some pro and con arguments at > http://people.internet2.edu/~matt/IPPM/Meetings/ietf62/ippm-2005-03-07-traceroute.pdf > > Thanks, > > Juergen > > --On 15.03.2005 11:15 +0100 Juergen Quittek wrote: > >> Dear all, >> >> Unfortunately, there was no discussion on traceroute storage during >> our last meeting. Therefore I bring this issue to the mailing list. >> >> There is an I-D describing an information model for traceroute records: >> http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroutes-00.txt >> >> This work was initiated by the development of a database for traffic >> measurement tools and traces, see http://www.ist-mome.org/database/ >> >> Currently, there is no standard way of exchanging traceroute >> measurements except for the DISMAN-TRACEROUTE-MIB module (RFC2925). >> But this can only be used for transferring measurement data from an >> SNMP agent to its manager(s). It is not useful for exchange between >> traffic measurement tools. >> >> A standardized record format for traceroute measurements would be >> very useful for building tools, databases and other applications >> that handle traceroute measurements and need to exchange them. >> >> Therefore I propose that this becomes an IPPM WG work item. >> Any comment, pro or con, is very welcome. >> >> Thanks, >> >> Juergen >> -- >> Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 28 15:28:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08162 for ; Mon, 28 Mar 2005 15:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG0pV-00052R-Hy; Mon, 28 Mar 2005 15:27:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG0pV-00052M-0N for ippm@megatron.ietf.org; Mon, 28 Mar 2005 15:27:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08103 for ; Mon, 28 Mar 2005 15:27:19 -0500 (EST) Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG0w3-0005hd-7u for ippm@ietf.org; Mon, 28 Mar 2005 15:34:08 -0500 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2SKR4Of016338 for ; Mon, 28 Mar 2005 14:27:10 -0600 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (7.2.052) id 4246E7BE0002D537 for ippm@ietf.org; Mon, 28 Mar 2005 15:27:09 -0500 Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.14]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j2SKR7Z18017 for ; Mon, 28 Mar 2005 15:27:07 -0500 (EST) Message-Id: <6.0.3.0.0.20050327111324.06086030@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 28 Mar 2005 15:24:43 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] The next steps for the reordering drafts. In-Reply-To: <423F3AE1.50801@engr.colostate.edu> References: <6.2.0.14.2.20050308182456.02cb66f8@localhost> <6.0.3.0.0.20050320110644.01edd400@custsla.mt.att.com> <423F3AE1.50801@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 04:21 PM 03/21/2005, Nischal M. Piratla wrote: >>Al wrote: >>The Reorder Buffer Density (RBD) metric retains the foundation of a >>general buffer occupancy calculation. This was the original form of >>reordering density in earlier versions of this draft, including the fact >>that it records buffer occupancy with loss alone (no reordering needed to >>grow the buffer, and the normalization for lost packets doesn't reduce >>the occupation to zero). See section 7, example b. for a scenario with >>loss, no reordering. > >To recall, example b from section 7: > >"Consider a sequence of 6 packets (1, 2, 4, 5, 6, 7) with DT = BT = 3." >In this sequence, a measurement needs to buffer packets until the loss >threshold is reached or sequence has ended. Only at this point the packet >can be treated as lost. So, the occupancy of buffer is intentional to >emulate buffering at the receiver and make it useful to the application. Every lost packet causes your buffer to grow until it is declared lost. That might be something useful, but RBD is not a reordering metric in a strict sense, because there will always be ambiguity: Did lost packets or reordered packets (or both) cause buffer growth? A key point of standardizing a reordering metric is to distinguish reordering from loss - they have different causes and cures. If I look at the RBD buffer occupation frequencies, there will be many sizes encountered as the buffer is growing. But only one of the sizes is relevant to buffer design in this context, the size needed to restore a reordered packet to order. One could look at a histogram of buffer sizes after a measurement, but the RDB frequencies alone are not sufficient to say whether a specific buffer size can mitigate reordering and to what extent (as a fraction of reordered packets). >For reference, please read the message: >http://www1.ietf.org/mail-archive/web/ippm/current/msg00316.html I did in 2004, and I incorporated several of Michal's comments in the draft (Section 6 on Measurement and Implementation Issues). We recently refined the text there through comment and review. >>Al wrote: >>draft-ippm-reordering-09 deals with buffer size more effectively, in that >>it only produces values when reordered packets arrive, >>in the dimension of bytes. See the Section on Byte Offset. This behavior >>doesn't seem to fit a reordering metric. Hmmm. Your mail tool seems to be reordering sentences. The last sentence above applies to RBD, and was prior to the others in my original message. The archive has the text in-order: http://www1.ietf.org/mail-archive/web/ippm/current/msg00605.html Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Mar 28 23:39:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19605 for ; Mon, 28 Mar 2005 23:39:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG8Ts-0004Km-UC; Mon, 28 Mar 2005 23:37:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG8Ts-0004Ke-6M for ippm@megatron.ietf.org; Mon, 28 Mar 2005 23:37:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19322 for ; Mon, 28 Mar 2005 23:37:29 -0500 (EST) Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG8aV-0004G9-Lt for ippm@ietf.org; Mon, 28 Mar 2005 23:44:24 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2T4bMHn014289 for ; Mon, 28 Mar 2005 23:37:22 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E0016A9BE for ippm@ietf.org; Mon, 28 Mar 2005 23:37:22 -0500 Received: from acmortonw.att.com ([135.210.128.32]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j2T4bJZ18137 for ; Mon, 28 Mar 2005 23:37:19 -0500 (EST) Message-Id: <6.0.3.0.0.20050328093229.05e140b0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 28 Mar 2005 23:35:35 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] RD and TCP retransmit analysis In-Reply-To: <4238BFF9@webmail.colostate.edu> References: <4238BFF9@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Consider this example: Arrivals: 1 4 5 6 7 3 2 ACKs: 2 2 2 2 2 2 Receive_index: 1 2 3 4 5 6 7 Displacement: 0 -2 -2 -2 -2 3 5 Is this an example of one of the circumstances you've excluded? (with the following sentence) >In addition, if a packet is reordered then the following packets >in the sequence are not reordered with same or higher displacement. Packet 3 follows 2 in the original sequence, and packet 3 has a lower displacement than packet 2. So Packet 3 may be included, and using Displacement>2 would predict two re-transmissions where only one seems likely. However, you may have meant "following arrivals", and then packet 3 would be excluded. In any case, how many arrivals must occur before Displacement can be evaluated again? IOW, the condition quoted above may also exclude this case: Arrivals: 1 3 4 5 6 2 7 9 10 11 12 8 Displacement: 4 4 but this seems to be a case where there may be two re-transmissions. We have not placed strong requirements like this on the measured stream in the past, and this one appears to need some refinement. Al At 05:02 PM 03/11/2005, Nischal M Piratla wrote: >... >Consider Fast Retransmit definition from RFC 2581 and delayed ACK criterion >from RFC 1122. Assume there is no packet duplication within the network. In >addition, if a packet is reordered then the following packets in the sequence >are not reordered with same or higher displacement. For such cases, a TCP >packet is retransmitted after its ack is not found in four attempts: > >Case 1: Duplicate ACKs for packet 3 >Arrivals: 1 2 4 5 6 3 >ACKs: 3 3 3 3 >Receive_index: 1 2 3 4 5 6 >Displacement: 0 0 -1 -1 -1 3 > >Case 2: Duplicate ACKs for packet 2 >Arrivals: 1 3 4 5 2 >ACKs: 2 2 2 2 >Receive_index: 1 2 3 4 5 >Displacement: 0 -1 -1 -1 3 > >Thus, the displacement (according to RD definitions) is greater than 2 for >retransmitted packets. >Therefore, "Sum of (all RD[k] for k >= 2) corresponds to fraction of packets >that is unnecessarily retransmitted." > >**************************************************** >Research Assistant >Computer Networking Research Laboratory (CNRL) >C203,Dept. of Electrical & Computer Eng. >Colorado State University, >Fort Collins, CO 80523 >Voice: 970-491-7067/7794 >Fax: 970-491-2249 >http://www.cnrl.colostate.edu >http://lamar.colostate.edu/~nischal >**************************************************** > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Mar 29 04:47:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08312 for ; Tue, 29 Mar 2005 04:47:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGDFo-0000P6-BJ; Tue, 29 Mar 2005 04:43:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGDFm-0000Od-5d for ippm@megatron.ietf.org; Tue, 29 Mar 2005 04:43:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07978 for ; Tue, 29 Mar 2005 04:43:16 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGDMS-0005vP-1m for ippm@ietf.org; Tue, 29 Mar 2005 04:50:12 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 11:43:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] traceroute as WG work item? IPFIX traceroute records Date: Tue, 29 Mar 2005 11:43:14 +0200 Message-ID: Thread-Topic: [ippm] traceroute as WG work item? IPFIX traceroute records Thread-Index: AcUzMkHqt1XZlr6jTkGIfmYGvpCH+ABCxOBA From: "STEPHAN Emile RD-CORE-LAN" To: "Juergen Quittek" , "Lutz Mark" X-OriginalArrivalTime: 29 Mar 2005 09:43:15.0416 (UTC) FILETIME=[BAF77580:01C53443] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: quoted-printable Cc: ipfix@net.doit.wisc.edu, ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Juergen and Lutz What we experienced with the IPPM MIB is that measures generate a lot of = data. So the binary format is the best for collecting.=20 Traceroute Field Types do not differ from Per Packet Field Types = (draft-pohl-perpktinfo-02.txt) or from IPPM Field Types, especially if = we include spatial and multicast metrics = (dratf-stephan-ippm-multimetrics-00.txt).=20 Moreover most of these fields are already defined as illustrated by the = example I sent. So it appears very fast and very easy to define in IPFIX = a common info model and a common set of templates to export results of = IPPM measures, traceroute measures and 'Per Packet' measures.=20 Regarding traceroute metric I propose to try to design this metric using = the IPPM framework and terminology (RFC2330), and then to present it to = the IPPM WG. At large this document may include metrics definitions of = middlebox one-way delay and jitter corresponding to 'Per Packet' = measurement technique.=20 To sum up I propose to write 2 drafts: The fist one defines in the IPFIX WG common templates for exporting = measure results; The second one defines in the IPPM WG traceroute and middlebox metrics. Regards Emile -----Message d'origine----- De=A0: Juergen Quittek [mailto:quittek@netlab.nec.de]=20 Envoy=E9=A0: lundi 28 mars 2005 03:06 =C0=A0: STEPHAN Emile RD-CORE-LAN Cc=A0: ippm@ietf.org; ipfix@net.doit.wisc.edu Objet=A0: RE: [ippm] traceroute as WG work item? IPFIX traceroute = records Emile, Thanks for your comments! The basic issue I raised was whether or not the standardization of an information model and data model for traceroute results would be a work item for the IPPM WG. Do I understand correctly from your message that, 1. yes, it should be standardized, 2. but not necessarily in the IPPM WG? Concerning the discussion at IPPM whether we should use a binary or an XML-based format for traceroute results, I interpret your message as support for a binary format. I think your thoughts open an interesting discussion on transmitting traceroute results in IPFIX records. Probably, this issue is worth mentioning it in the IPFIX applicability statement. Also, the issue should be considered by the information model = discussions in IPFIX and PSAMP. Thanks, Juergen --=20 Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 = 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 = 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany = http://www.netlab.nec.de --On 23.03.2005 18:30 h +0100 STEPHAN Emile RD-CORE-LAN wrote: > Hi Juergen, > > My thinking is that we might use IPFIX to export the traceroute = results. > > > What about using 2 templates: one for the measure and another one for = results? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowSet ID =3D 0 | Length =3D xx bytes | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 256 | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowID (e.g. measure ID) | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >| sourceIPv4Address | Field Length =3D 4 | Src > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| destinationIPv4Address | Field Length =3D 4 | Dst > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowSet ID =3D 0 | Length =3D xx bytes | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 257 | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| FlowID (e.g. measure ID) | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| SampleID | Field Length =3D 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Src = UDP >| flowStartMicroSeconds | Field Length =3D 8 | = pkts time > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| flowEndDeltaUSeconds | Field Length =3D 4 | = Troute RTT > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| destinationIPv4Address | Field Length =3D 4 | Hop = Addr > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > This is compact and is very close to what describes Guido draft = (draft-pohl-perpktinfo-02.txt). > > We need only to define a new Field Type named 'SampleID' (named = PacketID in Guido document). > > Regards > Emile > > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de Juergen Quittek > Envoy=E9=A0: mardi 15 mars 2005 12:09 > =C0=A0: ippm@ietf.org > Objet=A0: Re: [ippm] traceroute as WG work item? > > The I-D is still missing a data model, because there is no > consensus yet on the mailing list about whether to use an > XML-based data model or a more compact one. > Please find some pro and con arguments at > = http://people.internet2.edu/~matt/IPPM/Meetings/ietf62/ippm-2005-03-07-tr= aceroute.pdf > > Thanks, > > Juergen > > --On 15.03.2005 11:15 +0100 Juergen Quittek wrote: > >> Dear all, >> >> Unfortunately, there was no discussion on traceroute storage during >> our last meeting. Therefore I bring this issue to the mailing list. >> >> There is an I-D describing an information model for traceroute = records: >> = http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroutes= -00.txt >> >> This work was initiated by the development of a database for traffic >> measurement tools and traces, see http://www.ist-mome.org/database/ >> >> Currently, there is no standard way of exchanging traceroute >> measurements except for the DISMAN-TRACEROUTE-MIB module (RFC2925). >> But this can only be used for transferring measurement data from an >> SNMP agent to its manager(s). It is not useful for exchange between >> traffic measurement tools. >> >> A standardized record format for traceroute measurements would be >> very useful for building tools, databases and other applications >> that handle traceroute measurements and need to exchange them. >> >> Therefore I propose that this becomes an IPPM WG work item. >> Any comment, pro or con, is very welcome. >> >> Thanks, >> >> Juergen >> -- >> Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 = 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 = 90511-55 >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany = http://www.netlab.nec.de >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 30 16:44:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29538 for ; Wed, 30 Mar 2005 16:44:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkxR-0000nW-7H; Wed, 30 Mar 2005 16:42:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkll-0007cY-4A for ippm@megatron.ietf.org; Wed, 30 Mar 2005 16:30:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25557 for ; Wed, 30 Mar 2005 16:30:31 -0500 (EST) Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGksj-0007IJ-AS for ippm@ietf.org; Wed, 30 Mar 2005 16:37:46 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2ULUKd17666; Wed, 30 Mar 2005 23:30:20 +0200 (CEST) Received: from [10.61.65.136] (ams-clip-vpn-dhcp392.cisco.com [10.61.65.136]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2ULUJK22272; Wed, 30 Mar 2005 23:30:19 +0200 (CEST) Message-ID: <424B1A6B.5030608@cisco.com> Date: Wed, 30 Mar 2005 23:30:19 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN Subject: Re: [ipfix] RE: [ippm] traceroute as WG work item? IPFIX traceroute records References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id j2ULUKd17666 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 30 Mar 2005 16:42:35 -0500 Cc: Lutz Mark , ippm@ietf.org, ipfix@net.doit.wisc.edu X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Emile, If there is a need to push some IPPM data to a NMS (as opposed to pull=20 the data with SNMP), then the IPFIX protocol makes perfect sense as it=20 is efficient and flexible. BTW, this is described in the IPFIX applicability draft=20 (http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-04.txt) 2.7 SLA validation...........................................8=20 2.8 Traffic Monitoring.......................................8=20 2.8.1 Measurement of Round-trip-time (RTT)....................9=20 2.8.2 Measurement of One-way-delay (OWD)......................9=20 2.8.3 Measurement of One-way-loss (OWL)......................10=20 2.8.4 Measurement of IP delay variation (IPDV)...............10=20 3.3 IPFIX and IPPM=20 Note that this draft speaks of passive measurements as opposed to active = measurements in IPPM. However, from the pure IPFIX protocol point of view, the measurement mech= anism is not relevant. Regards, Benoit. >Hi Juergen and Lutz > >What we experienced with the IPPM MIB is that measures generate a lot of= data. So the binary format is the best for collecting.=20 > >Traceroute Field Types do not differ from Per Packet Field Types (draft-= pohl-perpktinfo-02.txt) or from IPPM Field Types, especially if we includ= e spatial and multicast metrics (dratf-stephan-ippm-multimetrics-00.txt).= =20 > >Moreover most of these fields are already defined as illustrated by the = example I sent. So it appears very fast and very easy to define in IPFIX = a common info model and a common set of templates to export results of IP= PM measures, traceroute measures and 'Per Packet' measures.=20 > >Regarding traceroute metric I propose to try to design this metric using= the IPPM framework and terminology (RFC2330), and then to present it to = the IPPM WG. At large this document may include metrics definitions of mi= ddlebox one-way delay and jitter corresponding to 'Per Packet' measuremen= t technique.=20 > >To sum up I propose to write 2 drafts: > The fist one defines in the IPFIX WG common templates for exporting mea= sure results; > The second one defines in the IPPM WG traceroute and middlebox metrics. > >Regards >Emile > >-----Message d'origine----- >De : Juergen Quittek [mailto:quittek@netlab.nec.de]=20 >Envoy=E9 : lundi 28 mars 2005 03:06 >=C0 : STEPHAN Emile RD-CORE-LAN >Cc : ippm@ietf.org; ipfix@net.doit.wisc.edu >Objet : RE: [ippm] traceroute as WG work item? IPFIX traceroute records > >Emile, > >Thanks for your comments! > >The basic issue I raised was whether or not the standardization >of an information model and data model for traceroute results would >be a work item for the IPPM WG. > >Do I understand correctly from your message that, > 1. yes, it should be standardized, > 2. but not necessarily in the IPPM WG? > >Concerning the discussion at IPPM whether we should use a binary >or an XML-based format for traceroute results, I interpret your >message as support for a binary format. > >I think your thoughts open an interesting discussion on transmitting >traceroute results in IPFIX records. Probably, this issue is worth >mentioning it in the IPFIX applicability statement. > >Also, the issue should be considered by the information model discussion= s >in IPFIX and PSAMP. > >Thanks, > > Juergen > =20 > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Mar 30 18:27:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09822 for ; Wed, 30 Mar 2005 18:27:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmZo-0003RO-58; Wed, 30 Mar 2005 18:26:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmZn-0003RJ-25 for ippm@megatron.ietf.org; Wed, 30 Mar 2005 18:26:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09646 for ; Wed, 30 Mar 2005 18:26:16 -0500 (EST) Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmgm-0002Qp-O6 for ippm@ietf.org; Wed, 30 Mar 2005 18:33:33 -0500 Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j2UNQES1613030 for ; Wed, 30 Mar 2005 16:26:14 -0700 Received: from [129.82.228.219] (prolix.engr.colostate.edu [129.82.228.219]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j2UNQCf12585 for ; Wed, 30 Mar 2005 16:26:12 -0700 (MST) Message-ID: <424B35A1.6010201@engr.colostate.edu> Date: Wed, 30 Mar 2005 16:26:25 -0700 From: "Nischal M. Piratla" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Subject: Re: [ippm] The next steps for the reordering drafts. References: <6.2.0.14.2.20050308182456.02cb66f8@localhost> <6.0.3.0.0.20050320110644.01edd400@custsla.mt.att.com> <423F3AE1.50801@engr.colostate.edu> <6.0.3.0.0.20050327111324.06086030@custsla.mt.att.com> In-Reply-To: <6.0.3.0.0.20050327111324.06086030@custsla.mt.att.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0704930067==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============0704930067== Content-Type: multipart/alternative; boundary="------------060007080409050102050705" This is a multi-part message in MIME format. --------------060007080409050102050705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Al Morton wrote: > At 04:21 PM 03/21/2005, Nischal M. Piratla wrote: > >>> Al wrote: >>> The Reorder Buffer Density (RBD) metric retains the foundation of a >>> general buffer occupancy calculation. This was the original form of >>> reordering density in earlier versions of this draft, including the >>> fact that it records buffer occupancy with loss alone (no reordering >>> needed to grow the buffer, and the normalization for lost packets >>> doesn't reduce the occupation to zero). See section 7, example b. >>> for a scenario with loss, no reordering. >> >> >> To recall, example b from section 7: >> >> "Consider a sequence of 6 packets (1, 2, 4, 5, 6, 7) with DT = BT = 3." >> In this sequence, a measurement needs to buffer packets until the >> loss threshold is reached or sequence has ended. Only at this point >> the packet can be treated as lost. So, the occupancy of buffer is >> intentional to emulate buffering at the receiver and make it useful >> to the application. > > > Every lost packet causes your buffer to grow until it is declared > lost. That might be something useful, but RBD is not a reordering metric > in a strict sense, because there will always be ambiguity: I thought, IPPM agreed on having multiple definitions of reordering, if there is a use. As I pointed out in 62nd IETF meeting, n-reordering does not measure reordering, as in sequence (1, 4, 5, 6, 2, 3), it shows 2 as reordered but not 3. "That might be something useful, but n-reordering is not a reordering metric in a strict sense, because there will always be ambiguity: " However, it was the consensus at IPPM meeting that we should explore multiple definitions to extract broader usefulness from the metrics. > Did lost packets or reordered packets (or both) cause buffer growth? > > A key point of standardizing a reordering metric is to distinguish > reordering from loss - they have different causes and cures. > > If I look at the RBD buffer occupation frequencies, > there will be many sizes encountered as the buffer is growing. > But only one of the sizes is relevant to buffer design in this context, > the size needed to restore a reordered packet to order. > One could look at a histogram of buffer sizes after a measurement, > but the RDB frequencies alone are not sufficient to say whether a > specific buffer size can mitigate reordering and to what extent > (as a fraction of reordered packets). Loss Orthogonal RBD or L-RBD is a modification to RBD that eliminates its sensitive behavior to buffering while waiting for lost packets. We suggested stay-back and go-back implementations for the same. If the objective is solely to make RBD sensitive to reordering and not losses as you suggest, L-RBD is capable of that and we can put it back. But we (and others (msg00316) feel that RBD is more useful in its current form.But it does not mean that we cannot have both of them if you convince us it is necessary. I am not sure whether we are trying to demerit/merit same points at different instances! (It seems that same people argue for and against same feature at different times..) >> For reference, please read the message: >> http://www1.ietf.org/mail-archive/web/ippm/current/msg00316.html > > > I did in 2004, and I incorporated several of Michal's comments in > the draft (Section 6 on Measurement and Implementation Issues). > We recently refined the text there through comment and review. > >>> Al wrote: >>> draft-ippm-reordering-09 deals with buffer size more effectively, in >>> that it only produces values when reordered packets arrive, >>> in the dimension of bytes. See the Section on Byte Offset. This >>> behavior doesn't seem to fit a reordering metric. >> > > Hmmm. Your mail tool seems to be reordering sentences. > The last sentence above applies to RBD, and was prior to the others > in my original message. The archive has the text in-order: > http://www1.ietf.org/mail-archive/web/ippm/current/msg00605.html I responded to each point you made in that e-mail, not necessarily in the same order that you raised them. The chronology of the drafts still remains valid, i.e., RBD (then RD) was first introduced in Nov. 2002 followed by our draft in Feb. 2003 and the concept had later appeared in March 2003 IPPM draft. - Nischal --------------060007080409050102050705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Al Morton wrote:
At 04:21 PM 03/21/2005, Nischal M. Piratla wrote:
Al wrote:
The Reorder Buffer Density (RBD) metric retains the foundation of a general buffer occupancy calculation. This was the original form of reordering density in earlier versions of this draft, including the fact that it records buffer occupancy with loss alone (no reordering needed to grow the buffer, and the normalization for lost packets doesn't reduce the occupation to zero). See section 7, example b. for a scenario with loss, no reordering.

To recall, example b from section 7:

"Consider a sequence of 6 packets (1, 2, 4, 5, 6, 7) with DT = BT = 3."
In this sequence, a measurement needs to buffer packets until the loss threshold is reached or sequence has ended. Only at this point the packet can be treated as lost. So, the occupancy of buffer is intentional to emulate buffering at the receiver and make it useful to the application.

Every lost packet causes your buffer to grow until it is declared lost. That might be something useful, but RBD is not a reordering metric
in a strict sense, because there will always be ambiguity:

I thought, IPPM agreed on having multiple definitions of reordering, if  there is a use. As I pointed out in 62nd IETF meeting, n-reordering does not measure reordering, as in sequence (1, 4, 5, 6, 2, 3), it shows 2 as reordered but not 3. "That might be something useful, but n-reordering is not a reordering metric in a strict sense, because there will always be ambiguity: " However, it was the consensus at IPPM meeting that we should explore multiple definitions to extract broader usefulness from the metrics.
> Did lost packets or reordered packets (or both) cause buffer growth?
>
> A key point of standardizing a reordering metric is to distinguish
> reordering from loss - they have different causes and cures.
>
> If I look at the RBD buffer occupation frequencies,
> there will be many sizes encountered as the buffer is growing.
> But only one of the sizes is relevant to buffer design in this context,
> the size needed to restore a reordered packet to order.
> One could look at a histogram of buffer sizes after a measurement,
> but the RDB frequencies alone are not sufficient to say whether a
> specific buffer size can mitigate reordering and to what extent
> (as a fraction of reordered packets).

Loss Orthogonal RBD or L-RBD is a modification to RBD that eliminates its sensitive behavior to buffering while waiting for lost packets. We suggested stay-back and go-back implementations for the same. If the objective is solely to make RBD sensitive to reordering and not losses as you suggest, L-RBD is capable of that and we can put it back. But we (and others (msg00316) feel that RBD is more useful in its current form.But it does not mean that we cannot have both of them if you convince us it is necessary.

I am not sure whether we are trying to demerit/merit same points at different instances! (It seems that same people argue for and against same feature at different times..)
For reference, please read the message:
http://www1.ietf.org/mail-archive/web/ippm/current/msg00316.html

I did in 2004, and I incorporated several of Michal's comments in
the draft (Section 6 on Measurement and Implementation Issues).
We recently refined the text there through comment and review.

Al wrote:
draft-ippm-reordering-09 deals with buffer size more effectively, in that it only produces values when reordered packets arrive,
in the dimension of bytes.  See the Section on Byte Offset. This behavior doesn't seem to fit a reordering metric.

Hmmm.  Your mail tool seems to be reordering sentences.
The last sentence above applies to RBD, and was prior to the others
in my original message.  The archive has the text in-order:
http://www1.ietf.org/mail-archive/web/ippm/current/msg00605.html
I responded to each point you made in that e-mail, not necessarily in the same order that you raised them. The chronology of the drafts still remains valid, i.e., RBD (then RD) was first introduced in Nov. 2002 followed by our draft in Feb. 2003 and the concept had later appeared in March 2003 IPPM draft.
- Nischal


--------------060007080409050102050705-- --===============0704930067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0704930067==-- From ippm-bounces@ietf.org Thu Mar 31 06:05:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03041 for ; Thu, 31 Mar 2005 06:05:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGxTV-0005ds-PT; Thu, 31 Mar 2005 06:04:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGxTO-0005au-5f for ippm@megatron.ietf.org; Thu, 31 Mar 2005 06:04:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02810 for ; Thu, 31 Mar 2005 06:04:24 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGxaT-0000CE-KN for ippm@ietf.org; Thu, 31 Mar 2005 06:11:47 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 094831525C; Thu, 31 Mar 2005 13:12:48 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] traceroute as WG work item? IPFIX traceroute records Date: Thu, 31 Mar 2005 13:04:15 +0200 Message-ID: Thread-Topic: [ippm] traceroute as WG work item? IPFIX traceroute records Thread-Index: AcUzMkHqt1XZlr6jTkGIfmYGvpCH+ABCxOBAAGg6g8A= From: "Saverio Niccolini" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Emile and all, > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On=20 > Behalf Of STEPHAN Emile RD-CORE-LAN > Sent: Tuesday, March 29, 2005 11:43 AM > To: Juergen Quittek; Lutz Mark > Cc: ipfix@net.doit.wisc.edu; ippm@ietf.org > Subject: RE: [ippm] traceroute as WG work item? IPFIX=20 > traceroute records >=20 > Hi Juergen and Lutz >=20 > What we experienced with the IPPM MIB is that measures=20 > generate a lot of data. So the binary format is the best for=20 > collecting.=20 >=20 > Traceroute Field Types do not differ from Per Packet Field=20 > Types (draft-pohl-perpktinfo-02.txt) or from IPPM Field=20 > Types, especially if we include spatial and multicast metrics=20 > (dratf-stephan-ippm-multimetrics-00.txt).=20 >=20 > Moreover most of these fields are already defined as=20 > illustrated by the example I sent. So it appears very fast=20 > and very easy to define in IPFIX a common info model and a=20 > common set of templates to export results of IPPM measures,=20 > traceroute measures and 'Per Packet' measures.=20 >=20 > Regarding traceroute metric I propose to try to design this=20 > metric using the IPPM framework and terminology (RFC2330),=20 > and then to present it to the IPPM WG. At large this document=20 > may include metrics definitions of middlebox one-way delay=20 > and jitter corresponding to 'Per Packet' measurement technique.=20 This is what the section: "7. Relevant metrics for traceroute measurements" of our draft would like to define (http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetracerout es-00.txt). We would like to define these metrics using the IPPM framework and terminology (this is why the draft was submitted in the IPPM working group), anyway we received some comments that there may be some discrepancies between the IPPM metrics already defined and the metrics traceroute is using.=20 I am not sure that our draft is the right place to define also metrics of middle-box one-way delay and jitter corresponding to 'Per Packet' measurement technique. What we had in mind was something specific to traceroute as in the scope of the IPPM working group. I am fine if you suggest to use IPFIX as a data model, this would mean that the binary mode is your preferred one. We had also other suggestions just going in the opposite direction. We still have to reach a consensus on this: -- text (XML) -- binary (IPFIX) this is why we have not yet defined the data model. If we decide to go for a binary format and, as a binary format, IPFIX, we will have to discuss it also in the IPFIX WG, of course. Anyway we are still waiting in order to understand if=20 traceroute should be picked up as a IPPM WG item. I interpret your comments as a suggestion to keep on working on the topic and that you like the idea of having the draft to be picked up as a IPPM WG item. Am I right? What about the other group members? Best regards, Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Research Staff Member Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 90511-18 Fax: +49 (0)6221 90511-55 e-mail: saverio.niccolini@netlab.nec.de =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Mar 31 08:27:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19622 for ; Thu, 31 Mar 2005 08:27:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGzfy-0007uO-So; Thu, 31 Mar 2005 08:25:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGzfw-0007uJ-Uj for ippm@megatron.ietf.org; Thu, 31 Mar 2005 08:25:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19435 for ; Thu, 31 Mar 2005 08:25:31 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGzn3-0006Fo-Eh for ippm@ietf.org; Thu, 31 Mar 2005 08:32:54 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 450682677A; Thu, 31 Mar 2005 15:25:22 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D83DF26734; Thu, 31 Mar 2005 15:25:20 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j2VDPIeu007228; Thu, 31 Mar 2005 15:25:20 +0200 Message-Id: <6.2.0.14.2.20050331150141.02c15020@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 31 Mar 2005 15:16:14 +0200 To: "Nischal M. Piratla" , ippm@ietf.org From: Henk Uijterwaal Subject: Re: [ippm] The next steps for the reordering drafts. In-Reply-To: <424B35A1.6010201@engr.colostate.edu> References: <6.2.0.14.2.20050308182456.02cb66f8@localhost> <6.0.3.0.0.20050320110644.01edd400@custsla.mt.att.com> <423F3AE1.50801@engr.colostate.edu> <6.0.3.0.0.20050327111324.06086030@custsla.mt.att.com> <424B35A1.6010201@engr.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.010593 / -5.9 X-RIPE-Signature: e22ef1135316515d887892f529605421 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Nischal, >I thought, IPPM agreed on having multiple definitions of reordering, >if there is a use. It is more the other way around: we would like to see 1 metric, but realized quite early on in the discussion that depending on the application some definitions make more sense than others. So, we agreed to include >1 metric in the draft. > As I pointed out in 62nd IETF meeting, n-reordering does not measure > reordering, as in sequence (1, 4, 5, 6, 2, 3), it shows 2 as reordered > but not 3. "That might be something useful, but n-reordering is not a > reordering metric in a strict sense, because there will always be ambiguity: I think this shows that there is no intuitive definition of reordering. Take the sequence (1, 4, 2, 3). This sequence is reordered with respect to the original (1, 2, 3, 4). It is not that clear for the individual packet. For packet 3, I can argue that it is still in the same order w.r.t. packet 2 (and packet 1) as they were sent, so packet 3 is not reordered. OTOH, it is out of order w.r.t. packet 4, so it is reordered. So, is packet 3 reordered or not? We can probably argue on this forever, but I don't think that will get us anywhere. Rather, I think we should simply define metrics, understand what they do in certain cases, and see if this returns a useful number to measure. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Mar 31 09:02:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23579 for ; Thu, 31 Mar 2005 09:02:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH08P-0005Wu-KZ; Thu, 31 Mar 2005 08:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGwAF-0007cD-Kr for ippm@megatron.ietf.org; Thu, 31 Mar 2005 04:40:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26613 for ; Thu, 31 Mar 2005 04:40:33 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGwHK-0006y6-6x for ippm@ietf.org; Thu, 31 Mar 2005 04:47:55 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 11:40:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2005 11:40:28 +0200 Message-ID: Thread-Topic: Common templates for exporting measurement results and middlebox metrics Thread-Index: AcU1b7hyRPKpb+c2RbyzSDXXXIPAUQAUJEQA From: "STEPHAN Emile RD-CORE-LAN" To: "Benoit Claise" , "Lutz Mark" , "Juergen Quittek" X-OriginalArrivalTime: 31 Mar 2005 09:40:43.0403 (UTC) FILETIME=[B52F9DB0:01C535D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 31 Mar 2005 08:54:54 -0500 Cc: ipfix@net.doit.wisc.edu, ippm@ietf.org Subject: [ippm] Common templates for exporting measurement results and middlebox metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Benoit, It is clear that IPFIX is suitable to export binary data such as = measurement results (either active or passive). Having common templates and clear metrics definitions is the only way to = increase the usability, interoperability and the scalability of the = collecting part of measurement systems. Templates: ---------- Nevertheless there are at least 3 issues with the current version of = IPFIX: Field Types SampleID, metricID are missing; The current delta timestamp computation is not applicable to measure = related to delay or jitter; Templates are not defined; That fully motivates the first I-D "common templates for exporting = measure results". It will fully specify the templates to export active = and passive measurement result; Metrics: -------- draft-ietf-ipfix-as-04.txt presents several usages for IPFIX. One of = them consists in using PSAMP technique to measure IPPM metrics. = Unfortunately the current IPPM metrics definitions are not directly = applicable to this technique. They must be adapted to routers and = middlebox. This is clearly the intent of the second I-D "traceroute and middlebox = metrics". Each section defining a metric will discuss measurement issues = related to the measure, the reporting... as RFC2679-80 do.=20 IPFIX Info Model: ----------------- I explained in the last PSAMP meeting (discussion related to = draft-pohl-perpktinfo-02.txt) that we have to identify the few field = types needed in the info model. What about basically adding PacketID, = SampleID, metricID and MeasureID in the IPFIX info model? IPFIX Protocol: --------------- Regarding measurement result, delta timestamping is the major issue. The = current approach is not applicable to measurement results and does not = conform to the IPFIX architecture. I proposed yesterday a solution. What = is the opinion of the WG fellows on this proposal? Regards Emile -----Message d'origine----- De=A0: Benoit Claise [mailto:bclaise@cisco.com]=20 Envoy=E9=A0: mercredi 30 mars 2005 23:30 =C0=A0: STEPHAN Emile RD-CORE-LAN Cc=A0: Juergen Quittek; Lutz Mark; ippm@ietf.org; = ipfix@net.doit.wisc.edu Objet=A0: Re: [ipfix] RE: [ippm] traceroute as WG work item? IPFIX = traceroute records Emile, If there is a need to push some IPPM data to a NMS (as opposed to pull=20 the data with SNMP), then the IPFIX protocol makes perfect sense as it=20 is efficient and flexible. BTW, this is described in the IPFIX applicability draft=20 (http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-04.txt) 2.7 SLA validation...........................................8=20 2.8 Traffic Monitoring.......................................8=20 2.8.1 Measurement of Round-trip-time (RTT)....................9=20 2.8.2 Measurement of One-way-delay (OWD)......................9=20 2.8.3 Measurement of One-way-loss (OWL)......................10=20 2.8.4 Measurement of IP delay variation (IPDV)...............10=20 3.3 IPFIX and IPPM=20 Note that this draft speaks of passive measurements as opposed to active = measurements in IPPM. However, from the pure IPFIX protocol point of view, the measurement = mechanism is not relevant. Regards, Benoit. >Hi Juergen and Lutz > >What we experienced with the IPPM MIB is that measures generate a lot = of data. So the binary format is the best for collecting.=20 > >Traceroute Field Types do not differ from Per Packet Field Types = (draft-pohl-perpktinfo-02.txt) or from IPPM Field Types, especially if = we include spatial and multicast metrics = (dratf-stephan-ippm-multimetrics-00.txt).=20 > >Moreover most of these fields are already defined as illustrated by the = example I sent. So it appears very fast and very easy to define in IPFIX = a common info model and a common set of templates to export results of = IPPM measures, traceroute measures and 'Per Packet' measures.=20 > >Regarding traceroute metric I propose to try to design this metric = using the IPPM framework and terminology (RFC2330), and then to present = it to the IPPM WG. At large this document may include metrics = definitions of middlebox one-way delay and jitter corresponding to 'Per = Packet' measurement technique.=20 > >To sum up I propose to write 2 drafts: > The fist one defines in the IPFIX WG common templates for exporting = measure results; > The second one defines in the IPPM WG traceroute and middlebox = metrics. > >Regards >Emile > >-----Message d'origine----- >De : Juergen Quittek [mailto:quittek@netlab.nec.de]=20 >Envoy=E9 : lundi 28 mars 2005 03:06 >=C0 : STEPHAN Emile RD-CORE-LAN >Cc : ippm@ietf.org; ipfix@net.doit.wisc.edu >Objet : RE: [ippm] traceroute as WG work item? IPFIX traceroute records > >Emile, > >Thanks for your comments! > >The basic issue I raised was whether or not the standardization >of an information model and data model for traceroute results would >be a work item for the IPPM WG. > >Do I understand correctly from your message that, > 1. yes, it should be standardized, > 2. but not necessarily in the IPPM WG? > >Concerning the discussion at IPPM whether we should use a binary >or an XML-based format for traceroute results, I interpret your >message as support for a binary format. > >I think your thoughts open an interesting discussion on transmitting >traceroute results in IPFIX records. Probably, this issue is worth >mentioning it in the IPFIX applicability statement. > >Also, the issue should be considered by the information model = discussions >in IPFIX and PSAMP. > >Thanks, > > Juergen > =20 > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Mar 31 09:04:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23813 for ; Thu, 31 Mar 2005 09:04:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH08P-0005Wp-3J; Thu, 31 Mar 2005 08:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGwua-0007fy-O0 for ippm@megatron.ietf.org; Thu, 31 Mar 2005 05:28:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01154 for ; Thu, 31 Mar 2005 05:28:26 -0500 (EST) Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGx1g-00083l-IX for ippm@ietf.org; Thu, 31 Mar 2005 05:35:49 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2VASHF07076; Thu, 31 Mar 2005 12:28:17 +0200 (CEST) Received: from [144.254.7.188] (dhcp-peg3-vl30-144-254-7-188.cisco.com [144.254.7.188]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2VASHK16040; Thu, 31 Mar 2005 12:28:17 +0200 (CEST) Message-ID: <424BD0C1.9090100@cisco.com> Date: Thu, 31 Mar 2005 12:28:17 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id j2VASHF07076 X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 31 Mar 2005 08:54:54 -0500 Cc: Lutz Mark , ippm@ietf.org, ipfix@net.doit.wisc.edu Subject: [ippm] Re: Common templates for exporting measurement results and middlebox metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Emile, >Hi Benoit, > >It is clear that IPFIX is suitable to export binary data such as measure= ment results (either active or passive). > >Having common templates and clear metrics definitions is the only way to= increase the usability, interoperability and the scalability of the coll= ecting part of measurement systems. > =20 > Agreed on the clear metrics definitions, this is the IPPM WG job. Regarding the common templates, I'm more in favor of letting the user=20 export what they need with a flexible export mechanism such as IPFIX. Imposing the templates is not the right approach. We tried that with=20 NetFlow version 5: it doesn't scale when you have new Information=20 Elements. Therefore NetFlow version 9 was created. Note for the IPPM=20 users: IPFIX is based on NetFlow version 9. >Templates: >---------- > >Nevertheless there are at least 3 issues with the current version of IPF= IX: > Field Types SampleID, metricID are missing; > =20 > SampleId is a typical PSAMP field that will be specified in the=20 information model. See the selectorID ... unless I misunderstood what=20 you meant with SampleID. Maybe you mean a hash value? Again it will=20 defined part of PSAMP. > The current delta timestamp computation is not applicable to measure re= lated to delay or jitter; > =20 > > Templates are not defined; > =20 > See my point above. >That fully motivates the first I-D "common templates for exporting measu= re results". It will fully specify the templates to export active and pas= sive measurement result; > >Metrics: >-------- > >draft-ietf-ipfix-as-04.txt presents several usages for IPFIX. One of the= m consists in using PSAMP technique to measure IPPM metrics. Unfortunatel= y the current IPPM metrics definitions are not directly applicable to thi= s technique. They must be adapted to routers and middlebox. > >This is clearly the intent of the second I-D "traceroute and middlebox m= etrics". Each section defining a metric will discuss measurement issues r= elated to the measure, the reporting... as RFC2679-80 do.=20 > > >IPFIX Info Model: >----------------- > >I explained in the last PSAMP meeting (discussion related to draft-pohl-= perpktinfo-02.txt) that we have to identify the few field types needed in= the info model. What about basically adding PacketID, SampleID, metricID= and MeasureID in the IPFIX info model? > =20 > We still have to work on the PSAMP information model > >IPFIX Protocol: >--------------- > >Regarding measurement result, delta timestamping is the major issue. The= current approach is not applicable to measurement results and does not c= onform to the IPFIX architecture. I proposed yesterday a solution.=20 > I replied to it. Let's keep 2 separate threads (BTW, I still don't=20 understand why it doesn't conform to the IPFIX architecture) Regards, Benoit. >What is the opinion of the WG fellows on this proposal? > > >Regards >Emile > >-----Message d'origine----- >De : Benoit Claise [mailto:bclaise@cisco.com]=20 >Envoy=E9 : mercredi 30 mars 2005 23:30 >=C0 : STEPHAN Emile RD-CORE-LAN >Cc : Juergen Quittek; Lutz Mark; ippm@ietf.org; ipfix@net.doit.wisc.edu >Objet : Re: [ipfix] RE: [ippm] traceroute as WG work item? IPFIX tracero= ute records > >Emile, > >If there is a need to push some IPPM data to a NMS (as opposed to pull=20 >the data with SNMP), then the IPFIX protocol makes perfect sense as it=20 >is efficient and flexible. >BTW, this is described in the IPFIX applicability draft=20 >(http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-04.txt) > > 2.7 SLA validation...........................................8=20 > 2.8 Traffic Monitoring.......................................8=20 > 2.8.1 Measurement of Round-trip-time (RTT)....................9=20 > 2.8.2 Measurement of One-way-delay (OWD)......................9=20 > 2.8.3 Measurement of One-way-loss (OWL)......................10=20 > 2.8.4 Measurement of IP delay variation (IPDV)...............10=20 > 3.3 IPFIX and IPPM=20 > >Note that this draft speaks of passive measurements as opposed to active= measurements in IPPM. >However, from the pure IPFIX protocol point of view, the measurement mec= hanism is not relevant. > >Regards, Benoit. > > =20 > >>Hi Juergen and Lutz >> >>What we experienced with the IPPM MIB is that measures generate a lot o= f data. So the binary format is the best for collecting.=20 >> >>Traceroute Field Types do not differ from Per Packet Field Types (draft= -pohl-perpktinfo-02.txt) or from IPPM Field Types, especially if we inclu= de spatial and multicast metrics (dratf-stephan-ippm-multimetrics-00.txt)= .=20 >> >>Moreover most of these fields are already defined as illustrated by the= example I sent. So it appears very fast and very easy to define in IPFIX= a common info model and a common set of templates to export results of I= PPM measures, traceroute measures and 'Per Packet' measures.=20 >> >>Regarding traceroute metric I propose to try to design this metric usin= g the IPPM framework and terminology (RFC2330), and then to present it to= the IPPM WG. At large this document may include metrics definitions of m= iddlebox one-way delay and jitter corresponding to 'Per Packet' measureme= nt technique.=20 >> >>To sum up I propose to write 2 drafts: >> The fist one defines in the IPFIX WG common templates for exporting me= asure results; >> The second one defines in the IPPM WG traceroute and middlebox metrics. >> >>Regards >>Emile >> >>-----Message d'origine----- >>De : Juergen Quittek [mailto:quittek@netlab.nec.de]=20 >>Envoy=E9 : lundi 28 mars 2005 03:06 >>=C0 : STEPHAN Emile RD-CORE-LAN >>Cc : ippm@ietf.org; ipfix@net.doit.wisc.edu >>Objet : RE: [ippm] traceroute as WG work item? IPFIX traceroute records >> >>Emile, >> >>Thanks for your comments! >> >>The basic issue I raised was whether or not the standardization >>of an information model and data model for traceroute results would >>be a work item for the IPPM WG. >> >>Do I understand correctly from your message that, >> 1. yes, it should be standardized, >> 2. but not necessarily in the IPPM WG? >> >>Concerning the discussion at IPPM whether we should use a binary >>or an XML-based format for traceroute results, I interpret your >>message as support for a binary format. >> >>I think your thoughts open an interesting discussion on transmitting >>traceroute results in IPFIX records. Probably, this issue is worth >>mentioning it in the IPFIX applicability statement. >> >>Also, the issue should be considered by the information model discussio= ns >>in IPFIX and PSAMP. >> >>Thanks, >> >> Juergen >>=20 >> >> =20 >> _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Mar 31 11:51:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11249 for ; Thu, 31 Mar 2005 11:51:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2qu-0001bc-AC; Thu, 31 Mar 2005 11:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2Xn-0006Ip-BA for ippm@megatron.ietf.org; Thu, 31 Mar 2005 11:29:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09592 for ; Thu, 31 Mar 2005 11:29:16 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH2ev-0005ET-AT for ippm@ietf.org; Thu, 31 Mar 2005 11:36:42 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 31 Mar 2005 17:28:33 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 17:28:32 +0100 Received: from 131.227.89.181 ([131.227.89.181]) by EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Mar 2005 16:28:30 +0000 Received: from ccsrlt31 by evs-ec1-node1.surrey.ac.uk; 31 Mar 2005 17:28:30 +0100 From: Lei Liang To: ippm@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112286509.8586.52.camel@ccsrlt31.ee.surrey.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 31 Mar 2005 17:28:30 +0100 X-OriginalArrivalTime: 31 Mar 2005 16:28:32.0504 (UTC) FILETIME=[ADE81F80:01C5360E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 31 Mar 2005 11:49:03 -0500 Subject: [ippm] question on the reordering draft 09 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, I am confused when reading the definition of the Type-P-Reordered (part 3.3) when it talks about the reordered and in-order. It says: The value of Type-P-Reordered is defined as TRUE if s < NextExp (the packet is reordered). The value of Type-P-Reordered is defined as FALSE if s >= NextExp (the packet is in-order). Then, as I understand it says a packet with sequence number S < the expected sequence number of the following packet should be reordered. the example can be given as a packet with sequence number of 3 and NextExp of 4 is not in order???? it doesn't make sense. or, it means that the sequence number s should be compared with the NextExp number of the previous packet. then the example becomes as a packet with sequence number of 3 is not in order because the previous packet has a metric parameter NextExp=4. this make sense. Seems to me, the two explanations can both fit the definition. And I suggest to stress the NextExp in the definition to clarify that it's belong to the previous packet rather than the current measured one. cheers, lei Liang _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Mar 31 14:11:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24418 for ; Thu, 31 Mar 2005 14:11:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4yc-0007MX-Kx; Thu, 31 Mar 2005 14:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4yb-0007MQ-AN for ippm@megatron.ietf.org; Thu, 31 Mar 2005 14:05:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23847 for ; Thu, 31 Mar 2005 14:05:08 -0500 (EST) Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH55j-0002w0-V4 for ippm@ietf.org; Thu, 31 Mar 2005 14:12:34 -0500 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2VJ0ucW025314 for ; Thu, 31 Mar 2005 14:04:57 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh2i.attrh.att.com (7.2.052) id 42477D2500095BAF; Thu, 31 Mar 2005 14:04:57 -0500 Received: from acmortonw.att.com ([135.210.73.160]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j2VJ4uZ19541; Thu, 31 Mar 2005 14:04:56 -0500 (EST) Message-Id: <6.0.3.0.0.20050331133807.06374eb0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 31 Mar 2005 14:03:41 -0500 To: Lei Liang , ippm@ietf.org From: Al Morton Subject: Re: [ippm] question on the reordering draft 09 In-Reply-To: <1112286509.8586.52.camel@ccsrlt31.ee.surrey.ac.uk> References: <1112286509.8586.52.camel@ccsrlt31.ee.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Lei, Thanks for your comment, see below: At 11:28 AM 03/31/2005, Lei Liang wrote: >Dear all, > I am confused when reading the definition of the Type-P-Reordered >(part 3.3) when it talks about the reordered and in-order. It says: > > The value of Type-P-Reordered is defined as TRUE if s < NextExp (the >packet is reordered). > > The value of Type-P-Reordered is defined as FALSE if s >= NextExp > (the packet is in-order). Both paragraphs above go on to say how to determine NextExp so that the next arriving packet can be evaluated. >Then, as I understand it says a packet with sequence number S < the >expected sequence number of the following packet should be reordered. >the example can be given as a packet with sequence number of 3 and NextExp >of 4 is not in order???? it doesn't make sense. Right, it doesn't make sense to calculate NextExp using the packet that you are trying to evaluate. Whether or not NextExp is re-calculated is conditioned on the outcome of the s to NextExp comparison. So the sentences you left out above are very important. >or, it means that the sequence number s should be compared with the >NextExp number of the previous packet. Yes, that's what we said when introducing the "next expected" concept in Section 3.0. >then the example becomes as a packet >with sequence number of 3 is not in order because the previous packet has a >metric parameter NextExp=4. this make sense. >Seems to me, the two explanations can both fit the definition. And I suggest >to stress the NextExp in the definition to clarify that it's belong to the >previous packet rather than the current measured one. >cheers, >lei Liang Will this help you (added second sentence)? + NextExp, the Next Expected Sequence number at the Destination, in units of messages. This stored value in NextExp is determined from a previously arriving packet. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm
****************************************************
Research Assistant
Computer Networking Research Laboratory (CNRL)
C203,Dept. of Electrical & Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: 970-491-7067/7974
Fax:   970-491-2249
http://www.cnrl.colostate.edu
http://lamar.colostate.edu/~nischal
****************************************************