From prvs=3838f656de=samita.chakrabarti@ericsson.com Mon May 6 10:16:52 2013 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 5864321F86E7 for ; Mon, 6 May 2013 10:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.145 X-Spam-Level: X-Spam-Status: No, score=0.145 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_FONT_FACE_BAD=0.884, 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 07J17sI9nlEr for ; Mon, 6 May 2013 10:16:44 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79E1B21F92CB for ; Mon, 6 May 2013 10:16:36 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-ce-5187e573d2b1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 56.4D.26377.375E7815; Mon, 6 May 2013 19:16:36 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 6 May 2013 13:16:35 -0400 From: Samita Chakrabarti To: dengguangqing , ippm Thread-Topic: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Thread-Index: AQHORP0NAj12+DMrGEGL6K2/Ym9zb5j33t2w Date: Mon, 6 May 2013 17:16:34 +0000 Message-ID: References: <201304300110302534533@cnnic.cn> In-Reply-To: <201304300110302534533@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01BEC5093eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXSPn27J0/ZAg72LOS1m/3nMZtHz4B2z A5PHpmuSHkuW/GQKYIritklKLCkLzkzP07dL4M64deI0e8GxqIoXT7kaGKf7dTFyckgImEjc mDKNBcIWk7hwbz1bFyMXh5DAUUaJzxt3MUI4yxglTnTMZAepYhOwkujo3QNmiwg4SDTPvcsK YgsLeEq87pvICBH3ktj/agkrhG0ksfDFRbANLAIqEheufmUDsXkFfCWan30DinMALSiQODJB GSTMKaArMXHiBLASRqCDvp9awwRiMwuIS9x6Mp8J4lABiSV7zjND2KISLx//Y4WwlSW+z3nE AlGfL7G6eTMzxCpBiZMzn7BMYBSZhWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy +AJG9lWMHKXFqWW56UYGmxiBsXNMgk13B+Oel5aHGKU5WJTEeaO4GgOFBNITS1KzU1MLUovi i0pzUosPMTJxcIIILqkGxp2PGi1qReI2b1zH65VQc8sw9+Cd6ynprduPTQpQswy8zZ564omf bLnK32mrOPsdNBSiuEsnfUyyEn50TWC50m+BM8f+v19/6++6uCu2lnvbbUv1tkRNyDuvUeWk FLKz4oqoo/j06ZZaaSdFfx92jPtWskKW3fjC+Z/CsoHC7dlbDwiKLGM+qsRSnJFoqMVcVJwI AE4tAGlwAgAA Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-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: Mon, 06 May 2013 17:16:53 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01BEC5093eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks. That was my point too. -Samita ________________________________ From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gua= ngqing Deng Sent: Monday, April 29, 2013 10:11 AM To: ippm Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt It is revealed that the proportion of Internet traffic caused by peer-to-pe= er file and video sharing is still not low, see http://www.cisco.com/en/US/= solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_n= s827_Networking_Solutions_White_Paper.html. Also, it is predicted that the = mobile data traffic will increase quickly in the next years. With the devel= opment of wireless access technology, people are increasingly inclined to u= pload the pictures, audios and videos gathered by their mobile phones to so= cial websites and so on for sharing. In a word, Internet users are not only= downloading content from but also creating and uploading content to Intern= et (and other Internet users).So it may be necessary to let this document a= llow both symmetric and asymmetric packet sizes and rates in forward and re= verse direction. ________________________________ Guangqing Deng cnnic From: Samita Chakrabarti Date: 2013-04-03 09:21 To: ippm@ietf.org; Brian Trammell Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Hello : This is regarding my comment at the IETF86 ippm meeting for the section 5 (= Test Protocol Control & Generation Requirements) section. Toward the end of the section, the document states: "The ability to control packet size on the tested path and enable asymmetrical packet size testing in a two-way architecture are REQUIRED." Request: Relax the requirement for "assymetrical" packet size so that the r= equirement document allows both symmetric and assymetric packet sizes in fo= rward and reverse direction. I was asked to provide a usecase for the request and here it is: Normally in fixed Broadband network, so far we are mostly interested with d= ata traffic download and thus we can see 80/20 (apprx) traffic distribution= in forward and reverse direction. Most often in the forward path we have a= ctual traffic packets and in upward direction it is most likely short packe= t sizes due to acknowledgements etc. However, looking forward in current and future deployment and in Mobile Bro= adband networks when we consider applications like VoLTE, peer-to-peer comm= unication, video-chat etc. we can easily expect that forward and reverse di= rection traffic rate and sizes are equivalent. Since the converged network= carries both mobile and fixed broadband traffic, it is important for many = carriers to measure the IP-network performance by using active measurement = protocol with same packet size of the traffic and in some cases with same r= ate in both directions ( i,e both symmetric and assymetric). Thus, we will need to allow both symmetric and assymetric measurement packe= t sizes and rates in forward and reverse direction. Hope this helps in understanding the requirement. Best regards, -Samita --_000_ECA43DA70480A3498E43C3471FB2E1F01BEC5093eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks. That was my poin= t too.
 
-Samita

From: ippm-bounces@ietf.org [mailto= :ippm-bounces@ietf.org] On Behalf Of Guangqing Deng
Sent: Monday, April 29, 2013 10:11 AM
To: ippm
Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-0= 2.txt

<= font color=3D"#000000" size=3D"3" face=3D"Times New Roman">It is revealed t= hat the proportion of Internet traffic caused by peer-to-peer file and vide= o sharing is still not low, see http://www.cisco.com/en/US/solutions/collat= eral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_= Solutions_White_Paper.html. Also, it is predicted that the mobile data traffic will increase quickly i= n the next years. With the development of wireless access technology, peopl= e are increasingly inclined to upload the pictures, audios and videos gathe= red by their mobile phones to social websites and so on for sharing. In a word, Internet users are not only dow= nloading content from but also creating and uploading content to Internet (= and other Internet users).So it may be necessary to let this document allow= both symmetric and asymmetric packet sizes and rates in forward and reverse direction.

 
Guangqing Deng
cnnic 
 
Date: 2013-04-03 09:21
To: ippm@ietf.org; Brian Trammell
Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-pro= blem-02.txt
 
Hello :=
 <= /div>
This is regarding my comment at the IETF86 ippm me= eting for the section 5 (Test Protocol Control & Generation Requirements) section.
Toward the end of the section, the document states:
"The ability to control packet size on the tested path and enab= le
asymmetrical packet size testing in a two-way architecture are
REQUIRED."
 
Request: Relax the requirement for "assymetrical" packet s= ize so that the requirement document allows both symmetric and assymetric p= acket sizes in forward and reverse direction.
 
I was asked to provide a usecase for the request and here it is:
Normally in fixed Broadband network, so far we are mostly interested= with data traffic download and thus we can see 80/20 (apprx) traffic distr= ibution in forward and reverse direction. Most often in the forward path we have actual traffic packets and in upwar= d direction it is most likely short packet sizes due to acknowledgements et= c.
However, looking forward in current and future deployment and in Mob= ile Broadband networks when we consider applications like VoLTE, peer-to-pe= er communication, video-chat etc. we can easily expect that forward and reverse direction traffic rate and size= s are equivalent.  Since the converged network carries both mobile and= fixed broadband traffic, it is important for many carriers to measure the = IP-network performance by using active measurement protocol with same packet size of the traffic and in some case= s with same rate in both directions ( i,e both symmetric and assymetric).
Thus, we will need to allow both symmetric and assymetric measuremen= t packet sizes and rates in forward and reverse direction.
Hope this helps in understanding the requirement.
 
Best regards,
-Samita
 
 <= /div>
--_000_ECA43DA70480A3498E43C3471FB2E1F01BEC5093eusaamb103erics_-- From dave.taht@gmail.com Mon May 6 10:35:43 2013 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 0F17B21F8709 for ; Mon, 6 May 2013 10:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 vW7gnZVhlXty for ; Mon, 6 May 2013 10:35:42 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3E05521F86F0 for ; Mon, 6 May 2013 10:35:42 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e11so4432721iej.2 for ; Mon, 06 May 2013 10:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=k+16IYKm4TAtivV/Lhq8ur1cvR3r1e74kUl+tXObIyc=; b=pymnChbBmzqCCn2ykKhw6i2OeMSFDcvr/oCLaHf/eqiDKde5Twndh7Qx7G2h2tyDMD YamgJXz5Hblqsyb7gGAAyEkdADSGgbe1kmvSndrt5QzuG1SI3c+JXkxZ5gSuGiseNQuL paiAcvmmYiWhjhK903Cu4uZ26XVR4VamhrUfUttgRmaY5uUW82at8VZkReoJa0MRAK0+ rX3XsEoWaNnayxy/+Bq51Az+ZpkbwcqfPgg178A4yxS228F9JXgU2DsWZkNFei7bjQvn at5h8T9wMPN/eQpAnT8jzRvtQDERy0ZMvB9FZkWbI8KYral2i2S48TLjvgs53bt4KD/D Vblw== MIME-Version: 1.0 X-Received: by 10.42.26.12 with SMTP id d12mr7599320icc.1.1367861741834; Mon, 06 May 2013 10:35:41 -0700 (PDT) Received: by 10.64.7.51 with HTTP; Mon, 6 May 2013 10:35:41 -0700 (PDT) Received: by 10.64.7.51 with HTTP; Mon, 6 May 2013 10:35:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 May 2013 10:35:41 -0700 Message-ID: From: Dave Taht To: Samita Chakrabarti Content-Type: multipart/alternative; boundary=20cf3042702e39591d04dc1021db Cc: ippm@ietf.org Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-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: Mon, 06 May 2013 17:35:43 -0000 --20cf3042702e39591d04dc1021db Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Apr 2, 2013 9:21 PM, "Samita Chakrabarti" < samita.chakrabarti@ericsson.com> wrote: > > > Hello : > > This is regarding my comment at the IETF86 ippm meeting for the section 5 (Test Protocol Control & Generation Requirements) section. > Toward the end of the section, the document states: > "The ability to control packet size on the tested path and enable > asymmetrical packet size testing in a two-way architecture are > REQUIRED." > > Request: Relax the requirement for "assymetrical" packet size so that the requirement document allows both symmetric and assymetric packet sizes in forward and reverse direction. > > I was asked to provide a usecase for the request and here it is: > Normally in fixed Broadband network, so far we are mostly interested with data traffic download and thus we can see 80/20 (apprx) traffic distribution in forward and reverse direction. Incidentally I have been collecting data from a business cable user configured for 20mbit down and 7 Mbit up. Packets in each direction is nearly symmetrical 89% ratio. Bytes was 48%. An astounding percentage (over half) were marked CS1. Furthermore fq-codel is enabled on the uplink and it dropped 3.3% of the packets marked background over a 10 day period. So I think in the age of tcp window scaling=85 gdrive and the like some of our assumptions regarding edge network asymmetry already need to be revisited and analysis of stuff like my small scale testbed ramped up. Most often in the forward path we have actual traffic packets and in upward direction it is most likely short packet sizes due to acknowledgements etc. > However, looking forward in current and future deployment and in Mobile Broadband networks when we consider applications like VoLTE, peer-to-peer communication, video-chat etc. we can easily expect that forward and reverse direction traffic rate and sizes are equivalent. Since the converged network carries both mobile and fixed broadband traffic, it is important for many carriers to measure the IP-network performance by using active measurement protocol with same packet size of the traffic and in some cases with same rate in both directions ( i,e both symmetric and assymetric). > Thus, we will need to allow both symmetric and assymetric measurement packet sizes and rates in forward and reverse direction. > Hope this helps in understanding the requirement. > > Best regards, > -Samita > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --20cf3042702e39591d04dc1021db Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2013 9:21 PM, "Samita Chakrabarti" <samita.chakrabarti@ericsson.com> = wrote:
>
> =A0
> Hello :
> =A0
> This is regarding my comment at the IETF86 ippm meeting for the sectio= n 5 (Test Protocol Control & Generation Requirements) section.
> Toward the end of the section, the document states:
> "The ability to control packet size on the tested path and enable=
> asymmetrical packet size testing in a two-way architecture are
> REQUIRED."
> =A0
> Request: Relax the requirement for "assymetrical" packet siz= e so that the requirement document allows both symmetric and assymetric pac= ket sizes in forward and reverse direction.
> =A0
> I was asked to provide a usecase for the request and here it is:
> Normally in fixed Broadband network, so far we are mostly interested w= ith data traffic download and thus we can see 80/20 (apprx) traffic distrib= ution in forward and reverse direction.

