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 <S257132AbRLJEtW>; 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" <lltew@go2.pl>
To: <ippm-archive@ietf.org>
Subject: Start the year with a fresh start.
X-message-flag: Authentic Sender, Hash: LKQLMTEA
List-ID: <ippm-archive@ietf.org>
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


<html>
<head>
<title>phenomenon interstice</title>
</head>

<body>
<table width="442" height="100" border="0" cellpadding="0" cellspacing="0">
   <tr>
    <td height="161" colspan="7" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
        <!--DWLayoutTable-->
        <tr>
          <td width="442" height="153" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
              <!--DWLayoutTable-->
              <tr>
                <td width="442" height="9" valign="top">
                <a href="http://www.g3tit.com/mortgage.asp">
                <img src = "cid:DTEHFHQD.QBJJWMEO.VEDLMHGT.DHUMBCHB_csseditor" border=0></a><br>
                </td>
              </tr>
              <tr>
                <td height="10" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="13" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
                    <!--DWLayoutTable-->
                    <tr>
                      <td width="442" height="13">.</td>
                    </tr>
                </table></td>
              </tr>
              <tr>
                <td height="3">.</td>
              </tr>
              <tr>
                <td height="4"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
                          </table></td>
        </tr>
        <tr>
          <td height="0">.</td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8">http://www.g3tit.com/mortgage.asp It's time to fix up your situation for once and for all</td>
        </tr>
        </table></td>
  </tr>
  <tr>
    <td width="49" height="19" valign="top">.</td>
    <td width="299">&nbsp;</td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="18" rowspan="2" valign="top"></td>
  </tr>
  <tr>
    <td height="173">&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
</table><FONT face=Verdana size 2><a href="http://www.g3tit.com/gone.asp">No More</FONT>
</body>
</html>


------------A85031401794097--

------------A48356845382213
Content-Type:  image/gif; name="medea.gif"
Content-Transfer-Encoding: base64
Content-ID: <DTEHFHQD.QBJJWMEO.VEDLMHGT.DHUMBCHB_csseditor>
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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <shalunov@internet2.edu>
From: Mark Allman <mallman@icir.org>
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 <Saverio.Niccolini@netlab.nec.de>, 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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <F0DC7B6021F256408935B31D97FC727E5035B6@europa.office>
Thread-Topic: [ippm] Way to store traceroutes 
Thread-Index: AcUfbS2pw0RrLAUiTBu3u3zgaSnliwAbY5Gw
From: "Sandra Tartarelli" <Sandra.Tartarelli@netlab.nec.de>
To: <mallman@icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: quoted-printable
Cc: Saverio Niccolini <Saverio.Niccolini@netlab.nec.de>, ippm@ietf.org
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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: <F0DC7B6021F256408935B31D97FC727E518F75@europa.office>
Thread-Topic: [ippm] Way to store traceroutes 
Thread-Index: AcUfbS24Dv+w8wJrShir2ZxQRdISbQApGFVg
From: "Saverio Niccolini" <Saverio.Niccolini@netlab.nec.de>
To: <ippm@ietf.org>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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" <Saverio.Niccolini@netlab.nec.de>, <ippm@ietf.org>
From: Henk Uijterwaal <henk@ripe.net>
Subject: RE: [ippm] Way to store traceroutes 
In-Reply-To: <F0DC7B6021F256408935B31D97FC727E518F75@europa.office>
References: <F0DC7B6021F256408935B31D97FC727E518F75@europa.office>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <S518132AbRLJEtW>; 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" <ixwuk@go2.pl>
To: <rmt@ietf.org>
Subject: Congrats - You have finally made it.
X-message-flag: Authentic Sender, Hash: LKQLMTEA
List-ID: <rmt@ietf.org>
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


<html>
<head>
<title>neptunium newt</title>
</head>

