From yaakov_s@rad.com Sun Apr 1 05:31:56 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693B21F90AE for ; Sun, 1 Apr 2012 05:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS1hZD1zA4oW for ; Sun, 1 Apr 2012 05:31:56 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9AE21F9092 for ; Sun, 1 Apr 2012 05:31:53 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 1 Apr 2012 15:22:23 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Sun, 1 Apr 2012 15:31:48 +0300 From: Yaakov Stein To: Henk Uijterwaal , IETF IPPM WG Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt Thread-Index: AQHNDZblzJ3KASTU1kyQrL9b6sTMPpaF1HSQ Date: Sun, 1 Apr 2012 12:31:47 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC90433200E@EXRAD5.ad.rad.co.il> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> In-Reply-To: <4F74397D.4050902@uijterwaal.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020202.4F784AB5.008F,ss=1,fgs=0 Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 12:31:57 -0000 Henk, I object to progressing the draft in question at the present time, for at least 4 reasons. 1) The new version clearly states : This memo is the product of a working prototype. It does not represent a consensus of the IETF community. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for measuring capacity metrics. ... This memo describes the protocol used in the current working prototype implementation of the Value-added octets feature in the Ericsson lab. The prototype has been tested in real network environments. The conclusion from these tests is that the Value-added octets feature is able to enable estimation of metrics such as available path capacity in both the forward and reverse direction of the network path. This is the definition of an individual submission track document, not a document to be submitted to the IESG as a product of the IPPM WG. Furthermore, the document seems to be a candidate for an "experimental" RFC= ,=20 not an "informational" one. 2) What is the relationship of this to "draft-morton-ippm-rate-problem" and "draft-morton-ippm-twamp-rate" ? I believe that the former is a problem statement for the same problem, and the latter a somewhat different solution. My understanding of the problem is to find a way of measuring=20 "available bandwidth" / "delivery rate" / "path capacity" using TWAMP packe= t bursts. I would really like to agree on the problem statement first, and only afterwards decide on which of the two solutions we prefer. Perhaps we could convince the authors of the two documents to merge them=20 into a single proposal backed by the WG. 3) I disagree with the statement : The second measurement principle is referred to as self-induced congestion. According to this principle, in order to measure APC, TSC and UDP delivery rate, some trains MUST cause momentary congestion on the network path. In essence this means that some trains MUST be sent at a higher rate than what is available on the network path. The idea of many burst proposals is to challenge the weakest-link buffer and to observe the subsequent increase in inter-packet delay BEFORE causing= congestion (unless the word "congestion" here is being used in a some extended sense, in which case this should be specified). 4) There are a few specific technical things I don't like about the draft i= n question. For example, I don't like the use of flags + values when a value definition= would suffice. I don't like the complex mechanism of defining a "Desired Reverse Packet In= terval", and "Desired Reverse Padding Length" . It is also not clear to me which features work for "TWAMP light" or if all of this requires the control protocol. However, these are minor issues as compared with the previous ones. Y(J)S -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: Thursday, March 29, 2012 12:29 To: IETF IPPM WG Subject: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt IPPM Group, This starts a WGLC for the draft: TWAMP Value-Added Octets draft-ietf-ippm-twamp-value-added-octets-01.txt Please review the draft and raise any issues by Monday, April 16, 2012, 8:00 UTC. Matt & Henk --=20 ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.xs4all.nl/~henku Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project= ) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From steve.baillargeon@videotron.ca Sun Apr 1 14:25:20 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C81D21F8923 for ; Sun, 1 Apr 2012 14:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG+ew87g2JRL for ; Sun, 1 Apr 2012 14:25:18 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9F03E21F8924 for ; Sun, 1 Apr 2012 14:25:18 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4Cq0z30M1qz3uOceQliK2g)" Received: from vl-mo-mpf02.ip.videotron.ca ([10.23.37.51]) by VL-VM-MR001.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0M1T000UNKU5NY00@VL-VM-MR001.ip.videotron.ca> for ippm@ietf.org; Sun, 01 Apr 2012 17:25:17 -0400 (EDT) Received: from videotron.ca (unknown [10.23.32.116]) by vl-mo-mpf02.ip.videotron.ca (Postfix) with ESMTP id A188772882D; Sun, 01 Apr 2012 17:25:17 -0400 (EDT) Received: from [10.23.37.1] (Forwarded-For: 10.23.117.21) by vl-vm-mm006.ip.videotron.ca (mshttpd); Sun, 01 Apr 2012 17:25:17 -0400 From: steve.baillargeon@videotron.ca To: Henk Uijterwaal Message-id: <77f0873031d71.4f788f7d@videotron.ca> Date: Sun, 01 Apr 2012 17:25:17 -0400 X-Mailer: Oracle Communications Messenger Express 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <07F7D7DED63154409F13298786A2ADC90433200E@EXRAD5.ad.rad.co.il> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <07F7D7DED63154409F13298786A2ADC90433200E@EXRAD5.ad.rad.co.il> Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 21:25:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_4Cq0z30M1qz3uOceQliK2g) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Henk = 1) We have discussed this aspect last year and have agreed Informationa= l is the best fit=2E The definitional of an Informational RFC (as define= d in RFC 4677) is a specification that is created outside the IETF but i= s referenced by IETF documents or a precursor for work being done by IET= F Working Groups=2E = 2) There is no relationship=2E This is for information only as a precur= sor to the problem statement=2E We will be happy to work on the problem= statement if the WG thinks it is beneficial=2E = 3) Yes the word congestion is used in a broad context here=2E In our wo= rking prototype=2C the accuracy of the results depends on having the int= er-packet interval running near or =93lower=94 the available capacity=2E= This is why the statement is there=2E I suggest debating a different p= hrasing in the problem statement=2E = 4) This draft mainly reflects the working prototype demonstrated in Pr= ague in 2011=2E The prototype should work with any existing TWAMP modes = including TWAMP light but it does not define a new TWAMP mode=2E We assu= me the work on the standard extension to the TWAMP protocol will be star= ted after the work on the problem statement is completed=2E Is this corr= ect=3F = Regards Steve Baillargeon = ----- Original Message ----- From=3A Yaakov Stein =3Cyaakov=5Fs=40rad=2Ecom=3E Date=3A Sunday=2C April 1=2C 2012 9=3A01 am Subject=3A Re=3A =5Bippm=5D WGLC for draft-ietf-ippm-twamp-value-added-o= ctets-01=2Etxt To=3A Henk Uijterwaal =3Chenk=40uijterwaal=2Enl=3E=2C IETF IPPM WG =3Cip= pm=40ietf=2Eorg=3E =3E Henk=2C =3E = =3E I object to progressing the draft in question at the present time=2C= =3E for at least 4 reasons=2E =3E = =3E 1) The new version clearly states =3A =3E This memo is the product of a working prototype=2E It = =3E does not =3E represent a consensus of the IETF community=2E The = =3E IETF community is =3E currently working on the problem statement and has = =3E not reached =3E consensus on the preferred method for measuring = =3E capacity metrics=2E =3E =2E=2E=2E =3E This memo describes the protocol used in the = =3E current working =3E prototype implementation of the Value-added octets = =3E feature in the =3E Ericsson lab=2E The prototype has been tested in real = =3E network environments=2E The conclusion from these = =3E tests is that the Value-added =3E octets feature is able to enable estimation of = =3E metrics such as =3E available path capacity in both the forward and = =3E reverse direction of =3E the network path=2E =3E = =3E This is the definition of an individual submission track document=2C= =3E not a document to be submitted to the IESG as a product of the = =3E IPPM WG=2E =3E Furthermore=2C the document seems to be a candidate for an = =3E =22experimental=22 RFC=2C = =3E not an =22informational=22 one=2E =3E = =3E 2) What is the relationship of this to =22draft-morton-ippm-rate- =3E problem=22and =22draft-morton-ippm-twamp-rate=22 =3F =3E I believe that the former is a problem statement for the same proble= m=2C =3E and the latter a somewhat different solution=2E =3E = =3E My understanding of the problem is to find a way of measuring = =3E =22available bandwidth=22 / =22delivery rate=22 / =22path capacity=22= using = =3E TWAMP packet bursts=2E =3E = =3E I would really like to agree on the problem statement first=2C =3E and only afterwards decide on which of the two solutions we prefer=2E= =3E Perhaps we could convince the authors of the two documents to = =3E merge them = =3E into a single proposal backed by the WG=2E =3E = =3E 3) I disagree with the statement =3A =3E The second measurement principle is referred to as = =3E self-induced =3E congestion=2E According to this principle=2C in order = =3E to measure APC=2C TSC =3E and UDP delivery rate=2C some trains MUST cause = =3E momentary congestion on =3E the network path=2E In essence this means that some = =3E trains MUST be sent =3E at a higher rate than what is available on the = =3E network path=2E =3E = =3E The idea of many burst proposals is to challenge the weakest- =3E link buffer =3E and to observe the subsequent increase in inter-packet delay = =3E BEFORE causing congestion =3E (unless the word =22congestion=22 here is being used in a some = =3E extended sense=2C =3E in which case this should be specified)=2E =3E = =3E 4) There are a few specific technical things I don=27t like about = =3E the draft in question=2E =3E For example=2C I don=27t like the use of flags + values when a value= = =3E definition would suffice=2E =3E I don=27t like the complex mechanism of defining a =22Desired = =3E Reverse Packet Interval=22=2C =3E and =22Desired Reverse Padding Length=22 =2E =3E It is also not clear to me which features work for =22TWAMP light=22= =3E or if all of this requires the control protocol=2E =3E = =3E However=2C these are minor issues as compared with the previous ones= =2E =3E = =3E Y(J)S =3E = =3E -----Original Message----- =3E From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf=2E= org=5D On = =3E Behalf Of Henk Uijterwaal =3E Sent=3A Thursday=2C March 29=2C 2012 12=3A29 =3E To=3A IETF IPPM WG =3E Subject=3A =5Bippm=5D WGLC for draft-ietf-ippm-twamp-value-added- =3E octets-01=2Etxt =3E = =3E IPPM Group=2C =3E = =3E This starts a WGLC for the draft=3A =3E = =3E TWAMP Value-Added Octets =3E draft-ietf-ippm-twamp-value-added-octets-01=2Etxt =3E = =3E Please review the draft and raise any issues by Monday=2C April = =3E 16=2C 2012=2C =3E 8=3A00 UTC=2E =3E = =3E Matt =26 Henk =3E = =3E -- = =3E ----------------------------------------------------------------- =3E ------------- =3E Henk = =3E Uijterwaal Email=3A henk(at)uijterwaal=2En= l =3E http=3A//www=2Exs4all=2Enl= /=7Ehenku =3E Phone=3A +31=2E6=2E5586174= 6 =3E ----------------------------------------------------------------- =3E ------------- =3E = =3E There appears to have been a collective retreat from reality = =3E that day=2E =3E (John Glanfield=2C on an engineerin= g project) =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E ippm mailing list =3E ippm=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm --Boundary_(ID_4Cq0z30M1qz3uOceQliK2g) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Content-disposition: inline =3C!--=5Bif gte mso 9=5D=3E=3Cxml=3E =3Cw=3AWordDocument=3E =3Cw=3AVi= ew=3ENormal=3C/w=3AView=3E =3Cw=3AZoom=3E0=3C/w=3AZoom=3E =3Cw=3APun= ctuationKerning/=3E =3Cw=3AValidateAgainstSchemas/=3E =3Cw=3ASaveIfX= MLInvalid=3Efalse=3C/w=3ASaveIfXMLInvalid=3E =3Cw=3AIgnoreMixedContent= =3Efalse=3C/w=3AIgnoreMixedContent=3E =3Cw=3AAlwaysShowPlaceholderText= =3Efalse=3C/w=3AAlwaysShowPlaceholderText=3E =3Cw=3ACompatibility=3E = =3Cw=3ABreakWrappedTables/=3E =3Cw=3ASnapToGridInCell/=3E =3Cw=3A= WrapTextWithPunct/=3E =3Cw=3AUseAsianBreakRules/=3E =3Cw=3ADontGro= wAutofit/=3E =3C/w=3ACompatibility=3E =3Cw=3ABrowserLevel=3EMicrosof= tInternetExplorer4=3C/w=3ABrowserLevel=3E =3C/w=3AWordDocument=3E =3C/x= ml=3E=3C!=5Bendif=5D--=3E=3C!--=5Bif gte mso 9=5D=3E=3Cxml=3E =3Cw=3ALa= tentStyles DefLockedState=3D=22false=22 LatentStyleCount=3D=22156=22=3E = =3C/w=3ALatentStyles=3E =3C/xml=3E=3C!=5Bendif=5D--=3E=3C!--=5Bif !mso=5D= =3E=3Cobject classid=3D=22clsid=3A38481807-CA0E-42D2-BF39-B33AF135CC4D=22= id=3Dieooui=3E=3C/object=3E =3Cstyle=3E st1=5C=3A*=7Bbehavior=3Aurl(=23= ieooui) =7D =3C/style=3E =3C!=5Bendif=5D--=3E=3C!--=5Bif gte mso 10=5D=3E= =3Cstyle=3E /* Style Definitions */ table=2EMsoNormalTable =7Bmso-st= yle-name=3A=22Table Normal=22=3B mso-tstyle-rowband-size=3A0=3B mso-ts= tyle-colband-size=3A0=3B mso-style-noshow=3Ayes=3B mso-style-parent=3A= =22=22=3B mso-padding-alt=3A0cm 5=2E4pt 0cm 5=2E4pt=3B mso-para-margin= =3A0cm=3B mso-para-margin-bottom=3A=2E0001pt=3B mso-pagination=3Awidow= -orphan=3B font-size=3A10=2E0pt=3B font-family=3A=22Times New Roman=22= =3B mso-ansi-language=3A=230400=3B mso-fareast-language=3A=230400=3B = mso-bidi-language=3A=230400=3B=7D =3C/style=3E =3C!=5Bendif=5D--=3E =3C= p class=3D=22MsoNormal=22=3EHi Henk=3Cbr=3E =3Cbr=3E 1) We have discusse= d this aspect last year and have agreed Informational is the best fit=2E= The definitional of an Informational RFC (as defined in RFC 4677) is a = specification that is created outside the IETF but is referenced by IETF= documents or a precursor for work being done by IETF Working Groups=2E=3C= br=3E =3Cbr=3E 2) There is no relationship=2E This is for information on= ly as a precursor to the problem statement=2E =3Cspan style=3D=22mso-spa= cerun=3Ayes=22=3E=26nbsp=3B=3C/span=3EWe will be happy to work on the pr= oblem statement if the WG thinks it is beneficial=2E=3C/p=3E =3Cp class= =3D=22MsoNormal=22=3E=3Cbr=3E 3) Yes the word congestion is used in a br= oad context here=2E In our working prototype=2C the accuracy of the resu= lts depends on having the inter-packet interval running near or =93lower= =94 the available capacity=2E =3Cspan style=3D=22mso-spacerun=3Ayes=22=3E= =26nbsp=3B=3C/span=3EThis is why the statement is there=2E I suggest deb= ating a different phrasing in the problem statement=2E=3C/p=3E =3Cp cla= ss=3D=22MsoNormal=22=3E=26nbsp=3B=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E= 4) This draft mainly reflects the working prototype demonstrated in Prag= ue in 2011=2E The prototype should work with any existing TWAMP modes in= cluding TWAMP light but it does not define a new TWAMP mode=2E We assume= the work on the standard extension to the TWAMP protocol will be starte= d after the work on the problem statement is completed=2E Is this correc= t=3F=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E=26nbsp=3B=3C/p=3E =3Cp cl= ass=3D=22MsoNormal=22=3ERegards=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E= Steve Baillargeon=3C/p=3E =3Cbr=3E=3Cbr=3E----- Original Message -----=3C= br=3EFrom=3A Yaakov Stein =26lt=3Byaakov=5Fs=40rad=2Ecom=26gt=3B=3Cbr=3E= Date=3A Sunday=2C April 1=2C 2012 9=3A01 am=3Cbr=3ESubject=3A Re=3A =5Bi= ppm=5D WGLC for draft-ietf-ippm-twamp-value-added-octets-01=2Etxt=3Cbr=3E= To=3A Henk Uijterwaal =26lt=3Bhenk=40uijterwaal=2Enl=26gt=3B=2C IETF IPP= M WG =26lt=3Bippm=40ietf=2Eorg=26gt=3B=3Cbr=3E=3Cbr=3E=26gt=3B Henk=2C=3C= br=3E=26gt=3B =3Cbr=3E=26gt=3B I object to progressing the draft in ques= tion at the present time=2C=3Cbr=3E=26gt=3B for at least 4 reasons=2E=3C= br=3E=26gt=3B =3Cbr=3E=26gt=3B 1) The new version clearly states =3A=3Cb= r=3E=26gt=3B =26nbsp=3B=26nbsp=3B This memo is the product of a working = prototype=2E It =3Cbr=3E=26gt=3B does not=3Cbr=3E=26gt=3B =26nbsp=3B=26n= bsp=3B represent a consensus of the IETF community=2E The =3Cbr=3E=26gt=3B= IETF community is=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B currently workin= g on the problem statement and has =3Cbr=3E=26gt=3B not reached=3Cbr=3E=26= gt=3B =26nbsp=3B=26nbsp=3B consensus on the preferred method for measuri= ng =3Cbr=3E=26gt=3B capacity metrics=2E=3Cbr=3E=26gt=3B =26nbsp=3B=26nbs= p=3B =2E=2E=2E=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B This memo describes = the protocol used in the =3Cbr=3E=26gt=3B current working=3Cbr=3E=26gt=3B= =26nbsp=3B=26nbsp=3B prototype implementation of the Value-added octets= =3Cbr=3E=26gt=3B feature in the=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B Er= icsson lab=2E The prototype has been tested in real =3Cbr=3E=26gt=3B net= work=26nbsp=3B=26nbsp=3B environments=2E The conclusion from these =3Cbr= =3E=26gt=3B tests is that the Value-added=3Cbr=3E=26gt=3B =26nbsp=3B=26n= bsp=3B octets feature is able to enable estimation of =3Cbr=3E=26gt=3B m= etrics such as=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B available path capac= ity in both the forward and =3Cbr=3E=26gt=3B reverse direction of=3Cbr=3E= =26gt=3B =26nbsp=3B=26nbsp=3B the network path=2E=3Cbr=3E=26gt=3B =3Cbr=3E= =26gt=3B This is the definition of an individual submission track docume= nt=2C=3Cbr=3E=26gt=3B not a document to be submitted to the IESG as a pr= oduct of the =3Cbr=3E=26gt=3B IPPM WG=2E=3Cbr=3E=26gt=3B Furthermore=2C = the document seems to be a candidate for an =3Cbr=3E=26gt=3B =22experime= ntal=22 RFC=2C =3Cbr=3E=26gt=3B not an =22informational=22 one=2E=3Cbr=3E= =26gt=3B =3Cbr=3E=26gt=3B 2) What is the relationship of this to =22draf= t-morton-ippm-rate-=3Cbr=3E=26gt=3B problem=22and =22draft-morton-ippm-t= wamp-rate=22 =3F=3Cbr=3E=26gt=3B I believe that the former is a problem = statement for the same problem=2C=3Cbr=3E=26gt=3B and the latter a somew= hat different solution=2E=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B My understand= ing of the problem is to find a way of measuring =3Cbr=3E=26gt=3B =22ava= ilable bandwidth=22 / =22delivery rate=22 / =22path capacity=22 using =3C= br=3E=26gt=3B TWAMP packet bursts=2E=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B I = would really like to agree on the problem statement first=2C=3Cbr=3E=26g= t=3B and only afterwards decide on which of the two solutions we prefer=2E= =3Cbr=3E=26gt=3B Perhaps we could convince the authors of the two docume= nts to =3Cbr=3E=26gt=3B merge them =3Cbr=3E=26gt=3B into a single propos= al backed by the WG=2E=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B 3) I disagree wi= th the statement =3A=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B The second mea= surement principle is referred to as =3Cbr=3E=26gt=3B self-induced=3Cbr=3E= =26gt=3B =26nbsp=3B=26nbsp=3B congestion=2E According to this principle=2C= in order =3Cbr=3E=26gt=3B to measure APC=2C TSC=3Cbr=3E=26gt=3B =26nbsp= =3B=26nbsp=3B and UDP delivery rate=2C some trains MUST cause =3Cbr=3E=26= gt=3B momentary congestion on=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B the n= etwork path=2E In essence this means that some =3Cbr=3E=26gt=3B trains M= UST be sent=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B at a higher rate than w= hat is available on the =3Cbr=3E=26gt=3B network path=2E=3Cbr=3E=26gt=3B= =3Cbr=3E=26gt=3B The idea of many burst proposals is to challenge the w= eakest-=3Cbr=3E=26gt=3B link buffer=3Cbr=3E=26gt=3B and to observe the s= ubsequent increase in inter-packet delay =3Cbr=3E=26gt=3B BEFORE causing= congestion=3Cbr=3E=26gt=3B (unless the word =22congestion=22 here is be= ing used in a some =3Cbr=3E=26gt=3B extended sense=2C=3Cbr=3E=26gt=3B in= which case this should be specified)=2E=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B= 4) There are a few specific technical things I don=27t like about =3Cbr= =3E=26gt=3B the draft in question=2E=3Cbr=3E=26gt=3B For example=2C I do= n=27t like the use of flags + values when a value =3Cbr=3E=26gt=3B defin= ition would suffice=2E=3Cbr=3E=26gt=3B I don=27t like the complex mechan= ism of defining a =22Desired =3Cbr=3E=26gt=3B Reverse Packet Interval=22= =2C=3Cbr=3E=26gt=3B and =22Desired Reverse Padding Length=22 =2E=3Cbr=3E= =26gt=3B It is also not clear to me which features work for =22TWAMP lig= ht=22=3Cbr=3E=26gt=3B or if all of this requires the control protocol=2E= =3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B However=2C these are minor issues as c= ompared with the previous ones=2E=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B Y(J)S= =3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B -----Original Message-----=3Cbr=3E=26g= t=3B From=3A ippm-bounces=40ietf=2Eorg =5Bmailto=3Aippm-bounces=40ietf=2E= org=5D On =3Cbr=3E=26gt=3B Behalf Of Henk Uijterwaal=3Cbr=3E=26gt=3B Sen= t=3A Thursday=2C March 29=2C 2012 12=3A29=3Cbr=3E=26gt=3B To=3A IETF IPP= M WG=3Cbr=3E=26gt=3B Subject=3A =5Bippm=5D WGLC for draft-ietf-ippm-twam= p-value-added-=3Cbr=3E=26gt=3B octets-01=2Etxt=3Cbr=3E=26gt=3B =3Cbr=3E=26= gt=3B IPPM Group=2C=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B This starts a WGLC = for the draft=3A=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B =26nbsp=3B TWAMP Value= -Added Octets=3Cbr=3E=26gt=3B =26nbsp=3B draft-ietf-ippm-twamp-value-add= ed-octets-01=2Etxt=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B Please review the dr= aft and raise any issues by Monday=2C April =3Cbr=3E=26gt=3B 16=2C 2012=2C= =3Cbr=3E=26gt=3B 8=3A00 UTC=2E=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B Matt =26= amp=3B Henk=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B -- =3Cbr=3E=26gt=3B -------= ----------------------------------------------------------=3Cbr=3E=26gt=3B= -------------=3Cbr=3E=26gt=3B Henk =3Cbr=3E=26gt=3B Uijterwaal=26nbsp=3B= =26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26= nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb= sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp= =3B=26nbsp=3B=26nbsp=3B=26nbsp=3B Email=3A henk(at)uijterwaal=2Enl=3Cbr=3E= =26gt=3B =26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26= nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb= sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp= =3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B= =26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26= nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B http=3A//www=2E= xs4all=2Enl/=7Ehenku=3Cbr=3E=26gt=3B =26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb= sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp= =3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B= =26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26= nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb= sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp= =3B=26nbsp=3B Phone=3A +31=2E6=2E55861746=3Cbr=3E=26gt=3B --------------= ---------------------------------------------------=3Cbr=3E=26gt=3B ----= ---------=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B There appears to have been a = collective retreat from reality =3Cbr=3E=26gt=3B that day=2E=3Cbr=3E=26g= t=3B =26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp= =3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B= =26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26= nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb= sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B (John Glanfield=2C on an engineering= project)=3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B =3Cbr=3E=26gt=3B =5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3Cbr=3E=26gt=3B= ippm mailing list=3Cbr=3E=26gt=3B ippm=40ietf=2Eorg=3Cbr=3E=26gt=3B htt= ps=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm=3Cbr=3E=26gt=3B =5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3Cbr=3E=26gt=3B= ippm mailing list=3Cbr=3E=26gt=3B ippm=40ietf=2Eorg=3Cbr=3E=26gt=3B htt= ps=3A//www=2Eietf=2Eorg/mailman/listinfo/ippm --Boundary_(ID_4Cq0z30M1qz3uOceQliK2g)-- From henk@uijterwaal.nl Mon Apr 2 06:53:09 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD40221F8567 for ; Mon, 2 Apr 2012 06:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aai5uXYJxiG for ; Mon, 2 Apr 2012 06:53:09 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id C436521F854D for ; Mon, 2 Apr 2012 06:53:08 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id q32DqVdf049185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 15:52:36 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F79AF1F.6030705@uijterwaal.nl> Date: Mon, 02 Apr 2012 15:52:31 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Yaakov Stein References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <07F7D7DED63154409F13298786A2ADC90433200E@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC90433200E@EXRAD5.ad.rad.co.il> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:53:09 -0000 Yaakov, others, > I object to progressing the draft in question at the present time, > for at least 4 reasons. > > 1) The new version clearly states : > This memo is the product of a working prototype. It does not > represent a consensus of the IETF community. The IETF community is > currently working on the problem statement and has not reached > consensus on the preferred method for measuring capacity metrics. > ... > This memo describes the protocol used in the current working > prototype implementation of the Value-added octets feature in the > Ericsson lab. The prototype has been tested in real network > environments. The conclusion from these tests is that the Value-added > octets feature is able to enable estimation of metrics such as > available path capacity in both the forward and reverse direction of > the network path. > > This is the definition of an individual submission track document, > not a document to be submitted to the IESG as a product of the IPPM WG. I understand the problem. The reason I asked for this to make it a WG document is that I think the WG should review this document. The document describes a problem plus a prototype implementation of a solution. I think it is good to have a good description of the prototype, that has been reviewed by the entire WG for clarity/completeness/etc of the prototype, even if the problem we ultimately have to solve is different or we may decide on a completely different approach towards solving the problem. So, what I hope the first paragraph ("This memo is ... metrics") says is "somebody in the WG did an experiment, the WG saw that it solved something close to an existing problem, the write-up of the experiment is clear"). If it doesn't then I've done something wrong :-) > Furthermore, the document seems to be a candidate for an "experimental" RFC, > not an "informational" one. I think I agree with Steve that "informational" is the best fit, but reading http://www.ietf.org/u/ietfchair/info-exp.html suggests that "experimental" might be a good choice either. I don't think this matters too much at this stage of the discussion though. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From acmorton@att.com Mon Apr 2 07:09:14 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272E721F856F for ; Mon, 2 Apr 2012 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyYlWcSS1PG2 for ; Mon, 2 Apr 2012 07:09:13 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 416F321F856C for ; Mon, 2 Apr 2012 07:09:13 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 803b97f4.0.245048.00-432.657907.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 02 Apr 2012 14:09:13 +0000 (UTC) X-MXL-Hash: 4f79b3096155ee18-71ff75d14ca6e8bba4ca28d0cb9603f41e7188dd Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q32E9C1V017736 for ; Mon, 2 Apr 2012 10:09:12 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q32E95VQ017696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Apr 2012 10:09:08 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Mon, 2 Apr 2012 10:08:43 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q32E8gHh001644 for ; Mon, 2 Apr 2012 10:08:42 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q32E8YEo001358 for ; Mon, 2 Apr 2012 10:08:36 -0400 Message-Id: <201204021408.q32E8YEo001358@alpd052.aldc.att.com> Received: from acmt.att.com (ds135-16-251-225.dhcps.ugn.att.com[135.16.251.225](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120402140541gw1004orn9e>; Mon, 2 Apr 2012 14:05:42 +0000 X-Originating-IP: [135.16.251.225] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Apr 2012 10:09:09 -0400 To: Henk Uijterwaal , IETF IPPM WG From: Al Morton In-Reply-To: <4F74397D.4050902@uijterwaal.nl> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=b3MHB_GQ4iAA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=_9] X-AnalysisOut: [jaCbEL3L1r5C-Vi3gA:9 a=v_X1rLt1NJE4sOcI6YAA:7 a=CjuIK1q_8u] X-AnalysisOut: [gA:10] Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:09:14 -0000 At 06:29 AM 3/29/2012, Henk Uijterwaal wrote: >... > TWAMP Value-Added Octets > draft-ietf-ippm-twamp-value-added-octets-01.txt > >Please review the draft and raise any issues by Monday, April 16, 2012, >8:00 UTC. Hi Henk and Matt, When I read: At 05:54 AM 1/24/2012, Henk Uijterwaal wrote: >The authors of draft-baillargeon-ippm-twamp-value-added-octets-02.txt >have asked for this document to be published as an informational RFC, >by the WG, with the goal of documenting the work done by them. I wasn't happy with the informational-only approach, but I figured that it was a decent compromise if the authors published the Ericsson IPR-encumbered work by itself, and then let the rest of the WG proceed with defining the problem and deciding on a standards track solution. No one else objected either, but then: - The authors published -value-added-octets with a WG document filename (which confuses things, it has not represented WG consensus at any stage) - The authors modified the draft to adopt the function of asymmetrical packet size test capability and possibly other functions identified in the problem statement draft (and in my talk at IETF-80 in Prague). - The authors now claim to have simplified their protocol, after discounting the WG's comments on the complexity of their approach for about a year. Adding features which they didn't suggest/invent, and reversing their position on protocol complexity means that the current draft does not meet the goal of "documenting work done by them", and instead lands in a middle-ground of "partly addresses WG comments and the problem statement". I don't think that's fair or useful. So, I still have no objection if the WG documents the individual draft-baillargeon-ippm-twamp-value-added-octets-02.txt (not -03 or other) with *Historic* status prepared on the way to a WG consensus solution, IF it means the WG can close the unproductive discussion on this draft. To me, the authors have circumvented the WG process with their current text, waving the "this is how the prototype works now" flag. It takes benefit from contributions under Note Well, and includes ideas of others contributed to the IETF IPPM WG which are not theirs. I object to publishing the current text, and I note that a new IPR disclosure is likely needed for it. I also appreciate Yaakov's comment attached below, that the Introduction's disclaimer describes an RFC Editor Stream submission, which is yet another way that authors publish alternative ideas outside the IETF Stream and remains a viable option for them. regards, Al At 08:31 AM 4/1/2012, Yaakov Stein wrote: >1) The new version clearly states : > This memo is the product of a working prototype. It does not > represent a consensus of the IETF community. The IETF community is > currently working on the problem statement and has not reached > consensus on the preferred method for measuring capacity metrics. > ... > This memo describes the protocol used in the current working > prototype implementation of the Value-added octets feature in the > Ericsson lab. The prototype has been tested in real network > environments. The conclusion from these tests is that the Value-added > octets feature is able to enable estimation of metrics such as > available path capacity in both the forward and reverse direction of > the network path. > >This is the definition of an individual submission track document, >not a document to be submitted to the IESG as a product of the IPPM WG. ... From steve.baillargeon@ericsson.com Mon Apr 2 09:04:22 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E0E21F861A for ; Mon, 2 Apr 2012 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dh37ThnFc36 for ; Mon, 2 Apr 2012 09:04:22 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E771B21F8619 for ; Mon, 2 Apr 2012 09:04:21 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q32G4Cvx002343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Apr 2012 11:04:19 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 2 Apr 2012 12:04:17 -0400 From: Steve Baillargeon To: Al Morton , Henk Uijterwaal , IETF IPPM WG Date: Mon, 2 Apr 2012 12:04:14 -0400 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt Thread-Index: Ac0Q2ji9zm3VhUfBQ0+EWy/hCkVRtgADhUKg Message-ID: <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> In-Reply-To: <201204021408.q32E8YEo001358@alpd052.aldc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:04:22 -0000 Hi =20 >>>The authors published -value-added-octets with a WG document filename(wh= ich confuses things, it has not represented WG consensus at any stage) My take on it is that it is OK for an Informational RFC: a subset did the w= ork, the entire WG was asked to review the write-up. >>>The authors modified the draft to adopt the function of asymmetrical pac= ket size test capability and possibly other functions identified in the pro= blem statement draft. The only field we added in 03 is Desired Reverse Padding Length. We showed = a prototype @ IETF-80, people came up with suggestions, we showed that our = prototype could be extended. >>>The authors now claim to have simplified their protocol, after discounti= ng the WG's comments on the complexity of their approach for about a year. The only field we removed in 03 is the Sender Discriminator since it is not= specifically related to capacity measurements. Sender Discriminator looked= like a good idea at the time @ IETF80 but then wasn't used during our demo= and is now dropped. Regards Steve B= From Ruediger.Geib@telekom.de Tue Apr 3 00:50:29 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B97B21F8623 for ; Tue, 3 Apr 2012 00:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwV3oYba-LQx for ; Tue, 3 Apr 2012 00:50:29 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id A454221F854E for ; Tue, 3 Apr 2012 00:50:28 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 03 Apr 2012 09:50:24 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 3 Apr 2012 09:50:22 +0200 From: To: , Date: Tue, 3 Apr 2012 09:50:20 +0200 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt Thread-Index: Ac0Q2ji9zm3VhUfBQ0+EWy/hCkVRtgADhUKgAB8SYiA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA4C5@HE111648.emea1.cds.t-internal.com> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 07:50:29 -0000 Chairs, could you clarify your idea of the process making value-added-octets an inf= ormational? I understand Al's position. I myself am not clear whether Al's view is foll= owing the process rules (and I don't know what exactly the process is). Please le= t me hear your version. Al wrote Adding features which they didn't suggest/invent, and reversing their position on protocol complexity means that the current draft does not mee= t the goal of "documenting work done by them", and instead lands in a middle-ground of "partly addresses WG comments and the problem statement"= . I don't think that's fair or useful. So, I still have no objection if the WG documents the individual draft-baillargeon-ippm-twamp-value-added-octets-02.txt (not -03 or other) with *Historic* status prepared on the way to a WG consensus solution, IF it means the WG can close the unproductive discussion on this draft. To me, the authors have circumvented the WG process with their current text, waving the "this is how the prototype works now" flag. It takes benefit from contributions under Note Well, and includes ideas of others contributed to the IETF IPPM WG which are not theirs. I object to publishing the current text, and I note that a new IPR disclosure is likely needed for it. As there is an IPR issue and the WG compromise seems to have been to publis= h value-added-octets with functionality as demonstrated during IETF 80, I favour sticking to tha= t. I agree with Al and Yaakov that it is not appropriate incorporate features = discussed under note well into an IPR protected solution. I don't think it is apropri= ate to continue to change technical features described in this publication before it's IETF st= amped as informational . It is not relevant whether these changes are small. Apart from that the aut= hors refuse to refer to other IETF work while they seem to integrate functionality resulting from t= his work into their prototype. If that's true (and it again doesn't matter whether changes are = big or small), it's not agreeable. Regards, Ruediger From henk@uijterwaal.nl Tue Apr 3 02:22:08 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167D521F8514 for ; Tue, 3 Apr 2012 02:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94kzU1C18eUR for ; Tue, 3 Apr 2012 02:22:07 -0700 (PDT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by ietfa.amsl.com (Postfix) with ESMTP id D937B21F8497 for ; Tue, 3 Apr 2012 02:22:06 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id q339LTlv082581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 11:21:30 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F7AC118.1060501@uijterwaal.nl> Date: Tue, 03 Apr 2012 11:21:28 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA4C5@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA4C5@HE111648.emea1.cds.t-internal.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:22:08 -0000 Ruediger, > could you clarify your idea of the process making value-added-octets an informational? As I said before, I think it is good to have a document describing the prototype developped by the authors, that has been reviewed by the entire WG for clarity and completeness. We do not agree on the problem that there is to be solved, we don't agree either if this is the best solution, but I believe we agree that the prototype solves something close to the actual problem. That suggests, at least to me, to make it an informational document that can be properly referenced in the future. Note that I have specifically never asked for consensus about the problem statement or the solution chosen, just if the description is clear. > I agree with Al and Yaakov that it is not appropriate incorporate features discussed > under note well into an IPR protected solution. I don't think it is apropriate to continue to > change technical features described in this publication before it's IETF stamped as informational . > It is not relevant whether these changes are small. Apart from that the authors refuse to refer to > other IETF work while they seem to integrate functionality resulting from this work into their > prototype. If that's true (and it again doesn't matter whether changes are big or small), it's > not agreeable. I'm not sure if I understand this. There is the prototype (with IPR), there are suggestions made by others (under the note-well). The latter have been incorporated into the prototype, but, as far as I understand, that doesn't put them under the IPR. In other words, we can still use those suggestions in another solution when we come to that. Or am I missing something here? Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From Ruediger.Geib@telekom.de Tue Apr 3 03:09:12 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F621F8712 for ; Tue, 3 Apr 2012 03:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mya004cH34YA for ; Tue, 3 Apr 2012 03:09:12 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id CE1CA21F86F8 for ; Tue, 3 Apr 2012 03:09:11 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 03 Apr 2012 12:09:09 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 3 Apr 2012 12:09:09 +0200 From: To: Date: Tue, 3 Apr 2012 12:09:08 +0200 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt Thread-Index: Ac0Re0SyKxuic/kpQj6GgeXxenIc/QAA/XTg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA7E4@HE111648.emea1.cds.t-internal.com> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA4C5@HE111648.emea1.cds.t-internal.com> <4F7AC118.1060501@uijterwaal.nl> In-Reply-To: <4F7AC118.1060501@uijterwaal.nl> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 10:09:13 -0000 Henk, thanks, that's what you've said so far. My question is: - Al says, agreement was to make ID -value-added-octets-02 an informational, and Al's interpretation is "as was written". - now it is a WG draft and it continues to change. Is that appropriate from your point of view? Reading your reply, I don't understand whether you've clearly answered this. I don't see a need for a fast reply, if you need time to think about it. My impression is, that leaving that open may block the standardisation progress on the technical issues behind that. The issue I see is, if we continue to work on the problem and possible solutions, the draft-documentation and functionality of the prototype may continue to be adapted as well. The question then is, what's the purpose of a second standards track document, if the very same solutions may be found in the informational? I think, that's not what the WG has agreed to do. Of course the prototype may be enhanced by features, standard or proprietar= y, after -value-added-octets has been published as informational. Regards, Ruediger -----Original Message----- From: Henk Uijterwaal [mailto:henk@uijterwaal.nl] Sent: Tuesday, April 03, 2012 11:21 AM To: Geib, R=FCdiger Cc: matt@internet2.edu; ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.tx= t Ruediger, > could you clarify your idea of the process making value-added-octets an i= nformational? As I said before, I think it is good to have a document describing the prot= otype developped by the authors, that has been reviewed by the entire WG for clar= ity and completeness. We do not agree on the problem that there is to be solve= d, we don't agree either if this is the best solution, but I believe we agree tha= t the prototype solves something close to the actual problem. That suggests, at = least to me, to make it an informational document that can be properly referenced= in the future. Note that I have specifically never asked for consensus about = the problem statement or the solution chosen, just if the description is clear. > I agree with Al and Yaakov that it is not appropriate incorporate feature= s discussed > under note well into an IPR protected solution. I don't think it is aprop= riate to continue to > change technical features described in this publication before it's IETF = stamped as informational . > It is not relevant whether these changes are small. Apart from that the a= uthors refuse to refer to > other IETF work while they seem to integrate functionality resulting from= this work into their > prototype. If that's true (and it again doesn't matter whether changes ar= e big or small), it's > not agreeable. I'm not sure if I understand this. There is the prototype (with IPR), ther= e are suggestions made by others (under the note-well). The latter have been incorporated into the prototype, but, as far as I understand, that doesn't put them under the IPR. In other words, we can still use those suggestions in another solution when we come to that. Or am I missing something here? Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project= ) From steve.baillargeon@ericsson.com Tue Apr 3 03:22:06 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5F721F8535 for ; Tue, 3 Apr 2012 03:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FGv9oGS5ilL for ; Tue, 3 Apr 2012 03:22:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC2221F852B for ; Tue, 3 Apr 2012 03:22:05 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q33AM2aP028405; Tue, 3 Apr 2012 05:22:04 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 3 Apr 2012 06:22:02 -0400 From: Steve Baillargeon To: "Ruediger.Geib@telekom.de" , "henk@uijterwaal.nl" Date: Tue, 3 Apr 2012 06:22:00 -0400 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt Thread-Index: Ac0Re0SyKxuic/kpQj6GgeXxenIc/QAA/XTgAAC5XDA= Message-ID: <4383945B8C24AA4FBC33555BB7B829EF178ACB3008@EUSAACMS0701.eamcs.ericsson.se> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA4C5@HE111648.emea1.cds.t-internal.com> <4F7AC118.1060501@uijterwaal.nl> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA7E4@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA7E4@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "matt@internet2.edu" , "ippm@ietf.org" Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 10:22:06 -0000 Hi Henk is correct. The only new field, Desire Reverse Padding Length is not covered by the IPR= . We were inspired from the field "Padding Length" that is already defined in= the OWAMP spec dated Sept 2006. We are open to remove it. -Steve =20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Rue= diger.Geib@telekom.de Sent: April-03-12 6:09 AM To: henk@uijterwaal.nl Cc: matt@internet2.edu; ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.tx= t Henk, thanks, that's what you've said so far. My question is: - Al says, agreement was to make ID -value-added-octets-02 an informational, and Al's interpretation is "as was written". - now it is a WG draft and it continues to change. Is that appropriate from your point of view? Reading your reply, I don't un= derstand whether you've clearly answered this. I don't see a need for a fas= t reply, if you need time to think about it. My impression is, that leaving= that open may block the standardisation progress on the technical issues b= ehind that. The issue I see is, if we continue to work on the problem and possible solu= tions, the draft-documentation and functionality of the prototype may conti= nue to be adapted as well. The question then is, what's the purpose of a se= cond standards track document, if the very same solutions may be found in t= he informational? I think, that's not what the WG has agreed to do. Of course the prototype may be enhanced by features, standard or proprietar= y, after -value-added-octets has been published as informational. Regards, Ruediger -----Original Message----- From: Henk Uijterwaal [mailto:henk@uijterwaal.nl] Sent: Tuesday, April 03, 2012 11:21 AM To: Geib, R=FCdiger Cc: matt@internet2.edu; ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.tx= t Ruediger, > could you clarify your idea of the process making value-added-octets an i= nformational? As I said before, I think it is good to have a document describing the prot= otype developped by the authors, that has been reviewed by the entire WG fo= r clarity and completeness. We do not agree on the problem that there is t= o be solved, we don't agree either if this is the best solution, but I beli= eve we agree that the prototype solves something close to the actual proble= m. That suggests, at least to me, to make it an informational document tha= t can be properly referenced in the future. Note that I have specifically = never asked for consensus about the problem statement or the solution chose= n, just if the description is clear. > I agree with Al and Yaakov that it is not appropriate incorporate=20 > features discussed under note well into an IPR protected solution. I=20 > don't think it is apropriate to continue to change technical features des= cribed in this publication before it's IETF stamped as informational . > It is not relevant whether these changes are small. Apart from that=20 > the authors refuse to refer to other IETF work while they seem to=20 > integrate functionality resulting from this work into their prototype.=20 > If that's true (and it again doesn't matter whether changes are big or sm= all), it's not agreeable. I'm not sure if I understand this. There is the prototype (with IPR), ther= e are suggestions made by others (under the note-well). The latter have bee= n incorporated into the prototype, but, as far as I understand, that doesn'= t put them under the IPR. In other words, we can still use those suggestio= ns in another solution when we come to that. Or am I missing something her= e? Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project= ) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From wes@mti-systems.com Tue Apr 3 08:03:04 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8927611E80B5 for ; Tue, 3 Apr 2012 08:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WGM3XEhdkxC for ; Tue, 3 Apr 2012 08:03:03 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 877EA11E80A0 for ; Tue, 3 Apr 2012 08:03:03 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q33F31U0023849 for ; Tue, 3 Apr 2012 11:03:02 -0400 Authentication-Results: cm-omr5 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.47.149.240] ([107.47.149.240:22633] helo=[192.168.43.65]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B5/4C-13999-2211B7F4; Tue, 03 Apr 2012 11:03:01 -0400 Message-ID: <4F7B1114.6080603@mti-systems.com> Date: Tue, 03 Apr 2012 11:02:44 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Steve Baillargeon References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Al Morton , IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:03:04 -0000 On 4/2/2012 12:04 PM, Steve Baillargeon wrote: > Hi > >>>> The authors published -value-added-octets with a WG document filename(which confuses things, it has not represented WG consensus at any stage) > > My take on it is that it is OK for an Informational RFC: a subset did the work, the entire WG was asked to review the write-up. > In similar cases, the document title (not to be confused with the filename) has clearly specified whose work it reflects. For instance, the document title is currently: "TWAMP Value-Added Octets" it could be something like: "Ericsson's TWAMP Value-Added Octets" I think that would be more clear for the record, rather than messing with the filename, which disappears from view once it's published as an RFC. >>>> The authors modified the draft to adopt the function of asymmetrical packet size test capability and possibly other functions identified in the problem statement draft. > > The only field we added in 03 is Desired Reverse Padding Length. We showed a prototype @ IETF-80, people came up with suggestions, we showed that our prototype could be extended. > >>>> The authors now claim to have simplified their protocol, after discounting the WG's comments on the complexity of their approach for about a year. > > The only field we removed in 03 is the Sender Discriminator since it is not specifically related to capacity measurements. Sender Discriminator looked like a good idea at the time @ IETF80 but then wasn't used during our demo and is now dropped. To address the comments about confusion as to which parts reflect the pre-WG activity, and which parts have been incorporated after IPPM WG feedback, it might make sense to just have a small bit of text in section 1 to say that it started as an Ericsson project, but currently incorporates some feedback from the IPPM working group. This would, I think, enhance the paragraph currently right before Section 1.1. You might list the things that reflect that feedback (e.g. the desired reverse padding length and removal of sender discriminator) an an appendix or something, if you want to be ultra-clear. -- Wes Eddy MTI Systems From acmorton@att.com Tue Apr 3 08:36:55 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BD821F845F for ; Tue, 3 Apr 2012 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT01LQFdqrUG for ; Tue, 3 Apr 2012 08:36:54 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4578421F8582 for ; Tue, 3 Apr 2012 08:36:44 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id b091b7f4.0.726279.00-473.2012182.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 03 Apr 2012 15:36:44 +0000 (UTC) X-MXL-Hash: 4f7b190c76f1f551-737238ed5e88317f9ecfb0b5da40efa312b0b474 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q33Fah29023789 for ; Tue, 3 Apr 2012 11:36:43 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q33Fac1Q023688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Apr 2012 11:36:38 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 3 Apr 2012 11:36:23 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q33FaN7q023559 for ; Tue, 3 Apr 2012 11:36:23 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q33FaI4s023412 for ; Tue, 3 Apr 2012 11:36:18 -0400 Message-Id: <201204031536.q33FaI4s023412@alpd052.aldc.att.com> Received: from acmt.att.com (ds135-16-251-225.dhcps.ugn.att.com[135.16.251.225](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120403153325gw1004orqee>; Tue, 3 Apr 2012 15:33:26 +0000 X-Originating-IP: [135.16.251.225] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Apr 2012 11:37:26 -0400 To: Wesley Eddy , Steve Baillargeon From: Al Morton In-Reply-To: <4F7B1114.6080603@mti-systems.com> References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se> <4F7B1114.6080603@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=b3MHB_GQ4iAA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=72] X-AnalysisOut: [wRlKAZfrG-vk3xMisA:9 a=gwvkBpJizD_J-EtwrxcA:7 a=CjuIK1q_8u] X-AnalysisOut: [gA:10 a=bRLDSXzgruogFMFv:21 a=PfLzAtYmP6lD2Bz8:21] Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:36:55 -0000 I agree that the title change helps to clarify the situation, but I also accept Steve's offer to remove the non-Ericsson idea from the text, specifically the "Padding Length" feature. (The single sentence or Appendix within the document would contradict the title, and again cause confusion.) regards, Al At 11:02 AM 4/3/2012, Wesley Eddy wrote: >On 4/2/2012 12:04 PM, Steve Baillargeon wrote: > > Hi > > > >>>> The authors published -value-added-octets with a WG document > filename(which confuses things, it has not represented WG consensus > at any stage) > > > > My take on it is that it is OK for an Informational RFC: a subset > did the work, the entire WG was asked to review the write-up. > > > > >In similar cases, the document title (not to be confused with >the filename) has clearly specified whose work it reflects. >For instance, the document title is currently: >"TWAMP Value-Added Octets" >it could be something like: >"Ericsson's TWAMP Value-Added Octets" > >I think that would be more clear for the record, rather than >messing with the filename, which disappears from view once it's >published as an RFC. > > > >>>> The authors modified the draft to adopt the function of > asymmetrical packet size test capability and possibly other > functions identified in the problem statement draft. > > > > The only field we added in 03 is Desired Reverse Padding Length. > We showed a prototype @ IETF-80, people came up with suggestions, > we showed that our prototype could be extended. > > > >>>> The authors now claim to have simplified their protocol, after > discounting the WG's comments on the complexity of their approach > for about a year. > > > > The only field we removed in 03 is the Sender Discriminator since > it is not specifically related to capacity measurements. Sender > Discriminator looked like a good idea at the time @ IETF80 but then > wasn't used during our demo and is now dropped. > > >To address the comments about confusion as to which parts >reflect the pre-WG activity, and which parts have been >incorporated after IPPM WG feedback, it might make sense >to just have a small bit of text in section 1 to say that >it started as an Ericsson project, but currently incorporates >some feedback from the IPPM working group. This would, I >think, enhance the paragraph currently right before Section 1.1. > >You might list the things that reflect that feedback (e.g. the >desired reverse padding length and removal of sender >discriminator) an an appendix or something, if you want to be >ultra-clear. > >-- >Wes Eddy >MTI Systems From Ruediger.Geib@telekom.de Wed Apr 4 00:25:51 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0CD21F86EE for ; Wed, 4 Apr 2012 00:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktsyIPcHJAP9 for ; Wed, 4 Apr 2012 00:25:51 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id B801B21F86DE for ; Wed, 4 Apr 2012 00:25:50 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 04 Apr 2012 09:25:48 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 4 Apr 2012 09:25:48 +0200 From: To: , Date: Wed, 4 Apr 2012 09:25:47 +0200 Thread-Topic: draft-cisco-sla-protocol Thread-Index: Ac0RlhfFGPHV/SBRQI26XrtwSDOo5AAnMXAg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> In-Reply-To: <201204031233.q33CXjX6026537@alpd052.aldc.att.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:25:51 -0000 Henk, Matt, I support work on draft-cisco-sla-protocol by the IPPM WG. A good next step= would be to discuss how the draft can make progress: - work on this draft within the IPPM WG (or another one)? - maintain it as Informational (in which case it should be published after = a brief review)? - if published as Informational - do we think it preceeds TWAMP or do we wa= nt or need a new Standards Track problem statement and solution draft? Regards, Ruediger From internet-drafts@ietf.org Wed Apr 4 11:29:11 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623A421F8779; Wed, 4 Apr 2012 11:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLzYJHHdP7VJ; Wed, 4 Apr 2012 11:29:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FB221F876D; Wed, 4 Apr 2012 11:29:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120404182910.17921.23413.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2012 11:29:10 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-value-added-octets-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 18:29:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group = of the IETF. Title : Ericsson TWAMP Value-Added Octets Author(s) : Steve Baillargeon Christofer Flinta Andreas Johnsson Svante Ekelin Filename : draft-ietf-ippm-twamp-value-added-octets-02.txt Pages : 17 Date : 2012-04-04 This memo describes an extension to the TWAMP test protocol for identifying and managing packet trains, which enables measuring capacity metrics like the available path capacity, tight section capacity and UDP delivery rate in the forward and reverse path directions. This memo contains the description of a working prototype. It does not represent a consensus of the IETF community. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for measuring capacity metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octet= s-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octets= -02.txt From steve.baillargeon@ericsson.com Wed Apr 4 11:41:29 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB35A11E80AD for ; Wed, 4 Apr 2012 11:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7Ymyky-3Srd for ; Wed, 4 Apr 2012 11:41:28 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 63B7211E80AA for ; Wed, 4 Apr 2012 11:41:24 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q34IeWDx018710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Apr 2012 13:41:23 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 4 Apr 2012 14:41:12 -0400 From: Steve Baillargeon To: "ippm@ietf.org" Date: Wed, 4 Apr 2012 14:41:11 -0400 Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-twamp-value-added-octets-02.txt Thread-Index: Ac0SkNmSyjAlmh0HQ4WdAGGr1nL05QAAKHdw Message-ID: <4383945B8C24AA4FBC33555BB7B829EF178AD75A08@EUSAACMS0701.eamcs.ericsson.se> References: <20120404182910.17921.23413.idtracker@ietfa.amsl.com> In-Reply-To: <20120404182910.17921.23413.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] I-D Action: draft-ietf-ippm-twamp-value-added-octets-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 18:41:29 -0000 Hi This update addresses comments from Henk, Wes, Yaakov, Al and Ruediger. Regards, Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: April-04-12 2:29 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-value-added-octets-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group = of the IETF. Title : Ericsson TWAMP Value-Added Octets Author(s) : Steve Baillargeon Christofer Flinta Andreas Johnsson Svante Ekelin Filename : draft-ietf-ippm-twamp-value-added-octets-02.txt Pages : 17 Date : 2012-04-04 This memo describes an extension to the TWAMP test protocol for identifying and managing packet trains, which enables measuring capacity metrics like the available path capacity, tight section capacity and UDP delivery rate in the forward and reverse path directions. This memo contains the description of a working prototype. It does not represent a consensus of the IETF community. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for measuring capacity metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octet= s-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octets= -02.txt _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From tiziano.ionta@telecomitalia.it Fri Apr 6 05:19:10 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC321F85D7 for ; Fri, 6 Apr 2012 05:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmk1Mtnm2oUZ for ; Fri, 6 Apr 2012 05:19:09 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93421F8609 for ; Fri, 6 Apr 2012 05:19:09 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 6 Apr 2012 14:19:07 +0200 Received: from GRFMBX702BA020.griffon.local ([10.188.101.12]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 6 Apr 2012 14:19:07 +0200 From: Ionta Tiziano To: "'ippm@ietf.org'" Importance: high X-Priority: 1 Date: Fri, 6 Apr 2012 14:19:05 +0200 Thread-Topic: New Version Notification for draft-ionta-new-multiparty-metrics-framework-01.txt Thread-Index: Ac0T7tILVZxcAd1pTi6ngRfoWvaFmQAABuKQ Message-ID: <885CC0380486234DBF486FA72FE9BE3BAB526C90EB@GRFMBX702BA020.griffon.local> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ippm] New Version Notification for draft-ionta-new-multiparty-metrics-framework-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:19:10 -0000 IPPM group, any suggestion/comment/support is welcome! Meanwhile I'm working on a new version based also on the comments given to = me by Al Morton. Thanks to everybody. Bye Tiziano Ionta A new version of I-D, draft-ionta-new-multiparty-metrics-framework-01.txt h= as been successfully submitted by Tiziano Ionta and posted to the IETF repo= sitory. Filename: draft-ionta-new-multiparty-metrics-framework Revision: 01 Title: New Performance Metrics Composition Framework for Multipar= ty Services Creation date: 2012-04-06 WG ID: Individual Submission Number of pages: 13 Abstract: One of the best chances for a Service Provider to face the complex growth of IP Services, and their challenging requirements/SLAs along the Core network, is to enrich the current Performance metrics - mainly derived from a "Network-Oriented point of view", and therefore a general perspective, not focused on specific services - with some more Performance factors, so to include a "Service-Oriented point of view&q= uot;, more centred on the particular kind of service, with its own characteristics in terms of protocol, application, manageability, and so on. Almost nothing about this new approach has been standardized yet for the core network. To achieve the above goal, and starting from the one-to-group performance metrics outlined in RFC 5644 [RFC5644], a new metrics composition/aggregation framework is proposed in this memo, where the main focus is on multiparty communications (e.g. video providers, online biding, online stock market, etc.). Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, framework concepts, and need to widen the current performance metrics depending on the application, service etc. The IETF Secretariat Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From henk@uijterwaal.nl Tue Apr 10 09:18:22 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF311E80EC for ; Tue, 10 Apr 2012 09:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHtlvrMamI2Y for ; Tue, 10 Apr 2012 09:18:21 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id 41E0711E80F3 for ; Tue, 10 Apr 2012 09:18:20 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3AGHnC8016782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Apr 2012 18:17:49 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F845D2D.7070205@uijterwaal.nl> Date: Tue, 10 Apr 2012 18:17:49 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Minutes of the Paris Meeting X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:18:22 -0000 IPPM Group, Please see: http://www.ietf.org/proceedings/83/minutes/minutes-83-ippm.txt Comments to the list please. Thanks to Al, Ruediger, Brian and Paul for their help in preparing the minutes. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From wwwrun@rfc-editor.org Wed Apr 11 07:13:04 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7121F8582 for ; Wed, 11 Apr 2012 07:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z47pOvMQGGwe for ; Wed, 11 Apr 2012 07:13:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BD5CC21F857A for ; Wed, 11 Apr 2012 07:13:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 799796218A; Wed, 11 Apr 2012 07:12:27 -0700 (PDT) To: almes@advanced.org, kalidindi@advanced.org, matt@advanced.org, wes@mti-systems.com, martin.stiemerling@neclab.eu, matt@internet2.edu, henk@uijterwaal.nl From: RFC Errata System Message-Id: <20120411141227.799796218A@rfc-editor.org> Date: Wed, 11 Apr 2012 07:12:27 -0700 (PDT) X-Mailman-Approved-At: Wed, 11 Apr 2012 07:17:42 -0700 Cc: bclaise@cisco.com, rfc-editor@rfc-editor.org, ippm@ietf.org Subject: [ippm] [Editorial Errata Reported] RFC2680 (3186) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:13:04 -0000 The following errata report has been submitted for RFC2680, "A One-way Packet Loss Metric for IPPM". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2680&eid=3186 -------------------------------------- Type: Editorial Reported by: Benoit Claise Section: 1 Original Text ------------- The structure of the memo is as follows: + A 'singleton' analytic metric, called Type-P-One-way-Loss, is introduced to measure a single observation of packet transmission or loss. Corrected Text -------------- The structure of the memo is as follows: + A 'singleton' analytic metric, called Type-P-One-way-Packet-Loss, is introduced to measure a single observation of packet transmission or loss. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2680 (draft-ietf-ippm-loss-07) -------------------------------------- Title : A One-way Packet Loss Metric for IPPM Publication Date : September 1999 Author(s) : G. Almes, S. Kalidindi, M. Zekauskas Category : PROPOSED STANDARD Source : IP Performance Metrics Area : Transport Stream : IETF Verifying Party : IESG From henk@uijterwaal.nl Thu Apr 12 00:45:30 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEA021F85D6 for ; Thu, 12 Apr 2012 00:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC0FGgJROfvC for ; Thu, 12 Apr 2012 00:45:29 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7C95421F85C5 for ; Thu, 12 Apr 2012 00:45:29 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3C7i8G2073437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 09:44:09 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8687C8.6090307@uijterwaal.nl> Date: Thu, 12 Apr 2012 09:44:08 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: RFC Errata System References: <20120411141227.799796218A@rfc-editor.org> In-Reply-To: <20120411141227.799796218A@rfc-editor.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: almes@advanced.org, ippm@ietf.org, kalidindi@advanced.org, matt@internet2.edu, bclaise@cisco.com, matt@advanced.org Subject: Re: [ippm] [Editorial Errata Reported] RFC2680 (3186) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:45:30 -0000 On 11/04/2012 16:12, RFC Errata System wrote: > The following errata report has been submitted for RFC2680, > "A One-way Packet Loss Metric for IPPM". This looks like a typo and should be corrected in an update of the RFC. I think the reader will understand what is meant though. Henk > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=2680&eid=3186 > > -------------------------------------- > Type: Editorial > Reported by: Benoit Claise > > Section: 1 > > Original Text > ------------- > The structure of the memo is as follows: > > + A 'singleton' analytic metric, called Type-P-One-way-Loss, is > introduced to measure a single observation of packet transmission > or loss. > > Corrected Text > -------------- > The structure of the memo is as follows: > > + A 'singleton' analytic metric, called Type-P-One-way-Packet-Loss, is > introduced to measure a single observation of packet transmission > or loss. > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2680 (draft-ietf-ippm-loss-07) > -------------------------------------- > Title : A One-way Packet Loss Metric for IPPM > Publication Date : September 1999 > Author(s) : G. Almes, S. Kalidindi, M. Zekauskas > Category : PROPOSED STANDARD > Source : IP Performance Metrics > Area : Transport > Stream : IETF > Verifying Party : IESG -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Thu Apr 12 04:20:41 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A76A21F8607 for ; Thu, 12 Apr 2012 04:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQDJLBVhfK-1 for ; Thu, 12 Apr 2012 04:20:40 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8C68821F860E for ; Thu, 12 Apr 2012 04:20:40 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3CBK4Bw023588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 13:20:04 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F86BA62.3080608@uijterwaal.nl> Date: Thu, 12 Apr 2012 13:20:02 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 11:20:41 -0000 Ruediger, others, > I support work on draft-cisco-sla-protocol by the IPPM WG. A good next step would be to discuss how the draft can make progress: Noted. The logical next step (to me) seems that people interested speak up and start reviewing/commenting on the document. If/when it becomes clear that there is sufficient interest in the WG to work on this _and_ the WG is interested in finding a generic solution to the problem (that is, one that can be implemented by others as well), then we can pick it up as a WG item. If this is not the case, then I'd suggest that the authors take all comments into account and ask for the document to be published as an individual submission RFC. Henk > > - work on this draft within the IPPM WG (or another one)? > - maintain it as Informational (in which case it should be published after a brief review)? > - if published as Informational - do we think it preceeds TWAMP or do we want or need a new Standards Track problem statement and solution draft? > > Regards, > > Ruediger > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From acmorton@att.com Thu Apr 12 05:07:43 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF921F85C2 for ; Thu, 12 Apr 2012 05:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.503 X-Spam-Level: X-Spam-Status: No, score=-105.503 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2iyDNK1Duf0 for ; Thu, 12 Apr 2012 05:07:43 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0614721F856F for ; Thu, 12 Apr 2012 05:07:42 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id e85c68f4.0.1470011.00-330.4082559.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 12 Apr 2012 12:07:43 +0000 (UTC) X-MXL-Hash: 4f86c58f674d6831-9dc4c8bd86a458f0ddaed31831f668fe4bd00eac Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3CC7gC8032539 for ; Thu, 12 Apr 2012 08:07:42 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3CC7aF9032448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2012 08:07:37 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 12 Apr 2012 08:07:16 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3CC7GjR007032 for ; Thu, 12 Apr 2012 08:07:16 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3CC79R6006714 for ; Thu, 12 Apr 2012 08:07:10 -0400 Message-Id: <201204121207.q3CC79R6006714@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-141-76.vpn.mwst.att.com[135.70.141.76](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120412120409gw1004or95e>; Thu, 12 Apr 2012 12:04:10 +0000 X-Originating-IP: [135.70.141.76] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Apr 2012 08:08:18 -0400 To: Henk Uijterwaal , RFC Errata System From: Al Morton In-Reply-To: <4F8687C8.6090307@uijterwaal.nl> References: <20120411141227.799796218A@rfc-editor.org> <4F8687C8.6090307@uijterwaal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=Yk6DvKRXlRgA:10 a=jkbhGRyIGlYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=hdcT0kuWhbthArLQsrEA:9 a=CjuIK1q_8ugA:10] Cc: bclaise@cisco.com, matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] [Editorial Errata Reported] RFC2680 (3186) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:07:43 -0000 At 03:44 AM 4/12/2012, Henk Uijterwaal wrote: >This looks like a typo and should be corrected in an update of the RFC. >I think the reader will understand what is meant though. Right, and when "Type-P" is specified thoroughly, "Packet" is redundant. Al From acmorton@att.com Thu Apr 12 05:19:57 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A44A21F8615 for ; Thu, 12 Apr 2012 05:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=1.251, BAYES_00=-2.599, GB_I_INVITATION=-2, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq79Lq0nPZex for ; Thu, 12 Apr 2012 05:19:56 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id ACCB921F85FF for ; Thu, 12 Apr 2012 05:19:56 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id c68c68f4.0.1476783.00-480.4095374.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 12 Apr 2012 12:19:56 +0000 (UTC) X-MXL-Hash: 4f86c86c439df14c-25aa7d43a506d5f77aeda38d486787b1984eccb3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3CCJtsj009202 for ; Thu, 12 Apr 2012 08:19:56 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3CCJnYZ009187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2012 08:19:49 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 12 Apr 2012 08:19:33 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3CCJVhS008838 for ; Thu, 12 Apr 2012 08:19:32 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3CCJRxs008599 for ; Thu, 12 Apr 2012 08:19:27 -0400 Message-Id: <201204121219.q3CCJRxs008599@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-141-76.vpn.mwst.att.com[135.70.141.76](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120412121627gw1004or96e>; Thu, 12 Apr 2012 12:16:28 +0000 X-Originating-IP: [135.70.141.76] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Apr 2012 08:20:35 -0400 To: Henk Uijterwaal , Ruediger.Geib@telekom.de From: Al Morton In-Reply-To: <4F86BA62.3080608@uijterwaal.nl> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=Yk6DvKRXlRgA:10 a=PDMPHasUweMA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=SawjgRLgM4MMAJSML6MA:9 a=] X-AnalysisOut: [tuQpn0AVSoOknjV9iLoA:7 a=CjuIK1q_8ugA:10 a=7A8_SDl5LwoA:10] X-AnalysisOut: [ a=Pn8t9tNLtOsA:10 a=EJGlZY1OXOMA:10 a=7NprUqGBDq0A:10 a=P] X-AnalysisOut: [n1_fcHrZ2IA:10] Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:19:57 -0000 At 07:20 AM 4/12/2012, Henk Uijterwaal wrote: >Ruediger, others, > > > I support work on draft-cisco-sla-protocol by the IPPM WG. A good > next step would be to discuss how the draft can make progress: > >Noted. The logical next step (to me) seems that people interested speak >up and start reviewing/commenting on the document. If/when it becomes >clear that there is sufficient interest in the WG to work on this >_and_ the WG is interested in finding a generic solution to the problem >(that is, one that can be implemented by others as well), then we can >pick it up as a WG item. ... Hi Henk, To save you some cycles, I've compiled all the other messages to ippm-list with comments on draft-cisco-sla-protocol. Messages have been appearing sporadically since the beginning of the year, so the trend may not have been evident. Here's the beginning of the thread, four responses offering to review, and comments already on the draft: Murtaza's invitation to review: http://www.ietf.org/mail-archive/web/ippm/current/msg02754.html Al's reply and comments: http://www.ietf.org/mail-archive/web/ippm/current/msg02758.html Greg Dowd's reply to Al message & comment: http://www.ietf.org/mail-archive/web/ippm/current/msg02761.html Tiziano Ionta's offer to work on the draft: http://www.ietf.org/mail-archive/web/ippm/current/msg02765.html Len Ciavattone's offer to work on the draft: http://www.ietf.org/mail-archive/web/ippm/current/msg02791.html Also, Yaakov Stein offered to work on the draft at the IPPM session at IETF-83. hope this helps, Al From internet-drafts@ietf.org Thu Apr 12 16:00:48 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6DC21F8742; Thu, 12 Apr 2012 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+Dnj4z53JPe; Thu, 12 Apr 2012 16:00:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED821F8731; Thu, 12 Apr 2012 16:00:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120412230047.21228.68766.idtracker@ietfa.amsl.com> Date: Thu, 12 Apr 2012 16:00:47 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rt-loss-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 23:00:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group = of the IETF. Title : Round-trip Packet Loss Metrics Author(s) : Al Morton Filename : draft-ietf-ippm-rt-loss-04.txt Pages : 13 Date : 2012-04-12 Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no metric specified according to the RFC 2330 framework. This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-rt-loss-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-rt-loss-04.txt From lars@netapp.com Fri Apr 13 09:48:31 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6180621F8467 for ; Fri, 13 Apr 2012 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.8 X-Spam-Level: X-Spam-Status: No, score=-10.8 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnmv+Lp11HAP for ; Fri, 13 Apr 2012 09:48:30 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id ABC8521F8577 for ; Fri, 13 Apr 2012 09:48:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,418,1330934400"; d="p7s'?scan'208";a="640897047" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 13 Apr 2012 09:48:20 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q3DGmKtu020329 for ; Fri, 13 Apr 2012 09:48:20 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.117]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Fri, 13 Apr 2012 09:48:19 -0700 From: "Eggert, Lars" To: "ippm@ietf.org" Thread-Topic: New Non-WG Mailing List: lmap -- Large Scale Measurement of Access network Performance Thread-Index: AQHNGYNuxVFXYyQ57EOXdwg+5pdUIQ== Date: Fri, 13 Apr 2012 16:48:19 +0000 Message-ID: <35021610-ECF3-4FCC-AACC-B6B7CA611280@netapp.com> References: <20120413144032.17625.17457.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_3ED72B48-2E4B-4A28-BE97-260075C28624"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Apr 2012 23:45:54 -0700 Subject: [ippm] Fwd: New Non-WG Mailing List: lmap -- Large Scale Measurement of Access network Performance X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:48:31 -0000 --Apple-Mail=_3ED72B48-2E4B-4A28-BE97-260075C28624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > From: IETF Secretariat > Subject: New Non-WG Mailing List: lmap -- Large Scale Measurement of = Access network Performance > Date: April 13, 2012 16:40:32 GMT+02:00 > To: IETF Announcement List > Cc: , >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: lmap@ietf.org > Archive: http://www.ietf.org/mail-archive/web/lmap/ > To subscribe: https://www.ietf.org/mailman/listinfo/lmap >=20 > Purpose: This list is for discussing requirements, architectures, = metrics, > and protocols for measuring the performance and reliability of > (mostly) residential and small-enterprise access links on a large > scale. The discussions may lead to a BoF and eventual working group. >=20 > For additional information, please contact the list administrators. --Apple-Mail=_3ED72B48-2E4B-4A28-BE97-260075C28624 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMzE2NDgxOFowIwYJKoZIhvcNAQkEMRYEFJ/X aWgKfLyJHq+proMwK5sa4uNrMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAAhEXQmL nqybJyck6JEVGMBEyH79ROaXOiQLZGlLVAGSri/nT7AgtwcL8r43tAY1570z4sbrlrPCyTqctbIM PxC8WZM6FRWJMpS6bPt2f9haLFdSlcAxOPHrRu1JSr5yKZZsPwDXbeO2zNmFnl25epNErd73V6lb WUwhX/QoIqzlWzx2g4HU1dVVFRUa56lKvEVonr7tz0LOO7EiqLQGB6rizLAlh7A4ifS4SwozeLfH 5d0z4WGQtScLdIz4dWm2b6oWRVpMWYayo+OLqVVUZgwsonvuqUwE7czKJ8pJa7BCLdoiq8gCaaQw 7GA4Pao2pI8B1no8xKk/D5V5ekiUq8cAAAAAAAA= --Apple-Mail=_3ED72B48-2E4B-4A28-BE97-260075C28624-- From Abdul.Wohab@qubee.com.bd Sun Apr 15 03:31:34 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24D21F8646 for ; Sun, 15 Apr 2012 03:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJirXWrt8m9f for ; Sun, 15 Apr 2012 03:31:33 -0700 (PDT) Received: from mail.qubee.com.bd (mail.qubee.com.bd [180.234.0.218]) by ietfa.amsl.com (Postfix) with SMTP id 4B64C21F8631 for ; Sun, 15 Apr 2012 03:31:21 -0700 (PDT) X-ASG-Debug-ID: 1334485877-43ca45f40001-e7AMy4 Received: from mail.qubee.com.bd ([192.168.103.22]) by mail.qubee.com.bd with ESMTP id bBfIEopaHVkLJrRI for ; Sun, 15 Apr 2012 16:31:17 +0600 (BTT) X-Barracuda-Envelope-From: Abdul.Wohab@qubee.com.bd Received: from EX-1.qubee.com.bd ([::1]) by EX-1.qubee.com.bd ([::1]) with mapi id 14.01.0218.012; Sun, 15 Apr 2012 16:34:34 +0600 From: "Md. Abdul Wohab (Mithun)" X-Barracuda-Apparent-Source-IP: ::1 To: "ippm@ietf.org" Thread-Topic: Metrics & Recommended Value X-ASG-Orig-Subj: Metrics & Recommended Value Thread-Index: Ac0a81iGgXhw2qQAQ9KhCUgpS/tgHw== Date: Sun, 15 Apr 2012 10:34:33 +0000 Message-ID: <6200CC0ECA70B741AC22E1C2C5ACC2F60AEF12@EX-1.qubee.com.bd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [180.234.0.190] Content-Type: multipart/alternative; boundary="_000_6200CC0ECA70B741AC22E1C2C5ACC2F60AEF12EX1qubeecombd_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.103.22] X-Barracuda-Start-Time: 1334485877 X-Barracuda-URL: http://192.168.103.24:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at qubee.com.bd X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.94184 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Mailman-Approved-At: Sun, 15 Apr 2012 08:31:08 -0700 Subject: [ippm] Metrics & Recommended Value X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 10:33:44 -0000 --_000_6200CC0ECA70B741AC22E1C2C5ACC2F60AEF12EX1qubeecombd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Concern Can I please have the IP performance metric list along with the standard re= commended value? Thanks //Mithun --_000_6200CC0ECA70B741AC22E1C2C5ACC2F60AEF12EX1qubeecombd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Concern

 

Can I please have the IP performance metric list along with = the standard recommended value?

 

Thanks

//Mithun

--_000_6200CC0ECA70B741AC22E1C2C5ACC2F60AEF12EX1qubeecombd_-- From henk@uijterwaal.nl Sun Apr 15 23:02:26 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5A321F8678 for ; Sun, 15 Apr 2012 23:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbqrHNfRdJoF for ; Sun, 15 Apr 2012 23:02:25 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4E821F8670 for ; Sun, 15 Apr 2012 23:02:10 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3G61cJq044899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 08:01:39 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8BB5C2.2090605@uijterwaal.nl> Date: Mon, 16 Apr 2012 08:01:38 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: ippm@ietf.org References: <6200CC0ECA70B741AC22E1C2C5ACC2F60AEF12@EX-1.qubee.com.bd> In-Reply-To: <6200CC0ECA70B741AC22E1C2C5ACC2F60AEF12@EX-1.qubee.com.bd> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [ippm] Metrics & Recommended Value X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 06:02:26 -0000 On 15/04/2012 12:34, Md. Abdul Wohab (Mithun) wrote: > Can I please have the IP performance metric list along with the standard > recommended value? One way: RFC 2679 Delay 2680 Packet loss 3393 Delay Variation 4737 Packet Reordering 5560 Duplication Two way: 2681 Round trip Delay draft-ietf-ippm-rt-loss-04.txt Loss For other documents, see http://datatracker.ietf.org/wg/ippm/ The IPPM group only defines the metrics, specifying recommended values (that is, defining "good" or "bad") is outside its scope. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Mon Apr 16 00:36:33 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35621F873E for ; Mon, 16 Apr 2012 00:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9wRAAxkwtRC for ; Mon, 16 Apr 2012 00:36:32 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 75DF421F8734 for ; Mon, 16 Apr 2012 00:36:30 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3G7Zxdx099411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 09:35:59 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8BCBDD.3050302@uijterwaal.nl> Date: Mon, 16 Apr 2012 09:35:57 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF IPPM WG References: <4F8BC2D4.3000106@uijterwaal.nl> In-Reply-To: <4F8BC2D4.3000106@uijterwaal.nl> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <4F8BC2D4.3000106@uijterwaal.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Fwd: Re: Adopt draft draft-morton-ippm-rate-problem-02 as a WG document X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 07:36:33 -0000 -------- Original Message -------- Subject: Re: Adopt draft draft-morton-ippm-rate-problem-02 as a WG document Date: Mon, 16 Apr 2012 08:57:24 +0200 From: Henk Uijterwaal To: Henk Uijterwaal IPPM group, > This is a formal proposal to adopt > > Rate Measurement Problem Statement > draft-morton-ippm-rate-problem-02 > > as a WG document. Please review the draft and raise any objections by > Monday, April 16, 8:00 UTC. A URL for the draft is: > > http://datatracker.ietf.org/doc/draft-morton-ippm-rate-problem/ > > Matt & Henk No issues have been raised, so this document is now a WG document. Authors: please resubmit with a draft-ietf-ippm- name. All others: please read and comment on the draft. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Mon Apr 16 00:36:42 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E60621F8748 for ; Mon, 16 Apr 2012 00:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LgVLigz7zh9 for ; Mon, 16 Apr 2012 00:36:42 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA721F8701 for ; Mon, 16 Apr 2012 00:36:41 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3G7a8KP019186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 09:36:10 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8BCBE8.2070306@uijterwaal.nl> Date: Mon, 16 Apr 2012 09:36:08 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" References: <4F8BC304.9020701@uijterwaal.nl> In-Reply-To: <4F8BC304.9020701@uijterwaal.nl> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <4F8BC304.9020701@uijterwaal.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Fwd: Re: Adopt draft-morton-ippm-testplan-rfc2680-02 as a WG document X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 07:36:42 -0000 -------- Original Message -------- Subject: Re: Adopt draft-morton-ippm-testplan-rfc2680-02 as a WG document Date: Mon, 16 Apr 2012 08:58:12 +0200 From: Henk Uijterwaal To: Henk Uijterwaal IPPM group, > This is a formal proposal to adopt: > > Test Plan and Results for Advancing RFC 2680 on the Standards Track > draft-morton-ippm-testplan-rfc2680-02 > > as a WG document. Please review the draft and raise any objections by > Monday, April 16, 8:00 UTC. A URL for the draft is: > > http://datatracker.ietf.org/doc/draft-morton-ippm-testplan-rfc2680/ Same here: no issues were raised, so this is now a WG document. Authors: please resubmit with a draft-ietf-ippm- name. All others: please read and comment. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Mon Apr 16 00:36:50 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C580421F8757 for ; Mon, 16 Apr 2012 00:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCU9RMBxbYgW for ; Mon, 16 Apr 2012 00:36:50 -0700 (PDT) Received: from smtp-vbr18.xs4all.nl (smtp-vbr18.xs4all.nl [194.109.24.38]) by ietfa.amsl.com (Postfix) with ESMTP id A93C921F8755 for ; Mon, 16 Apr 2012 00:36:49 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr18.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3G7aH0J027691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 09:36:18 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8BCBF1.9000907@uijterwaal.nl> Date: Mon, 16 Apr 2012 09:36:17 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" References: <4F8BC42D.2010003@uijterwaal.nl> In-Reply-To: <4F8BC42D.2010003@uijterwaal.nl> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <4F8BC42D.2010003@uijterwaal.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Fwd: Re: WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 07:36:50 -0000 -------- Original Message -------- Subject: Re: WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt Date: Mon, 16 Apr 2012 09:03:09 +0200 From: Henk Uijterwaal To: Henk Uijterwaal IPPM Group, > This starts a WGLC for the draft: > > TWAMP Value-Added Octets > draft-ietf-ippm-twamp-value-added-octets-01.txt > > Please review the draft and raise any issues by Monday, April 16, 2012, > 8:00 UTC. After the start of the WGLC (on 29/3), there was some discussion on the draft and a new version has been submitted (-02, on April 4). I haven't seen any feedback on this one though. As a result, I'm extending the WGLC by one week, until April 23. If you commented on the previous version, please look at the new one and let me know if this addresses your comments. A one-line review ("yes, I've read it and I'm now {happy|still not happy} with the document") is already quite useful. If nobody speaks up, I'm going to assume that everybody _is_ happy with the document. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Mon Apr 16 00:41:37 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C5721F8734 for ; Mon, 16 Apr 2012 00:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccy9mXhex8Pq for ; Mon, 16 Apr 2012 00:41:37 -0700 (PDT) Received: from smtp-vbr16.xs4all.nl (smtp-vbr16.xs4all.nl [194.109.24.36]) by ietfa.amsl.com (Postfix) with ESMTP id AA09B21F8733 for ; Mon, 16 Apr 2012 00:41:36 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr16.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3G7f48q023240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 09:41:05 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8BCD0F.9050404@uijterwaal.nl> Date: Mon, 16 Apr 2012 09:41:03 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF IPPM WG References: <4F8BC453.4080709@uijterwaal.nl> In-Reply-To: <4F8BC453.4080709@uijterwaal.nl> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <4F8BC453.4080709@uijterwaal.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Fwd: Re: WGLC for draft-ietf-ippm-testplan-rfc2679-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 07:41:37 -0000 -------- Original Message -------- Subject: Re: WGLC for draft-ietf-ippm-testplan-rfc2679-01 Date: Mon, 16 Apr 2012 09:03:47 +0200 From: Henk Uijterwaal To: Henk Uijterwaal IPPM group, On 29/03/2012 11:36, Henk Uijterwaal wrote: > IPPM Group, > > This starts a WGLC for the draft: > > Test Plan and Results for Advancing RFC 2679 on the Standards Track > draft-ietf-ippm-testplan-rfc2679-01 > > Please review the draft and raise any issues by Monday, April 16, 2012, > 8:00 UTC. No issues were raised, so this document is approved and will be moved forward. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk@uijterwaal.nl Mon Apr 16 02:48:46 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E9821F8650 for ; Mon, 16 Apr 2012 02:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc0iIB6DXVoj for ; Mon, 16 Apr 2012 02:48:45 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by ietfa.amsl.com (Postfix) with ESMTP id 423AC21F8633 for ; Mon, 16 Apr 2012 02:48:45 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3G9mAgg079701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2012 11:48:11 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8BEAD9.6090600@uijterwaal.nl> Date: Mon, 16 Apr 2012 11:48:09 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Al Morton References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> In-Reply-To: <201204121219.q3CCJRij008598@alpd052.aldc.att.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:48:46 -0000 Hi Al, others, >> > I support work on draft-cisco-sla-protocol by the IPPM WG. A good next step >> would be to discuss how the draft can make progress: >> >> Noted. The logical next step (to me) seems that people interested speak >> up and start reviewing/commenting on the document. If/when it becomes >> clear that there is sufficient interest in the WG to work on this >> _and_ the WG is interested in finding a generic solution to the problem >> (that is, one that can be implemented by others as well), then we can >> pick it up as a WG item. ... > > Hi Henk, > > To save you some cycles, I've compiled all the other > messages to ippm-list with comments on draft-cisco-sla-protocol. > Messages have been appearing sporadically since the beginning > of the year, so the trend may not have been evident. Yes, I saw those mails and I agree that there is a trend. So, let me rephrase ;-) It appears that there is interest in this work (besides the authors from Al, Greg, Tiziano, Len, Yaakov and Ruediger). The question to be answered is, I think, whether the WG is interested in finding a generic solution to the problem discussed in this draft (that is, something that can be implemented by anybody). Speak up in support or disagreement. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From wes@mti-systems.com Tue Apr 17 09:24:10 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377B421F8499 for ; Tue, 17 Apr 2012 09:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCLjwXvktSj4 for ; Tue, 17 Apr 2012 09:24:09 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF621F848A for ; Tue, 17 Apr 2012 09:24:09 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3HGO5GW001157 for ; Tue, 17 Apr 2012 12:24:08 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [192.206.187.24] ([192.206.187.24:31809] helo=[172.27.250.175]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 12/90-22702-4299D8F4; Tue, 17 Apr 2012 12:24:05 -0400 Message-ID: <4F8D9919.9080007@mti-systems.com> Date: Tue, 17 Apr 2012 12:23:53 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Henk Uijterwaal References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> In-Reply-To: <4F8BEAD9.6090600@uijterwaal.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org, Al Morton , matt@internet2.edu Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:24:10 -0000 On 4/16/2012 5:48 AM, Henk Uijterwaal wrote: > Hi Al, others, > >>>> I support work on draft-cisco-sla-protocol by the IPPM WG. A good next step >>> would be to discuss how the draft can make progress: >>> >>> Noted. The logical next step (to me) seems that people interested speak >>> up and start reviewing/commenting on the document. If/when it becomes >>> clear that there is sufficient interest in the WG to work on this >>> _and_ the WG is interested in finding a generic solution to the problem >>> (that is, one that can be implemented by others as well), then we can >>> pick it up as a WG item. ... >> >> Hi Henk, >> >> To save you some cycles, I've compiled all the other >> messages to ippm-list with comments on draft-cisco-sla-protocol. >> Messages have been appearing sporadically since the beginning >> of the year, so the trend may not have been evident. > > Yes, I saw those mails and I agree that there is a trend. > > So, let me rephrase ;-) > > It appears that there is interest in this work (besides the authors > from Al, Greg, Tiziano, Len, Yaakov and Ruediger). The question to > be answered is, I think, whether the WG is interested in finding > a generic solution to the problem discussed in this draft (that is, > something that can be implemented by anybody). Speak up in > support or disagreement. As responsible AD, I share some concerns similar to what Steve raised. I think it definitely makes sense to document what has been done to-date with Cisco's SLA protocol as an Informational RFC that describes the protocol and hopefully describes it in the context of the IPPM OWAMP/TWAMP as to how it differs. I don't think that has to be done by the IPPM WG. It should be done either on the ISE-track or as AD-sponsored, in my opinion. If there's strong motivation for IPPM to develop another protocol, I have not understood it yet, and would like to understand why we would initiate work on a new protocol rather than patching OWAMP/TWAMP. -- Wes Eddy MTI Systems From henk@uijterwaal.nl Wed Apr 18 01:31:53 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C4521F8671 for ; Wed, 18 Apr 2012 01:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuA454hNMest for ; Wed, 18 Apr 2012 01:31:48 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51D21F8661 for ; Wed, 18 Apr 2012 01:31:48 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3I8VC1Z062451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2012 10:31:13 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8E7BCE.4010306@uijterwaal.nl> Date: Wed, 18 Apr 2012 10:31:10 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Wesley Eddy References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> In-Reply-To: <4F8D9919.9080007@mti-systems.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: ippm@ietf.org, Al Morton , matt@internet2.edu Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:31:53 -0000 Wes, > I think it definitely makes sense to document what has > been done to-date with Cisco's SLA protocol as an > Informational RFC that describes the protocol and hopefully > describes it in the context of the IPPM OWAMP/TWAMP as to > how it differs. I don't think that has to be done by the > IPPM WG. It should be done either on the ISE-track or as > AD-sponsored, in my opinion. The ISE asked if IPPM could pick this up, as he preferred a review by IPPM rather than do this himself. When the authors announced the existence of this draft on the IPPM list, a handful of people spoke up and said they were interested in the topic. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From acmorton@att.com Wed Apr 18 06:17:29 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE5E21F84EB for ; Wed, 18 Apr 2012 06:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.479 X-Spam-Level: X-Spam-Status: No, score=-105.479 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdIPqbVsrdVI for ; Wed, 18 Apr 2012 06:17:28 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCEB21F846F for ; Wed, 18 Apr 2012 06:17:28 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 7eebe8f4.0.1121567.00-332.3111391.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 18 Apr 2012 13:17:28 +0000 (UTC) X-MXL-Hash: 4f8ebee808c3bd22-e54e8f4216cb36defbdece615939f437b8082cb3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3IDHRLo002752 for ; Wed, 18 Apr 2012 09:17:27 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3IDHPQc002704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 09:17:26 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Wed, 18 Apr 2012 09:17:03 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3IDH3pL031037 for ; Wed, 18 Apr 2012 09:17:03 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3IDGx0i030800 for ; Wed, 18 Apr 2012 09:16:59 -0400 Message-Id: <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-233-115.vpn.east.att.com[135.70.233.115](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120418131353gw1004orkte>; Wed, 18 Apr 2012 13:13:54 +0000 X-Originating-IP: [135.70.233.115] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Apr 2012 09:18:08 -0400 To: Henk Uijterwaal , Wesley Eddy From: Al Morton In-Reply-To: <4F8E7BCE.4010306@uijterwaal.nl> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=xnrb5j7JfCUA:10 a=PDMPHasUweMA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=mzcrxHQT1hQmHIRexGsA:9 a=CjuIK1q_8ugA:10] Cc: matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 13:17:29 -0000 Wes, appending more to Henk's response, below. At 04:31 AM 4/18/2012, Henk Uijterwaal wrote: >Wes, > > > I think it definitely makes sense to document what has > > been done to-date with Cisco's SLA protocol as an > > Informational RFC that describes the protocol and hopefully > > describes it in the context of the IPPM OWAMP/TWAMP as to > > how it differs. I don't think that has to be done by the > > IPPM WG. It should be done either on the ISE-track or as > > AD-sponsored, in my opinion. > >The ISE asked if IPPM could pick this up, as he preferred a review by >IPPM rather than do this himself. When the authors announced the existence >of this draft on the IPPM list, a handful of people spoke up and said they >were interested in the topic. At 12:23 PM 4/17/2012, Wesley Eddy wrote: > >If there's strong motivation for IPPM to develop another > >protocol, I have not understood it yet, and would like to > >understand why we would initiate work on a new protocol > >rather than patching OWAMP/TWAMP. I will give this a shot, as briefly as possible. TWAMP looks a lot like OWAMP because, when a protocol for a two-way test with low-complexity responder architecture was proposed, OWAMP-folks wanted the design to "just use OWAMP in two directions, you're done." The compromise was to extend OWAMP for two-directional use, and therefore pull more implementors closer to a full OWAMP-compliant system over time. Years on, we found that we had to separate the protocols because TWAMP-only and OWAMP-only hosts could not negotiate a common mode of operation. Taking TWAMP through IESG also brought a surprise. The Security ADs had agreed not to block OWAMP if we never used the same (non-standard, in their eyes) security features again, and here we were with TWAMP doing exactly the same thing. Sam Hartman ultimately Abstained, and Pasi Eronen and I worked out a compromise one night in Dublin where I would investigate using TLS on TWAMP-Control and try to get IPPM interested to add it. I presented a very do-able plan at the next IETF face2face and on ippm-list, but no one was interested. Also, many of the enhancements/new TWAMP features have been fixes for the sort of thing testers expect in a protocol (symmetrical packet size, for one). And we have the baggage of TWAMP specs written to reference OWAMP as much as possible, making reading and understanding TWAMP about as hard as possible. The hoped-for benefit of getting more implementors to consider OWAMP has never happened, AFAICT, and the low-complexity responder architecture actually precludes it (OWAMP is for test hosts that are peers in processing power, sync, etc.). In summary, we have a two-way measurement protocol spec that could really use a lot of work to resolve issues of clarity, existing patches, plus unusual security features, and if Henk's poll earlier this year is accurate, no one willing to do the work. And it is a lot of work. So when I saw a simple and independent spec for the two-way testing protocol function that resolves many of TWAMP's shortcomings and fits nicely with the low-complexity responder architecture, I was very interested. Why spend my time re-writing TWAMP, when a successful outcome would look a lot like draft-cisco-sla-protocol? If draft-cisco-sla-protocol can't be done as an IPPM WG doc, then I'd like to see it go forward as AD-sponsored and reviewed frequently on the IPPM list. regards, Al From steve.baillargeon@ericsson.com Wed Apr 18 07:03:20 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F7921F84B8 for ; Wed, 18 Apr 2012 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q5FzJAqZT-v for ; Wed, 18 Apr 2012 07:03:16 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 54E6A21F8582 for ; Wed, 18 Apr 2012 07:03:16 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3IE3CcJ029657; Wed, 18 Apr 2012 09:03:14 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.157]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 18 Apr 2012 10:03:07 -0400 From: Steve Baillargeon To: Al Morton , Henk Uijterwaal , Wesley Eddy Date: Wed, 18 Apr 2012 10:03:06 -0400 Thread-Topic: [ippm] draft-cisco-sla-protocol Thread-Index: Ac0dZa1/zitCUtIZQL2H4LPmU2O1IQAANnxg Message-ID: <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> In-Reply-To: <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "matt@internet2.edu" , "ippm@ietf.org" Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:03:20 -0000 Hi >>In summary, we have a two-way measurement protocol spec that could really= use a lot of work to resolve issues of clarity, existing patches, plus unu= sual security features, and if Henk's poll earlier this year is accurate, n= o one willing to do the work. And it is a lot of work. I agree that TWAMP is far from perfect. I also agree the contribution level= at the IPPM is fairly low (except for Al who drives most of the new contri= butions) but I do not necessarily agree the poll represent an industry cons= ensus. As far as I know, many vendors have already implemented TWAMP and I = suspect most of them are expecting the WG to improve it over time. I know i= t requires work but I assume it will also be work to improve the IPR-protec= ted IP SLA protocol over time. On the other hand, I suspect these new IP SL= A related contributions will mostly come from Cisco and Al. >>So when I saw a simple and independent spec for the two-way testing proto= col function that resolves many of TWAMP's shortcomings and fits nicely wit= h the low-complexity responder architecture, I was very interested. Why spe= nd my time re-writing TWAMP, when a successful outcome would look a lot lik= e draft-cisco-sla-protocol?=20 It sounds like Al has already decided to pull the plug on OWAMP and TWAMP. = Is it the consensus of the WG? Do we need a draft comparing the pros and cons of Cisco IP SLA vs TWAMP in = order to make a better decision? -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: April-18-12 9:18 AM To: Henk Uijterwaal; Wesley Eddy Cc: matt@internet2.edu; ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol Wes, appending more to Henk's response, below. At 04:31 AM 4/18/2012, Henk Uijterwaal wrote: >Wes, > > > I think it definitely makes sense to document what has been done=20 > > to-date with Cisco's SLA protocol as an Informational RFC that=20 > > describes the protocol and hopefully describes it in the context of=20 > > the IPPM OWAMP/TWAMP as to how it differs. I don't think that has=20 > > to be done by the IPPM WG. It should be done either on the=20 > > ISE-track or as AD-sponsored, in my opinion. > >The ISE asked if IPPM could pick this up, as he preferred a review by=20 >IPPM rather than do this himself. When the authors announced the=20 >existence of this draft on the IPPM list, a handful of people spoke up=20 >and said they were interested in the topic. At 12:23 PM 4/17/2012, Wesley Eddy wrote: > >If there's strong motivation for IPPM to develop another protocol, I=20 > >have not understood it yet, and would like to understand why we would=20 > >initiate work on a new protocol rather than patching OWAMP/TWAMP. I will give this a shot, as briefly as possible. TWAMP looks a lot like OWAMP because, when a protocol for a two-way test wi= th low-complexity responder architecture was proposed, OWAMP-folks wanted t= he design to "just use OWAMP in two directions, you're done." The compromis= e was to extend OWAMP for two-directional use, and therefore pull more impl= ementors closer to a full OWAMP-compliant system over time. Years on, we found that we had to separate the protocols because TWAMP-only= and OWAMP-only hosts could not negotiate a common mode of operation. Taking TWAMP through IESG also brought a surprise. The Security ADs had agr= eed not to block OWAMP if we never used the same (non-standard, in their ey= es) security features again, and here we were with TWAMP doing exactly the = same thing. Sam Hartman ultimately Abstained, and Pasi Eronen and I worked= out a compromise one night in Dublin where I would investigate using TLS o= n TWAMP-Control and try to get IPPM interested to add it. I presented a ver= y do-able plan at the next IETF face2face and on ippm-list, but no one was = interested. Also, many of the enhancements/new TWAMP features have been fixes for the s= ort of thing testers expect in a protocol (symmetrical packet size, for one= ). And we have the baggage of TWAMP specs written to reference OWAMP as mu= ch as possible, making reading and understanding TWAMP about as hard as pos= sible. The hoped-for benefit of getting more implementors to consider OWAMP= has never happened, AFAICT, and the low-complexity responder architecture = actually precludes it (OWAMP is for test hosts that are peers in processing= power, sync, etc.). In summary, we have a two-way measurement protocol spec that could really u= se a lot of work to resolve issues of clarity, existing patches, plus unusu= al security features, and if Henk's poll earlier this year is accurate, no = one willing to do the work. And it is a lot of work. So when I saw a simple and independent spec for the two-way testing protoco= l function that resolves many of TWAMP's shortcomings and fits nicely with = the low-complexity responder architecture, I was very interested. Why spend= my time re-writing TWAMP, when a successful outcome would look a lot like = draft-cisco-sla-protocol? If draft-cisco-sla-protocol can't be done as an IPPM WG doc, then I'd like = to see it go forward as AD-sponsored and reviewed frequently on the IPPM li= st. regards, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Wed Apr 18 07:47:20 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B2321F8498 for ; Wed, 18 Apr 2012 07:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.505 X-Spam-Level: X-Spam-Status: No, score=-105.505 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5n76Ksb8gW7 for ; Wed, 18 Apr 2012 07:47:19 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6310A21F849B for ; Wed, 18 Apr 2012 07:47:19 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 6f3de8f4.0.1167167.00-278.3238439.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 18 Apr 2012 14:47:19 +0000 (UTC) X-MXL-Hash: 4f8ed3f70eeddfd7-041593067558312889c4d400198ea91c5acfe3ac Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3IElIKu031580 for ; Wed, 18 Apr 2012 10:47:18 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3IElEqG031498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 10:47:14 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Wed, 18 Apr 2012 10:46:49 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3IEkmS8011505 for ; Wed, 18 Apr 2012 10:46:48 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3IEkhbA011345 for ; Wed, 18 Apr 2012 10:46:43 -0400 Message-Id: <201204181446.q3IEkhbA011345@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-233-115.vpn.east.att.com[135.70.233.115](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120418144337gw1004orlie>; Wed, 18 Apr 2012 14:43:38 +0000 X-Originating-IP: [135.70.233.115] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Apr 2012 10:47:52 -0400 To: Steve Baillargeon , Henk Uijterwaal , Wesley Eddy From: Al Morton In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.ea mcs.ericsson.se> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=xnrb5j7JfCUA:10 a=PDMPHasUweMA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=AolkArHYVldFadxXsQwA:9 a=CjuIK1q_8ugA:10] Cc: "matt@internet2.edu" , "ippm@ietf.org" Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:47:20 -0000 At 10:03 AM 4/18/2012, Steve Baillargeon wrote: >Al wrote: > >So when I saw a simple and independent spec for the two-way > testing protocol >function that resolves many of TWAMP's > shortcomings and fits nicely with the >low-complexity responder > architecture, I was very interested. Why spend my >time re-writing > TWAMP, when a successful outcome would look a lot like > draft->cisco-sla-protocol? > >It sounds like Al has already decided to pull the plug on OWAMP and >TWAMP. Is it the consensus of the WG? Your over-reaction is unnecessary, and don't put words in my mouth. The intended status of draft-cisco-sla-protocol is Informational, so it would not Update or Obsolete any of IPPM's Standards Track protocols. Al From henk@uijterwaal.nl Wed Apr 18 23:41:37 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F15411E8079 for ; Wed, 18 Apr 2012 23:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVEsdjgO52h4 for ; Wed, 18 Apr 2012 23:41:33 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 60DE611E8076 for ; Wed, 18 Apr 2012 23:41:25 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3J6ejpO066376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2012 08:40:45 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F8FB36C.4020209@uijterwaal.nl> Date: Thu, 19 Apr 2012 08:40:44 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Steve Baillargeon References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: "ippm@ietf.org" , Al Morton , "matt@internet2.edu" Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 06:41:37 -0000 On 18/04/2012 16:03, Steve Baillargeon wrote: > Hi > >>> In summary, we have a two-way measurement protocol spec that could really >>> use a lot of work to resolve issues of clarity, existing patches, plus >>> unusual security features, and if Henk's poll earlier this year is >>> accurate, no one willing to do the work. And it is a lot of work. > > I agree that TWAMP is far from perfect. I also agree the contribution level > at the IPPM is fairly low (except for Al who drives most of the new > contributions) but I do not necessarily agree the poll represent an industry > consensus. TWAMP does what it is supposed to be doing, perhaps it isn't perfect, but it is good enough. The way the spec is written down, is not. TWAMP started by taking another protocol (OWAMP), the first document just listed what has to be changed and there have been many modifications since then. The result is that the current TWAMP spec is scattered of a number of documents and not everything is written down clearly. People do feel the need for a single document that describes TWAMP from top to bottom and can be used by somebody who wants to implement it. Creating this document is mainly a matter of editing, all the elements are there, "all" that the editor has to do, is take them, put them into a logical order and make sure that the text is consistent. "all" is an understatement, as it is a lot of work. Currently there doesn't seem to be anybody who has the time, money and knowledge available to take on this job. That was the outcome of the poll: we need it, but we don't have time to do it now. > It sounds like Al has already decided to pull the plug on OWAMP and TWAMP. Is > it the consensus of the WG? Do we need a draft comparing the pros and cons of > Cisco IP SLA vs TWAMP in order to make a better decision? I don't think the working group has reached a consensus on anything yet, the only thing that happened is that an individual submission draft was announced to the group and people have said that this is interesting and should be discussed. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From jerome.benoit@grenouille.com Mon Apr 23 11:56:18 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33B21F8639 for ; Mon, 23 Apr 2012 11:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlcr2takoQuO for ; Mon, 23 Apr 2012 11:56:17 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 486E821F8636 for ; Mon, 23 Apr 2012 11:56:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 56A1A7F430 for ; Mon, 23 Apr 2012 20:56:16 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szOqrY9G-tiW for ; Mon, 23 Apr 2012 20:56:14 +0200 (CEST) Received: from nemesis.grenouille.com (bea13-2-82-239-143-199.fbx.proxad.net [82.239.143.199]) by laposte.grenouille.com (Postfix) with ESMTP id 5C0F77F411 for ; Mon, 23 Apr 2012 20:56:14 +0200 (CEST) Received: from nemesis.grenouille.com (nemesis.grenouille.com [127.0.0.1]) by nemesis.grenouille.com (Postfix) with ESMTP id 0FAB760C96 for ; Mon, 23 Apr 2012 20:56:14 +0200 (CEST) Date: Mon, 23 Apr 2012 20:56:13 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: ippm@ietf.org Message-ID: <20120423205613.52440897@nemesis.grenouille.com> In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> Organization: Grenouille.com X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Uci18e8YQWiUXzI0dWpWIjg"; protocol="application/pgp-signature" Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:56:18 -0000 --Sig_/Uci18e8YQWiUXzI0dWpWIjg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 18 Apr 2012 10:03:06 -0400 Steve Baillargeon wrote: > Hi >=20 > >>In summary, we have a two-way measurement protocol spec that could > >>really use a lot of work to resolve issues of clarity, existing > >>patches, plus unusual security features, and if Henk's poll earlier > >>this year is accurate, no one willing to do the work. And it is a > >>lot of work. >=20 > I agree that TWAMP is far from perfect. I also agree the contribution > level at the IPPM is fairly low (except for Al who drives most of the > new contributions) but I do not necessarily agree the poll represent > an industry consensus. As far as I know, many vendors have already > implemented TWAMP and I suspect most of them are expecting the WG to > improve it over time. I know it requires work but I assume it will > also be work to improve the IPR-protected IP SLA protocol over time. > On the other hand, I suspect these new IP SLA related contributions > will mostly come from Cisco and Al. The measurement control side of OWAMP, TWAMP or cisco-sla protocol are not NAT friendly and mostly because of the datagram-based protocol, it make them hard (or impossible) to extent. There's also the high traffic for large-scale measurement, just to control the measurement. That's why I still think that a datagram-based approach for measurement control is just a real bad idea.=20 Regards, --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/Uci18e8YQWiUXzI0dWpWIjg Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk+Vpc0ACgkQ+qDLUJ/pFh2zFwCfVwkWU0rSdNPXurmLZbwMiElS Y+UAoMxdetkbCA03hxd2CLLr9PlaS1uC =FKwF -----END PGP SIGNATURE----- --Sig_/Uci18e8YQWiUXzI0dWpWIjg-- From boote@internet2.edu Mon Apr 23 12:50:48 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D7521F84D3 for ; Mon, 23 Apr 2012 12:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvAtRTxAZJJ9 for ; Mon, 23 Apr 2012 12:50:47 -0700 (PDT) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id 670BA21F84B5 for ; Mon, 23 Apr 2012 12:50:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id C7650100047; Mon, 23 Apr 2012 15:50:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlObtP47j50i; Mon, 23 Apr 2012 15:50:42 -0400 (EDT) Received: from [10.6.159.9] (unknown [63.238.48.2]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id DE2EE10003B; Mon, 23 Apr 2012 15:50:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: "Jeff W. Boote" In-Reply-To: <20120423205613.52440897@nemesis.grenouille.com> Date: Mon, 23 Apr 2012 13:50:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0C517358-3CDA-49D2-AB73-29C39C6CD67D@internet2.edu> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE79C1CC@HE111648.emea1.cds.t-internal.com> <201204021502.q32F21Iq000861@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA1A2@HE111648.emea1.cds.t-internal.com> <201204031233.q33CXjX6026537@alpd052.aldc.att.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> <20120423205613.52440897@nemesis.grenouille.com> X-Mailtags: { "mailTagsKeyWords" : ["EMAILLIST", "IETF"]} To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= X-Mailtags-Uuid: 1B1907F9-0074-4B2E-B708-F5835C2FF697 X-Keywords: EMAILLIST IETF X-Mailtags-Timestamp: 2012-04-23 13:50:40 -0600 X-Mailtags-Version: 2.5 X-Mailer: Apple Mail (2.1084) Cc: ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:50:48 -0000 On Apr 23, 2012, at 12:56 PM, J=E9r=F4me Benoit wrote: > On Wed, 18 Apr 2012 10:03:06 -0400 > Steve Baillargeon wrote: >=20 >> Hi >>=20 >>>> In summary, we have a two-way measurement protocol spec that could >>>> really use a lot of work to resolve issues of clarity, existing >>>> patches, plus unusual security features, and if Henk's poll earlier >>>> this year is accurate, no one willing to do the work. And it is a >>>> lot of work. >>=20 >> I agree that TWAMP is far from perfect. I also agree the contribution >> level at the IPPM is fairly low (except for Al who drives most of the >> new contributions) but I do not necessarily agree the poll represent >> an industry consensus. As far as I know, many vendors have already >> implemented TWAMP and I suspect most of them are expecting the WG to >> improve it over time. I know it requires work but I assume it will >> also be work to improve the IPR-protected IP SLA protocol over time. >> On the other hand, I suspect these new IP SLA related contributions >> will mostly come from Cisco and Al. >=20 > The measurement control side of OWAMP, TWAMP or cisco-sla protocol are > not NAT friendly and mostly because of the datagram-based protocol, it > make them hard (or impossible) to extent. There's also the high > traffic for large-scale measurement, just to control the measurement. > That's why I still think that a datagram-based approach for = measurement > control is just a real bad idea.=20 The 'control side' of OWAMP is TCP:861 and not datagram based. The = 'measurement' is datagram based, because it is measuring the speed of = datagrams. Jeff >=20 > Regards, >=20 > --=20 > J=E9r=F4me Benoit aka fraggle > La M=E9t=E9o du Net - http://grenouille.com > OpenPGP Key ID : 9FE9161D > Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From jerome.benoit@grenouille.com Mon Apr 23 14:27:24 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0854221E8026 for ; Mon, 23 Apr 2012 14:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU7cvGU9N267 for ; Mon, 23 Apr 2012 14:27:23 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id DD80821E8020 for ; Mon, 23 Apr 2012 14:27:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 04AAD7F430; Mon, 23 Apr 2012 23:27:22 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Iupm+gZRAI9; Mon, 23 Apr 2012 23:27:20 +0200 (CEST) Received: from nemesis.grenouille.com (bea13-2-82-239-143-199.fbx.proxad.net [82.239.143.199]) by laposte.grenouille.com (Postfix) with ESMTP id 0B7837F411; Mon, 23 Apr 2012 23:27:20 +0200 (CEST) Received: by nemesis.grenouille.com (Postfix, from userid 1000) id 9F7C460CBD; Mon, 23 Apr 2012 23:27:19 +0200 (CEST) Date: Mon, 23 Apr 2012 23:27:19 +0200 From: =?iso-8859-1?B?Suly9G1l?= Benoit To: "Jeff W. Boote" Message-ID: <20120423212719.GA20290@nemesis.grenouille.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> <20120423205613.52440897@nemesis.grenouille.com> <0C517358-3CDA-49D2-AB73-29C39C6CD67D@internet2.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <0C517358-3CDA-49D2-AB73-29C39C6CD67D@internet2.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:27:24 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Mon, Apr 23, 2012 at 01:50:40PM -0600, Jeff W. Boote a =E9crit: > >=20 > > The measurement control side of OWAMP, TWAMP or cisco-sla protocol are > > not NAT friendly and mostly because of the datagram-based protocol, it > > make them hard (or impossible) to extent. There's also the high > > traffic for large-scale measurement, just to control the measurement. > > That's why I still think that a datagram-based approach for measurement > > control is just a real bad idea.=20 >=20 > The 'control side' of OWAMP is TCP:861 and not datagram based. The 'measu= rement' is datagram based, because it is measuring the speed of datagrams. >=20 I suppose you've misread the RFC :) Even the "Hello" response from the control server is a datagram. =20 There's no single ABNF rules in these RFCs. I'm just saying that none of these RFCs met my needs to run large scale measurement campaign from the network edge so we've chosen a RESTful API and JSON syntax to express a way to control the measurement tools' set of f= unctionnalities and capabilities. Cheers. --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+VyTcACgkQ+qDLUJ/pFh25lQCghKBFWZHGi/b66lK/UclPzlGR mzQAoIl5jq+lJNDk1yScaG+k1/dTv6bK =hYHG -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From acmorton@att.com Mon Apr 23 14:48:04 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC3A21E8041 for ; Mon, 23 Apr 2012 14:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.441 X-Spam-Level: X-Spam-Status: No, score=-105.441 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvezrgdrmCdu for ; Mon, 23 Apr 2012 14:48:03 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 8919C21E803A for ; Mon, 23 Apr 2012 14:48:03 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 31ec59f4.0.485537.00-450.1347421.nbfkord-smmo03.seg.att.com (envelope-from ); Mon, 23 Apr 2012 21:48:03 +0000 (UTC) X-MXL-Hash: 4f95ce132d0bccdd-067fc2d2f9dfc544da8e5336fa23ec7d222faf2e Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3NLm2jn023297 for ; Mon, 23 Apr 2012 17:48:03 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3NLlusH023254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2012 17:47:56 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Mon, 23 Apr 2012 17:47:26 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3NLlQ0X023957 for ; Mon, 23 Apr 2012 17:47:26 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3NLlKpY023731 for ; Mon, 23 Apr 2012 17:47:20 -0400 Message-Id: <201204232147.q3NLlKpY023731@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-227-140.vpn.east.att.com[135.70.227.140](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120423214410gw1004or00e>; Mon, 23 Apr 2012 21:44:10 +0000 X-Originating-IP: [135.70.227.140] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Apr 2012 17:48:31 -0400 To: =?iso-8859-1?Q?J=E9r=F4me?= Benoit From: Al Morton In-Reply-To: <20120423212719.GA20290@nemesis.grenouille.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CAF14@HE111648.emea1.cds.t-internal.com> <4F86BA62.3080608@uijterwaal.nl> <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> <20120423205613.52440897@nemesis.grenouille.com> <0C517358-3CDA-49D2-AB73-29C39C6CD67D@internet2.edu> <20120423212719.GA20290@nemesis.grenouille.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=1ddunAWZQ7IA:10 a=PDMPHasUweMA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=qnErwNonvH8ix2Zj9JIA:9 a=wPNLvfGTeEIA:10] Cc: ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:48:04 -0000 At 05:27 PM 4/23/2012, J=E9r=F4me Benoit wrote: >...I'm just saying that none of these RFCs met my needs to run large scale >measurement campaign from the network edge so we've chosen a RESTful API >and JSON syntax to express a way to control the=20 >measurement tools' set of functionnalities and capabilities. Interesting, care to share some specs with ippm? Al From jerome.benoit@grenouille.com Mon Apr 23 15:49:32 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF8A21F8589 for ; Mon, 23 Apr 2012 15:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfq20ii8tEUU for ; Mon, 23 Apr 2012 15:49:31 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 76BFE21F8582 for ; Mon, 23 Apr 2012 15:49:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 91E7C7F432; Tue, 24 Apr 2012 00:49:30 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFe1MAgs0EHe; Tue, 24 Apr 2012 00:49:28 +0200 (CEST) Received: from nemesis.grenouille.com (bea13-2-82-239-143-199.fbx.proxad.net [82.239.143.199]) by laposte.grenouille.com (Postfix) with ESMTP id 5B3517F430; Tue, 24 Apr 2012 00:49:28 +0200 (CEST) Received: by nemesis.grenouille.com (Postfix, from userid 1000) id EFD7D60CBD; Tue, 24 Apr 2012 00:49:27 +0200 (CEST) Date: Tue, 24 Apr 2012 00:49:27 +0200 From: =?iso-8859-1?B?Suly9G1l?= Benoit To: Al Morton Message-ID: <20120423224927.GA20986@nemesis.grenouille.com> References: <201204121219.q3CCJRij008598@alpd052.aldc.att.com> <4F8BEAD9.6090600@uijterwaal.nl> <4F8D9919.9080007@mti-systems.com> <4F8E7BCE.4010306@uijterwaal.nl> <201204181316.q3IDGx0i030800@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF1E2C84C539@EUSAACMS0701.eamcs.ericsson.se> <20120423205613.52440897@nemesis.grenouille.com> <0C517358-3CDA-49D2-AB73-29C39C6CD67D@internet2.edu> <20120423212719.GA20290@nemesis.grenouille.com> <201204232147.q3NLlKcg023730@alpd052.aldc.att.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <201204232147.q3NLlKcg023730@alpd052.aldc.att.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ippm@ietf.org Subject: Re: [ippm] draft-cisco-sla-protocol X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 22:49:32 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Mon, Apr 23, 2012 at 05:48:31PM -0400, Al Morton a =E9crit: > At 05:27 PM 4/23/2012, J=E9r=F4me Benoit wrote: > >...I'm just saying that none of these RFCs met my needs to run large sca= le > >measurement campaign from the network edge so we've chosen a RESTful API > >and JSON syntax to express a way to control the measurement tools' > >set of functionnalities and capabilities. >=20 > Interesting, care to share some specs with ippm? > Al Sure, we're a FOSS project for the best and the worse. The best : the measurement agent code is readable and under heavy developement, we still lack a stable API to manipulate packets in a asynchronous way and a syntax to describe some common packets train. The worse : the lack of documentation on the active probe already doable. An example of JSON file to run an active measurement:=20 {"probe": // The probe definition part=20 // The probe module to load {"name":["delay","round_trip","icmp","bin"] // The definition that will define how to send the probe : the // time part ,"send": // The time sequence definition : repeat 3 times {"seq": {"repeat": {"count":3 // repeat periodically each period (that // can be poisson, gamma, uniform time // sequence, some time sequence can be // composed, some not ,"seq":{"periodic":{"period":3.0}} } } } // The definition that define how to receive the send probe : the time // part ,"recv": {"seq": {"repeat": {"count":2 ,"seq":{"periodic":{"period":0.50}} } } } // How to run the probe=20 ,"parallel": [ {"mark":null // The probe definition keywork that contain // probe specific syntax, here landmark name and // ICMP type 8 packet size ,"data": {"host":"free.fr" ,"size":16 } } ,{"mark":null ,"data": {"host":"google.fr" ,"size":16 } } ] } // Where to write the result, might be file, RESTful server URI, stdout ,"sample": {"file":"-" } } It's just an example to show the basic ideas for active probing. Security mechanism are lacking and the syntax might be refined but in versionned fashion.=20 The very few documentation is in French (we're a French FOSS project). We plan te write a full documentation. Time to sleep here. --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+V3HcACgkQ+qDLUJ/pFh3fdQCgndKFYYmB3RbVmYeI5c30YDeV wRQAoJ0oZei8lOXbJ1nJ0o6jjg+lvgHW =bQCt -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From henk@uijterwaal.nl Tue Apr 24 07:32:28 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8358C21F8830 for ; Tue, 24 Apr 2012 07:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAYXeeaKsjQn for ; Tue, 24 Apr 2012 07:32:27 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id A059621F8839 for ; Tue, 24 Apr 2012 07:32:23 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3OEVnx2021543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2012 16:31:50 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F96B955.5010206@uijterwaal.nl> Date: Tue, 24 Apr 2012 16:31:49 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: ippm@ietf.org References: <4F8BC42D.2010003@uijterwaal.nl> <4F8BCBF1.9000907@uijterwaal.nl> In-Reply-To: <4F8BCBF1.9000907@uijterwaal.nl> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [ippm] Fwd: Re: WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 14:32:28 -0000 IPPM Group, On 16/04/2012 09:36, Henk Uijterwaal wrote: > -------- Original Message -------- > Subject: Re: WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt > Date: Mon, 16 Apr 2012 09:03:09 +0200 > From: Henk Uijterwaal > To: Henk Uijterwaal > > IPPM Group, > >> This starts a WGLC for the draft: >> >> TWAMP Value-Added Octets >> draft-ietf-ippm-twamp-value-added-octets-01.txt >> >> Please review the draft and raise any issues by Monday, April 16, 2012, >> 8:00 UTC. > > After the start of the WGLC (on 29/3), there was some discussion on the > draft and a new version has been submitted (-02, on April 4). I haven't > seen any feedback on this one though. > > As a result, I'm extending the WGLC by one week, until April 23. If you > commented on the previous version, please look at the new one and let > me know if this addresses your comments. A one-line review ("yes, I've > read it and I'm now {happy|still not happy} with the document") is > already quite useful. If nobody speaks up, I'm going to assume that > everybody _is_ happy with the document. Nobody spoke up, so I'm assuming that we are all happy with the -02 version of the document. It will be sent to the IESG in the next days. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From internet-drafts@ietf.org Thu Apr 26 05:52:59 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA06E21F8823; Thu, 26 Apr 2012 05:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEqpnSzxjwAM; Thu, 26 Apr 2012 05:52:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74E21F87A7; Thu, 26 Apr 2012 05:52:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120426125257.24661.25590.idtracker@ietfa.amsl.com> Date: Thu, 26 Apr 2012 05:52:57 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-value-added-octets-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:52:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group = of the IETF. Title : Ericsson TWAMP Value-Added Octets Author(s) : Steve Baillargeon Christofer Flinta Andreas Johnsson Svante Ekelin Filename : draft-ietf-ippm-twamp-value-added-octets-03.txt Pages : 17 Date : 2012-04-26 This memo describes an extension to the TWAMP test protocol for identifying and managing packet trains, which enables measuring capacity metrics like the available path capacity, tight section capacity and UDP delivery rate in the forward and reverse path directions. This memo contains the description of a working prototype. It does not represent a consensus of the IETF community. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for measuring capacity metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octet= s-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octets= -03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-value-added-octets/ From henk@uijterwaal.nl Thu Apr 26 05:57:52 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8EA21F884F for ; Thu, 26 Apr 2012 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DHal1Xy+JqX for ; Thu, 26 Apr 2012 05:57:52 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3221F884D for ; Thu, 26 Apr 2012 05:57:51 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id q3QCvJgP021327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2012 14:57:20 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F99462F.8050803@uijterwaal.nl> Date: Thu, 26 Apr 2012 14:57:19 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF IPPM WG References: <20120426125257.24661.25590.idtracker@ietfa.amsl.com> In-Reply-To: <20120426125257.24661.25590.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [ippm] I-D Action: draft-ietf-ippm-twamp-value-added-octets-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:57:52 -0000 IPPM group, > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the IP Performance Metrics Working > Group of the IETF. This version fixes a couple of nits discovered in the publication process. There is no new content. Henk > > Title : Ericsson TWAMP Value-Added Octets Author(s) : Steve > Baillargeon Christofer Flinta Andreas Johnsson Svante Ekelin Filename > : draft-ietf-ippm-twamp-value-added-octets-03.txt Pages : 17 Date > : 2012-04-26 > > This memo describes an extension to the TWAMP test protocol for identifying > and managing packet trains, which enables measuring capacity metrics like the > available path capacity, tight section capacity and UDP delivery rate in the > forward and reverse path directions. > > This memo contains the description of a working prototype. It does not > represent a consensus of the IETF community. The IETF community is currently > working on the problem statement and has not reached consensus on the > preferred method for measuring capacity metrics. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octets-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ippm-twamp-value-added-octets-03.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-value-added-octets/ > > _______________________________________________ ippm mailing list > ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From anmolsheth@gmail.com Sun Apr 29 00:27:30 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0BF21F84D9 for ; Sun, 29 Apr 2012 00:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJIzw7hZSGbs for ; Sun, 29 Apr 2012 00:27:29 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEEB21F84D8 for ; Sun, 29 Apr 2012 00:27:29 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2550759pbb.31 for ; Sun, 29 Apr 2012 00:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7n9c8MzUnat1+QSz0dihji4eCbHsvSXOWr35/Qj5GUs=; b=laS+GeVUr3vEcYUgDnc54Vu1119FKMwvqo14aI5ngEOfWxpY3tRZ4iU552jc9sL9lk +dhBSHqkzGjkprYN40Zn+TCCfCjsK4EL4SpusqiF3SacHrnqzQTa09LhdSVMh1eETou/ fsBfCjrwuzC7oVEOVW/oKKrvLsSyzfgjXYOBGB5jefawflJij8HhOqoXoagS+p+Y2alj iWFZUvljhLr+jqSIPIX/uoJJD6l10ETe10E85vuUdLQ6E42YxqybqKH5th78mfc0okgZ YH/reyLlDb2Ov84PBFspuV3RAz7ltK09SD6ubTqDBLGuuqzIneCIfeQTJDly1iWeo8Vr BbUg== MIME-Version: 1.0 Received: by 10.68.219.226 with SMTP id pr2mr29867320pbc.66.1335684449246; Sun, 29 Apr 2012 00:27:29 -0700 (PDT) Received: by 10.142.232.6 with HTTP; Sun, 29 Apr 2012 00:27:29 -0700 (PDT) Date: Sun, 29 Apr 2012 00:27:29 -0700 Message-ID: From: Anmol Sheth To: ippm@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff24d29211e8d04becc459f X-Mailman-Approved-At: Sun, 29 Apr 2012 05:07:06 -0700 Subject: [ippm] CFP ACM HomeSys 2012 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 07:30:00 -0000 --e89a8ff24d29211e8d04becc459f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable ------------------------------------------------------------ ------------------------- Our apologies if you receive multiple copies of this CFP ------------------------------------------------------------ ------------------------- ACM HomeSys 2012 1st ACM Workshop on Systems and Infrastructure for the Digital Home September 8th, 2012 - Pittsburgh, PA, USA Held in conjunction with Ubicomp 2012 Website: https://sites.google.com/site/homesys2012/ Ubiquitous computing has often presented the future digital home as a mix of rich computing, networking and sensing infrastructure that seamlessly interacts with the inhabitants to enable new and enjoyable experiences, applications and services. Today=92s reality, however, is far from that. Th= e digital home has already migrated into many homes in a piecemeal manner. The home of today is a complex mix of heterogeneous technologies, operating with limited coordination, and certainly not offering the set of services originally imagined. Furthermore as the number of devices inside the home and their functionality continue to increase, the complexity involved in managing, troubleshooting and securing digital technology in the home will become a major overhead for users and a barrier to the adoption of new technology. Overcoming these barriers requires a user-centered approach to developing systems for the digital home. Such an approach would provide careful considerations to the needs of inhabitants in the home who may lack the technical skills needed to setup, manage and secure digital systems or the inclination to do so. HomeSys will foster this approach by bringing together researchers and practitioners from the multiple disciplines of networking, systems, HCI, ubiquitous computing and security. HomeSys will provide a platform to share new ideas and experiences and to discuss the challenges and important questions posed by today=92s and future technology in the digital home. HomeSys builds upon the two successful ACM SIGCOMM HomeNets workshops (2011, 2010) and aims to be the premier workshop for user-centered digital home technology. We solicit stimulating, original, previously unpublished ideas on completed work, position papers, and/or work-in-progress papers. We further encourage papers that propose new research directions or could generate lively debate at the workshop. Topics of interest include, but are not limited to: * User centered methods and techniques for home systems development * Monitoring, troubleshooting and management of systems and infrastructure * Deployments and assessments of home systems * Automatic and user driven approaches to the configuration of digital home systems * Networked digital home applications and measurements (Video Streaming, Games, etc). * User interfaces for complex digital home systems * Home networking technologies (xDSL/Cable, WiFi, Bluetooth, 3/4G, femto cells, power lines, satellite, sensor networks) * Studies of inhabitants use of digital technology in domestic settings * Smart technologies for home utilities (e.g., smart grid). * Users understandings of environmental monitoring technologies. * Incorporation of mobile devices within home networks and home systems * Studies of mobility and the link between home and other environments * Cloud-aware Home Infrastructures * Security and privacy issues in digital home systems * Home infrastructures and neighborhood/community infrastructures. * Home automation with novel sensing technologies * Tools and interfaces for digital home systems Important Dates: * Paper submission: 1st June 2012 (midnight PST) * Notification: 29th June 2012 * Camera ready:July 6th 2012 * Workshop date: September 8th 2012 Submission Guidelines: * Submissions must be as a single PDF file no longer than 6 pages in length= . * They must include the authors' names and affiliations for single-blind peer reviewing by the program committee. * Submissions must follow the ACM formatting guidelines. * Authors of accepted papers are expected to present their papers at the workshop. * Submissions must be original work not under review at any other workshop, conference, or journal. * Papers should be submitted via the submission site. --e89a8ff24d29211e8d04becc459f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable --------------------------------------------= -----------------------------------------
Our apologies if you receive multiple copies of this CFP
--------------------------------------------= -----------------------------------------

ACM HomeSys 2012
1st ACM Workshop on= Systems and Infrastructure for the Digital Home
September 8th, 2012 - Pittsburgh, PA, USA
Held i= n conjunction with Ubicomp 2012


Ubiquitous computing = has often presented the future digital home as a mix of rich computing, net= working and sensing infrastructure that seamlessly interacts with the inhab= itants to enable new and enjoyable experiences, applications and services. = Today=92s reality, however, is far from that. The digital home has already = migrated into many homes in a piecemeal manner. The home of today is a comp= lex mix of heterogeneous technologies, operating with limited coordination,= and certainly not offering the set of services originally imagined. Furthe= rmore as the number of devices inside the home and their functionality cont= inue to increase, the complexity involved in managing, troubleshooting and = securing digital technology in the home will become a major overhead for us= ers and a barrier to the adoption of new technology.

Overcoming these barriers requires a user-centered ap= proach to developing systems for the digital home. Such an approach would p= rovide careful considerations to the needs of inhabitants in the home who m= ay lack the technical skills needed to setup, manage and secure digital sys= tems or the inclination to do so.

HomeSys will foster this approach by bringing togethe= r researchers and practitioners from the multiple disciplines of networking= , systems, HCI, ubiquitous computing and security. HomeSys will provide a p= latform to share new ideas and experiences and to discuss the challenges an= d important questions posed by today=92s and future technology in the digit= al home. HomeSys builds upon the two successful ACM SIGCOMM HomeNets worksh= ops (2011, 2010) and aims to be the premier workshop for user-centered digi= tal home technology.

We solicit stimulating, original, previously unpublis= hed ideas on completed work, position papers, and/or work-in-progress paper= s. We further encourage papers that propose new research directions or coul= d generate lively debate at the workshop.

Topics of interest include, but are not limited to:

* User centered methods and techniques= for home systems development
* Monitoring, tro= ubleshooting and management of systems and infrastructure
* Deployments and assessments of home systems
<= span style>* Automatic and user driven approaches to the configuration of d= igital home systems
* Networked digital home ap= plications and measurements (Video Streaming, =A0Games, etc).
* User interfaces for complex digital home systems
* Home networking technologies (xDSL/Cable, WiFi, Bluetooth= , 3/4G, femto cells, power lines, satellite, sensor networks)
* Studies of inhabitants use of digital technology in domestic = settings
* Smart technologies for home utilitie= s (e.g., smart grid).
* Users understandings of= environmental monitoring technologies.
* Incorporation of mobile devices within home networks and home= systems
* Studies of mobility and the link bet= ween home and other environments
* Cloud-aware = Home Infrastructures
* Security and privacy issues in digital home systems* Home infrastructures and neighborhood/community infras= tructures.
* Home automation with novel sensing= technologies
* Tools and interfaces for digital home systems

Important Dates:
* Paper= submission: 1st June 2012 (midnight PST)
* Not= ification: 29th June 2012
* Camera ready:July 6th 2012
* Work= shop date: September 8th 2012

Submiss= ion Guidelines:
* Submissions must be as a sing= le PDF file no longer than 6 pages in length.
* They must include the authors' names and affiliations for= single-blind peer reviewing by the program committee.=A0
<= span style>* Submissions must follow the ACM formatting guidelines.=A0
* Authors of accepted papers are expected to present their pape= rs at the workshop.=A0
* Submissions must be or= iginal work not under review at any other workshop, conference, or journal.= =A0
* Papers should be submitted via the submission site. --e89a8ff24d29211e8d04becc459f--