Incidentally I have been collecting data from a business cab= le user configured for 20mbit down and 7 Mbit up.

Packets in each direction is nearly symmetrical 89% ratio.

Bytes was 48%. An astounding percentage (over half) were mar= ked CS1.

Furthermore fq-codel is enabled on the uplink and it dropped= 3.3% of the packets marked background over a 10 day period.

So I think in the age of tcp window scaling=85 gdrive and th= e like some of our assumptions regarding edge network asymmetry already nee= d to be revisited and analysis of stuff like my small scale testbed ramped = up.

Most often in the forward path we have actual traffic packet= s and in upward direction it is most likely short packet sizes due to ackno= wledgements etc.
> However, looking forward in current and future deployment and in Mobil= e Broadband networks when we consider applications like VoLTE, peer-to-peer= communication, video-chat etc. we can easily expect that forward and rever= se direction traffic rate and sizes are equivalent.=A0 Since the converged = network carries both mobile and fixed broadband traffic, it is important fo= r many carriers to measure the IP-network performance by using active measu= rement protocol with same packet size of the traffic and in some cases with= same rate in both directions ( i,e both symmetric and assymetric).
> Thus, we will need to allow both symmetric and assymetric measurement = packet sizes and rates in forward and reverse direction.
> Hope this helps in understanding the requirement.
> =A0
> Best regards,
> -Samita
> =A0
> =A0
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.iet= f.org/mailman/listinfo/ippm
>