<body>
<table width="442" height="100" border="0" cellpadding="0" cellspacing="0">
   <tr>
    <td height="161" colspan="7" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
        <!--DWLayoutTable-->
        <tr>
          <td width="442" height="153" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
              <!--DWLayoutTable-->
              <tr>
                <td width="442" height="9" valign="top">
                <a href="http://www.runninshit.info/mortgage.asp">
                <img src = "cid:DTEHFHQD.QBJJWMEO.VEDLMHGT.DHUMBCHB_csseditor" border=0></a><br>
                </td>
              </tr>
              <tr>
                <td height="10" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="13" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
                    <!--DWLayoutTable-->
                    <tr>
                      <td width="442" height="13">.</td>
                    </tr>
                </table></td>
              </tr>
              <tr>
                <td height="3">.</td>
              </tr>
              <tr>
                <td height="4"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
                          </table></td>
        </tr>
        <tr>
          <td height="0">.</td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8">http://www.runninshit.info/mortgage.asp It's time to fix up your situation for once and for all</td>
        </tr>
        </table></td>
  </tr>
  <tr>
    <td width="49" height="19" valign="top">.</td>
    <td width="299">&nbsp;</td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="18" rowspan="2" valign="top"></td>
  </tr>
  <tr>
    <td height="173">&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
</table><FONT face=Verdana size 2><a href="http://www.runninshit.info/gone.asp">No More</FONT>
</body>
</html>


------------A85031401794097--

------------A48356845382213
Content-Type:  image/gif; name="emperor.gif"
Content-Transfer-Encoding: base64
Content-ID: <DTEHFHQD.QBJJWMEO.VEDLMHGT.DHUMBCHB_csseditor>
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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <henk@ripe.net>
From: Mark Allman <mallman@icir.org>
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 <Saverio.Niccolini@netlab.nec.de>, 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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <S124132AbRLJEtW>; 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" <vnukihos@go2.pl>
To: <ippm-archive@ietf.org>
Subject: You will open and fill this one out for sure.
X-message-flag: Authentic Sender, Hash: LKQLMTEA
List-ID: <ippm-archive@ietf.org>
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


<html>
<head>
<title>barrack noxious</title>
</head>

<body>
<table width="442" height="100" border="0" cellpadding="0" cellspacing="0">
   <tr>
    <td height="161" colspan="7" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
        <!--DWLayoutTable-->
        <tr>
          <td width="442" height="153" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
              <!--DWLayoutTable-->
              <tr>
                <td width="442" height="9" valign="top">
                <a href="http://www.runninshit.info/mortgage.asp">
                <img src = "cid:DTEHFHQD.QBJJWMEO.VEDLMHGT.DHUMBCHB_csseditor" border=0></a><br>
                </td>
              </tr>
              <tr>
                <td height="10" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="19" valign="top"><!--DWLayoutEmptyCell-->&nbsp;</td>
              </tr>
              <tr>
                <td height="13" valign="top"><table width="100%" border="0" cellpadding="0" cellspacing="0">
                    <!--DWLayoutTable-->
                    <tr>
                      <td width="442" height="13">.</td>
                    </tr>
                </table></td>
              </tr>
              <tr>
                <td height="3">.</td>
              </tr>
              <tr>
                <td height="4"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
              <tr>
                <td height="7"></td>
              </tr>
                          </table></td>
        </tr>
        <tr>
          <td height="0">.</td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="0"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="1"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="2"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="4"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8"></td>
        </tr>
        <tr>
          <td height="8">http://www.runninshit.info/mortgage.asp It's time to fix up your situation for once and for all</td>
        </tr>
        </table></td>
  </tr>
  <tr>
    <td width="49" height="19" valign="top">.</td>
    <td width="299">&nbsp;</td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="19" rowspan="2" valign="top"></td>
    <td width="18" rowspan="2" valign="top"></td>
  </tr>
  <tr>
    <td height="173">&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
</table><FONT face=Verdana size 2><a href="http://www.runninshit.info/gone.asp">No More</FONT>
</body>
</html>