--20cf3042702e39591d04dc1021db-- From mach.chen@huawei.com Tue May 14 02:09:33 2013 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 E0AE221F9048 for ; Tue, 14 May 2013 02:09:33 -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 v6Bnu7UE7iMQ for ; Tue, 14 May 2013 02:09:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AA44321F901B for ; Tue, 14 May 2013 02:09:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AST94241; Tue, 14 May 2013 09:09:22 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 10:08:47 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 10:09:15 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.134]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Tue, 14 May 2013 17:09:08 +0800 From: Mach Chen To: "ippm@ietf.org" Thread-Topic: What's the recharter status? Thread-Index: Ac5QgrAbTomvIzV+S+icIeHOgmvvGA== Date: Tue, 14 May 2013 09:09:07 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ippm] What's the recharter status? 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, 14 May 2013 09:09:34 -0000 Hi Folks, I just had a look at the latest charter text (2013-05-02 charter), seems th= at it does not reflect the recent new charter discussion/consensus. Does it= mean that the new charter was not approved or did I miss something? Many thanks, Mach From trammell@tik.ee.ethz.ch Tue May 14 02:37:38 2013 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 46CA621F8F7B for ; Tue, 14 May 2013 02:37:38 -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 pUpfsWdbY4Lj for ; Tue, 14 May 2013 02:37:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9FB21F8FF1 for ; Tue, 14 May 2013 02:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6DCD9D930C; Tue, 14 May 2013 11:37:28 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id x2TXuoe2gYPs; Tue, 14 May 2013 11:37:28 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2C4CDD9304; Tue, 14 May 2013 11:37:28 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: Date: Tue, 14 May 2013 11:37:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <376E52CB-1C91-463D-8BE9-C3B1C96B7E60@tik.ee.ethz.ch> References: To: Mach Chen X-Mailer: Apple Mail (2.1503) Cc: "ippm@ietf.org" Subject: Re: [ippm] What's the recharter status? 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, 14 May 2013 09:37:38 -0000 Hi, Mach, all, The charter is presently in IESG review (see = http://datatracker.ietf.org/doc/charter-ietf-ippm/); there will be some = changes to the charter following this review, which will be discussed on = the list following the review, to ensure the modified charter reflects = the recent consensus. Best regards, Brian On May 14, 2013, at 11:09 AM, Mach Chen wrote: > Hi Folks, >=20 > I just had a look at the latest charter text (2013-05-02 charter), = seems that it does not reflect the recent new charter = discussion/consensus. Does it mean that the new charter was not approved = or did I miss something? >=20 > Many thanks, > Mach > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From mach.chen@huawei.com Tue May 14 17:48:45 2013 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 E958C21F8E9A for ; Tue, 14 May 2013 17:48:45 -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 csKi-eIk1Jkb for ; Tue, 14 May 2013 17:48:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8625621F8545 for ; Tue, 14 May 2013 17:48:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARJ66516; Wed, 15 May 2013 00:48:39 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 01:48:09 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 01:48:38 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.134]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Wed, 15 May 2013 08:48:36 +0800 From: Mach Chen To: Brian Trammell Thread-Topic: [ippm] What's the recharter status? Thread-Index: Ac5QgrAbTomvIzV+S+icIeHOgmvvGP//gc6A//57txA= Date: Wed, 15 May 2013 00:48:35 +0000 Message-ID: References: <376E52CB-1C91-463D-8BE9-C3B1C96B7E60@tik.ee.ethz.ch> In-Reply-To: <376E52CB-1C91-463D-8BE9-C3B1C96B7E60@tik.ee.ethz.ch> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ippm@ietf.org" Subject: Re: [ippm] What's the recharter status? 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, 15 May 2013 00:48:46 -0000 Got it, thanks Brian! Best regards, Mach > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Tuesday, May 14, 2013 5:37 PM > To: Mach Chen > Cc: ippm@ietf.org > Subject: Re: [ippm] What's the recharter status? >=20 > Hi, Mach, all, >=20 > The charter is presently in IESG review (see > http://datatracker.ietf.org/doc/charter-ietf-ippm/); there will be some c= hanges > to the charter following this review, which will be discussed on the list= following > the review, to ensure the modified charter reflects the recent consensus. >=20 > Best regards, >=20 > Brian >=20 >=20 > On May 14, 2013, at 11:09 AM, Mach Chen wrote: >=20 > > Hi Folks, > > > > I just had a look at the latest charter text (2013-05-02 charter), seem= s that it > does not reflect the recent new charter discussion/consensus. Does it mea= n that > the new charter was not approved or did I miss something? > > > > Many thanks, > > Mach > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From a.botta@unina.it Fri May 24 07:42:46 2013 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 B50C521F93A6 for ; Fri, 24 May 2013 07:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 0sBcNtHDjB-m for ; Fri, 24 May 2013 07:42:42 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id D485C21F96E9 for ; Fri, 24 May 2013 07:42:39 -0700 (PDT) Received: from [192.168.1.248] (adsl-ull-41-140.46-151.net24.it [151.46.140.41]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r4OEgae9022149 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 24 May 2013 16:42:37 +0200 Message-ID: <519F7BF3.3080801@unina.it> Date: Fri, 24 May 2013 16:40:51 +0200 From: Alessio Botta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121123 Icedove/10.0.11 MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: YIC@zurich.ibm.com Subject: [ippm] CFP: ICNC 2014, Communication QoS and System Modeling Symposium, Feb 2014, Hawaii 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, 24 May 2013 14:42:46 -0000 (We apologize if you receive multiple copies of this email) ------------------------------------------------------------- Communication QoS and System Modeling Symposium at ICNC 2014: CALL FOR PAPER - First Announcement ------------------------------------------------------------- Communication QoS and System Modeling Symposium at the International Conference on Computing, Networking and Communications (ICNC) 2014 February 3-6, 2014, Honolulu, Hawaii, USA URL: http://www.conf-icnc.org/2014 =============== Important date =============== Paper submission: July 5, 2013 Paper Acceptance: Sept. 20, 2013 Camera-ready paper: Oct. 20, 2013 =============== Submission Guidelines =============== Please follow the author instructions at http://www.conf-icnc.org/2014/author.htm Direct paper submission link of this symposium is http://www.edas.info/newPaper.php?c=14505&track=31375 ============== Scope ============== Communication networks are designed to offer services to end-users with suitable Quality of Service (QoS) level. To such an end, network traffic should be analyzed and appropriately controlled so that the desired QoS requirements are achieved. The development of today’s applications, network technologies and standards greatly leverages modeling and design tools. Furthermore, different methodologies including analytical modeling, simulation, experimentation, and monitoring are needed to support designs of communication networks and services. The aim of the “Communication QoS and System Modeling” Symposium is to provide an international forum for the discussion of communications service provisioning, the quality and mechanisms to support such services as well as the techniques to model and assess the efficiency of communication networks. ============== List of Topics ============== Authors are invited to submit original technical papers covering but not limited to the topics of interest listed below: -- Quality, scalability, reliability, and performance in network and their services, including o Internet o Optical networks o Autonomic systems o Wireless and mobile networks o Wireless and mobile networks o Grid and distributed computing o Wireless and mobile networks o Multimedia networks in voice over IP and IPTV -- Performance of large-scale experimental platforms -- Standardization aspects of QoS and reliability -- Network Performance evaluation methodologies o Network simulation o Network modeling o Network measurement and monitoring -- Design of networks and their services -- Cross-layer design, modeling and optimization -- Traffic economics -- Application/service oriented networking -- Traffic workload modeling and characterization -- Traffic and workload control -- Traffic engineering and traffic theory -- Metrics and models for QoE ============== Symposium Organizers ============== Lydia Y. Chen IBM Zurich Research Laboratory Säumerstrasse 4 8803 Rüschlikon, Switzerland yic[AT]zurich.ibm.com Antonio Pescapé Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione University of Napoli ''Federico II'' Via Claudio, 21 - 80125, Napoli (Italy) pescape[AT]unina.it -- Alessio Botta, PhD Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione Università degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) [Room 3.09] Phone: +390817683865 - Fax: +390817683816 Skypeid: alessiobotta Email: a.botta@unina.it alessio.botta@consorzio-cini.it WWW: http://wpage.unina.it/a.botta From skikuchi@jp.fujitsu.com Fri May 24 17:10:40 2013 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 BF39D11E812F for ; Fri, 24 May 2013 17:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.09 X-Spam-Level: X-Spam-Status: No, score=-104.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 0E7+O+cBMgiX for ; Fri, 24 May 2013 17:10:36 -0700 (PDT) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3CABD11E812E for ; Fri, 24 May 2013 17:10:35 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 9358C3EE081 for ; Sat, 25 May 2013 09:10:34 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 8725D3A62C2 for ; Sat, 25 May 2013 09:10:34 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 687BF1EF081 for ; Sat, 25 May 2013 09:10:34 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 578ED1DB804E for ; Sat, 25 May 2013 09:10:34 +0900 (JST) Received: from g01jpexchkw37.g01.fujitsu.local (g01jpexchkw37.g01.fujitsu.local [10.0.193.67]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 133C61DB804D for ; Sat, 25 May 2013 09:10:34 +0900 (JST) Received: from G01JPEXMBKW24.g01.fujitsu.local ([10.0.193.132]) by g01jpexchkw37 ([10.0.193.67]) with mapi id 14.02.0309.002; Sat, 25 May 2013 09:10:33 +0900 From: "Kikuchi, Shinji" To: "'ippm@ietf.org'" Thread-Topic: IEEE CloudNet 2013: CfP (Deadline Extended) Thread-Index: Ac5Y3C5Vomdtok1LTDq38OhdnlOrOg== Date: Sat, 25 May 2013 00:10:32 +0000 Message-ID: <44D5947A9C7ADF429D48E9F4F55AD6C834B6A714@g01jpexmbkw24> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-securitypolicycheck: OK by SHieldMailChecker v1.8.4 x-originating-ip: [10.75.179.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [ippm] IEEE CloudNet 2013: CfP (Deadline Extended) 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: Sat, 25 May 2013 00:10:40 -0000 V2UgYXBvbG9naXplIGZvciBwb3NzaWJsZSBjcm9zcyBwb3N0aW5ncy4NCg0KLS0NCg0KMm5kIElF RUUgSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9uIENsb3VkIE5ldHdvcmtpbmcNCklFRUUgQ2xv dWROZXQgMjAxMw0KTm92ZW1iZXIgMTEtMTMsIDIwMTMgfCBTYW4gRnJhbmNpc2NvLCBVU0ENCmh0 dHA6Ly93d3cuaWVlZS1jbG91ZG5ldC5vcmcvDQoNCnN1cHBvcnRlZCBieSBJRUVFIENsb3VkIENv bXB1dGluZyBJbml0aWF0aXZlDQoNCg0KQ2xvdWQgTmV0d29ya2luZyBoYXMgZW1lcmdlZCBhcyBh IHByb21pc2luZyBkaXJlY3Rpb24gZm9yIGNvc3QgZWZmaWNpZW50IGFuZA0KcmVsaWFibGUgc2Vy dmljZSBkZWxpdmVyeSBhY3Jvc3MgZGF0YSBjb21tdW5pY2F0aW9uIG5ldHdvcmtzLiBUaGUgZHlu YW1pYw0KbG9jYXRpb24gb2Ygc2VydmljZSBmYWNpbGl0aWVzIGFuZCB0aGUgdmlydHVhbGl6YXRp b24gb2YgaGFyZHdhcmUgYW5kIHNvZnR3YXJlDQplbGVtZW50cyBhcmUgc3RyZXNzaW5nIHRoZSBj b21tdW5pY2F0aW9uIG5ldHdvcmsgYW5kIHByb3RvY29scywgZXNwZWNpYWxseQ0Kd2hlbiBkYXRh IGNlbnRlcnMgYXJlIGludGVyY29ubmVjdGVkIHRocm91Z2ggdGhlIEludGVybmV0LiBBbHRob3Vn aCB0aGUNCiJjb21wdXRpbmciIGFzcGVjdHMgb2YgQ2xvdWQgdGVjaG5vbG9naWVzIGhhdmUgYmVl biBsYXJnZWx5IGludmVzdGlnYXRlZCwgbG93ZXINCmF0dGVudGlvbiBoYXMgYmVlbiBkZXZvdGVk IHRvIHRoZSAibmV0d29ya2luZyIgYXNwZWN0cy4gVGhlIDJuZCBJRUVFDQpJbnRlcm5hdGlvbmFs IENvbmZlcmVuY2Ugb24gQ2xvdWQgTmV0d29ya2luZyAoSUVFRSBDbG91ZE5ldCAyMDEzKSwgcGFy dCBvZg0KdGhlIElFRUUgQ2xvdWQgQ29tcHV0aW5nIEluaXRpYXRpdmUsIHByZWNpc2VseSBhZGRy ZXNzZXMgdGhlc2UgYXNwZWN0cy4NCkNvbmZlcmVuY2UgdG9waWNzIGluY2x1ZGUgKGJ1dCBhcmUg bm90IGxpbWl0ZWQgdG8pOg0KDQotIERhdGEgQ2VudGVyIE5ldHdvcmsgTWFuYWdlbWVudCwgUmVs aWFiaWxpdHksIE9wdGltaXphdGlvbg0KLSBEaXN0cmlidXRlZCBEYXRhIENlbnRlciBBcmNoaXRl Y3R1cmVzDQotIEludGVybmV0IFJvdXRpbmcgb2YgQ2xvdWQgZGF0YQ0KLSBFdGhlcm5ldCBSb3V0 aW5nOiBUUklMTCwgU1BCLCBMMkxTUA0KLSBOZXR3b3JrIFByb2dyYW1tYWJpbGl0eSwgU29mdHdh cmUtRGVmaW5lZCBOZXR3b3JraW5nDQotIFZpcnR1YWwgRXRoZXJuZXQgU3dpdGNoaW5nLCBEYXRh IENlbnRlciBCcmlkZ2luZw0KLSBDbG91ZCBUcmFmZmljIENoYXJhY3Rlcml6YXRpb24gYW5kIE1l YXN1cmVtZW50cw0KLSBJbnRyYS1DbG91ZCB2cyBJbnRlci1DbG91ZCBNYW5hZ2VtZW50DQotIENs b3VkIFRyYWZmaWMgRW5naW5lZXJpbmcgYW5kIENvbnRyb2wtUGxhbmUgQXJjaGl0ZWN0dXJlcw0K LSBHcmVlbiBDbG91ZCBOZXR3b3JraW5nDQotIFNlY3VyaXR5LCBQcml2YWN5LCBDb25maWRlbnRp YWxpdHkgaW4gQ2xvdWQgTmV0d29ya2luZw0KLSBOZXR3b3JrIG9uIHRoZSBmbHksIFZpcnR1YWwg Y29udHJvbCwgVmlydHVhbCByYWRpbywgSXNvbGF0aW9uDQotIFZpcnR1YWxpemF0aW9uIG9mIFdp cmVsZXNzIEVxdWlwbWVudA0KLSBVbmlmaWVkIFVzZXIgYW5kIE1hY2hpbmUgTW9iaWxpdHkgTWFu YWdlbWVudA0KLSBNb2JpbGUgQ2xvdWQgTmV0d29ya2luZywgRm9sbG93LU1lLUNsb3VkDQotIFN0 b3JhZ2UgQXJlYSBOZXR3b3JrcywgT3B0aWNhbCBJbnRlcmNvbm5lY3QsIEZpYmVyIENoYW5uZWwN Ci0gQ29udGVudCBhbmQgU2VydmljZSBEaXN0cmlidXRpb24NCg0KDQoNClN1Ym1pc3Npb24gR3Vp ZGVsaW5lcw0KDQpPcmlnaW5hbCBtYW51c2NyaXB0cyBub3QgdW5kZXIgY29uc2lkZXJhdGlvbiBp biBvdGhlciB2ZW51ZXMgYXJlIHNvbGljaXRlZC4NClN1Ym1pc3Npb25zIHNob3VsZCBhZGhlcmUg dG8gdGhlIElFRUUgQ29tbXVuaWNhdGlvbnMgU29jaWV0eSBkb3VibGUgY29sdW1uLA0Kc2luZ2xl IHNwYWNlIGZvcm1hdCBhbmQgc2hvdWxkIG5vdCBleGNlZWQgOCBwYWdlcy4gQXQgbGVhc3Qgb25l IGF1dGhvcg0Kb2YgZWFjaCBhY2NlcHRlZCBwYXBlciBtdXN0IHJlZ2lzdGVyIGFuZCBwcmVzZW50 IGF0IHRoZSBjb25mZXJlbmNlLCBmb3IgdGhlIHBhcGVyDQp0byBhcHBlYXIgaW4gdGhlIGNvbmZl cmVuY2UgcHJvY2VlZGluZ3MgYW5kIHRoZSBJRUVFIGRpZ2l0YWwgbGlicmFyeQ0KDQoNCkltcG9y dGFudCBEYXRlcw0KLSBBYnN0cmFjdCByZWdpc3RyYXRpb246IEp1bmUgN3RoLCAyMDEzDQotIFBh cGVyIHN1Ym1pc3Npb246IEp1bmUgN3RoLCAyMDEzDQotIE5vdGlmaWNhdGlvbjogQXVndXN0IDFz dCwgMjAxMw0KLSBDYW1lcmEtcmVhZHk6IFNlcHRlbWJlciAxc3QsIDIwMTMNCg0KDQpPcmdhbml6 ZXJzDQoNCkdlbmVyYWwgQ2hhaXINCkRlZXAgTWVkaGksIFVuaXZlcnNpdHkgb2YgTWlzc291cmkt S2Fuc2FzIENpdHksIFVTQQ0KDQpUUEMgQ28tY2hhaXJzDQpYaWFvbWluZyBGdSwgVW5pdmVyc2l0 eSBvZiBHw7Z0dGluZ2VuLCBHZXJtYW55DQpQdW5lZXQgU2hhcm1hLCBIUCBMYWJzLCBVU0ENCg0K UGF0cm9uIENoYWlyDQpNYXN1bSBIYXNhbiwgQ2lzY28gU3lzdGVtcywgVVNBDQoNClB1YmxpY2l0 eSBDaGFpcnMNCkxpc2FuZHJvIFphbWJlbmVkZXR0aSBHcmFudmlsbGUsIEZlZGVyYWwgVW5pdmVy c2l0eSBvZiBSaW8gR3JhbmRlIGRvIFN1bCAoVUZSR1MpLCBCcmF6aWwNClNoaW5qaSBLaWt1Y2hp LCBGVUpJVFNVIExhYiwgSmFwYW4NCg0KUHVibGljYXRpb24gQ2hhaXINCkRpamlhbmcgSHVhbmcs IEFyaXpvbmEgU3RhdGUgVW5pdmVyc2l0eSwgVVNBDQoNCldlYiBDaGFpcg0KWWFuZyBDaGVuLCBE dWtlIFVuaXZlcnNpdHksIFVTQQ0K From talmi@marvell.com Tue May 28 09:28:06 2013 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 E3D2721F986F for ; Tue, 28 May 2013 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DIAtKoZDp+ms for ; Tue, 28 May 2013 09:28:02 -0700 (PDT) Received: from na3sys009aog137.obsmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2D23E21F982A for ; Tue, 28 May 2013 09:28:02 -0700 (PDT) Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKUaTa9EDYpjRGyY1df31fLoGzf7EfdtQT@postini.com; Tue, 28 May 2013 09:28:02 PDT Received: from YK-HUB01.marvell.com (10.4.102.51) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 28 May 2013 09:26:22 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Tue, 28 May 2013 19:26:18 +0300 From: Tal Mizrahi To: "ippm@ietf.org" Date: Tue, 28 May 2013 19:26:13 +0300 Thread-Topic: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Thread-Index: Ac5bs4WuaRAokonHQLeJcPwzWQh1Mw== Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F9C9380EILMB01marve_" MIME-Version: 1.0 Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 28 May 2013 16:28:07 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9380EILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, History: - http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer= -00 Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP. - There was some discussion in the mailing list: http://www.ietf.o= rg/mail-archive/web/ntp/current/msg00492.html - Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/minu= tes?item=3Dminutes81.html Current version: - Split into 2 drafts. There are some similarities, but still it i= s more appropriate to discuss it as two separate drafts: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00 - [NTP draft] Clarified the usage of the NTP extension field witho= ut authentication. Comments will be appreciated. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9380EILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

History:

-     &n= bsp;    = http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00
= Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP.

-&nb= sp;         There was some discussion in the mailing list: http= ://www.ietf.org/mail-archive/web/ntp/current/msg00492.html

-       = ;   Some discussio= n in IETF 81: http://tools.ietf.org/wg/tictoc/minutes?item=3Dminutes81.html<= /a>

 

Current version:

- &n= bsp;        Split into 2 drafts. There are some similarities, but st= ill it is more appropriate to discuss it as two separate drafts:=

http://tools.ietf.org/html/draft-mizrahi-= ntp-checksum-trailer-00
http://tools.ietf.org/html/draft-m= izrahi-owamp-twamp-checksum-trailer-00

-          <= /span>[NTP draft] Clarified the usage of t= he NTP extension field without authentication.

 

Comments will be app= reciated.

 

Thanks,

Tal.

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9380EILMB01marve_-- From prvs=986075ffbf=steve.baillargeon@ericsson.com Tue May 28 13:02:13 2013 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 BBAA521F93FB for ; Tue, 28 May 2013 13:02:13 -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 C+iqZRf5attr for ; Tue, 28 May 2013 13:02:08 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F41A621E8084 for ; Tue, 28 May 2013 13:02:04 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-b9-51a50d3a7653 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9D.9E.06724.A3D05A15; Tue, 28 May 2013 22:02:03 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 28 May 2013 16:02:02 -0400 From: Steve Baillargeon To: Tal Mizrahi , "ippm@ietf.org" Thread-Topic: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Thread-Index: Ac5bs4WuaRAokonHQLeJcPwzWQh1MwAKTOIg Date: Tue, 28 May 2013 20:02:01 +0000 Message-ID: References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_DCF22B50497F7641B6DDD16ECC516F7F170DEE8Deusaamb106erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPlK4179JAg7mPGS16Hrxjtnj1bwuL A5PHkiU/mTwmL7zIHMAUxW2TlFhSFpyZnqdvl8CdceHwavaC7zEVWxbdYGlg/BfUxcjJISFg IrFgVhsbhC0mceHeeiCbi0NI4CijxP/lX5ghnOWMEvdWd7GCVLEJWEisn7uMGcQWEXCR+Ldv N1hcWMBV4vS9L6wQcTeJNY37WCBsI4nTUz6zg9gsAqoSjVNPgG3jFfCVWH7vFpgtJOAn0d93 F6yGU8BfYvH8T2BzGAVkJXafvc4EYjMLiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUlljzZ zwJRny9x+ksXC8QuQYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DET svgCRvZVjBylxalluelGhpsYgRF0TILNcQfjgk+WhxilOViUxHl1eBcHCgmkJ5akZqemFqQW xReV5qQWH2Jk4uAEEVxSDYx2dS83vZ8Q63Vor9Ybpc0KElyGc0S65Pbll9h2bYyJjL90/52M ioqxt3iDXpmCiGKNzskLDnmbOd2NvTd/O8VW0Vac+05B57DcksDzL77X3zGoZ4xttijL2vZq 258l2WJdS667PmwzPLPj6qqteksYTVOjfYr1H3Sd+TWteZlL4JtYoc4TfEosxRmJhlrMRcWJ ABpMQWNzAgAA Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 28 May 2013 20:02:13 -0000 --_000_DCF22B50497F7641B6DDD16ECC516F7F170DEE8Deusaamb106erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal Good work! For OWAM/TWAMP, since you are changing the test packet format, you will nee= d to assign a new mode that can work in conjunction with the unauthenticate= d mode (or other modes). Bottom-line, a new value in the Modes field is req= uired during test session establishment. You will also need a good name for= it e.g. UDP checksum mode. Regards Steve Baillargeon From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Tal= Mizrahi Sent: May-28-13 12:26 PM To: ippm@ietf.org Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi, History: - http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-0= 0 Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP. - There was some discussion in the mailing list: http://www.ietf.org= /mail-archive/web/ntp/current/msg00492.html - Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/minute= s?item=3Dminutes81.html Current version: - Split into 2 drafts. There are some similarities, but still it is = more appropriate to discuss it as two separate drafts: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00 - [NTP draft] Clarified the usage of the NTP extension field without= authentication. Comments will be appreciated. Thanks, Tal. --_000_DCF22B50497F7641B6DDD16ECC516F7F170DEE8Deusaamb106erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal

Good work!<= /span>

 

For OWAM/TWAMP, since = you are changing the test packet format, you will need to assign a new mode= that can work in conjunction with the unauthenticated mode (or other modes= ). Bottom-line, a new value in the Modes field is required during test session establishment. You will also need a = good name for it e.g. UDP checksum mode.

 

 

Regards

Steve Baillargeon=

 

 

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: May-28-13 12:26 PM
To: ippm@ietf.org
Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-traile= r-00

 

Hi,

 

History:

-  = ;      http://tools.ietf.= org/html/draft-mizrahi-tictoc-checksum-trailer-00
Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP.

-  = ;      There was some discussi= on in the mailing list: = http://www.ietf.org/mail-archive/web/ntp/current/msg00492.html

-  = ;      Some discussion in IETF= 81: http://tools.ietf.org/wg/tictoc/minutes?item=3Dminutes81.html

 

Current version:

-  = ;      Split into 2 drafts. Th= ere are some similarities, but still it is more appropriate to discuss it a= s two separate drafts:

http://tools.ietf.org/= html/draft-mizrahi-ntp-checksum-trailer-00
http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-tra= iler-00

-  = ;      [NTP draft] Clarified t= he usage of the NTP extension field without authentication.

 

Comments will be appreciated.

 

Thanks,

Tal.

 

--_000_DCF22B50497F7641B6DDD16ECC516F7F170DEE8Deusaamb106erics_-- From gregimirsky@gmail.com Tue May 28 16:41:24 2013 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 C94F711E80A6 for ; Tue, 28 May 2013 16:41:24 -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, HTML_MESSAGE=0.001, NO_RELAYS=-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 GeQdZ6ni3rC3 for ; Tue, 28 May 2013 16:41:24 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC821F89D5 for ; Tue, 28 May 2013 16:41:23 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id m1so131227ves.14 for ; Tue, 28 May 2013 16:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=taeGjU4Jw3Y1h8XtagM7xOnUvkaXfHf0GQUxtiqAfM0=; b=EaJhNVX3iXz/ipfH8O9NQNvRNWJx6x6zT60x2BMIL2NlsQz/cMEEVv731FmZtddzAw 3iY3UkfPdsVGMohXzbuRW9InWd61Hxs553fV4dm+AZ2k5ROLeqVvzIk+3pielXuN7UMT q3IMmGo3EskI5zIycPESMXU9z69TjM33OBO18JMZ7a+kDl/bil/UgoMSsPs7l4TG9usx W2O1xF69P5HW9BNcPqo0ELtR74EoUKehQqCEeLmBWPdaP/ULEL8Gx1t164GYzfn7+Ld6 kJxjqHpRK0+YqQgS7S6s1UOzMqz+pPi1KcY5Hc8ZVyqZzHtQkaH6sQgztw+dGOt9UOjp dAYA== MIME-Version: 1.0 X-Received: by 10.52.24.167 with SMTP id v7mr101211vdf.20.1369784483369; Tue, 28 May 2013 16:41:23 -0700 (PDT) Received: by 10.220.107.203 with HTTP; Tue, 28 May 2013 16:41:23 -0700 (PDT) In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> Date: Tue, 28 May 2013 16:41:23 -0700 Message-ID: From: Greg Mirsky To: Tal Mizrahi Content-Type: multipart/alternative; boundary=20cf3071d05e8cd7a304ddcfcd44 Cc: "ippm@ietf.org" Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 28 May 2013 23:41:24 -0000 --20cf3071d05e8cd7a304ddcfcd44 Content-Type: text/plain; charset=ISO-8859-1 Hi Tal, yours is very interesting work. Couple comments: - I think that requirement of at least 2 octets of padding might be not sufficient to work with section 4.2.1 of RFC 5357 that suggests that Session-Reflector MAY re-use packet padding for reflected packet. For Reflector to use Checksum Trailer mode packet padding in TWAMP-Test packet sent by Sender must be at least 29 octets in unauthenticated mode and 58 in authenticated and encrypted modes; - last paragraph in section 3.2.1 implicitly requires that if Checksum Trailer mode desired, packet padding must be used. I think that puts forth some requirements for OWAMP and TWAMP Control that would be useful to make explicit; - I'd consider how Checksum Trailer mode can be used with TWAMP test session negotiated with RFRC 6038; - I think that proposed mode has implication on TWAMP-Light operation. If TWAMP-Sender uses Checksum Trailer mode and sent test packet has sufficient number of octets so that Reflector will return at least two octets of padding, then Sender might interpret the last two octets as Checksum Trailer. I think that impact on TWAMP-Light needs to be discussed. Regards, Greg On Tue, May 28, 2013 at 9:26 AM, Tal Mizrahi wrote: > Hi,**** > > ** ** > > History:**** > > **- ** > http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 > Originally submitted to TICTOC in 2011, and discussed checksum trailers > for both NTP and OWAMP/TWAMP.**** > > **- **There was some discussion in the mailing list: > http://www.ietf.org/mail-archive/web/ntp/current/msg00492.html**** > > **- **Some discussion in IETF 81: > http://tools.ietf.org/wg/tictoc/minutes?item=minutes81.html**** > > ** ** > > Current version:**** > > **- **Split into 2 drafts. There are some similarities, but > still it is more appropriate to discuss it as two separate drafts:**** > > http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 > http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00** > ** > > **- **[NTP draft] Clarified the usage of the NTP extension field > without authentication. > **** > > ** ** > > Comments will be appreciated.**** > > ** ** > > Thanks,**** > > Tal.**** > > ** ** > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --20cf3071d05e8cd7a304ddcfcd44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tal,
yours is very interesting work.=
Couple comments:
  • I think that requirement of at least = 2 octets of padding might be not sufficient to work with section 4.2.1 of R= FC 5357 that suggests that Session-Reflector MAY re-use packet padding for = reflected packet. For Reflector to use Checksum Trailer mode packet padding= in TWAMP-Test packet sent by Sender must be at least 29 octets in unauthen= ticated mode and 58 in authenticated and encrypted modes;
  • last paragraph in section 3.2.1 implicitly requires that if Checks= um Trailer mode desired, packet padding must be used. I think that puts for= th some requirements for OWAMP and TWAMP Control that would be useful to ma= ke explicit;
  • I'd consider how Checksum Trailer mode can be used with TWAMP = test session negotiated with RFRC 6038;
  • I think that proposed mode = has implication on TWAMP-Light operation. If TWAMP-Sender uses Checksum Tra= iler mode and sent test packet has sufficient number of octets so that Refl= ector will return at least two octets of padding, then Sender might interpr= et the last two octets as Checksum Trailer. I think that impact on TWAMP-Li= ght needs to be discussed.