------------A85031401794097--

------------A48356845382213
Content-Type:  image/gif; name="sawfly.gif"
Content-Transfer-Encoding: base64
Content-ID: <DTEHFHQD.QBJJWMEO.VEDLMHGT.DHUMBCHB_csseditor>
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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <e35ffd8a44730014baafb17abb72f3dd@ieee.org>
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 <henk@ripe.net>, Matthew J Zekauskas <matt@internet2.edu>
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 <pfc@ieee.org>
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <pfc@ieee.org>, ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
Subject: Re: [ippm] initial rough draft of capacity definitions
In-Reply-To: <e35ffd8a44730014baafb17abb72f3dd@ieee.org>
References: <e35ffd8a44730014baafb17abb72f3dd@ieee.org>
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 <matt@internet2.edu>
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <henk@ripe.net>
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: <e35ffd8a44730014baafb17abb72f3dd@ieee.org>
	<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 <matt@internet2.edu>
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; Mon,  7 Mar 2005 11:42:04 -0500 (EST)
To: ippm@ietf.org
From: Mark Allman <mallman@icir.org>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <mallman@icir.org>
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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <matt@internet2.edu>
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 <henk@ripe.net>, Matt Zekauskas <matt@internet2.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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

<http://people.internet2.edu/~matt/IPPM/Meetings/ietf62/>

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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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: <AF696B16DAC33B46B1911BAD0CCECF7F09314370@ZANEVS03.cc-ntd1.covad.com>
Thread-Topic: [ippm]Comments on initial rough draft of capacity definitions
Thread-Index: AcUjdaQaUMFdTxECToaHfxM8TwQLFw==
From: "Fardid, Reza" <RFardid@covad.com>
To: <ippm@ietf.org>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Phil,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A couple of comments on this draft:&nbsp;&nbsp; =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<ol start=3D1 type=3D1>
 <li class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'>Only metrics defined should be referred to, or
     otherwise all terms used should be defined: effective capacity and
     throughput (2.3), vs. </span></font></li>
</ol>

<p class=3DMsoNormal style=3D'margin-left:.25in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>available capacity and =
utilization
(3).</span></font></p>

<ol start=3D2 type=3D1>
 <li class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'>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.</span></font></li>
</ol>

<p class=3DMsoNormal style=3D'margin-left:.25in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Regards,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Reza Fardid </span></font></p>

</div>

</body>

</html>
=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <AF696B16DAC33B46B1911BAD0CCECF7F09314370@ZANEVS03.cc-ntd1.covad.com>
To: "Fardid, Reza" <RFardid@covad.com>
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: <AF696B16DAC33B46B1911BAD0CCECF7F09314370@ZANEVS03.cc-ntd1.covad.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>;
	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 <ippm@ietf.org>; Mon,  7 Mar 2005 22:02:26 -0500 (EST)
To: ippm@ietf.org
Subject: [ippm] spatial complexity of n-reordering
From: stanislav shalunov <shalunov@internet2.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>;
	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 <ippm@ietf.org>; 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 <shalunov@internet2.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

stanislav shalunov <shalunov@internet2.edu> 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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <matt@internet2.edu>, ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <matt@internet2.edu>, ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <henk@ripe.net>, ippm@ietf.org
From: Al Morton <acmorton@att.com>
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 <matt@internet2.edu>
X-BeenThere: ippm@ietf.org 
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>
To: ippm <ippm@ietf.org>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <shalunov@internet2.edu> =====
>stanislav shalunov <shalunov@internet2.edu> 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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>;
	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 <ippm@ietf.org>; 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 <shalunov@internet2.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