Regards,

Greg


On Tue, May 28, 2013 at 9:26 AM, Tal Mizrahi <= talmi@marvell.com> wrote:

Hi,

=A0

History:

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>http://= tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00
Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP.

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 There was some discussion in the ma= iling list: http://www.ietf.org/mail-archive/web/ntp/curr= ent/msg00492.html

-=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Some= discussion in IETF 81: http://tools.ietf.org/wg/tictoc/mi= nutes?item=3Dminutes81.html

=A0

Current = version:

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Split into 2 drafts. There are some similarities, but= still it is more appropriate to discuss it as two separate drafts:<= u>

http://tools.ietf.org/html/draft-mizrahi-ntp-checksu= m-trailer-00
http://tools.ietf.org/html/= draft-mizrahi-owamp-twamp-checksum-trailer-00

-=A0= =A0=A0=A0=A0=A0=A0=A0=A0 [NTP= draft] Clarified the usage of the NTP extension field without authenticati= on.

=A0

Comments= will be appreciated.

=A0=

Thanks,

Tal.

=A0


_______________= ________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm


--20cf3071d05e8cd7a304ddcfcd44-- From talmi@marvell.com Tue May 28 20:45:18 2013 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 BCECF21F8EAF for ; Tue, 28 May 2013 20:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iS2GbAuOGsrq for ; Tue, 28 May 2013 20:45:14 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3721F8EBB for ; Tue, 28 May 2013 20:45:11 -0700 (PDT) Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUaV5x2UYxeN47YlJR9qh05MUxa0F4Q4c@postini.com; Tue, 28 May 2013 20:45:13 PDT Received: from YK-HUB01.marvell.com (10.4.102.51) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 28 May 2013 20:44:55 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Wed, 29 May 2013 06:44:51 +0300 From: Tal Mizrahi To: Steve Baillargeon , "ippm@ietf.org" Date: Wed, 29 May 2013 06:44:47 +0300 Thread-Topic: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Thread-Index: Ac5bs4WuaRAokonHQLeJcPwzWQh1MwAKTOIgABBqkoA= Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9C9387F@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F9C9387FILMB01marve_" MIME-Version: 1.0 Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 29 May 2013 03:45:18 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9387FILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, Thanks for the feedback. I was hoping not to create a new mode, since the new fie= ld is piggybacked in the padding, and is thus transparent to the reflector = (TWAMP) and receiver (OWAMP). Thanks, Tal. From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com] Sent: Tuesday, May 28, 2013 11:02 PM To: Tal Mizrahi; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Tal Good work! For OWAM/TWAMP, since you are changing the test packet format, you will nee= d to assign a new mode that can work in conjunction with the unauthenticate= d mode (or other modes). Bottom-line, a new value in the Modes field is req= uired during test session establishment. You will also need a good name for= it e.g. UDP checksum mode. Regards Steve Baillargeon From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Tal= Mizrahi Sent: May-28-13 12:26 PM To: ippm@ietf.org Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi, History: - http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer= -00 Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP. - There was some discussion in the mailing list: http://www.ietf.o= rg/mail-archive/web/ntp/current/msg00492.html - Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/minu= tes?item=3Dminutes81.html Current version: - Split into 2 drafts. There are some similarities, but still it i= s more appropriate to discuss it as two separate drafts: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00 - [NTP draft] Clarified the usage of the NTP extension field witho= ut authentication. Comments will be appreciated. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9387FILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 

Thanks for the feedback.

I was hoping not to create a= new mode, since the new <Checksum Trailer> field is piggybacked in t= he padding, and is thus transparent to the reflector (TWAMP) and receiver (= OWAMP).

 

Thanks,

Tal.

 

From: Steve = Baillargeon [mailto:steve.baillargeon@ericsson.com]
Sent: Tuesda= y, May 28, 2013 11:02 PM
To: Tal Mizrahi; ippm@ietf.org
Sub= ject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00=

 

Hi Tal

Good work!

 

For OWAM/TWAMP, since you are chang= ing the test packet format, you will need to assign a new mode that can wor= k in conjunction with the unauthenticated mode (or other modes). Bottom-lin= e, a new value in the Modes field is required during test session establish= ment. You will also need a good name for it e.g. UDP checksum mode.

 

 

Regards

Steve Baillargeon

 

 

=  

From: ippm-bounces@ietf.org [mailto:ippm-bounc= es@ietf.org] On Behalf Of Tal Mizrahi
Sent: May-28-13 12:2= 6 PM
To: ippm@ietf.org
Subject: [ippm] New Draft: draft= -mizrahi-owamp-twamp-checksum-trailer-00

<= p class=3DMsoNormal> 

Hi,

 

History:

-&nb= sp;         http://tools.ietf.org/html/draft-mizrahi-ticto= c-checksum-trailer-00
Originally submitted to TICTOC in 2011, and di= scussed checksum trailers for both NTP and OWAMP/TWAMP.

-        &n= bsp; There was some discussi= on in the mailing list: http://www.ietf.org/mail-archive/web/ntp/current/ms= g00492.html

-  &nb= sp;       Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/mi= nutes?item=3Dminutes81.html

&nb= sp;

Current version:

-         = ; Split into 2 drafts. There= are some similarities, but still it is more appropriate to discuss it as t= wo separate drafts:

http://tool= s.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00
http= ://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00

-     &nb= sp;    [NTP d= raft] Clarified the usage of the NTP extension field without authentication= .

 

Comments will be appreciated.

&= nbsp;

Thanks,

Tal.<= o:p>

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9387FILMB01marve_-- From talmi@marvell.com Tue May 28 22:51:02 2013 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 9741D21F8267 for ; Tue, 28 May 2013 22:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gLNrgEVNJGWM for ; Tue, 28 May 2013 22:50:49 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEAA21F8FD0 for ; Tue, 28 May 2013 22:50:44 -0700 (PDT) Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUaWXNIdNOT24IP+OKDvfaTw2P2pT4GAu@postini.com; Tue, 28 May 2013 22:50:49 PDT Received: from YK-HUB01.marvell.com (10.4.102.51) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 28 May 2013 22:50:44 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Wed, 29 May 2013 08:50:40 +0300 From: Tal Mizrahi To: Greg Mirsky Date: Wed, 29 May 2013 08:50:37 +0300 Thread-Topic: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Thread-Index: Ac5b/S6qHl7O7f3qTe6CLC5S1mZspgALes3g Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9C9388B@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F9C9388BILMB01marve_" MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 29 May 2013 05:51:02 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9388BILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments. >I think that requirement of at least 2 octets of padding might be not suff= icient to work with section 4.2.1 of RFC 5357 that suggests that Session-Re= flector MAY re-use packet padding for reflected packet. For Reflector to us= e Checksum Trailer mode packet padding in TWAMP-Test packet sent by Sender = must be at least 29 octets in unauthenticated mode and 58 in authenticated = and encrypted modes; That's a good point, and I will add discussion about this in the next draft= . Note, however, that there are 2 possible scenarios: (1) Reflector supports Checksum Trailer - your comment is indeed relevan= t in this case. (2) Sender supports Checksum Trailer, but Reflector does not support Che= cksum Trailer - in this case the Checksum Trailer is only used in the sende= r-->reflector packet, and thus the 2 octets of padding suffice. The Checksu= m Trailer is not used in the reflector-->sender packet, there is no need fo= r 29/58 octets of padding in the original packet. Obviously, the sender does not necessarily know whether the reflector suppo= rts the Checksum Trailer or not, and thus it is probably good practice to a= ppend 29/58 octets. >last paragraph in section 3.2.1 implicitly requires that if Checksum Trail= er mode desired, packet padding must be used. I think that puts forth some = requirements for OWAMP and TWAMP Control that would be useful to make expli= cit; Right, as section 3.2 says: "The length of the Packet Padding field in test= packets is announced during the session initiation through the "Padding Le= ngth" field in the Request-Session message [OWAMP], or in the Request-TW-Se= ssion [TWAMP]." I will clarify this in 3.2.1 as well. >I'd consider how Checksum Trailer mode can be used with TWAMP test session= negotiated with RFRC 6038; I will look into it and address it in the next draft. >I think that proposed mode has implication on TWAMP-Light operation. If TW= AMP-Sender uses Checksum Trailer mode and sent test packet has sufficient n= umber of octets so that Reflector will return at least two octets of paddin= g, then Sender might interpret the last two octets as Checksum Trailer. I t= hink that impact on TWAMP-Light needs to be discussed. It is important to note that when a sender receives a test packet it does n= ot care whether the packet includes a Checksum Trailer or not. The reflecto= r may or may not use a Checksum Trailer when reflecting the test packet; in= both cases when the sender receives the test packet it simply treats the C= hecksum Trailer as part of the padding. Thanks, Tal. From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Wednesday, May 29, 2013 2:41 AM To: Tal Mizrahi Cc: ippm@ietf.org Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-0= 0 Hi Tal, yours is very interesting work. Couple comments: * I think that requirement of at least 2 octets of padding might be not = sufficient to work with section 4.2.1 of RFC 5357 that suggests that Sessio= n-Reflector MAY re-use packet padding for reflected packet. For Reflector t= o use Checksum Trailer mode packet padding in TWAMP-Test packet sent by Sen= der must be at least 29 octets in unauthenticated mode and 58 in authentica= ted and encrypted modes; * last paragraph in section 3.2.1 implicitly requires that if Checksum T= railer mode desired, packet padding must be used. I think that puts forth s= ome requirements for OWAMP and TWAMP Control that would be useful to make e= xplicit; * I'd consider how Checksum Trailer mode can be used with TWAMP test ses= sion negotiated with RFRC 6038; * I think that proposed mode has implication on TWAMP-Light operation. I= f TWAMP-Sender uses Checksum Trailer mode and sent test packet has sufficie= nt number of octets so that Reflector will return at least two octets of pa= dding, then Sender might interpret the last two octets as Checksum Trailer.= I think that impact on TWAMP-Light needs to be discussed. Regards, Greg On Tue, May 28, 2013 at 9:26 AM, Tal Mizrahi > wrote: Hi, History: - http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer= -00 Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP. - There was some discussion in the mailing list: http://www.ietf.o= rg/mail-archive/web/ntp/current/msg00492.html - Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/minu= tes?item=3Dminutes81.html Current version: - Split into 2 drafts. There are some similarities, but still it i= s more appropriate to discuss it as two separate drafts: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00 - [NTP draft] Clarified the usage of the NTP extension field witho= ut authentication. Comments will be appreciated. Thanks, Tal. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9388BILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,<= o:p>

 

Thanks for your comments.

>I think that requirement of at least 2 octets of padding might= be not sufficient to work with section 4.2.1 of RFC 5357 that suggests tha= t Session-Reflector MAY re-use packet padding for reflected packet. For Ref= lector to use Checksum Trailer mode packet padding in TWAMP-Test packet sen= t by Sender must be at least 29 octets in unauthenticated mode and 58 in au= thenticated and encrypted modes;

= That’s a good point, and I will add discussion about this in the next= draft.

Note, however, tha= t there are 2 possible scenarios:

(1)    Reflector supports Checksum Trailer – your co= mment is indeed relevant in this case.

(2)    <= span dir=3DLTR>Sender supports Checksum Trailer, but Reflecto= r does not support Checksum Trailer – in this case the Checksum Trail= er is only used in the sender-->reflector packet, and thus the 2 octets = of padding suffice. The Checksum Trailer is not used in the reflector-->= sender packet, there is no need for 29/58 octets of padding in the original= packet.  

Obviously,= the sender does not necessarily know whether the reflector supports the Ch= ecksum Trailer or not, and thus it is probably good practice to append 29/5= 8 octets.

>last paragraph in section 3.2.1 i= mplicitly requires that if Checksum Trailer mode desired, packet padding mu= st be used. I think that puts forth some requirements for OWAMP and TWAMP C= ontrol that would be useful to make explicit;

Right, as section 3.2 says: “The length of the Packet Pa= dding field in test packets is announced during the session initiation thro= ugh the "Padding Length" field in the Request-Session message [OW= AMP], or in the Request-TW-Session [TWAMP].”

I will clarify this in 3.2.1 as well.

 

&= gt;I'd consider how Checksum Trailer mode can be used with TWAMP test sessi= on negotiated with RFRC 6038;

I w= ill look into it and address it in the next draft.

 

>I think tha= t proposed mode has implication on TWAMP-Light operation. If TWAMP-Sender u= ses Checksum Trailer mode and sent test packet has sufficient number of oct= ets so that Reflector will return at least two octets of padding, then Send= er might interpret the last two octets as Checksum Trailer. I think that im= pact on TWAMP-Light needs to be discussed.

It is important to note that when a sender receives a test packet= it does not care whether the packet includes a Checksum Trailer or not. Th= e reflector may or may not use a Checksum Trailer when reflecting the test = packet; in both cases when the sender receives the test packet it simply tr= eats the Checksum Trailer as part of the padding.

 

 

Thanks,

Tal.

 

From: Gr= eg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Wednesday, May 29= , 2013 2:41 AM
To: Tal Mizrahi
Cc: ippm@ietf.org
= Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trail= er-00

 

<= div>

Hi Tal,

yours is very interesting work.

Couple comments:

  • I think that requirement of at least 2 octets of padding might be not= sufficient to work with section 4.2.1 of RFC 5357 that suggests that Sessi= on-Reflector MAY re-use packet padding for reflected packet. For Reflector = to use Checksum Trailer mode packet padding in TWAMP-Test packet sent by Se= nder must be at least 29 octets in unauthenticated mode and 58 in authentic= ated and encrypted modes;
  • la= st paragraph in section 3.2.1 implicitly requires that if Checksum Trailer = mode desired, packet padding must be used. I think that puts forth some req= uirements for OWAMP and TWAMP Control that would be useful to make explicit= ;
  • I'd consider how Checksum = Trailer mode can be used with TWAMP test session negotiated with RFRC 6038;=
  • I think that proposed mode = has implication on TWAMP-Light operation. If TWAMP-Sender uses Checksum Tra= iler mode and sent test packet has sufficient number of octets so that Refl= ector will return at least two octets of padding, then Sender might interpr= et the last two octets as Checksum Trailer. I think that impact on TWAMP-Li= ght needs to be discussed.

Regards,

Greg

 

On Tue, May 28, 2013= at 9:26 AM, Tal Mizrahi <talmi@marvell.com> wrote:

H= i,

 

History:

=

-      &nb= sp;   http://tools.ietf.org/html/dr= aft-mizrahi-tictoc-checksum-trailer-00
Originally submitted to TICTO= C in 2011, and discussed checksum trailers for both NTP and OWAMP/TWAMP.

-    &nb= sp;     There was some discussion in the mailing= list: http://www.ietf.org/mail-archive/web/ntp/current/m= sg00492.html

- &n= bsp;        Some discussion in IE= TF 81: http://tools.ietf.org/wg/tictoc/minutes?item=3Dminu= tes81.html

 

Current ver= sion:

-   &= nbsp;      Split into 2 drafts. There are s= ome similarities, but still it is more appropriate to discuss it as two sep= arate drafts:

http://tools.ietf.org/ht= ml/draft-mizrahi-ntp-checksum-trailer-00
http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00

-   &nbs= p;      [NTP draft] Clarified the usage of = the NTP extension field without authentication.

 =

Comments will be appreciated.

&= nbsp;

Thanks,

Tal.

 


_______________________________________________
ippm = mailing list
ippm@ietf.org
https:/= /www.ietf.org/mailman/listinfo/ippm

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F9C9388BILMB01marve_-- From prvs=586179dd01=steve.baillargeon@ericsson.com Wed May 29 05:56:24 2013 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 97E1121F8B65 for ; Wed, 29 May 2013 05:56:24 -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 b1-x9hh4fypj for ; Wed, 29 May 2013 05:56:19 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id ED7F321F89C3 for ; Wed, 29 May 2013 05:56:18 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-5c-51a5faf11c94 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 86.A5.05617.2FAF5A15; Wed, 29 May 2013 14:56:18 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Wed, 29 May 2013 08:56:17 -0400 From: Steve Baillargeon To: Tal Mizrahi , "ippm@ietf.org" Thread-Topic: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Thread-Index: Ac5bs4WuaRAokonHQLeJcPwzWQh1MwAKTOIgABBqkoAAEt+/0A== Date: Wed, 29 May 2013 12:56:17 +0000 Message-ID: References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> <74470498B659FA4687F0B0018C19A89C01A0F9C9387F@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9C9387F@IL-MB01.marvell.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_DCF22B50497F7641B6DDD16ECC516F7F170DF0D1eusaamb106erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXSPn+6nX0sDDc5slbDoefCO2eLVvy0s DkweS5b8ZPKYvPAicwBTFLdNUmJJWXBmep6+XQJ3RsfpP8wFzb2MFaeX/mFqYLxZ28XIySEh YCLxcuNGNghbTOLCvfVANheHkMBRRolND18wQjjLGSUuPHsAVsUmYCGxfu4yZhBbRMBF4t++ 3awgtrCAq8Tpe19YIeJuEmsa97FA2E4S1ydfZAexWQRUJV6enQtUw8HBK+ArMWFjFMT864wS D/6+BotzCvhLHL/jCFLOKCArsfvsdSYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSyx 5Ml+Foj6fImbq76DncwrIChxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hn DjxmQhZfwMi+ipGjtDi1LDfdyHATIzCCjkmwOe5gXPDJ8hCjNAeLkjivDu/iQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycIIJLqoGx8Y7i0wA+XkefNRsZwrZd87l8t4/lsJej3JtlXjITdV69 krmbsdjMe9kT3dnv3BrYRe7ZhE2crZ9xnquiWUKL/6Tl3CMM7NMZbt2PNzzgcdp4+ZnjJcIq E7deUTyg5vxIjd0taL5VxPaHh45o7JCXveum/Xafcrsc842OLYe3Wu6fssrkvd8jJZbijERD Leai4kQAqGmg8HMCAAA= Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 29 May 2013 12:56:24 -0000 --_000_DCF22B50497F7641B6DDD16ECC516F7F170DF0D1eusaamb106erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal Based on your draft: UDP over IPv6, as defined in [IPv6], does not allow a = zero checksum, and requires the UDP checksum field to contain a correct checksum of the UDP payload. How will bypass this requirement without "configuring" (via signaling or ou= t-of-band configuration) the responder to ignore the UDP checksum? How much saving (CPU cycles) do you expect between 1) update the timestamp= field, and then update the Checksum Trailer and 2) update the timestamp an= d then update the UDP checksum residing at the UDP header? -Steve From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: May-28-13 11:45 PM To: Steve Baillargeon; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Steve, Thanks for the feedback. I was hoping not to create a new mode, since the new fie= ld is piggybacked in the padding, and is thus transparent to the reflector = (TWAMP) and receiver (OWAMP). Thanks, Tal. From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com] Sent: Tuesday, May 28, 2013 11:02 PM To: Tal Mizrahi; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Tal Good work! For OWAM/TWAMP, since you are changing the test packet format, you will nee= d to assign a new mode that can work in conjunction with the unauthenticate= d mode (or other modes). Bottom-line, a new value in the Modes field is req= uired during test session establishment. You will also need a good name for= it e.g. UDP checksum mode. Regards Steve Baillargeon From: ippm-bounces@ietf.org [mailto:ippm-boun= ces@ietf.org] On Behalf Of Tal Mizrahi Sent: May-28-13 12:26 PM To: ippm@ietf.org Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi, History: - http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-0= 0 Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP. - There was some discussion in the mailing list: http://www.ietf.org= /mail-archive/web/ntp/current/msg00492.html - Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/minute= s?item=3Dminutes81.html Current version: - Split into 2 drafts. There are some similarities, but still it is = more appropriate to discuss it as two separate drafts: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00 - [NTP draft] Clarified the usage of the NTP extension field without= authentication. Comments will be appreciated. Thanks, Tal. --_000_DCF22B50497F7641B6DDD16ECC516F7F170DF0D1eusaamb106erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal

 

Based on your draft: UDP over IPv6, as defined in [IP= v6], does not allow a zero checksum, and requires the UDP checksum field to= contain a

correct checksum= of the UDP payload.

How will bypass this r= equirement without “configuring” (via signaling or out-of-band = configuration) the responder to ignore the UDP checksum?<= /p>

 