Nischal M Piratla <nischal@engr.colostate.edu> 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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <AF696B16DAC33B46B1911BAD0CCECF7F09314374@ZANEVS03.cc-ntd1.covad.com>
Thread-Topic: [ippm]Comments on initial rough draft of capacity definitions
Thread-Index: AcUjfsj6DjtZdUMySb+I5ayF/Zle/QApju/g
From: "Fardid, Reza" <RFardid@covad.com>
To: <vze275m9@verizon.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>, ippm <ippm@ietf.org>
From: Henk Uijterwaal <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <shalunov@internet2.edu> 
> =====
> >stanislav shalunov <shalunov@internet2.edu> 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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>, ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <henk@ripe.net> =====
>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 <shalunov@internet2.edu>
>> =====
>> >stanislav shalunov <shalunov@internet2.edu> 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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>
To: Henk Uijterwaal <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>
From: Henk Uijterwaal <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>
To: stanislav shalunov <shalunov@internet2.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <shalunov@internet2.edu> =====
>Nischal M Piratla <nischal@engr.colostate.edu> 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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; Wed, 09 Mar 2005 14:01:15 +0100
Date: Wed, 9 Mar 2005 14:01:15 +0100
From: Federico Montesino Pouzols <fedemp@altern.org>
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: <AF696B16DAC33B46B1911BAD0CCECF7F09314374@ZANEVS03.cc-ntd1.covad.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AF696B16DAC33B46B1911BAD0CCECF7F09314374@ZANEVS03.cc-ntd1.covad.com>
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 <fedemp@altern.org>
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <fedemp@altern.org>
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: <AF696B16DAC33B46B1911BAD0CCECF7F09314374@ZANEVS03.cc-ntd1.covad.com>
	<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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <i
	ppm@ietf.org>;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 <ippm@ietf.org>;
	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 <jishac@grc.nasa.gov>
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 <jishac@grc.nasa.gov>
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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: <AF696B16DAC33B46B1911BAD0CCECF7F09314379@ZANEVS03.cc-ntd1.covad.com>
Thread-Topic: Comments on ITU-T IP Performance Work Status
Thread-Index: AcUk06rZLMESl5baTam3/TIZ7xrrfQ==
From: "Fardid, Reza" <RFardid@covad.com>
To: <ippm@ietf.org>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi Al,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A have a number of comments on the Y.1541 loss =
performance
objectives, existing and new:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<ol start=3D1 type=3D1>
 <li class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'>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 ?</span></font></li>
 <li class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'>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 ?</span></font></li>
 <li class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'>Is the new loss objective of 10^(-5) derived =
from
     empirical evidence or some other methodology ?</span></font></li>
</ol>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regards,</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Reza Fardid</span></font></p>

</div>

</body>

</html>
=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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" <RFardid@covad.com>, <ippm@ietf.org>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] Comments on ITU-T IP Performance Work Status
In-Reply-To: <AF696B16DAC33B46B1911BAD0CCECF7F09314379@ZANEVS03.cc-ntd1.
	covad.com>
References: <AF696B16DAC33B46B1911BAD0CCECF7F09314379@ZANEVS03.cc-ntd1.covad.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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"

<html>
<body>
Hi Reza,<br><br>
Let's take this off the list, because of scope and the fact that<br>
ippm needs to focus on several in-scope topics.&nbsp; But I'll<br>
supply some quick answers below so that we don't leave everyone<br>
hanging.&nbsp; We have discussed this topic briefly on ippm-list in the
past.<br><br>
If you're interested in this discussion, let Reza and me know.<br><br>
Al <br><br>
At 01:13 PM 03/09/2005, Fardid, Reza wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>A have a
number of comments on the Y.1541 loss performance objectives, existing
and new:
<ol>
<li>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 ?</font> </blockquote>
</ol>There's no formal report, just confirmation from several SPs<br>
that they have put the current objectives to
use.<br><br><blockquote type=cite class=cite cite>
<ol>
<li><font face="arial" size=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
?</font> </blockquote>
</ol>The current 6 classes (five with loss &lt; 10^-3) have been declared
&quot;stable&quot;.<br>
There are two new provisional classes with &lt;10^-5
loss.<br><br><blockquote type=cite class=cite cite>
<ol>
<li><font face="arial" size=2>Is the new loss objective of 10^(-5)
derived from empirical evidence or some other methodology ?</font>
</blockquote>
</ol>Yes, we looked at requirements for digital video transport<br>
(at various quality levels and positions in the distribution <br>
hierarchy), for high capacity applications that use TCP, and<br>
for various digital/TDM service emulations on packet networks.<br>
Some of the above require Forward Error Correction, in addition<br>
to the &lt;10^-5 loss, in order to meet their objectives.<br><br>
<blockquote type=cite class=cite cite><font face="arial" size=2>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.</font></blockquote></body>
</html>