How much saving (CPU c= ycles) do you expect between 1)  update the timestamp field, and then = update the Checksum Trailer and 2) update the timestamp and then update the= UDP checksum residing at the UDP header?

 

-Steve

 

 

From: Tal Mizrahi [mailto:talmi@marvell.com]
Sent: May-28-13 11:45 PM
To: Steve Baillargeon; ippm@ietf.org
Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-0= 0

 

Hi Stev= e,

&n= bsp;

Thanks = for the feedback.

I was h= oping not to create a new mode, since the new <Checksum Trailer> fiel= d is piggybacked in the padding, and is thus transparent to the reflector (= TWAMP) and receiver (OWAMP).

&n= bsp;

Thanks,=

Tal.

&n= bsp;

From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com]
Sent: Tuesday, May 28, 2013 11:02 PM
To: Tal Mizrahi; ippm@ietf.org<= br> Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-0= 0

 

Hi Tal

Good work!<= /span>

 

For OWAM/TWAMP, since = you are changing the test packet format, you will need to assign a new mode= that can work in conjunction with the unauthenticated mode (or other modes= ). Bottom-line, a new value in the Modes field is required during test session establishment. You will also need a = good name for it e.g. UDP checksum mode.

 

 

Regards

Steve Baillargeon=

 

 

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: May-28-13 12:26 PM
To: ippm@ietf.org
Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-traile= r-00

 

Hi,

 

History:

-  = ;      http://tools.ietf.= org/html/draft-mizrahi-tictoc-checksum-trailer-00
Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP.

-  = ;      There was some discussi= on in the mailing list: = http://www.ietf.org/mail-archive/web/ntp/current/msg00492.html

-  = ;      Some discussion in IETF= 81: http://tools.ietf.org/wg/tictoc/minutes?item=3Dminutes81.html

 

Current version:

-  = ;      Split into 2 drafts. Th= ere are some similarities, but still it is more appropriate to discuss it a= s two separate drafts:

http://tools.ietf.org/= html/draft-mizrahi-ntp-checksum-trailer-00
http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-tra= iler-00

-  = ;      [NTP draft] Clarified t= he usage of the NTP extension field without authentication.

 

Comments will be appreciated.

 

Thanks,

Tal.

 

--_000_DCF22B50497F7641B6DDD16ECC516F7F170DF0D1eusaamb106erics_-- From talmi@marvell.com Wed May 29 07:18:41 2013 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 DBCCF21F9121 for ; Wed, 29 May 2013 07:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fsbtFU+8hkyz for ; Wed, 29 May 2013 07:18:37 -0700 (PDT) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id AEA7321F8FA9 for ; Wed, 29 May 2013 07:18:20 -0700 (PDT) Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKUaYOFUKgfYexlMmS1b7c4plCFgWicd+i@postini.com; Wed, 29 May 2013 07:18:33 PDT Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 May 2013 07:17:34 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Wed, 29 May 2013 17:17:29 +0300 From: Tal Mizrahi To: Steve Baillargeon , "ippm@ietf.org" Date: Wed, 29 May 2013 17:17:22 +0300 Thread-Topic: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Thread-Index: Ac5bs4WuaRAokonHQLeJcPwzWQh1MwAKTOIgABBqkoAAEt+/0AAAiOEw Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9C93AA4@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> <74470498B659FA4687F0B0018C19A89C01A0F9C9387F@IL-MB01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F9C93AA4ILMB01marve_" MIME-Version: 1.0 Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 29 May 2013 14:18:42 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F9C93AA4ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, > How will bypass this requirement without "configuring" (via signaling or = out-of-band configuration) the responder to ignore the UDP checksum? The receiver does not ignore the checksum. The sender changes the value of = the Checksum Trailer to a value that makes the UDP Checksum field correct. = The receiver simply treats the Checksum Trailer as part of the padding (i.e= ., part of the UDP payload). >How much saving (CPU cycles) do you expect between 1) update the timestam= p field, and then update the Checksum Trailer and 2) update the timestamp a= nd then update the UDP checksum residing at the UDP header? Well, since I work for a silicon vendor, I was thinking more about silicon = implementations, where you update the timestamp in the chip. In such implementations, you often process the data in a serial manner, a f= ew bytes at a time. So as you go over the packet: you first process the UDP header (including t= he checksum), and then process the payload (including the timestamp). At th= is point you know how you want to update the UDP checksum, but it is alread= y too late since the UDP header may have already been transmitted. It's sti= ll not too late to update the Checksum Trailer at the end of the packet, so= it is updated to a value that keeps the existing UDP checksum correct. Regards, Tal. From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com] Sent: Wednesday, May 29, 2013 3:56 PM To: Tal Mizrahi; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Tal Based on your draft: UDP over IPv6, as defined in [IPv6], does not allow a = zero checksum, and requires the UDP checksum field to contain a correct checksum of the UDP payload. How will bypass this requirement without "configuring" (via signaling or ou= t-of-band configuration) the responder to ignore the UDP checksum? How much saving (CPU cycles) do you expect between 1) update the timestamp= field, and then update the Checksum Trailer and 2) update the timestamp an= d then update the UDP checksum residing at the UDP header? -Steve From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: May-28-13 11:45 PM To: Steve Baillargeon; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Steve, Thanks for the feedback. I was hoping not to create a new mode, since the new fie= ld is piggybacked in the padding, and is thus transparent to the reflector = (TWAMP) and receiver (OWAMP). Thanks, Tal. From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com] Sent: Tuesday, May 28, 2013 11:02 PM To: Tal Mizrahi; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Tal Good work! For OWAM/TWAMP, since you are changing the test packet format, you will nee= d to assign a new mode that can work in conjunction with the unauthenticate= d mode (or other modes). Bottom-line, a new value in the Modes field is req= uired during test session establishment. You will also need a good name for= it e.g. UDP checksum mode. Regards Steve Baillargeon From: ippm-bounces@ietf.org [mailto:ippm-boun= ces@ietf.org] On Behalf Of Tal Mizrahi Sent: May-28-13 12:26 PM To: ippm@ietf.org Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi, History: - http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer= -00 Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP. - There was some discussion in the mailing list: http://www.ietf.o= rg/mail-archive/web/ntp/current/msg00492.html - Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/minu= tes?item=3Dminutes81.html Current version: - Split into 2 drafts. There are some similarities, but still it i= s more appropriate to discuss it as two separate drafts: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00 - [NTP draft] Clarified the usage of the NTP extension field witho= ut authentication. Comments will be appreciated. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F9C93AA4ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

 

> How will bypass this requirement without “configurin= g” (via signaling or out-of-band configuration) the responder to igno= re the UDP checksum?

 

The receiver does not ign= ore the checksum. The sender changes the value of the Checksum Trailer to a= value that makes the UDP Checksum field correct. The receiver simply treat= s the Checksum Trailer as part of the padding (i.e., part of the UDP payloa= d).

 

>How much saving (CPU cycles) do you expect between 1)  up= date the timestamp field, and then update the Checksum Trailer and 2) updat= e the timestamp and then update the UDP checksum residing at the UDP header= ?

 

Well, since I work for a silicon vendor, I was= thinking more about silicon implementations, where you update the timestam= p in the chip.
In such implementations, you often process the data in a= serial manner, a few bytes at a time.

So as you go over the pac= ket: you first process the UDP header (including the checksum), and then pr= ocess the payload (including the timestamp). At this point you know how you= want to update the UDP checksum, but it is already too late since the UDP = header may have already been transmitted. It’s still not too late to = update the Checksum Trailer at the end of the packet, so it is updated to a= value that keeps the existing UDP checksum correct.

<= p class=3DMsoNormal> <= /p>

Regards,

Tal.

 

From: Steve Baillargeon [mailto:steve.bai= llargeon@ericsson.com]
Sent: Wednesday, May 29, 2013 3:56 PM
= To: Tal Mizrahi; ippm@ietf.org
Subject: RE: New Draft: dra= ft-mizrahi-owamp-twamp-checksum-trailer-00

 

Hi Tal

 <= /p>

Based on your draft: UDP over IPv6, as defined in [IPv6], does not allo= w a zero checksum, and requires the UDP checksum field to contain a

correct checksum of the UDP payload.

How will bypass thi= s requirement without “configuring” (via signaling or out-of-ba= nd configuration) the responder to ignore the UDP checksum?

=  

How much saving (CPU cycles) do you expect between 1)  upd= ate the timestamp field, and then update the Checksum Trailer and 2) update= the timestamp and then update the UDP checksum residing at the UDP header?=

 

-Steve

 

 

From: Tal Mizrahi [mailto:t= almi@marvell.com]
Sent: May-28-13 11:45 PM
To: Steve B= aillargeon; ippm@ietf.org
Subject: RE: New Draft: draft-mizrahi-o= wamp-twamp-checksum-trailer-00

 

Hi Steve,

 

Thanks for the feedback.

I was hop= ing not to create a new mode, since the new <Checksum Trailer> field = is piggybacked in the padding, and is thus transparent to the reflector (TW= AMP) and receiver (OWAMP).

 

Thanks,

Tal.

 

From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com]
Sent: Tuesday,= May 28, 2013 11:02 PM
To: Tal Mizrahi; ippm@ietf.org
Subject: RE: New Draft: draft-mizrahi-o= wamp-twamp-checksum-trailer-00

 

Hi Tal

Good work!

 =

= For OWAM/TWAMP, since you are changing the test packet format, you will nee= d to assign a new mode that can work in conjunction with the unauthenticate= d mode (or other modes). Bottom-line, a new value in the Modes field is req= uired during test session establishment. You will also need a good name for= it e.g. UDP checksum mode.

 

 

Re= gards

Steve Baillargeon

 

 

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf= Of Tal Mizrahi
Sent: May-28-13 12:26 PM
To: ippm@ietf.org
Subject: [ippm] New = Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00

<= /div>

 =

Hi,

 =

History:

-          http://tools.ietf.org/html/draft-m= izrahi-tictoc-checksum-trailer-00
Originally submitted to TICTOC in = 2011, and discussed checksum trailers for both NTP and OWAMP/TWAMP.

-      &n= bsp;   There was s= ome discussion in the mailing list: http://www.ietf.org/mail-archive/web/nt= p/current/msg00492.html

-&nb= sp;         Some discussion in IETF 81: http://tools.ietf.org/wg= /tictoc/minutes?item=3Dminutes81.html

 

Current version:

=

-       &nb= sp;  Split into 2 draft= s. There are some similarities, but still it is more appropriate to discuss= it as two separate drafts:

htt= p://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00
http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-0= 0

-    &= nbsp;     [NTP draft] Clarified the usage of the NTP extension field without authen= tication.

 

Comments will be appreciated.

 

Thanks,