--===============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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <DD8B8FEBBFAF9E488F63FF0F1A69EDD10B1146@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [ipfix] new version of IPFIX per packet information
Thread-Index: AcUemo9JgfJXx9YbTFirIcwvOzUIWQGSo9HA
From: "STEPHAN Emile RD-CORE-LAN" <emile.stephan@francetelecom.com>
To: <ipfix@net.doit.wisc.edu>, <psamp@ops.ietf.org>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; Thu, 10 Mar 2005 14:07:59 +0100
Date: Thu, 10 Mar 2005 14:07:59 +0100
From: Federico Montesino Pouzols <fedemp@altern.org>
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 <fedemp@altern.org>
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <nischal@engr.colostate.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <acmorton@att.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; Tue, 15 Mar 2005 11:15:33 +0100 (CET)
Date: Tue, 15 Mar 2005 11:15:33 +0100
From: Juergen Quittek <quittek@netlab.nec.de>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; Tue, 15 Mar 2005 12:09:03 +0100 (CET)
Date: Tue, 15 Mar 2005 12:09:04 +0100
From: Juergen Quittek <quittek@netlab.nec.de>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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" <Chadi.Barakat@sophia.inria.fr>
To: "Chadi Barakat" <Chadi.Barakat@sophia.inria.fr>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <acmorton@att.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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" <nischal@engr.colostate.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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: <http://mailhost.advanced.org/archives/ippm/>
> 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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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" <nischal@engr.colostate.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Al Morton wrote:<br>
<blockquote type="cite">
  <blockquote type="cite">The ippm metrics require a comprehensive
detection of duplicate packets.
    <br>
There are ways to reduce the complexity described in the ippm
    <br>
reordering draft. The final complexity depends on implementation.
    <br>
    <br>
RD and RDB would not detect duplicate packets if they arrive with
    <br>
separation greater than DT or BT, the buffer sizes.&nbsp; DT and BT also
    <br>
set the threshold for declaring loss (in terms of packets). Clearly
    <br>
the choices of DT and BT have a profound influence on the results,
    <br>
and they must be set prior to the measurement.
    <br>
  </blockquote>
</blockquote>
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.
<br>
<blockquote type="cite">
  <blockquote type="cite"><br>
Making DT and BT "large enough" is not always possible, as the
application
    <br>
of interest may require small thresholds for accurate assessment.
    <br>
So, duplicates could be defined as reordered, depending on the distance
    <br>
between the first packet and its duplicate.
    <br>
  </blockquote>
</blockquote>
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.
<br>
<br>
Further, in RD and RBD duplicates are <b class="moz-txt-star"><span
 class="moz-txt-tag">*</span>never<span class="moz-txt-tag">*</span></b>
defined as reordered. <br>
<pre class="moz-signature" cols="72">****************************************************
Research Assistant
Computer Networking Research Laboratory (CNRL)
C203,Dept. of Electrical &amp; Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: 970-491-7067/7974
Fax:   970-491-2249
<a class="moz-txt-link-freetext" href="http://www.cnrl.colostate.edu">http://www.cnrl.colostate.edu</a>
<a class="moz-txt-link-freetext" href="http://lamar.colostate.edu/~nischal">http://lamar.colostate.edu/~nischal</a>
****************************************************</pre>
<br>
</body>
</html>