Tal.

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F9C93AA4ILMB01marve_-- From prvs=1861a0c467=steve.baillargeon@ericsson.com Wed May 29 07:37:45 2013 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 0232021F8F0A for ; Wed, 29 May 2013 07:37:45 -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 9jjf2XFL2uIp for ; Wed, 29 May 2013 07:37:39 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2CF21F8B07 for ; Wed, 29 May 2013 07:37:38 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-ee-51a612b2257b Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DC.0C.05617.2B216A15; Wed, 29 May 2013 16:37:38 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Wed, 29 May 2013 10:37:37 -0400 From: Steve Baillargeon To: Tal Mizrahi , "ippm@ietf.org" Thread-Topic: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Thread-Index: Ac5bs4WuaRAokonHQLeJcPwzWQh1MwAKTOIgABBqkoAAEt+/0AAAiOEwAAM2tRA= Date: Wed, 29 May 2013 14:37:36 +0000 Message-ID: References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380E@IL-MB01.marvell.com> <74470498B659FA4687F0B0018C19A89C01A0F9C9387F@IL-MB01.marvell.com> <74470498B659FA4687F0B0018C19A89C01A0F9C93AA4@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9C93AA4@IL-MB01.marvell.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_DCF22B50497F7641B6DDD16ECC516F7F170DF1DAeusaamb106erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPn+4moWWBBg2XlS16Hrxjtnj1bwuL A5PHkiU/mTwmL7zIHMAUxW2TlFhSFpyZnqdvl8Cdsbb/FnvBpGOMFXfO3mJvYFy6nrGLkZND QsBE4lxXOzOELSZx4d56ti5GLg4hgaOMEt2bZjJBOMsZJW59bQbrYBOwkFg/dxlYh4iAi8S/ fbtZQWxhAVeJ0/e+sELE3STWNO5jgbD9JLY9uMcEYrMIqEp8bW8DquHg4BXwlTjwwQti/gMm iVMLZ4LVcAr4S9xs/s0GYjMKyErsPnsdLM4sIC5x68l8JohLBSSW7DkPdbWoxMvH/1ghbGWJ JU/2s0DU50s07doLVsMrIChxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hn DjxmQhZfwMi+ipGjtDi1LDfdyHATIzCKjkmwOe5gXPDJ8hCjNAeLkjivDu/iQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycIIJLqoGxwpWPOYyPl6s1mNlASobvzRXZ6KR1Zb7e0cf3szyWtuT7 KLPVUnmN+odHO3Ydi1qwLklxWrJo/IUsa9fJU89cOpe5sUM5tmH9I/Xtm1oU/II/Ce7x6n9h WbnDV3Ozz33dwjMMwgeXLhWSNBR4eSzyzrHm71nt9vVuBubSSx/1736mMeHLNjMlluKMREMt 5qLiRADWZcAXdQIAAA== Subject: Re: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 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, 29 May 2013 14:37:45 -0000 --_000_DCF22B50497F7641B6DDD16ECC516F7F170DF1DAeusaamb106erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal I see your point now. I agree that a local configuration to use or not to use a Checksum Trailer = for outgoing test packets should be sufficient (at least in unauthenticated= mode). I agree that a new TWAMP mode is not needed. -Steve From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: May-29-13 10:17 AM To: Steve Baillargeon; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Steve, > How will bypass this requirement without "configuring" (via signaling or = out-of-band configuration) the responder to ignore the UDP checksum? The receiver does not ignore the checksum. The sender changes the value of = the Checksum Trailer to a value that makes the UDP Checksum field correct. = The receiver simply treats the Checksum Trailer as part of the padding (i.e= ., part of the UDP payload). >How much saving (CPU cycles) do you expect between 1) update the timestam= p field, and then update the Checksum Trailer and 2) update the timestamp a= nd then update the UDP checksum residing at the UDP header? Well, since I work for a silicon vendor, I was thinking more about silicon = implementations, where you update the timestamp in the chip. In such implementations, you often process the data in a serial manner, a f= ew bytes at a time. So as you go over the packet: you first process the UDP header (including t= he checksum), and then process the payload (including the timestamp). At th= is point you know how you want to update the UDP checksum, but it is alread= y too late since the UDP header may have already been transmitted. It's sti= ll not too late to update the Checksum Trailer at the end of the packet, so= it is updated to a value that keeps the existing UDP checksum correct. Regards, Tal. From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com] Sent: Wednesday, May 29, 2013 3:56 PM To: Tal Mizrahi; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Tal Based on your draft: UDP over IPv6, as defined in [IPv6], does not allow a = zero checksum, and requires the UDP checksum field to contain a correct checksum of the UDP payload. How will bypass this requirement without "configuring" (via signaling or ou= t-of-band configuration) the responder to ignore the UDP checksum? How much saving (CPU cycles) do you expect between 1) update the timestamp= field, and then update the Checksum Trailer and 2) update the timestamp an= d then update the UDP checksum residing at the UDP header? -Steve From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: May-28-13 11:45 PM To: Steve Baillargeon; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Steve, Thanks for the feedback. I was hoping not to create a new mode, since the new fie= ld is piggybacked in the padding, and is thus transparent to the reflector = (TWAMP) and receiver (OWAMP). Thanks, Tal. From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com] Sent: Tuesday, May 28, 2013 11:02 PM To: Tal Mizrahi; ippm@ietf.org Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi Tal Good work! For OWAM/TWAMP, since you are changing the test packet format, you will nee= d to assign a new mode that can work in conjunction with the unauthenticate= d mode (or other modes). Bottom-line, a new value in the Modes field is req= uired during test session establishment. You will also need a good name for= it e.g. UDP checksum mode. Regards Steve Baillargeon From: ippm-bounces@ietf.org [mailto:ippm-boun= ces@ietf.org] On Behalf Of Tal Mizrahi Sent: May-28-13 12:26 PM To: ippm@ietf.org Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-00 Hi, History: - http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-0= 0 Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP. - There was some discussion in the mailing list: http://www.ietf.org= /mail-archive/web/ntp/current/msg00492.html - Some discussion in IETF 81: http://tools.ietf.org/wg/tictoc/minute= s?item=3Dminutes81.html Current version: - Split into 2 drafts. There are some similarities, but still it is = more appropriate to discuss it as two separate drafts: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-00 http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-00 - [NTP draft] Clarified the usage of the NTP extension field without= authentication. Comments will be appreciated. Thanks, Tal. --_000_DCF22B50497F7641B6DDD16ECC516F7F170DF1DAeusaamb106erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal

I see your point now.<= o:p>

I agree that a local c= onfiguration to use or not to use a Checksum Trailer for outgoing test pac= kets should be sufficient (at least in unauthenticated mode).

I agree that a new TWA= MP mode is not needed.

 

-Steve

 

From: Tal Mizrahi [mailto:talmi@marvell.com]
Sent: May-29-13 10:17 AM
To: Steve Baillargeon; ippm@ietf.org
Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-0= 0

 

Steve,<= o:p>

&n= bsp;

> How will bypass thi= s requirement without “configuring” (via signaling or out-of-ba= nd configuration) the responder to ignore the UDP checksum?

 

The receiver does not = ignore the checksum. The sender changes the value of the Checksum Trailer t= o a value that makes the UDP Checksum field correct. The receiver simply tr= eats the Checksum Trailer as part of the padding (i.e., part of the UDP payload).

 

>How much saving (CPU cycles) do you expect betwe= en 1)  update the timestamp field, and then update the Checksum Traile= r and 2) update the timestamp and then update the UDP checksum residing at = the UDP header?

 

Well, since I work for= a silicon vendor, I was thinking more about silicon implementations, where= you update the timestamp in the chip.
In such implementations, you often process the data in a serial manner, a f= ew bytes at a time.

So as you go over the = packet: you first process the UDP header (including the checksum), and then= process the payload (including the timestamp). At this point you know how = you want to update the UDP checksum, but it is already too late since the UDP header may have already been tran= smitted. It’s still not too late to update the Checksum Trailer at th= e end of the packet, so it is updated to a value that keeps the existing UD= P checksum correct.

&n= bsp;

Regards= ,

Tal.

&n= bsp;

From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com]
Sent: Wednesday, May 29, 2013 3:56 PM
To: Tal Mizrahi; ippm@ietf.org<= br> Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-0= 0

 

Hi Tal

 

Based on your draft: UDP over IPv6, as defined in [IP= v6], does not allow a zero checksum, and requires the UDP checksum field to= contain a

correct checksum= of the UDP payload.

How will bypass this r= equirement without “configuring” (via signaling or out-of-band = configuration) the responder to ignore the UDP checksum?<= /p>

 

How much saving (CPU c= ycles) do you expect between 1)  update the timestamp field, and then = update the Checksum Trailer and 2) update the timestamp and then update the= UDP checksum residing at the UDP header?

 

-Steve

 

 

From: Tal Mizrahi [mai= lto:talmi@marvell.com]
Sent: May-28-13 11:45 PM
To: Steve Baillargeon; ippm@ietf.or= g
Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-0= 0

 

Hi Stev= e,

&n= bsp;

Thanks = for the feedback.

I was h= oping not to create a new mode, since the new <Checksum Trailer> fiel= d is piggybacked in the padding, and is thus transparent to the reflector (= TWAMP) and receiver (OWAMP).

&n= bsp;

Thanks,=

Tal.

&n= bsp;

From: Steve Baillargeon [mailto:steve.baillargeon@ericsson.com]
Sent: Tuesday, May 28, 2013 11:02 PM
To: Tal Mizrahi; ippm@ietf.org<= br> Subject: RE: New Draft: draft-mizrahi-owamp-twamp-checksum-trailer-0= 0

 

Hi Tal

Good work!<= /span>

 

For OWAM/TWAMP, since = you are changing the test packet format, you will need to assign a new mode= that can work in conjunction with the unauthenticated mode (or other modes= ). Bottom-line, a new value in the Modes field is required during test session establishment. You will also need a = good name for it e.g. UDP checksum mode.

 

 

Regards

Steve Baillargeon=

 

 

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: May-28-13 12:26 PM
To: ippm@ietf.org
Subject: [ippm] New Draft: draft-mizrahi-owamp-twamp-checksum-traile= r-00

 

Hi,

 

History:

-  = ;      http://tools.ietf.= org/html/draft-mizrahi-tictoc-checksum-trailer-00
Originally submitted to TICTOC in 2011, and discussed checksum trailers for= both NTP and OWAMP/TWAMP.

-  = ;      There was some discussi= on in the mailing list: = http://www.ietf.org/mail-archive/web/ntp/current/msg00492.html

-  = ;      Some discussion in IETF= 81: http://tools.ietf.org/wg/tictoc/minutes?item=3Dminutes81.html

 

Current version:

-  = ;      Split into 2 drafts. Th= ere are some similarities, but still it is more appropriate to discuss it a= s two separate drafts:

http://tools.ietf.org/= html/draft-mizrahi-ntp-checksum-trailer-00
http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-tra= iler-00

-  = ;      [NTP draft] Clarified t= he usage of the NTP extension field without authentication.

 

Comments will be appreciated.

 

Thanks,

Tal.

 

--_000_DCF22B50497F7641B6DDD16ECC516F7F170DF1DAeusaamb106erics_--