--------------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 <ippm-archive@lists.ietf.org>; 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: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F0C7B1@ftrdmel1.rd.francetelecom.fr>
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" <emile.stephan@francetelecom.com>
To: "JP Vasseur" <jvasseur@cisco.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 =
<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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi JP,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DTimes><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Times'>Objective metrics</span></font><font size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:11.0pt;font-family:Arial'> include
2 main categories:</span></font></p>

<p class=3DMsoNormal style=3D'text-indent:35.4pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:Arial'>Those for =
measuring the
performance (the rapidity) of a PCE entity;</span></font></p>

<p class=3DMsoNormal style=3D'text-indent:35.4pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:Arial'>Those for =
measuring the
accuracy of the PCE computation: </span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:35.4pt;text-indent:35.4pt'><font size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:11.0pt;font-family:Arial'>Do the quality
and the performance of the path computed by PCEs entities complies with =
the query?</span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:35.4pt;text-indent:35.4pt'><font size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>Regarding the second point, Lei and I merged 3 =
I-Ds in
one which defines &quot;</span></font><font size=3D2><span lang=3DEN-GB
style=3D'font-size:11.0pt'>Spatial and Multicast Metrics for IPPM&quot; =
(</span></font><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:11.0pt;font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetri=
cs-00.txt"><font
color=3Dblack><span =
style=3D'color:windowtext'>http://www.ietf.org/internet-drafts/draft-step=
han-ippm-multimetrics-00.txt</span></font></a>
). It defines 2 sets of metrics, spatial and one-to-group: =
</span></font></p>

<p class=3DMsoNormal style=3D'text-indent:35.4pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:Arial'>The intend of =
the spatial
metrics part is clearly to provide TE and interdomain with metrics to =
decompose
end-to-end performance;</span></font></p>

<p class=3DMsoNormal style=3D'text-indent:35.4pt'><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:Arial'>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;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:11.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>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. </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>This draft will be discussed in the IPPM =
mailing. Mid
April, chairs will decide its status evolution.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>I have no doubt that there are a lot of =
missing points
in the discussion section such as case study, applicability&#8230; So =
please
read the document and send your comment in PCE and IPPM =
list.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>Regards</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
11.0pt;font-family:Arial'>Emile</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>De&nbsp;:<=
/span></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Tahoma'>
JP Vasseur [mailto:jvasseur@cisco.com] <br>
<b><span style=3D'font-weight:bold'>Envoy=E9&nbsp;:</span></b> jeudi 13 =
janvier
2005 20:09<br>
<b><span style=3D'font-weight:bold'>=C0&nbsp;:</span></b> STEPHAN Emile =
RD-CORE-LAN<br>
<b><span style=3D'font-weight:bold'>Cc&nbsp;:</span></b> pce@iet<span =
lang=3DFR>f.org</span><br>
</span></font><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>Objet&nbsp;:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Re: [Pce]
contribution to charter item</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Salut Emile, </span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>On Nov 17, 2004, at 8:00 AM, STEPHAN Emile RD-CORE-LAN wrote: =
</span></font></p>

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Dear</span></font> <font size=3D2><span =
style=3D'font-size:10.0pt'>JP,</span></font>
<font size=3D2><span style=3D'font-size:10.0pt'>Adrian and =
all</span></font> </p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>There is an important item in the</span></font> <font =
size=3D2><span
style=3D'font-size:10.0pt'>PCE WG</span></font> <font size=3D2><span
style=3D'font-size:10.0pt'>charter, which is</span></font> <font =
size=3D2><span
style=3D'font-size:10.0pt'>the definition of MIBs and management =
procedures
related to the</span></font> <font size=3D2><span =
style=3D'font-size:10.0pt'>new</span></font>
<font size=3D2><span style=3D'font-size:10.0pt'>protocols, protocol =
extensions and
operational elements.</span></font> </p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>I am interested to contribute to this WG item.</span></font> =
</p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</blockquote>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Great ! </span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Considering your involvement in IPPM, you may also be interested =
by: </span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DTimes><span =
style=3D'font-size:12.0pt;
font-family:Times'>May 05: Submit first draft of the definition of =
objective
metrics </span></font></p>

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Please let</span></font> <font size=3D2><span =
style=3D'font-size:10.0pt'>me</span></font>
<font size=3D2><span style=3D'font-size:10.0pt'>know</span></font> <font =
size=3D2><span
style=3D'font-size:10.0pt'>when</span></font> <font size=3D2><span
style=3D'font-size:10.0pt'>you will start this activity.</span></font> =
</p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</blockquote>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>As indicated in the WG Milestones ... of course, for the MIB, =
this
requires some time until we make progress on the protocol(s). =
</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Cheers. </span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>JP. </span></font></p>

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Regards</span></font> </p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Emile</span></font> </p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>_______________________________________________ =
</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Pce mailing list </span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Pce@lists.ietf.org </span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>https://www1.ietf.org/mailman/listinfo/pce </span></font></p>

</div>

</blockquote>

</div>

</body>

</html>

------_=_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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F4F982@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [ippm] traceroute as WG work item? IPFIX traceroute records
Thread-Index: AcUpT+A+wm9JYVbYT+SM5xVhfYQY/gGeTYTA
From: "STEPHAN Emile RD-CORE-LAN" <emile.stephan@francetelecom.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <quittek@netlab.nec.de>
To: STEPHAN Emile RD-CORE-LAN <emile.stephan@francetelecom.com>
Subject: RE: [ippm] traceroute as WG work item? IPFIX traceroute records
Message-ID: <E068E35AF117C9B4D7BF5C77@dialin-145-254-220-195.arcor-ip.net>
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F4F982@ftrdmel1.rd.francetelecom.fr>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F4F982@ftrdmel1.rd.francetelecom.fr>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <acmorton@att.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <acmorton@att.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F50444@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [ippm] traceroute as WG work item? IPFIX traceroute records
Thread-Index: AcUzMkHqt1XZlr6jTkGIfmYGvpCH+ABCxOBA
From: "STEPHAN Emile RD-CORE-LAN" <emile.stephan@francetelecom.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>,
        "Lutz Mark" <mark@fokus.fraunhofer.de>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <bclaise@cisco.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: STEPHAN Emile RD-CORE-LAN <emile.stephan@francetelecom.com>
Subject: Re: [ipfix] RE: [ippm] traceroute as WG work item? IPFIX traceroute
	records
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F50444@ftrdmel1.rd.francetelecom.fr>
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F50444@ftrdmel1.rd.francetelecom.fr>
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 <mark@fokus.fraunhofer.de>, 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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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" <nischal@engr.colostate.edu>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Al Morton wrote:
<blockquote
 cite="mid6.0.3.0.0.20050327111324.06086030@custsla.mt.att.com"
 type="cite">At 04:21 PM 03/21/2005, Nischal M. Piratla wrote: <br>
  <blockquote type="cite">
    <blockquote type="cite">Al wrote: <br>
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. <br>
    </blockquote>
    <br>
To recall, example b from section 7: <br>
    <br>
"Consider a sequence of 6 packets (1, 2, 4, 5, 6, 7) with DT = BT = 3."
    <br>
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. <br>
  </blockquote>
  <br>
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
  <br>
in a strict sense, because there will always be ambiguity:
  <br>
</blockquote>
<br>
I thought, IPPM agreed on having multiple definitions of reordering,
if&nbsp; 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.
<pre>&gt; Did lost packets or reordered packets (or both) cause buffer growth?
&gt;
&gt; A key point of standardizing a reordering metric is to distinguish
&gt; reordering from loss - they have different causes and cures.
&gt;
&gt; If I look at the RBD buffer occupation frequencies,
&gt; there will be many sizes encountered as the buffer is growing.
&gt; But only one of the sizes is relevant to buffer design in this context,
&gt; the size needed to restore a reordered packet to order.
&gt; One could look at a histogram of buffer sizes after a measurement,
&gt; but the RDB frequencies alone are not sufficient to say whether a
&gt; specific buffer size can mitigate reordering and to what extent
&gt; (as a fraction of reordered packets).</pre>
<br>
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.<br>
<br>
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..)<br>
<blockquote
 cite="mid6.0.3.0.0.20050327111324.06086030@custsla.mt.att.com"
 type="cite">
  <blockquote type="cite">For reference, please read the message: <br>
    <a class="moz-txt-link-freetext"
 href="http://www1.ietf.org/mail-archive/web/ippm/current/msg00316.html">http://www1.ietf.org/mail-archive/web/ippm/current/msg00316.html</a>
    <br>
  </blockquote>
  <br>
I did in 2004, and I incorporated several of Michal's comments in <br>
the draft (Section 6 on Measurement and Implementation Issues). <br>
We recently refined the text there through comment and review. <br>
  <br>
  <blockquote type="cite">
    <blockquote type="cite">Al wrote: <br>
draft-ippm-reordering-09 deals with buffer size more effectively, in
that it only produces values when reordered packets arrive, <br>
in the dimension of bytes.&nbsp; See the Section on Byte Offset. This
behavior doesn't seem to fit a reordering metric. <br>
    </blockquote>
  </blockquote>
  <br>
Hmmm.&nbsp; Your mail tool seems to be reordering sentences. <br>
The last sentence above applies to RBD, and was prior to the others <br>
in my original message.&nbsp; The archive has the text in-order: <br>
  <a class="moz-txt-link-freetext"
 href="http://www1.ietf.org/mail-archive/web/ippm/current/msg00605.html">http://www1.ietf.org/mail-archive/web/ippm/current/msg00605.html</a>
  <br>
</blockquote>
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.<br>
- Nischal<br>
<br>
<br>
</body>
</html>

--------------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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <F0DC7B6021F256408935B31D97FC727EB70B16@europa.office>
Thread-Topic: [ippm] traceroute as WG work item? IPFIX traceroute records
Thread-Index: AcUzMkHqt1XZlr6jTkGIfmYGvpCH+ABCxOBAAGg6g8A=
From: "Saverio Niccolini" <Saverio.Niccolini@netlab.nec.de>
To: <ipfix@net.doit.wisc.edu>, <ippm@ietf.org>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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" <nischal@engr.colostate.edu>, ippm@ietf.org
From: Henk Uijterwaal <henk@ripe.net>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F97389@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: Common templates for exporting measurement results and middlebox
	metrics
Thread-Index: AcU1b7hyRPKpb+c2RbyzSDXXXIPAUQAUJEQA
From: "STEPHAN Emile RD-CORE-LAN" <emile.stephan@francetelecom.com>
To: "Benoit Claise" <bclaise@cisco.com>,
        "Lutz Mark" <mark@fokus.fraunhofer.de>,
        "Juergen Quittek" <quittek@netlab.nec.de>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <bclaise@cisco.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: STEPHAN Emile RD-CORE-LAN <emile.stephan@francetelecom.com>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F97389@ftrdmel1.rd.francetelecom.fr>
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1F97389@ftrdmel1.rd.francetelecom.fr>
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 <mark@fokus.fraunhofer.de>, 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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <L.Liang@surrey.ac.uk>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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 <ippm-archive@lists.ietf.org>; 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 <ippm@ietf.org>; 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 <ippm@ietf.org>; 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 <L.Liang@surrey.ac.uk>, ippm@ietf.org
From: Al Morton <acmorton@att.com>
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 <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>,
	<mailto:ippm-request@ietf.org ?subject=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


