From nobody Fri Sep 7 14:56:46 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 792DA130DE2; Fri, 7 Sep 2018 14:56:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <153635740444.28980.6908501775124770245@ietfa.amsl.com> Date: Fri, 07 Sep 2018 14:56:44 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 21:56:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-02.txt Pages : 14 Date : 2018-09-07 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-02 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 7 15:54:06 2018 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 226B5130DCF for ; Fri, 7 Sep 2018 15:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVn3W489GBHO for ; Fri, 7 Sep 2018 15:54:02 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51484130DC7 for ; Fri, 7 Sep 2018 15:54:02 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id l15-v6so13472362lji.6 for ; Fri, 07 Sep 2018 15:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=S72Vp7MRif6pkNE3UICrAq5Hlhx39Yd1Odpta2urors=; b=tMax5tE15RMfL/dxQjGlGcD8Wv2INah1erf97RgRSY7a6uAyBbtngg6KjfAPtX7IEw 1e0OC6+qKdUjSor9Ij8cjltgkqsMDng8TGUaJSTcdQbIBeG2J2DlVmzY00CG0V8luwEP qWTsRudUuXqNAcubfdV9TzKUe2aEWADKu7hJekziSuLEjo5mNcgeX0MMxKLpOc/AmS+n 3kE5q3dzv7A+b87RDFMxYh+gLRj3zru00GR5uUDd4fK6GlFjn++2gsM12A3GW6oHsGNE khis1Sz6WG80K8K9GKWBbepq6TcKfQIbeyDdvEIwSHfN+PLrApw4Nok4LKLOZw3KE5iW tAxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=S72Vp7MRif6pkNE3UICrAq5Hlhx39Yd1Odpta2urors=; b=qLzH4ygJdY62Dw2FJJ1uQ+95GN7sGurGngQWsPJilsfc1YGit+9xlP1zDNjJ4eza4/ NVyEfWQXfOwf11Ie2x04GbwDFgjP/xexFBGRB5rS77w3CDtrvwdzMth5BJQ1sFOGTliC ap7WgXoFVQE6pSuHXfBj2e5E4MR0d47hAKC6jvDNTxngW8PpFDAtuQiwYgxHcC7dIL7O Unaru0pKfE/LBr/y0pCE6bwhjKOUTBF1kI0kjbKlbU01XRCcAM6rftj+MQDBhMH+ba2B hwvqqzg9da64KUQKeyAE+PCVjIwDU38WgxBFq2vTQyl2Mqdj5rNewMJbH0F5sEaD0mKt Qt8A== X-Gm-Message-State: APzg51C2PPfs+2AFmEWYCgm5/F2Z5Tg0bzn6I+UYASM59Mb0MFlGLIgu Vy3o1Ei+QhDb3+mvrM68ahE5NKD4tZgg3lYLxr/YDw== X-Google-Smtp-Source: ANB0VdbTGMF30inUte4uMFgAkYIeO8lSRDFLap0+6Nzv68MCp3ArZlTPLXd8TIEyqdzRuDIsjBDRv3zF7OFT/ASQgYY= X-Received: by 2002:a2e:680a:: with SMTP id c10-v6mr6361223lja.59.1536360839944; Fri, 07 Sep 2018 15:53:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:193:0:0:0:0:0 with HTTP; Fri, 7 Sep 2018 15:53:59 -0700 (PDT) In-Reply-To: <153635740444.28980.6908501775124770245@ietfa.amsl.com> References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 7 Sep 2018 15:53:59 -0700 Message-ID: To: IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000001ca30605754fe202" Archived-At: Subject: [ippm] Fwd: I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Sep 2018 22:54:05 -0000 --0000000000001ca30605754fe202 Content-Type: text/plain; charset="UTF-8" Dear All, minor editorial improvements to the document. Your comments, questions, and suggestions always welcome and much appreciated. Regards, Greg ---------- Forwarded message ---------- From: Date: Fri, Sep 7, 2018 at 2:56 PM Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt To: i-d-announce@ietf.org Cc: ippm@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-02.txt Pages : 14 Date : 2018-09-07 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-02 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --0000000000001ca30605754fe202 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
minor editorial improvements to the document= .
Your comments, questions, and suggestions always welcome and mu= ch appreciated.

Regards,
Greg
=
---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
D= ate: Fri, Sep 7, 2018 at 2:56 PM
Subject: [ippm] I-D Action: draft-ietf-= ippm-stamp-02.txt
To: i-d-annou= nce@ietf.org
Cc: ippm@ietf.org<= br>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Performance Measurement WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Simple Two-way Active Measurement Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Greg= Mirsky
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Guo Jun
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Henrik Nydell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Richard Foote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ippm-stamp-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-09-07

Abstract:
=C2=A0 =C2=A0This document describes a Simple Two-way Active Measurement Pr= otocol
=C2=A0 =C2=A0which enables measurement of both one-way and round-trip perfo= rmance
=C2=A0 =C2=A0metrics like delay, delay variation, and packet loss.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-ippm-stamp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ippm= -stamp-02
https://datatracker.ietf.org/doc/= html/draft-ietf-ippm-stamp-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-ippm-stamp-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--0000000000001ca30605754fe202-- From nobody Fri Sep 7 15:55:34 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D41130DC7; Fri, 7 Sep 2018 15:55:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <153636092619.28959.14184902132697825991@ietfa.amsl.com> Date: Fri, 07 Sep 2018 15:55:26 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-yang-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 22:55:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol (STAMP) Data Model Authors : Greg Mirsky Xiao Min Wei S Luo Filename : draft-ietf-ippm-stamp-yang-02.txt Pages : 35 Date : 2018-09-07 Abstract: This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-02 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-yang-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 7 16:26:06 2018 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 49AEA130E16 for ; Fri, 7 Sep 2018 16:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL81g1hEcV6b for ; Fri, 7 Sep 2018 16:26:03 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC56F130DC7 for ; Fri, 7 Sep 2018 16:26:02 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id x207-v6so13305473lff.3 for ; Fri, 07 Sep 2018 16:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=d85vbbOIPmxtGXREQmUidqfCEpV+9DFgDuQ5FgJgUus=; b=DwO68+785Pg/S6vmZGnqDtDz/EPKPsa7qEFEVxVRQobZdQdt9bn8qyD4scDdb/2BR3 S+T1SUU7C3fTWM7MEZIkwZeO0jsEZqYP/Sa6gqcLj43I4GFPHS2/fMjgq6EBChiBmx6f zErZrbbHY1tWaGPzatsJPTJ+5vd/qe2Z0JRa6CLSJZtqUTCbHVyVBTPYVvDJWT8IIANF Ogf6W07TqbErh8T2YvWEpTLr1LSF1cmRuVAttExBAuKRDvCLCfHsGKGNcegtMg2vCxks BLljocNE50he2hx8C/bWrXuLxM+8m9sC36pyjZX78Aw/H1/fLVwaFbl2pFqNhZOMjZP0 Lgcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=d85vbbOIPmxtGXREQmUidqfCEpV+9DFgDuQ5FgJgUus=; b=KLvlLtEb/nCBsGX2zf/fjkRn5oXF12LPIVQZ+Y/d/y4b58xD3auMUxFzI/hqEf2tEi yGcx3OKtQuePrvF+DEDL18zG2Gc8Z2hg4DUzgDz4Mqe6TL2+5y2p+jyZsaLL+5VMZ9Qm 8bNNqF8F2vX/WZi6tb/U7SwzhZjtv8JU/7yALdSqEKtbf1haRha43VziTYQKefsBjbTW 15srVapF6TGdq7tGaMES0pu6cmMtd/2P1IcA90BB+v0iwADaFW/Nkae2L96jhGf8yoFO 6fUu1ZIf2iza6Q+9NwXlDpYZKT/8/PU4jraVqypReblhoGI17VqNQu9QbVP9Op1nqDDc WpCA== X-Gm-Message-State: APzg51DIDCz2s3dcwJJTlhmbr5xEZdOAmoXNp+7QMNMTHhOPk8wCvb/i elUt70eZTsuftM1DSaTTxxZ18uu0Y3MONUvGGNW90w== X-Google-Smtp-Source: ANB0VdY/MN7ZKNxmWWg+noa88COtkcR8hNfnVLtoXVJ4+O5ZH6XEMRB68ZUJAT87mz3Xx+gdX9Jxv2mntvECx1g3HUs= X-Received: by 2002:a19:cc08:: with SMTP id c8-v6mr6651357lfg.145.1536362760868; Fri, 07 Sep 2018 16:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:193:0:0:0:0:0 with HTTP; Fri, 7 Sep 2018 16:26:00 -0700 (PDT) In-Reply-To: <153636092619.28959.14184902132697825991@ietfa.amsl.com> References: <153636092619.28959.14184902132697825991@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 7 Sep 2018 16:26:00 -0700 Message-ID: To: IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000009b983e0575505441" Archived-At: Subject: [ippm] Fwd: I-D Action: draft-ietf-ippm-stamp-yang-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Sep 2018 23:26:05 -0000 --0000000000009b983e0575505441 Content-Type: text/plain; charset="UTF-8" Dear All, while we still are working on addressing the comments from the yearly YANGDoctors review (many thanks to Mahesh), decided to share the progress report with you. As always, welcome your comments, questions, and suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Fri, Sep 7, 2018 at 3:55 PM Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-yang-02.txt To: i-d-announce@ietf.org Cc: ippm@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol (STAMP) Data Model Authors : Greg Mirsky Xiao Min Wei S Luo Filename : draft-ietf-ippm-stamp-yang-02.txt Pages : 35 Date : 2018-09-07 Abstract: This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-02 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-yang-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --0000000000009b983e0575505441 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
while we still are working on addressing the= comments from the yearly YANGDoctors review (many thanks to Mahesh), decid= ed to share the progress report with you.
As always, welcome your= comments, questions, and suggestions.

Regards,
Greg

---------- Forwarded = message ----------
From: <internet-drafts@ietf.= org>
Date: Fri, Sep 7, 2018 at 3:55 PM
Subject: [ippm] = I-D Action: draft-ietf-ippm-stamp-yang-02.txt
To: i-d-announce@ietf.org
Cc: ippm@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Performance Measurement WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Simple Two-way Active Measurement Protocol (STAMP) Data Model
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Greg= Mirsky
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Xiao Min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Wei S Luo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ippm-stamp-yang-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 35
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-09-07

Abstract:
=C2=A0 =C2=A0This document specifies the data model for implementations of<= br> =C2=A0 =C2=A0Session-Sender and Session-Reflector for Simple Two-way Active=
=C2=A0 =C2=A0Measurement Protocol (STAMP) mode using YANG.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-ippm-stamp-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-ippm-stamp-yang-02
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-ippm-stamp-yang-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--0000000000009b983e0575505441-- From nobody Mon Sep 10 05:36:43 2018 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 40026130EBD; Mon, 10 Sep 2018 05:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeRsTLPTNpDY; Mon, 10 Sep 2018 05:36:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83549127B92; Mon, 10 Sep 2018 05:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28742; q=dns/txt; s=iport; t=1536582992; x=1537792592; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BBe4xfy2+ktX/PUos+I3GKgWnte8md5nt0OurMVtoB4=; b=D2Lnn99drSeR+lbNpHWZqPGaOZtVygYm5Gv+WU4yiepLRcDoKJ122E4M 8neXSUu8GMMruZTceVyoMbiaVbOztHN073GZHJhlJ+hOQE7BJTGAAyTj5 G9tiJwWeb4vU5715IyIfLBWsK27c4MsmQwhz4aLhXsTYSnrpMSmXKPagg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AABxZJZb/5NdJa1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCV0gvZX8oCoNoiBOMHoFoJZY0gXoLJ4EvAYMVAheDYiE?= =?us-ascii?q?0GAECAQECAQECbRwMhTgBAQEBAyNEEhACAQgRAwEBASEHAwICAjAUCQgCBA4?= =?us-ascii?q?FgyEBgR1kD6RQgS4fhA8BPYUJBYplF4FBP4ESJwwTgkyCdyQCAwGBMkIJFoJ?= =?us-ascii?q?LMYImAogmhQyFYYh1CQKGN4lJF45wizqILAIRFIElHTiBVXAVZQGCQYsVhT5?= =?us-ascii?q?vjHuBHQEB?= X-IronPort-AV: E=Sophos;i="5.53,355,1531785600"; d="scan'208,217";a="232185009" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2018 12:36:30 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w8ACaUiP031303 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Sep 2018 12:36:30 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Sep 2018 07:36:30 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1395.000; Mon, 10 Sep 2018 07:36:30 -0500 From: "Rakesh Gandhi (rgandhi)" To: Mach Chen CC: "ippm@ietf.org" , spring Thread-Topic: New Draft draft-gandhi-spring-udp-pm Thread-Index: AQHUHdYWIyzVjAdRVki/QCU1ZO1Y+aSdv1EAgEwbkYA= Date: Mon, 10 Sep 2018 12:36:30 +0000 Message-ID: References: <92ED16BE-ACDF-4901-91B5-BC39A744C2F1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.181.86] Content-Type: multipart/alternative; boundary="_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [ippm] New Draft draft-gandhi-spring-udp-pm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Sep 2018 12:36:35 -0000 --_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1hY2ggZm9yIHRoZSBjb21tZW50cy4gV2Ugd2lsbCBhZGQgZm9sbG93aW5nIFRMViBp biB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuDQoNCg0KMy4xLjIuMS4gIEJsb2NrIE51 bWJlciBUTFYNCg0KICAgVGhlIExvc3MgTWVhc3VyZW1lbnQgdXNpbmcgQWx0ZXJuYXRlLU1hcmtp bmcgbWV0aG9kIGRlZmluZWQgaW4NCiAgIFtSRkM4MzIxXSByZXF1aXJlcyB0byBpZGVudGlmeSB0 aGUgQmxvY2sgTnVtYmVyIChjb2xvdXIpIG9mIHRoZQ0KICAgdHJhZmZpYyBjb3VudGVycyBjYXJy aWVkIGJ5IHRoZSBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMuDQogICBQcm9iZSBx dWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgc3BlY2lmaWVkIGluIFtSRkM2Mzc0XSBmb3IgTG9z cw0KICAgTWVhc3VyZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8gY2FycnkgdGhlIEJs b2NrIE51bWJlci4NCg0KICAgW1JGQzYzNzRdIGRlZmluZXMgcHJvYmUgcXVlcnkgYW5kIHJlc3Bv bnNlIG1lc3NhZ2VzIHRoYXQgY2FuIGluY2x1ZGUNCiAgIG9uZSBvciBtb3JlIG9wdGlvbmFsIFRM VnMuICBOZXcgVExWIFR5cGUgKHZhbHVlIFRCQTgpIGlzIGRlZmluZWQgaW4NCiAgIHRoaXMgZG9j dW1lbnQgdG8gY2FycnkgQmxvY2sgTnVtYmVyICgzMi1iaXQpIGZvciB0aGUgdHJhZmZpYyBjb3Vu dGVycw0KICAgaW4gdGhlIHByb2JlIHF1ZXJ5IGFuZCByZXNwb25zZSBtZXNzYWdlcyBmb3IgbG9z cyBtZWFzdXJlbWVudC4gIFRoZQ0KICAgZm9ybWF0IG9mIHRoZSBCbG9jayBOdW1iZXIgVExWIGlz IHNob3duIGluIEZpZ3VyZSAxMToNCg0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgIHwgICBUeXBlIFRCQTcgICB8ICAgIExlbmd0aCAgICAgfCAgICAgIFJlc2VydmVkICAg ICAgICAgICAgICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICBCbG9jayBOdW1iZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQoNCiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDExOiBCbG9jayBOdW1iZXIgVExWDQoNCiAg IFRoZSBCbG9jayBOdW1iZXIgVExWIGlzIG9wdGlvbmFsLiAgVGhlIFBNIHF1ZXJpZXIgbm9kZSBT SE9VTEQgb25seQ0KICAgaW5zZXJ0IG9uZSBCbG9jayBOdW1iZXIgVExWIGluIHRoZSBwcm9iZSBx dWVyeSBtZXNzYWdlIGFuZCB0aGUNCiAgIHJlc3BvbmRlciBub2RlIGluIHRoZSBwcm9iZSByZXNw b25zZSBtZXNzYWdlIFNIT1VMRCByZXR1cm4gdGhlIGZpcnN0DQogICBCbG9jayBOdW1iZXIgVExW IGZyb20gdGhlIHByb2JlIHF1ZXJ5IG1lc3NhZ2VzIGFuZCBpZ25vcmUgb3RoZXIgQmxvY2sNCiAg IE51bWJlciBUTFZzIGlmIHByZXNlbnQuICBJbiBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVz c2FnZXMsIHRoZQ0KICAgY291bnRlcnMgTVVTVCBiZWxvbmcgdG8gdGhlIHNhbWUgQmxvY2sgTnVt YmVyLg0KDQoNClRoYW5rcywNClJha2VzaA0KDQoNCg0KRnJvbTogTWFjaCBDaGVuIDxtYWNoLmNo ZW5AaHVhd2VpLmNvbT4NCkRhdGU6IE1vbmRheSwgSnVseSAyMywgMjAxOCBhdCAxMTozMSBQTQ0K VG86ICI9U01UUDpyZ2FuZGhpQGNpc2NvLiBjb20iIDxyZ2FuZGhpQGNpc2NvLmNvbT4NCkNjOiAi aXBwbUBpZXRmLm9yZyIgPGlwcG1AaWV0Zi5vcmc+LCBzcHJpbmcgPHNwcmluZ0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhpLXNwcmluZy11ZHAtcG0NCg0KSGkg QXV0aG9ycywNCg0KVGhlIGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtLTAxIGRlZmluZXMgYSBu ZXcgQyBmbGFnIGFzIGZvbGxvd2luZzoNCg0KMy4xLjIuMS4gIExvc3MgTWVhc3VyZW1lbnQgRmxh Z3MNCg0KICAgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERhdGEgRm9ybWF0IEZsYWdzIChERmxhZ3Mp IGFzIGRlZmluZWQgaW4NCiAgIFtSRkM2Mzc0XS4gIE5ldyBGbGFnIGlzIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudCBmb3IgQ29sb3IgKEMpIGluIHRoZQ0KICAgREZsYWdzIGZpZWxkIGFzIGZvbGxv d3MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfFh8QnxDfDB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBEYXRhIEZvcm1hdCBG bGFncw0KDQogICBUaGUgRmxhZyBDIGluZGljYXRlcyB0aGUgQ29sb3Igb2YgdGhlIGNvdW50ZXJz IGluIHRoZSBMTSBwcm9iZQ0KICAgbWVzc2FnZSBbUkZDNjM3NF0gd2hlbiB1c2luZyBBbHRlcm5h dGUtTWFya2luZyBtZXRob2QgZGVmaW5lZCBpbg0KICAgW1JGQzgzMjFdLg0KLS0tLS0tLS0tLS0t LQ0KDQpBcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yIG9mIFtSRkM4MzIxXSwgY291bGQgeW91IGNv bnNpZGVyIHRvIGRlZmluZSBtb3JlIHRoYW4gb25lIGZsYWcgb3IgYSBUTFYgdG8gY2FycnkgQmxv Y2sgbnVtYmVyIGluc3RlYWQ/DQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KRnJvbTogaXBwbSBb bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJha2VzaCBHYW5kaGkg KHJnYW5kaGkpDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDk6NTcgUE0NClRvOiBpcHBt QGlldGYub3JnDQpTdWJqZWN0OiBbaXBwbV0gTmV3IERyYWZ0IGRyYWZ0LWdhbmRoaS1zcHJpbmct dWRwLXBtDQoNCkhpIFdHLA0KDQpXZSBsaWtlIHRvIGludHJvZHVjZSBmb2xsb3dpbmcgbmV3IGRy YWZ0IHRoYXQgd2FzIHByZXNlbnRlZCB0byBTUFJJTkcgV0cgeWVzdGVyZGF5Lg0KDQpUaGlzIGRy YWZ0IGRlZmluZXMgSVAvVURQIHBhdGggZm9yIHNlbmRpbmcgcHJvYmUgcXVlcnkgbWVzc2FnZXMg Zm9yIGRlbGF5IGFuZCBsb3NzIG1lYXN1cmVtZW50IHRoYXQgaXMgYWdub3N0aWNzIHRvIGRhdGEg cGxhbmUgKFNSLU1QTFMvU1J2Ni9JUCkgYW5kIGRvZXMgbm90IHJlcXVpcmUgdG8gYm9vdHN0cmFw IFBNIHNlc3Npb24uDQoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Z2FuZGhpLXNwcmluZy11ZHAtcG0vDQoNCllvdSBtYXkgZmluZCBwcmVzZW50YXRpb24gaW4gdGhl IGZvbGxvd2luZyBwYWNrYWdlIChpdCBpcyB0aGUgc2Vjb25kIGRyYWZ0KS4NCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9tYXRlcmlhbHMvc2xpZGVzLTEwMi1zcHJp bmctMTMtcGVyZm9ybWFuY2UtbWVhc3VyZW1lbnQtaW4tc3ItbmV0d29ya3MtMDANCg0KV2Ugd2Vs Y29tZSB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4NCg0KVGhhbmtzLA0KUmFrZXNoIChP biBiZWhhbGYgb2YgYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzKQ0KDQo= --_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <354D19C367601E41B0C5F8B24FC3292D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHlsZS1uYW1lOnAxOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjVwdDsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMwNDYzQzE7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uczENCgl7bXNvLXN0eWxlLW5hbWU6czE7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnAucDIsIGxpLnAyLCBkaXYucDIN Cgl7bXNvLXN0eWxlLW5hbWU6cDI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjcuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5w MywgbGkucDMsIGRpdi5wMw0KCXttc28tc3R5bGUtbmFtZTpwMzsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28t c3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzIE1hY2ggZm9yIHRoZSBjb21tZW50cy4gV2Ug d2lsbCBhZGQgZm9sbG93aW5nIFRMViBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+My4xLjIuMS4m bmJzcDsgQmxvY2sgTnVtYmVyIFRMVjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBMb3NzIE1lYXN1cmVtZW50 IHVzaW5nIEFsdGVybmF0ZS1NYXJraW5nIG1ldGhvZCBkZWZpbmVkIGluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBbUkZD ODMyMV0gcmVxdWlyZXMgdG8gaWRlbnRpZnkgdGhlIEJsb2NrIE51bWJlciAoY29sb3VyKSBvZiB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHRyYWZmaWMgY291bnRlcnMgY2FycmllZCBieSB0aGUgcHJvYmUgcXVlcnkg YW5kIHJlc3BvbnNlIG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDtQcm9iZSBxdWVyeSBhbmQgcmVz cG9uc2UgbWVzc2FnZXMgc3BlY2lmaWVkIGluIFtSRkM2Mzc0XSBmb3IgTG9zczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg TWVhc3VyZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8gY2FycnkgdGhlIEJsb2NrIE51 bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBbUkZDNjM3NF0gZGVmaW5lcyBwcm9iZSBxdWVyeSBhbmQgcmVz cG9uc2UgbWVzc2FnZXMgdGhhdCBjYW4gaW5jbHVkZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb25lIG9yIG1vcmUgb3B0 aW9uYWwgVExWcy4mbmJzcDsgTmV3IFRMViBUeXBlICh2YWx1ZSBUQkE4KSBpcyBkZWZpbmVkIGlu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyB0aGlzIGRvY3VtZW50IHRvIGNhcnJ5IEJsb2NrIE51bWJlciAoMzItYml0KSBm b3IgdGhlIHRyYWZmaWMgY291bnRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluIHRoZSBwcm9iZSBxdWVyeSBhbmQg cmVzcG9uc2UgbWVzc2FnZXMgZm9yIGxvc3MgbWVhc3VyZW1lbnQuJm5ic3A7IFRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgZm9ybWF0IG9mIHRoZSBCbG9jayBOdW1iZXIgVExWIGlzIHNob3duIGluIEZpZ3VyZSAxMTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IFR5cGUgVEJB NyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlbmd0aCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlc2VydmVkJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJs b2NrIE51bWJlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDt8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSAx MTogQmxvY2sgTnVtYmVyIFRMVjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBCbG9jayBOdW1iZXIgVExWIGlz IG9wdGlvbmFsLiZuYnNwOyBUaGUgUE0gcXVlcmllciBub2RlIFNIT1VMRCBvbmx5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBpbnNlcnQgb25lIEJsb2NrIE51bWJlciBUTFYgaW4gdGhlIHByb2JlIHF1ZXJ5IG1lc3NhZ2Ug YW5kIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgcmVzcG9uZGVyIG5vZGUgaW4gdGhlIHByb2JlIHJlc3BvbnNlIG1l c3NhZ2UgU0hPVUxEIHJldHVybiB0aGUgZmlyc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJsb2NrIE51bWJlciBUTFYg ZnJvbSB0aGUgcHJvYmUgcXVlcnkgbWVzc2FnZXMgYW5kIGlnbm9yZSBvdGhlciBCbG9jazxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgTnVtYmVyIFRMVnMgaWYgcHJlc2VudC4mbmJzcDsgSW4gcHJvYmUgcXVlcnkgYW5kIHJl c3BvbnNlIG1lc3NhZ2VzLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNvdW50ZXJzIE1VU1QgYmVsb25nIHRvIHRo ZSBzYW1lIEJsb2NrIE51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlJha2VzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1h Y2ggQ2hlbiAmbHQ7bWFjaC5jaGVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1v bmRheSwgSnVseSAyMywgMjAxOCBhdCAxMTozMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PVNN VFA6cmdhbmRoaUBjaXNjby4gY29tJnF1b3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90O2lwcG1AaWV0Zi5vcmcmcXVvdDsgJmx0O2lwcG1AaWV0Zi5vcmcm Z3Q7LCBzcHJpbmcgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UkU6IE5ldyBEcmFmdCBkcmFmdC1nYW5kaGktc3ByaW5nLXVkcC1wbTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SGkgQXV0aG9ycyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5U aGUgZHJhZnQtZ2FuZGhpLXNwcmluZy11ZHAtcG0tMDEgZGVmaW5lcyBhIG5ldyBDIGZsYWcgYXMg Zm9sbG93aW5nOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjMuMS4yLjEuJm5ic3A7IExvc3MgTWVhc3VyZW1lbnQg RmxhZ3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERh dGEgRm9ybWF0IEZsYWdzIChERmxhZ3MpIGFzIGRlZmluZWQgaW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgW1JGQzYzNzRdLiZuYnNwOyBOZXcgRmxhZyBpcyBk ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZm9yIENvbG9yIChDKSBpbiB0aGU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgREZsYWdzIGZpZWxkIGFzIGZvbGxvd3Mu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxYfEJ8Q3wwfDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRhIEZvcm1hdCBGbGFn czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBUaGUgRmxhZyBDIGluZGljYXRlcyB0aGUgQ29s b3Igb2YgdGhlIGNvdW50ZXJzIGluIHRoZSBMTSBwcm9iZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtZXNzYWdlIFtSRkM2Mzc0XSB3aGVuIHVzaW5nIEFsdGVy bmF0ZS1NYXJraW5nIG1ldGhvZCBkZWZpbmVkIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IFtSRkM4MzIxXS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEIj4tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+QXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQu MiBvZiBbUkZDODMyMV0sIGNvdWxkIHlvdSBjb25zaWRlciB0byBkZWZpbmUgbW9yZSB0aGFuIG9u ZSBmbGFnIG9yIGEgVExWIHRvIGNhcnJ5IEJsb2NrIG51bWJlciBpbnN0ZWFkPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5NYWNoPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gaXBwbSBb bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmFrZXNo IEdhbmRoaSAocmdhbmRoaSk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywgMjAx OCA5OjU3IFBNPGJyPg0KPGI+VG86PC9iPiBpcHBtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtpcHBtXSBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhpLXNwcmluZy11ZHAtcG08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkhpIFdHLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5XZSBsaWtlIHRvIGlu dHJvZHVjZSBmb2xsb3dpbmcgbmV3IGRyYWZ0IHRoYXQgd2FzIHByZXNlbnRlZCB0byBTUFJJTkcg V0cgeWVzdGVyZGF5Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPlRoaXMgZHJhZnQgZGVmaW5lcyBJUC9VRFAgcGF0 aCBmb3Igc2VuZGluZyBwcm9iZSBxdWVyeSBtZXNzYWdlcyBmb3IgZGVsYXkgYW5kIGxvc3MgbWVh c3VyZW1lbnQgdGhhdCBpcyBhZ25vc3RpY3MgdG8gZGF0YSBwbGFuZSAoU1ItTVBMUy9TUnY2L0lQ KSBhbmQgZG9lcyBub3QgcmVxdWlyZSB0byBib290c3RyYXAgUE0gc2Vzc2lvbi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2FuZGhpLXNw cmluZy11ZHAtcG0vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nYW5k aGktc3ByaW5nLXVkcC1wbS88L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Zb3UgbWF5IGZpbmQgcHJl c2VudGF0aW9uIGluIHRoZSBmb2xsb3dpbmcgcGFja2FnZSAoaXQgaXMgdGhlIHNlY29uZCBkcmFm dCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy8xMDIvbWF0ZXJpYWxzL3NsaWRlcy0xMDItc3ByaW5nLTEzLXBlcmZvcm1hbmNlLW1lYXN1 cmVtZW50LWluLXNyLW5ldHdvcmtzLTAwIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTAyL21hdGVyaWFscy9zbGlkZXMtMTAyLXNwcmluZy0xMy1wZXJmb3JtYW5jZS1tZWFz dXJlbWVudC1pbi1zci1uZXR3b3Jrcy0wMDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+V2Ugd2VsY29tZSB5b3Vy IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+VGhhbmtzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdCI+UmFrZXNoIChPbiBiZWhhbGYgb2YgYXV0aG9ycyBhbmQgY29u dHJpYnV0b3JzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_-- From nobody Mon Sep 10 06:04:48 2018 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 BA566130E96; Mon, 10 Sep 2018 06:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLl0jQOlgm9c; Mon, 10 Sep 2018 06:04:42 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45C5130E94; Mon, 10 Sep 2018 06:04:41 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id z11-v6so17345461lff.9; Mon, 10 Sep 2018 06:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wOI2AoC2u6mp/nMg/44rsyArmviGtBqYuthQDUQlto8=; b=R9Hg1DYkk+zZyfAHDqwjnJEVEfRNBgvosXp7mKuHk2TbIyrUAhdhlFpqaZFFIOOeDQ wQx6ZVxfXtXESAfhhVlm0FeAVHQ0h3AnVm/sWspZTP0G/2UNYOWJkT2vFC/gAmzoZQKN JBfc0Ul3oZTBh5+U39erggPN6mqCy+FTs45VnxwuJTPARlMtr04T0esEotMW7XDST9as Pe/iow9vEGxduq0ru7XUZ54H3ivoPG5FVffoB0UjRSyhFE8ESJMh1odYXi6U+i4YhmnN 4r1N1v6mCzHc5NSXB7rLOlsynChdnDy9Ykkif68sIjvq1/jqPQ+OW2NGQs9nA4IPR+hr +QnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wOI2AoC2u6mp/nMg/44rsyArmviGtBqYuthQDUQlto8=; b=gBCtekzX7VqfXNMbfLulDH/TZaTpHONWS2LJntqw7Q10KcnucwGoXxG/dPK63A5qoH z+76S1EdJ4BhCv+qVwBLRReuG+2pPv3hBI3d7z6ApSuDlXtQWA0a3r8Iy5yIuYqiC3mh bnuyrpX5N5nViX3UW/7+SE3mYuoz8mU0un4E+33rZPbg4V8IGd9hGqrOtAM2eAFNQmsl lgcFpbRhLMD6eR6XGPp5EAGaRRxw0obUUgWpfRIDzapx8TNJsNj8zjS1nrlEpT+E3YUE T29SAaJMPNWHotLWaRbXv6jT+DTwz7NWDL4cVG0+hEE3P5y0/Jwv39kGZuUHmWEOPeNY 6sFw== X-Gm-Message-State: APzg51CPDz2jCXVopq4YNzNkKue2zbUuegd7Ev67tr60nb/iw1jsujFy tFU2A7lhPE5jAemfB1fJXmHhWIN6frtiNf6OGA== X-Google-Smtp-Source: ANB0VdbBbLWP/yRC7GYpXR1JP5POQm0Ev0TyeAJ/8Ru1jZoqk4TD4n4RasMJ1rCWG8Dr3WZvZceyabRpaTrUZ6+1XaU= X-Received: by 2002:a19:4283:: with SMTP id p125-v6mr8293120lfa.104.1536584676903; Mon, 10 Sep 2018 06:04:36 -0700 (PDT) MIME-Version: 1.0 References: <92ED16BE-ACDF-4901-91B5-BC39A744C2F1@cisco.com> In-Reply-To: From: Rakesh Gandhi Date: Mon, 10 Sep 2018 09:04:25 -0400 Message-ID: To: Greg Mirsky Cc: rgandhi=40cisco.com@dmarc.ietf.org, spring@ietf.org, ippm@ietf.org Content-Type: multipart/alternative; boundary="000000000000d58fa3057583ff4e" Archived-At: Subject: Re: [ippm] [spring] New Draft draft-gandhi-spring-udp-pm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Sep 2018 13:04:46 -0000 --000000000000d58fa3057583ff4e Content-Type: text/plain; charset="UTF-8" Hi Greg, Thanks for your comments. We can add following summary in the draft for STAMP. Please advise if the text is correct. The Simple Two-way Active Measurement Protocol (STAMP) [I-D.ippm-stamp] extends TWAMP by alleviating control channel signaling to setup test channel and supports IEEE 1588 timestamp format. The STAMP defines mechanisms such as using the TCP port of control channel for test channel, using configuration data model to provision test channels and using responder node in reflector mode for two-way measurement. The TWAMP Light from broadband forum [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer Edge IP networks. Thanks, Rakesh On Tue, Jul 17, 2018 at 3:30 PM Greg Mirsky wrote: > Hi Rakesh, > thank you for bringing this draft up for discussion. There was not enough > time to ask questions at the SPRING WG meeting and this is a very good > opportunity. > I understand that you've proposed to use RFC 6374 to encode PM operations > and measurements.. Also, you've referenced work on OWAMP and TWAMP. But I > don't find any reference to STAMP > in the draft. How > would you position STAMP, its optional extensions > , and YANG > model in > comparison with your new draft? > > Regards, > Greg > > On Tue, Jul 17, 2018 at 6:57 AM, Rakesh Gandhi (rgandhi) < > rgandhi=40cisco.com@dmarc.ietf.org> wrote: > >> Hi WG, >> >> >> >> We like to introduce following new draft that was presented to SPRING WG >> yesterday. >> >> >> >> This draft defines IP/UDP path for sending probe query messages for delay >> and loss measurement that is agnostics to data plane (SR-MPLS/SRv6/IP) and >> does not require to bootstrap PM session. >> >> >> >> https://datatracker.ietf.org/doc/draft-gandhi-spring-udp-pm/ >> >> >> >> You may find presentation in the following package (it is the second >> draft). >> >> >> >> >> https://datatracker.ietf.org/meeting/102/materials/slides-102-spring-13-performance-measurement-in-sr-networks-00 >> >> >> >> We welcome your comments and suggestions. >> >> >> >> Thanks, >> >> Rakesh (On behalf of authors and contributors) >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000d58fa3057583ff4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

Th= anks for your comments. We can add following summary in the draft for STAMP= . Please advise if the text is correct.

=C2=A0= The Simple Two-way Active Measurement Protocol (STAMP)
=C2=A0=C2=A0 [I-= D.ippm-stamp] extends TWAMP by alleviating control channel
=C2=A0=C2=A0 = signaling to setup test channel and supports IEEE 1588 timestamp
=C2=A0= =C2=A0 format.=C2=A0 The STAMP defines mechanisms such as using the TCP por= t of
=C2=A0=C2=A0 control channel for test channel, using configuration = data model to
=C2=A0=C2=A0 provision test channels and using responder n= ode in reflector mode
=C2=A0=C2=A0 for two-way measurement.=C2=A0 The TW= AMP Light from broadband forum
=C2=A0=C2=A0 [BBF.TR-390] provides simpli= fied mechanisms for active performance
=C2=A0=C2=A0 measurement in Custo= mer Edge IP networks.

Thanks,
Rakesh=


On Tue, Jul 17, 2018 at 3:30 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Rakesh,
thank you for bringin= g this draft up for discussion. There was not enough time to ask questions = at the SPRING WG meeting and this is a very good opportunity.=C2=A0
I understand that you've proposed to use RFC 6374 to encode PM opera= tions and measurements.. Also, you've referenced work on OWAMP and TWAM= P. But I don't find any reference to STAMP in the draft. Ho= w would you position STAMP, its optional extensions, and YANG model=C2=A0in comparison with your new draft?<= /div>

Regards,
Greg

On Tue, Jul 17, 2018 at 6:57 AM,= Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.i= etf.org> wrote:

Hi W= G,

<= /u>=C2=A0

We l= ike to introduce following new draft that was presented to SPRING WG yester= day.

<= /u>=C2=A0

This= draft defines IP/UDP path for sending probe query messages for delay and l= oss measurement that is agnostics to data plane (SR-MPLS/SRv6/IP) and does = not require to bootstrap PM session.

<= /u>=C2=A0

https://datatracker.ietf.org/doc/draft-gandhi-spring-= udp-pm/

<= /u>=C2=A0

You = may find presentation in the following package (it is the second draft).=

<= /u>=C2=A0

https://da= tatracker.ietf.org/meeting/102/materials/slides-102-spring-13-performance-m= easurement-in-sr-networks-00

<= /u>=C2=A0

We w= elcome your comments and suggestions.

<= /u>=C2=A0

Than= ks,

Rake= sh (On behalf of authors and contributors)

<= /u>=C2=A0


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


_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000d58fa3057583ff4e-- From nobody Mon Sep 10 18:12:29 2018 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 D05A4130FF2; Mon, 10 Sep 2018 18:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mOVL6vL1MOe; Mon, 10 Sep 2018 18:12:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83473130F34; Mon, 10 Sep 2018 18:12:26 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 00A62F0A362C3; Tue, 11 Sep 2018 02:12:24 +0100 (IST) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 11 Sep 2018 02:12:24 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.7]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0382.000; Tue, 11 Sep 2018 09:12:19 +0800 From: Mach Chen To: spring CC: "ippm@ietf.org" Thread-Topic: Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm Thread-Index: AdRJbGlD0dKzTMmeRKC4ZAeuWsJEag== Date: Tue, 11 Sep 2018 01:12:19 +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.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 01:12:28 -0000 Hi Authors, =20 The draft-li-pce-sr-path-segment and draft-cheng-spring-mpls-path-segment d= efine the notion of path segment identifier. Could you please consider addi= ng some text in draft-gandhi-spring-udp-pm and draft-gandhi-spring-sr-mpls-= pm and how it is applicable to performance measurement in segment routing? =20 Best regards Mach From nobody Mon Sep 10 18:25:52 2018 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 02F3113101C; Mon, 10 Sep 2018 18:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa9DeQ4zNOFE; Mon, 10 Sep 2018 18:25:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640E9131008; Mon, 10 Sep 2018 18:25:47 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E2BD8CACA80E7; Tue, 11 Sep 2018 02:09:33 +0100 (IST) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 11 Sep 2018 02:09:33 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.7]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0399.000; Tue, 11 Sep 2018 09:09:28 +0800 From: Mach Chen To: "Rakesh Gandhi (rgandhi)" CC: "ippm@ietf.org" , spring Thread-Topic: New Draft draft-gandhi-spring-udp-pm Thread-Index: AQHUHdYWIyzVjAdRVki/QCU1ZO1Y+aSdv1EAgEwbkYCAAMFW0A== Date: Tue, 11 Sep 2018 01:09:28 +0000 Message-ID: References: <92ED16BE-ACDF-4901-91B5-BC39A744C2F1@cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] New Draft draft-gandhi-spring-udp-pm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 01:25:50 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFrZXNoLA0KDQpJdCBsb29rcyBnb29kIHRvIG1lLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNo DQoNCkZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIFttYWlsdG86cmdhbmRoaUBjaXNjby5j b21dDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxOCA4OjM3IFBNDQpUbzogTWFjaCBD aGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4NCkNjOiBpcHBtQGlldGYub3JnOyBzcHJpbmcgPHNw cmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhpLXNwcmlu Zy11ZHAtcG0NCg0KVGhhbmtzIE1hY2ggZm9yIHRoZSBjb21tZW50cy4gV2Ugd2lsbCBhZGQgZm9s bG93aW5nIFRMViBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuDQoNCg0KMy4xLjIu MS4gIEJsb2NrIE51bWJlciBUTFYNCg0KICAgVGhlIExvc3MgTWVhc3VyZW1lbnQgdXNpbmcgQWx0 ZXJuYXRlLU1hcmtpbmcgbWV0aG9kIGRlZmluZWQgaW4NCiAgIFtSRkM4MzIxXSByZXF1aXJlcyB0 byBpZGVudGlmeSB0aGUgQmxvY2sgTnVtYmVyIChjb2xvdXIpIG9mIHRoZQ0KICAgdHJhZmZpYyBj b3VudGVycyBjYXJyaWVkIGJ5IHRoZSBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMu DQogICBQcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgc3BlY2lmaWVkIGluIFtSRkM2 Mzc0XSBmb3IgTG9zcw0KICAgTWVhc3VyZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8g Y2FycnkgdGhlIEJsb2NrIE51bWJlci4NCg0KICAgW1JGQzYzNzRdIGRlZmluZXMgcHJvYmUgcXVl cnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIHRoYXQgY2FuIGluY2x1ZGUNCiAgIG9uZSBvciBtb3Jl IG9wdGlvbmFsIFRMVnMuICBOZXcgVExWIFR5cGUgKHZhbHVlIFRCQTgpIGlzIGRlZmluZWQgaW4N CiAgIHRoaXMgZG9jdW1lbnQgdG8gY2FycnkgQmxvY2sgTnVtYmVyICgzMi1iaXQpIGZvciB0aGUg dHJhZmZpYyBjb3VudGVycw0KICAgaW4gdGhlIHByb2JlIHF1ZXJ5IGFuZCByZXNwb25zZSBtZXNz YWdlcyBmb3IgbG9zcyBtZWFzdXJlbWVudC4gIFRoZQ0KICAgZm9ybWF0IG9mIHRoZSBCbG9jayBO dW1iZXIgVExWIGlzIHNob3duIGluIEZpZ3VyZSAxMToNCg0KICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgIHwgICBUeXBlIFRCQTcgICB8ICAgIExlbmd0aCAgICAgfCAgICAg IFJlc2VydmVkICAgICAgICAgICAgICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAg ICAgICAgICAgICAgICBCbG9jayBOdW1iZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQoNCiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDExOiBCbG9jayBOdW1i ZXIgVExWDQoNCiAgIFRoZSBCbG9jayBOdW1iZXIgVExWIGlzIG9wdGlvbmFsLiAgVGhlIFBNIHF1 ZXJpZXIgbm9kZSBTSE9VTEQgb25seQ0KICAgaW5zZXJ0IG9uZSBCbG9jayBOdW1iZXIgVExWIGlu IHRoZSBwcm9iZSBxdWVyeSBtZXNzYWdlIGFuZCB0aGUNCiAgIHJlc3BvbmRlciBub2RlIGluIHRo ZSBwcm9iZSByZXNwb25zZSBtZXNzYWdlIFNIT1VMRCByZXR1cm4gdGhlIGZpcnN0DQogICBCbG9j ayBOdW1iZXIgVExWIGZyb20gdGhlIHByb2JlIHF1ZXJ5IG1lc3NhZ2VzIGFuZCBpZ25vcmUgb3Ro ZXIgQmxvY2sNCiAgIE51bWJlciBUTFZzIGlmIHByZXNlbnQuICBJbiBwcm9iZSBxdWVyeSBhbmQg cmVzcG9uc2UgbWVzc2FnZXMsIHRoZQ0KICAgY291bnRlcnMgTVVTVCBiZWxvbmcgdG8gdGhlIHNh bWUgQmxvY2sgTnVtYmVyLg0KDQoNClRoYW5rcywNClJha2VzaA0KDQoNCg0KRnJvbTogTWFjaCBD aGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20+Pg0K RGF0ZTogTW9uZGF5LCBKdWx5IDIzLCAyMDE4IGF0IDExOjMxIFBNDQpUbzogIj1TTVRQOnJnYW5k aGlAY2lzY28uIGNvbSIgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNv bT4+DQpDYzogImlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+IiA8aXBwbUBpZXRm Lm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+LCBzcHJpbmcgPHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhp LXNwcmluZy11ZHAtcG0NCg0KSGkgQXV0aG9ycywNCg0KVGhlIGRyYWZ0LWdhbmRoaS1zcHJpbmct dWRwLXBtLTAxIGRlZmluZXMgYSBuZXcgQyBmbGFnIGFzIGZvbGxvd2luZzoNCg0KMy4xLjIuMS4g IExvc3MgTWVhc3VyZW1lbnQgRmxhZ3MNCg0KICAgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERhdGEg Rm9ybWF0IEZsYWdzIChERmxhZ3MpIGFzIGRlZmluZWQgaW4NCiAgIFtSRkM2Mzc0XS4gIE5ldyBG bGFnIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBmb3IgQ29sb3IgKEMpIGluIHRoZQ0KICAg REZsYWdzIGZpZWxkIGFzIGZvbGxvd3MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstKy0rLSstKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfFh8QnxDfDB8DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICBEYXRhIEZvcm1hdCBGbGFncw0KDQogICBUaGUgRmxhZyBDIGluZGljYXRlcyB0aGUg Q29sb3Igb2YgdGhlIGNvdW50ZXJzIGluIHRoZSBMTSBwcm9iZQ0KICAgbWVzc2FnZSBbUkZDNjM3 NF0gd2hlbiB1c2luZyBBbHRlcm5hdGUtTWFya2luZyBtZXRob2QgZGVmaW5lZCBpbg0KICAgW1JG QzgzMjFdLg0KLS0tLS0tLS0tLS0tLQ0KDQpBcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yIG9mIFtS RkM4MzIxXSwgY291bGQgeW91IGNvbnNpZGVyIHRvIGRlZmluZSBtb3JlIHRoYW4gb25lIGZsYWcg b3IgYSBUTFYgdG8gY2FycnkgQmxvY2sgbnVtYmVyIGluc3RlYWQ/DQoNCkJlc3QgcmVnYXJkcywN Ck1hY2gNCg0KRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE3LCAy MDE4IDk6NTcgUE0NClRvOiBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KU3Vi amVjdDogW2lwcG1dIE5ldyBEcmFmdCBkcmFmdC1nYW5kaGktc3ByaW5nLXVkcC1wbQ0KDQpIaSBX RywNCg0KV2UgbGlrZSB0byBpbnRyb2R1Y2UgZm9sbG93aW5nIG5ldyBkcmFmdCB0aGF0IHdhcyBw cmVzZW50ZWQgdG8gU1BSSU5HIFdHIHllc3RlcmRheS4NCg0KVGhpcyBkcmFmdCBkZWZpbmVzIElQ L1VEUCBwYXRoIGZvciBzZW5kaW5nIHByb2JlIHF1ZXJ5IG1lc3NhZ2VzIGZvciBkZWxheSBhbmQg bG9zcyBtZWFzdXJlbWVudCB0aGF0IGlzIGFnbm9zdGljcyB0byBkYXRhIHBsYW5lIChTUi1NUExT L1NSdjYvSVApIGFuZCBkb2VzIG5vdCByZXF1aXJlIHRvIGJvb3RzdHJhcCBQTSBzZXNzaW9uLg0K DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdhbmRoaS1zcHJpbmct dWRwLXBtLw0KDQpZb3UgbWF5IGZpbmQgcHJlc2VudGF0aW9uIGluIHRoZSBmb2xsb3dpbmcgcGFj a2FnZSAoaXQgaXMgdGhlIHNlY29uZCBkcmFmdCkuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL3NsaWRlcy0xMDItc3ByaW5nLTEzLXBlcmZvcm1h bmNlLW1lYXN1cmVtZW50LWluLXNyLW5ldHdvcmtzLTAwDQoNCldlIHdlbGNvbWUgeW91ciBjb21t ZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNClRoYW5rcywNClJha2VzaCAoT24gYmVoYWxmIG9mIGF1 dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycykNCg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHlsZS1uYW1lOnAxOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjVwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDQ2M0MxO30NCnAucDIsIGxp LnAyLCBkaXYucDINCgl7bXNvLXN0eWxlLW5hbWU6cDI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjcuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KcC5wMywgbGkucDMsIGRpdi5wMw0KCXttc28tc3R5bGUtbmFtZTpwMzsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLnMxDQoJe21zby1zdHlsZS1uYW1lOnMxOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj5IaSBSYWtlc2gsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkl0IGxvb2tzIGdvb2QgdG8gbWUuPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkJl c3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPk1hY2g8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwv Zm9udD48L2I+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBS YWtlc2ggR2FuZGhpIChyZ2FuZGhpKSBbbWFpbHRvOnJnYW5kaGlAY2lzY28uY29tXQ0KPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gTW9uZGF5 LCBTZXB0ZW1iZXIgMTAsIDIwMTggODozNyBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBNYWNoIENoZW4gJmx0O21hY2guY2hlbkBodWF3ZWku Y29tJmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+ PC9iPiBpcHBtQGlldGYub3JnOyBzcHJpbmcgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTog TmV3IERyYWZ0IGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aGFua3MgTWFjaCBmb3IgdGhlIGNvbW1lbnRzLiBXZSB3aWxsIGFkZCBmb2xsb3dpbmcgVExWIGlu IHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+My4xLjIuMS4mbmJzcDsgQmxvY2sgTnVtYmVyIFRMVjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGUgTG9zcyBNZWFzdXJlbWVu dCB1c2luZyBBbHRlcm5hdGUtTWFya2luZyBtZXRob2QgZGVmaW5lZCBpbjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBbUkZDODMyMV0gcmVxdWlyZXMg dG8gaWRlbnRpZnkgdGhlIEJsb2NrIE51bWJlciAoY29sb3VyKSBvZiB0aGU8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdHJhZmZpYyBjb3VudGVycyBj YXJyaWVkIGJ5IHRoZSBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMuPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7UHJvYmUgcXVl cnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIHNwZWNpZmllZCBpbiBbUkZDNjM3NF0gZm9yIExvc3M8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTWVhc3Vy ZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8gY2FycnkgdGhlIEJsb2NrIE51bWJlci48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgW1JGQzYzNzRdIGRlZmluZXMg cHJvYmUgcXVlcnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIHRoYXQgY2FuIGluY2x1ZGU8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb25lIG9yIG1vcmUg b3B0aW9uYWwgVExWcy4mbmJzcDsgTmV3IFRMViBUeXBlICh2YWx1ZSBUQkE4KSBpcyBkZWZpbmVk IGluPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRo aXMgZG9jdW1lbnQgdG8gY2FycnkgQmxvY2sgTnVtYmVyICgzMi1iaXQpIGZvciB0aGUgdHJhZmZp YyBjb3VudGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBpbiB0aGUgcHJvYmUgcXVlcnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciBsb3NzIG1l YXN1cmVtZW50LiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgZm9ybWF0IG9mIHRoZSBCbG9jayBOdW1iZXIgVExWIGlzIHNob3duIGlu IEZpZ3VyZSAxMTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsg MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBUeXBlIFRCQTcmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBMZW5ndGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZlZCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQmxvY2sgTnVtYmVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3w8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRmlndXJlIDExOiBCbG9jayBOdW1iZXIgVExWPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBCbG9jayBOdW1iZXIgVExWIGlzIG9wdGlvbmFs LiZuYnNwOyBUaGUgUE0gcXVlcmllciBub2RlIFNIT1VMRCBvbmx5PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluc2VydCBvbmUgQmxvY2sgTnVtYmVy IFRMViBpbiB0aGUgcHJvYmUgcXVlcnkgbWVzc2FnZSBhbmQgdGhlPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJlc3BvbmRlciBub2RlIGluIHRoZSBw cm9iZSByZXNwb25zZSBtZXNzYWdlIFNIT1VMRCByZXR1cm4gdGhlIGZpcnN0PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJsb2NrIE51bWJlciBUTFYg ZnJvbSB0aGUgcHJvYmUgcXVlcnkgbWVzc2FnZXMgYW5kIGlnbm9yZSBvdGhlciBCbG9jazxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBOdW1iZXIgVExW cyBpZiBwcmVzZW50LiZuYnNwOyBJbiBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMs IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBj b3VudGVycyBNVVNUIGJlbG9uZyB0byB0aGUgc2FtZSBCbG9jayBOdW1iZXIuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+UmFrZXNoPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNp emU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2s7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48L2Zv bnQ+PC9iPjxmb250IGNvbG9yPSJibGFjayI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NYWNo IENoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbSI+bWFjaC5jaGVu QGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+PC9iPk1vbmRheSwgSnVseSAyMywgMjAxOCBhdCAxMTozMSBQTTxicj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPjwvYj4mcXVvdDs9 U01UUDpyZ2FuZGhpQGNpc2NvLiBjb20mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyZ2FuZGhp QGNpc2NvLmNvbSI+cmdhbmRoaUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPjwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzppcHBtQGlldGYub3JnIj5pcHBtQGlldGYub3JnPC9hPiZndDssIHNwcmluZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPjwvYj5SRTog TmV3IERyYWZ0IGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SGkgQXV0aG9ycyw8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhlIGRy YWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtLTAxIGRlZmluZXMgYSBuZXcgQyBmbGFnIGFzIGZvbGxv d2luZzo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+My4xLjIuMS4mbmJzcDsgTG9zcyBNZWFzdXJlbWVudCBGbGFnczwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERhdGEgRm9ybWF0IEZsYWdzIChERmxh Z3MpIGFzIGRlZmluZWQgaW48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyBbUkZDNjM3NF0uJm5ic3A7IE5ldyBGbGFnIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBm b3IgQ29sb3IgKEMpIGluIHRoZTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IERGbGFncyBmaWVsZCBhcyBmb2xsb3dzLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0Mzs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8WHxCfEN8MHw8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF0YSBGb3JtYXQg RmxhZ3M8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFRoZSBGbGFnIEMgaW5kaWNhdGVzIHRoZSBDb2xvciBv ZiB0aGUgY291bnRlcnMgaW4gdGhlIExNIHByb2JlPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgbWVzc2FnZSBbUkZDNjM3NF0gd2hlbiB1c2luZyBBbHRlcm5hdGUtTWFy a2luZyBtZXRob2QgZGVmaW5lZCBpbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IFtSRkM4MzIxXS48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPi0tLS0tLS0tLS0t LS08L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+QXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMiBvZiBbUkZDODMyMV0sIGNvdWxkIHlv dSBjb25zaWRlciB0byBkZWZpbmUgbW9yZSB0aGFuIG9uZSBmbGFnIG9yIGEgVExWIHRvIGNhcnJ5 IEJsb2NrIG51bWJlciBpbnN0ZWFkPzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj5NYWNoPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gaXBwbSBbPGEgaHJlZj0ibWFpbHRvOmlwcG0t Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mIDwvc3Bhbj48L2I+UmFr ZXNoIEdhbmRoaSAocmdhbmRoaSk8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U2VudDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDk6NTcgUE08YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gPGEgaHJlZj0i bWFpbHRvOmlwcG1AaWV0Zi5vcmciPmlwcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gW2lwcG1dIE5ldyBEcmFm dCBkcmFmdC1nYW5kaGktc3ByaW5nLXVkcC1wbTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSI0 IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQiPkhpIFdHLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPldlIGxpa2UgdG8gaW50cm9k dWNlIGZvbGxvd2luZyBuZXcgZHJhZnQgdGhhdCB3YXMgcHJlc2VudGVkIHRvIFNQUklORyBXRyB5 ZXN0ZXJkYXkuDQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5UaGlzIGRyYWZ0IGRlZmlu ZXMgSVAvVURQIHBhdGggZm9yIHNlbmRpbmcgcHJvYmUgcXVlcnkgbWVzc2FnZXMgZm9yIGRlbGF5 IGFuZCBsb3NzIG1lYXN1cmVtZW50IHRoYXQgaXMgYWdub3N0aWNzIHRvIGRhdGEgcGxhbmUgKFNS LU1QTFMvU1J2Ni9JUCkgYW5kIGRvZXMgbm90IHJlcXVpcmUNCiB0byBib290c3RyYXAgUE0gc2Vz c2lvbi48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjx1Pjxmb250IHNpemU9IjQiIGNvbG9yPSIjMDQ2 M2MxIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2FuZGhpLXNwcmluZy11 ZHAtcG0vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nYW5kaGktc3By aW5nLXVkcC1wbS88L2E+PC9zcGFuPjwvZm9udD48L3U+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Z b3UgbWF5IGZpbmQgcHJlc2VudGF0aW9uIGluIHRoZSBmb2xsb3dpbmcgcGFja2FnZSAoaXQgaXMg dGhlIHNlY29uZCBkcmFmdCkuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9tYXRlcmlhbHMvc2xpZGVz LTEwMi1zcHJpbmctMTMtcGVyZm9ybWFuY2UtbWVhc3VyZW1lbnQtaW4tc3ItbmV0d29ya3MtMDAi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL3NsaWRl cy0xMDItc3ByaW5nLTEzLXBlcmZvcm1hbmNlLW1lYXN1cmVtZW50LWluLXNyLW5ldHdvcmtzLTAw PC9hPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPldlIHdlbGNvbWUgeW91ciBjb21tZW50 cyBhbmQgc3VnZ2VzdGlvbnMuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+VGhhbmtzLDwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxNC4wcHQiPlJha2VzaCAoT24gYmVoYWxmIG9mIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyk8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_-- From nobody Tue Sep 11 05:20:09 2018 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 A50C9130E71; Tue, 11 Sep 2018 05:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbvWJPv-d-nH; Tue, 11 Sep 2018 05:20:05 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1213130E46; Tue, 11 Sep 2018 05:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1536668405; x=1537878005; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=97Up8qdZsfCBjX4ioBY7qF60531cC4MkrWTI4C7/tJs=; b=MYU3FRyK9ugzuKAGXk83LeuBDvfIYoCUs2I1i55hhoQrLauinAp60lkJ weB6cY98IrLtyt/kvcNLonKpIZCVcc3AHyEbzJpa8IAd9iAVn4+TqYXW3 P7BVMw/CUSXo8KXi7wJWDo1qyxenKbWHnhNXQpdvwySxNCA2iythwpxC5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAwCLsZdb/5BdJa1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMfL2V/KAqDaIgTjB6BaINikneBegsYC4RJGYNzITQYAQIBAQI?= =?us-ascii?q?BAQJtHAyFOQIBAwEBIRE6CxIBCBoCJgIEJQsVEgQBDQWDIQGCAQ+lEYEuhGy?= =?us-ascii?q?FFAWBC4laF4FBP4E5DBOCTIMbAQGBYReCajGCJgKcCAkCkAAXgUCEP4hxk2Y?= =?us-ascii?q?CERSBJR04gVVwFTsqAYJBgk2ISIU+b4x9gR0BAQ?= X-IronPort-AV: E=Sophos;i="5.53,360,1531785600"; d="scan'208";a="170116239" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 12:20:04 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w8BCK3ng027639 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2018 12:20:04 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Sep 2018 07:20:01 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1395.000; Tue, 11 Sep 2018 07:20:01 -0500 From: "Rakesh Gandhi (rgandhi)" To: Mach Chen , spring CC: "ippm@ietf.org" Thread-Topic: [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm Thread-Index: AQHUScnDT6yM7jL8dky5UDpY/GMOVA== Date: Tue, 11 Sep 2018 12:20:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.181.86] Content-Type: text/plain; charset="utf-8" Content-ID: <5F60945E5857484190B313A1E673841B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 12:20:08 -0000 VGhhbmtzIE1hY2ggZm9yIHRoZSByZXZpZXcgY29tbWVudHMuIFdlIHdpbGwgYWRkIGZvbGxvd2lu ZyB0ZXh0IGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudHMuDQoNCjEuICBMb3Nz IE1lYXN1cmVtZW50DQogDQogIFRoZSBwYXRoIHNlZ21lbnQgaWRlbnRpZmllciBbSS1ELnNwcmlu Zy1tcGxzLXBhdGgtc2VnbWVudF0NCiAgIFtJLUQucGNlLXNyLXBhdGgtc2VnbWVudF0gb2YgdGhl IFNSIFBvbGljeSBpcyByZXF1aXJlZCBmb3IgYWNjb3VudGluZw0KICAgcmVjZWl2ZWQgdHJhZmZp YyBvbiB0aGUgZWdyZXNzIG5vZGUgZm9yIGxvc3MgbWVhc3VyZW1lbnQuDQogDQoyLiBUd28td2F5 IEVuZC10by1lbmQgTWVhc3VyZW1lbnQgb2YgU1IgUG9saWN5DQogDQogICBUaGUgcGF0aCBzZWdt ZW50IGlkZW50aWZpZXIgW0ktRC5zcHJpbmctbXBscy1wYXRoLXNlZ21lbnRdDQogICBbSS1ELnBj ZS1zci1wYXRoLXNlZ21lbnRdIG9mIHRoZSBmb3J3YXJkIFNSIFBvbGljeSBjYW4gYmUgdXNlZCB0 bw0KICAgZmluZCB0aGUgcmV2ZXJzZSBTUiBQb2xpY3kgdG8gc2VuZCB0aGUgcHJvYmUgcmVzcG9u c2UgbWVzc2FnZS4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KT24gMjAxOC0wOS0xMCwgOToxMiBQ TSwgImlwcG0gb24gYmVoYWxmIG9mIE1hY2ggQ2hlbiIgPGlwcG0tYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgbWFjaC5jaGVuQGh1YXdlaS5jb20+IHdyb3RlOg0KDQogICAgSGkgQXV0aG9y cywNCiAgICAgDQogICAgVGhlIGRyYWZ0LWxpLXBjZS1zci1wYXRoLXNlZ21lbnQgYW5kIGRyYWZ0 LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudCBkZWZpbmUgdGhlIG5vdGlvbiBvZiBwYXRo IHNlZ21lbnQgaWRlbnRpZmllci4gQ291bGQgeW91IHBsZWFzZSBjb25zaWRlciBhZGRpbmcgc29t ZSB0ZXh0IGluIGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtIGFuZCBkcmFmdC1nYW5kaGktc3By aW5nLXNyLW1wbHMtcG0gYW5kIGhvdyBpdCBpcyBhcHBsaWNhYmxlIHRvIHBlcmZvcm1hbmNlIG1l YXN1cmVtZW50IGluIHNlZ21lbnQgcm91dGluZz8NCiAgICAgDQogICAgQmVzdCByZWdhcmRzDQog ICAgTWFjaA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgaXBwbSBtYWlsaW5nIGxpc3QNCiAgICBpcHBtQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQogICAgDQoNCg== From nobody Tue Sep 11 19:32:58 2018 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 50FB9130DC1; Tue, 11 Sep 2018 19:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vz93aTvNm13; Tue, 11 Sep 2018 19:32:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C998130DCD; Tue, 11 Sep 2018 19:32:54 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7FAAE36782477; Wed, 12 Sep 2018 03:32:49 +0100 (IST) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 12 Sep 2018 03:32:50 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.7]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0399.000; Wed, 12 Sep 2018 10:32:43 +0800 From: Mach Chen To: "Rakesh Gandhi (rgandhi)" , spring CC: "ippm@ietf.org" Thread-Topic: [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm Thread-Index: AQHUScnDT6yM7jL8dky5UDpY/GMOVKTr7eww Date: Wed, 12 Sep 2018 02:32:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 02:32:56 -0000 SGkgUmFrZXNoLA0KDQpUaGFua3MgZm9yIGNvbnNpZGVyaW5nIG15IGNvbW1lbnRzIQ0KDQpCZXN0 IHJlZ2FyZHMsDQpNYWNoIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIFttYWlsdG86cmdhbmRoaUBjaXNjby5jb21dDQo+IFNl bnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMSwgMjAxOCA4OjIwIFBNDQo+IFRvOiBNYWNoIENoZW4g PG1hY2guY2hlbkBodWF3ZWkuY29tPjsgc3ByaW5nIDxzcHJpbmdAaWV0Zi5vcmc+DQo+IENjOiBp cHBtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaXBwbV0gQ29tbWVudHMgb24gZHJhZnQtZ2Fu ZGhpLXNwcmluZy1zci1tcGxzLXBtIGFuZCBkcmFmdC0NCj4gZ2FuZGhpLXNwcmluZy11ZHAtcG0N Cj4gDQo+IFRoYW5rcyBNYWNoIGZvciB0aGUgcmV2aWV3IGNvbW1lbnRzLiBXZSB3aWxsIGFkZCBm b2xsb3dpbmcgdGV4dCBpbiB0aGUNCj4gbmV4dCByZXZpc2lvbiBvZiB0aGUgZG9jdW1lbnRzLg0K PiANCj4gMS4gIExvc3MgTWVhc3VyZW1lbnQNCj4gDQo+ICAgVGhlIHBhdGggc2VnbWVudCBpZGVu dGlmaWVyIFtJLUQuc3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50XQ0KPiAgICBbSS1ELnBjZS1zci1w YXRoLXNlZ21lbnRdIG9mIHRoZSBTUiBQb2xpY3kgaXMgcmVxdWlyZWQgZm9yIGFjY291bnRpbmcN Cj4gICAgcmVjZWl2ZWQgdHJhZmZpYyBvbiB0aGUgZWdyZXNzIG5vZGUgZm9yIGxvc3MgbWVhc3Vy ZW1lbnQuDQo+IA0KPiAyLiBUd28td2F5IEVuZC10by1lbmQgTWVhc3VyZW1lbnQgb2YgU1IgUG9s aWN5DQo+IA0KPiAgICBUaGUgcGF0aCBzZWdtZW50IGlkZW50aWZpZXIgW0ktRC5zcHJpbmctbXBs cy1wYXRoLXNlZ21lbnRdDQo+ICAgIFtJLUQucGNlLXNyLXBhdGgtc2VnbWVudF0gb2YgdGhlIGZv cndhcmQgU1IgUG9saWN5IGNhbiBiZSB1c2VkIHRvDQo+ICAgIGZpbmQgdGhlIHJldmVyc2UgU1Ig UG9saWN5IHRvIHNlbmQgdGhlIHByb2JlIHJlc3BvbnNlIG1lc3NhZ2UuDQo+IA0KPiBUaGFua3Ms DQo+IFJha2VzaA0KPiANCj4gDQo+IE9uIDIwMTgtMDktMTAsIDk6MTIgUE0sICJpcHBtIG9uIGJl aGFsZiBvZiBNYWNoIENoZW4iIDxpcHBtLQ0KPiBib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBtYWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgSGkgQXV0aG9ycywNCj4g DQo+ICAgICBUaGUgZHJhZnQtbGktcGNlLXNyLXBhdGgtc2VnbWVudCBhbmQgZHJhZnQtY2hlbmct c3ByaW5nLW1wbHMtcGF0aC0NCj4gc2VnbWVudCBkZWZpbmUgdGhlIG5vdGlvbiBvZiBwYXRoIHNl Z21lbnQgaWRlbnRpZmllci4gQ291bGQgeW91IHBsZWFzZQ0KPiBjb25zaWRlciBhZGRpbmcgc29t ZSB0ZXh0IGluIGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtIGFuZCBkcmFmdC1nYW5kaGktDQo+ IHNwcmluZy1zci1tcGxzLXBtIGFuZCBob3cgaXQgaXMgYXBwbGljYWJsZSB0byBwZXJmb3JtYW5j ZSBtZWFzdXJlbWVudCBpbg0KPiBzZWdtZW50IHJvdXRpbmc/DQo+IA0KPiAgICAgQmVzdCByZWdh cmRzDQo+ICAgICBNYWNoDQo+IA0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gICAgIGlwcG0gbWFpbGluZyBsaXN0DQo+ICAgICBpcHBtQGll dGYub3JnDQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0N Cj4gDQoNCg== From nobody Tue Sep 18 15:53:39 2018 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 25C4C130EA5 for ; Tue, 18 Sep 2018 15:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z40PBUP8MII for ; Tue, 18 Sep 2018 15:53:36 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B249130E8A for ; Tue, 18 Sep 2018 15:53:36 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id o15-v6so3380617qtk.6 for ; Tue, 18 Sep 2018 15:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d6l878HAYK8ymoPmkCIopSW+9XE3NU+2huazThS6eJc=; b=Uj9PZG+NmxyBS3h+dEIOhpxR4NUr0V7Rxabcmn+sKOKyE+WFXrqTlLasVkWjjBxHGc kc+PZjVV9BCQtjXRfpy1aAlKj/ntg4RkkO703MvY4ULp0AXGf/oVU9ju4y7s3ysHl8b9 wA0NjbamgRpueZlw4wa/Joe8JIXFMJhy5tYOA2pTAM2+Q4baTJqReq2xX/ys0Lpp6iCG cF56c4/B+sfYiFeNmh/ryvpYqA9fz8nN9aL7xpvBTklLN9Z7PjqFUxVQ/QBId65hoZiJ NbmJg5ncWoLmS3j3yfsqSSD5HIaOW/2LNhKH3LWwo+lJDsC01Q0MClbezxUoUZhOArkD DTxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=d6l878HAYK8ymoPmkCIopSW+9XE3NU+2huazThS6eJc=; b=mAutHKriWFznqnB/kN663X4HkX19tukQNGwkpN9UZCFnyGB3yz78igf28/5MrUL3Fi 21pRihKbSIQ92k0J+OYwoFPNDsD7V0ZKCBRGn6plwPVq30XWIkOBAms7aLyUOfvrJF4L W4Dh3e47IU6+FiUx/YZ5zSdph3FtehPflCFDt78Alv9T9ncdtpIy4YmBzgAPW3YbeEDe yBy5sYhjM2XP9x3fUbIzp/yA195ElZCtB45jFd/+EKaDztNka5DHf+x6usE0qRuQ/Nge Xg2akRquCgxJ7yNnhBSUQLh32NaENdqj9PDWXNNF9O0+XrjSXtmHzYBVSPIhrrxtjcKp K9Ug== X-Gm-Message-State: APzg51AwvXyph33E3vlrvZIcqmMes8jeSoswUN/sLdaSHYlijH41H/dM uhRSF1vcr4RY479zX3KGhRSnoWwxdUbXO/+SdrRdww== X-Google-Smtp-Source: ANB0VdbIQN4fg1RaCYdLxoOqh49bm5bSn24zwfwu/ZUPWIH3Nfag8fumZFruBT/CLwvRLGmlYu4CqtDk2oB3N7T4T8Q= X-Received: by 2002:a0c:f987:: with SMTP id t7-v6mr22870640qvn.72.1537311215153; Tue, 18 Sep 2018 15:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Tue, 18 Sep 2018 15:53:34 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 18 Sep 2018 15:53:34 -0700 Message-ID: To: "Brian Trammell (IETF)" Cc: tsvwg , QUIC WG , IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 22:53:38 -0000 On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) w= rote: > Greetings, TSVWG, QUIC, and IPPM, > > I've just submitted a new I-D, "Why do we need passive measurement of rou= nd trip time?" (https://tools.ietf.org/html/draft-trammell-why-measure-rtt-= 00), which may be of some interest to each of these WGs. :) It presents a s= et of use cases for on-path passive RTT measurement, both generally, and sp= ecific to the facility described in "A Transport-Independent Explicit Signa= l for Hybrid RTT Measurement" (https://tools.ietf.org/html/draft-trammell-t= svwg-spin-00), or the "spin bit". > Hi Brian, I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to me how this mechanism is transport-independent. The draft shows how to do this in QUIC and TCP, but there's no support that I see for DCCP, SCTP, IPsec, other encapsulations, etc. I would think that for something to be truly transport-independent the information would need to reside in the network layer. Tom > - For QUIC, this draft addresses the second half of the risk/utility ques= tion raised by the spin bit and spin+VEC latency signal -- much of the cont= ent comes from the original QUIC spin bit document, but there are new secti= ons on using VEC for loss/reordering proxy metrics and exploiting correlati= ons between RTT and other metrics to drive intraflow diagnostics from only = RTT signals. In particular, I'll talk about ongoing experimentation along t= he lines of section 3 at the interim in New York. > > - For TSVWG and tsvarea, it addresses some of the "why design wire images= " questions raised in the tsvarea meeting in Montreal, with respect to the = specific tasks for which RTT data is useful. > > - And for IPPM, it gives a bit more background on the "passive RTT" metri= c in the initial registry document. > > Feedback is much appreciated. :) > > Thanks, cheers, > > Brian (as an individual contributor) > > P.S. apologies for the resend: the previous message was not an obscure jo= ke about ubiquitous encryption: apparently the interaction among my MUA, it= s bolt-on GPG, and the somewhat underprovisioned network in SIGCOMM led to = an encrypted draft being posted to the list. :/ > From nobody Tue Sep 18 16:59:30 2018 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 7450D130DDD; Tue, 18 Sep 2018 16:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS41Uc2plk_g; Tue, 18 Sep 2018 16:59:27 -0700 (PDT) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A157130DC4; Tue, 18 Sep 2018 16:59:27 -0700 (PDT) Received: by mail-yw1-xc2b.google.com with SMTP id j131-v6so1550919ywc.13; Tue, 18 Sep 2018 16:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mP6Z3WpwttDQ+KdcGWzScKkHwK/VOslAbCg3AhJ9IMU=; b=N5n6IZfN4zfioi3Ne53UzAUUJcXcxWaLcMmCBeVn11Bxcm8eZBxjSTlzE+SK5OQUER V0qndB9argwcwtNNMqCbJgTS+chPijgLodRkbVVcUgwfRhx3lZ1Gr3zQrbtoda29hEnB 2v1WkDJozsAJCmoUAe4i7cW4gRKanobMiBp6/PK3dYt5UEGwKUikw0087o0H5rUhsrlm Q9hxrNiuiJm6M77nmbCt1rOhlVE2qWUbmyP5YfObpWfH75vGCaquQNRvm2fjhs0OfZG+ gsJOyhY3s3+72vrgcGYWSIWaraInOfUTq8lZuoxWPBoenaUtN2Y8RCXeH2MaajKt6SNK Zf8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mP6Z3WpwttDQ+KdcGWzScKkHwK/VOslAbCg3AhJ9IMU=; b=XILBikciO1ViFN0y/0jaThjIWuGIgPuU5QQN1O464Dp15W8AmDzZElTepv53tXyEzC Z6xSelUJ87oZEBLlD0vFO8BhNIJFKFYUldnG2Z+f4TKeOiZ0UYCqq/tY82WYp+PD7Jt6 D+uV7zQOMNe1OoimdHlWjgbUWbnlY03hPgKJd4I6FSBuWF+EIcSMOVwA9ubWCKBjINAH qFlhV+tJY7g/mpKZwN0NGntfqx0nt1MWjMCS6S2a3rVEE1DkpiUFPTsUkxESmgAhNC2U f7iiSHAG1cY1/0dMbfP3tsYeyZkS3t0C+G5Za6wt5BUMpupZnI/qTQh0uP3qDVqog/nO ghDQ== X-Gm-Message-State: APzg51Ciss3uoWxxtOhPj0Ii0jC+1IVEePC6U/ZcJESuY737BGhMHhG0 mTPsPqySXSvrm4arzkc0bMyouWWqGIBqsCGkY3wdDMBe X-Google-Smtp-Source: ANB0VdZkLU8osodz4u02xnYf6tbI4fv7bq4mSBpRvsUBoLwCZckVmP870F8+sAKtd4yeR/p300+LRuzsTIwoWR2fc+w= X-Received: by 2002:a81:530a:: with SMTP id h10-v6mr13596332ywb.411.1537315166326; Tue, 18 Sep 2018 16:59:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 18 Sep 2018 18:59:12 -0500 Message-ID: To: Tom Herbert Cc: Brian Trammell , IETF QUIC WG , tsvwg@ietf.org, ippm@ietf.org Content-Type: multipart/alternative; boundary="0000000000006595a405762e14f1" Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 23:59:29 -0000 --0000000000006595a405762e14f1 Content-Type: text/plain; charset="UTF-8" Speaking without a hat (heck, I don't even have hair) ... On Tue, Sep 18, 2018 at 5:53 PM Tom Herbert wrote: > On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) > wrote: > > Greetings, TSVWG, QUIC, and IPPM, > > > > I've just submitted a new I-D, "Why do we need passive measurement of > round trip time?" ( > https://tools.ietf.org/html/draft-trammell-why-measure-rtt-00), which may > be of some interest to each of these WGs. :) It presents a set of use cases > for on-path passive RTT measurement, both generally, and specific to the > facility described in "A Transport-Independent Explicit Signal for Hybrid > RTT Measurement" (https://tools.ietf.org/html/draft-trammell-tsvwg-spin-00), > or the "spin bit". > > > Hi Brian, > > I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to > me how this mechanism is transport-independent. The draft shows how to > do this in QUIC and TCP, but there's no support that I see for DCCP, > SCTP, IPsec, other encapsulations, etc. I would think that for > something to be truly transport-independent the information would need > to reside in the network layer. > Forget that I'm an AD, because I'm not wearing any hats, but I'm having a really difficult time explaining to other people internally how a spin bit that's not in the IP header, but is part of a mostly-encrypted transport header, is better than putting something in an IP (extension? iOAM?) header that would be transport-independent. I recognize there are trade-offs, starting with the availability of bits in headers at different layers of the protocol stack, and I recognize that I probably don't know what all of them are, so it's likely that I'm missing something critical here. Me missing something critical would surprise no one, but as an individual participant, I have the same question Tom has. Thanks, Spencer --0000000000006595a405762e14f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking without a hat (heck, I don't even have hair) = ...=C2=A0

On Tue, Sep 18= , 2018 at 5:53 PM Tom Herbert <to= m@herbertland.com> wrote:
On= Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> Greetings, TSVWG, QUIC, and IPPM,
>
> I've just submitted a new I-D, "Why do we need passive measur= ement of round trip time?" (https:= //tools.ietf.org/html/draft-trammell-why-measure-rtt-00), which may be = of some interest to each of these WGs. :) It presents a set of use cases fo= r on-path passive RTT measurement, both generally, and specific to the faci= lity described in "A Transport-Independent Explicit Signal for Hybrid = RTT Measurement" (https://tools.ietf.or= g/html/draft-trammell-tsvwg-spin-00), or the "spin bit".
>
Hi Brian,

I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to me how this mechanism is transport-independent. The draft shows how to
do this in QUIC and TCP, but there's no support that I see for DCCP, SCTP, IPsec, other encapsulations, etc. I would think that for
something to be truly transport-independent the information would need
to reside in the network layer.

Forget = that I'm an AD, because I'm not wearing any hats, but I'm havin= g a really difficult time explaining to other people internally how a spin = bit that's not in the IP header, but is part of a mostly-encrypted tran= sport header, is better than putting something in an IP (extension? iOAM?) = header that would be transport-independent.=C2=A0

= I recognize there are trade-offs, starting with the availability of bits in= headers at different layers of the protocol stack, and I recognize that I = probably don't know what all of them are, so it's likely that I'= ;m missing something critical here.

Me missing som= ething critical would surprise no one, but as an individual participant, I = have the same question Tom has.=C2=A0

Thanks,

Spencer
--0000000000006595a405762e14f1-- From nobody Wed Sep 19 04:46:44 2018 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 57E55130DDB; Wed, 19 Sep 2018 04:46:42 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj-HL-PuM65P; Wed, 19 Sep 2018 04:46:39 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B01130DC0; Wed, 19 Sep 2018 04:46:39 -0700 (PDT) Received: from [192.168.1.9] (p57BB422A.dip0.t-ipconnect.de [87.187.66.42]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 2C713721E280D; Wed, 19 Sep 2018 13:46:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Tuexen In-Reply-To: Date: Wed, 19 Sep 2018 13:46:31 +0200 Cc: "Brian Trammell (IETF)" , QUIC WG , tsvwg , IETF IPPM WG Content-Transfer-Encoding: quoted-printable Message-Id: <15454907-02C1-42C7-893B-EB2959FF18D8@lurchi.franken.de> References: To: Tom Herbert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 11:46:42 -0000 > On 19. Sep 2018, at 00:53, Tom Herbert wrote: >=20 > On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) = wrote: >> Greetings, TSVWG, QUIC, and IPPM, >>=20 >> I've just submitted a new I-D, "Why do we need passive measurement of = round trip time?" = (https://tools.ietf.org/html/draft-trammell-why-measure-rtt-00), which = may be of some interest to each of these WGs. :) It presents a set of = use cases for on-path passive RTT measurement, both generally, and = specific to the facility described in "A Transport-Independent Explicit = Signal for Hybrid RTT Measurement" = (https://tools.ietf.org/html/draft-trammell-tsvwg-spin-00), or the "spin = bit". >>=20 > Hi Brian, >=20 > I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to > me how this mechanism is transport-independent. The draft shows how to > do this in QUIC and TCP, but there's no support that I see for DCCP, > SCTP, IPsec, other encapsulations, etc. I would think that for > something to be truly transport-independent the information would need > to reside in the network layer. I agree with Tom, right now this does not look like = transport-independent. One could add a chunk for SCTP to expose the 3 bits, but I was wondering why not just let the endpoints willing to expose the RTT signal let them send the measured RTT explicitly? Best regards Michael >=20 > Tom >=20 >> - For QUIC, this draft addresses the second half of the risk/utility = question raised by the spin bit and spin+VEC latency signal -- much of = the content comes from the original QUIC spin bit document, but there = are new sections on using VEC for loss/reordering proxy metrics and = exploiting correlations between RTT and other metrics to drive intraflow = diagnostics from only RTT signals. In particular, I'll talk about = ongoing experimentation along the lines of section 3 at the interim in = New York. >>=20 >> - For TSVWG and tsvarea, it addresses some of the "why design wire = images" questions raised in the tsvarea meeting in Montreal, with = respect to the specific tasks for which RTT data is useful. >>=20 >> - And for IPPM, it gives a bit more background on the "passive RTT" = metric in the initial registry document. >>=20 >> Feedback is much appreciated. :) >>=20 >> Thanks, cheers, >>=20 >> Brian (as an individual contributor) >>=20 >> P.S. apologies for the resend: the previous message was not an = obscure joke about ubiquitous encryption: apparently the interaction = among my MUA, its bolt-on GPG, and the somewhat underprovisioned network = in SIGCOMM led to an encrypted draft being posted to the list. :/ >>=20 >=20 From nobody Wed Sep 19 05:24:21 2018 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 399C3130FE1 for ; Wed, 19 Sep 2018 05:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUAGOfVm13hO for ; Wed, 19 Sep 2018 05:24:16 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23C4130DE3 for ; Wed, 19 Sep 2018 05:24:15 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx128.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1g2bWd-000Xj7-Hc for ippm@ietf.org; Wed, 19 Sep 2018 14:24:12 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1g2bWY-0002sS-46 for ippm@ietf.org; Wed, 19 Sep 2018 08:24:06 -0400 Received: (qmail 30906 invoked from network); 19 Sep 2018 12:24:02 -0000 Received: from unknown (HELO [172.20.6.146]) (Authenticated-user:_huitema@huitema.net@[207.110.29.138]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Sep 2018 12:24:02 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Wed, 19 Sep 2018 08:24:00 -0400 Cc: Tom Herbert , Brian Trammell , IETF QUIC WG , tsvwg@ietf.org, ippm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Spencer Dawkins at IETF X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jNmkwdkgL6xb5Ik2HU5SYp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzeD5dlaABHsIv+xS3njCtZs1ujulqUFmMITHM77eiVisi5mcMEayL2imvTskEmfnc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBMtTRquENyRIJu/sK6SVySE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseytLy0an6SuH9Dnc48fGLITnLlugkesThE0m2G9WntXtCh6UCD7wGAf Gu6y2/oFYrlqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1Z+7sPmjIM3bM0ihYRE0YjPM ySEj7fwLz33nMnt8v2VACW4JJLnVejFxn/py1lO++mCP6KnOBvL4JpDTCrFGRy3dpU6jXVi1s+4N 666W2W3fse+3hj2S5n6KR2yLtAeMoSHqAeeZGuerhbgzLuS7t5uWwhEJBPk7WpO8jVZh2VH4zM60 voqUUzJmvILAkkfgILwrzxcMEL7SnkJgQ5VKYC9Xgjmuntq3xZgBxhdNFJUcZu3d9ZNXJQW8HUxK X5uYJmvDK3PKrieG7T6bf9hS7hR0q7xASYaBUaOtmtSkj3iuxJhh7EHDojb6D9Mx+gs1+GHf4ys4 4rg2B8/9FmK9a1O9x7lsssuZ/53sObhu0YJN X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 12:24:19 -0000 =20 > On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF wrote: >=20 > Forget that I'm an AD, because I'm not wearing any hats, but I'm having a r= eally difficult time explaining to other people internally how a spin bit th= at's not in the IP header, but is part of a mostly-encrypted transport heade= r, is better than putting something in an IP (extension? iOAM?) header that w= ould be transport-independent.=20 The one advantage of the bit in transport header is that it is authenticated= end to end. The other advantage is that it is automatically tied to a trans= port flow and its five tuple. Then there is the reality that IP header bits a= re commonly rewritten by a variety of middleboxes. The downside is that different encrypted transports will most likely end up a= dopting different encodings and conventions. But of course we could also repurpose one of the TOS bits or one of the flow= header bits for the purpose, to mirror the transport level bit. Mirror inst= ead of replace: that would alleviate the need of parsing transport headers, b= ut still allow end to end detection of IP header rewriting. -- Christian Huitema=20= From nobody Wed Sep 19 05:29:02 2018 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 8CADB130FDF; Wed, 19 Sep 2018 05:28:52 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89piu0HVGpTz; Wed, 19 Sep 2018 05:28:50 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0274713104A; Wed, 19 Sep 2018 05:28:50 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 11B0D3410BB; Wed, 19 Sep 2018 14:28:48 +0200 (CEST) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/14501.3082); Wed, 19 Sep 2018 14:28:48 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 19 Sep 2018 14:28:47 +0200 (CEST) Received: from [207.237.187.10] (account ietf@trammell.ch HELO [10.0.201.89]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 67735489; Wed, 19 Sep 2018 14:28:47 +0200 From: "Brian Trammell (IETF)" Message-Id: <96100918-CCD7-447D-AF09-F4E60A733661@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_AEA9DFAC-2F59-4A81-930C-C249C2FEA20E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 19 Sep 2018 08:28:44 -0400 In-Reply-To: Cc: tsvwg , QUIC WG , IETF IPPM WG To: Tom Herbert References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 12:29:00 -0000 --Apple-Mail=_AEA9DFAC-2F59-4A81-930C-C249C2FEA20E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Sep 2018, at 18:53, Tom Herbert wrote: >=20 > On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) = wrote: >> Greetings, TSVWG, QUIC, and IPPM, >>=20 >> I've just submitted a new I-D, "Why do we need passive measurement of = round trip time?" = (https://tools.ietf.org/html/draft-trammell-why-measure-rtt-00), which = may be of some interest to each of these WGs. :) It presents a set of = use cases for on-path passive RTT measurement, both generally, and = specific to the facility described in "A Transport-Independent Explicit = Signal for Hybrid RTT Measurement" = (https://tools.ietf.org/html/draft-trammell-tsvwg-spin-00), or the "spin = bit". >>=20 > Hi Brian, >=20 > I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to > me how this mechanism is transport-independent. The draft shows how to > do this in QUIC and TCP, but there's no support that I see for DCCP, > SCTP, IPsec, other encapsulations, etc. Those bindings are future work -- and, indeed, the draft should be = clearer about that. Mea culpa, usual excuses about -00, and all that. > I would think that for > something to be truly transport-independent the information would need > to reside in the network layer. This is, architecturally speaking, my preference as well. The reasons we = propose this as a layer 4 signal, as opposed to a layer 3 signal, are = elaborated in section 5.1. The overwhelming one here is that ports are = often used in combination with addresses to make forwarding decisions, = such that a 2-tuple does not fully describe a "path" between two = endpoints at any instance in time. IOW, we're trying to solve the measurement problem it looks like we = have, not the one we'd like to. That said, the technique described here could also be applied to three = bits (theoretically clawed back) from the network layer header, with the = logic to be applied to the flow aggregate of all packets sent between = two IP addresses. Since there's no two-tuple state structure that we = could already hang this off (that I know of), this would require the = design of new state structures in the IP stack. Cheers, Brian > Tom >=20 >> - For QUIC, this draft addresses the second half of the risk/utility = question raised by the spin bit and spin+VEC latency signal -- much of = the content comes from the original QUIC spin bit document, but there = are new sections on using VEC for loss/reordering proxy metrics and = exploiting correlations between RTT and other metrics to drive intraflow = diagnostics from only RTT signals. In particular, I'll talk about = ongoing experimentation along the lines of section 3 at the interim in = New York. >>=20 >> - For TSVWG and tsvarea, it addresses some of the "why design wire = images" questions raised in the tsvarea meeting in Montreal, with = respect to the specific tasks for which RTT data is useful. >>=20 >> - And for IPPM, it gives a bit more background on the "passive RTT" = metric in the initial registry document. >>=20 >> Feedback is much appreciated. :) >>=20 >> Thanks, cheers, >>=20 >> Brian (as an individual contributor) >>=20 >> P.S. apologies for the resend: the previous message was not an = obscure joke about ubiquitous encryption: apparently the interaction = among my MUA, its bolt-on GPG, and the somewhat underprovisioned network = in SIGCOMM led to an encrypted draft being posted to the list. :/ >>=20 --Apple-Mail=_AEA9DFAC-2F59-4A81-930C-C249C2FEA20E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluiQPwACgkQihK3vwvq RqMVyhAAwhwQ8IWHfk0fIckatiaoexFXgg5vujXgyGQrPoAGgRyOt79w70CT6sc8 UNcBpRTkz2rwuG7YwaMkoznUhR+VfaU+BxD7ijMdVevwfk8K8avRp+vO+uU3QM9S WB9oEzaQdSO/fcw1VriEOReNAlz1Fv/307zxutgJ2PY0Y3FKN2r/cZbO7MG9PmgA J6+P8fj9CcCRSV2AoxQQ5EHybSr9DTiq4TjwVXysus1BZ1ntJRtVdEch4CuhyIUW iwd7lG4xhma6f/5iVuIMau7CGt0sn11FXVJtEqj+/ix8mJvQOrYUVXxT+/81vKD3 IoSgIXFNFQx4VD4kx1YmQwMza84Y5REiaAry6eExX4ZFWTOd3N3HS6+m5Y3pRHLK HThW/SpXa/td/7HVqHplz57YQKvt09V3lNoZbwmvoIx8MRvl8XUZL1nK7lfpul/J Nc0S8SlnwPPGBamB6xmK0CgGArx6khvm/qoaOKEluxVEA6FfeT8q5FJRHYXl8A20 fJPhnI8hW40N5YyN6gOK1FxV9v6L068Q+OBKgNqXekMLSW2U11ApjS9gtACA+Y3G 1x5YtGramXzTIK3K1L1LsG3dgBZk7esNZtoAcx8qXzNZwh9mEmUXsgS9lx9MbuoF A45BHpoIUMJqz2n2f4K/2qrnA2jh+qa7t44DSxWnip1o/oo9phc= =S8tD -----END PGP SIGNATURE----- --Apple-Mail=_AEA9DFAC-2F59-4A81-930C-C249C2FEA20E-- From nobody Wed Sep 19 06:56:23 2018 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 9AD45131027; Wed, 19 Sep 2018 06:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnEogJzDInWI; Wed, 19 Sep 2018 06:56:11 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 46E281310A2; Wed, 19 Sep 2018 06:56:10 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:6022:d145:5fd3:4bef]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 080491B0065C; Wed, 19 Sep 2018 14:56:04 +0100 (BST) To: Christian Huitema , Spencer Dawkins at IETF Cc: IETF QUIC WG , tsvwg@ietf.org, ippm@ietf.org References: From: Gorry Fairhurst Message-ID: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> Date: Wed, 19 Sep 2018 14:56:03 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 13:56:21 -0000 On 19/09/2018 13:24, Christian Huitema wrote: > >> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF wrote: >> >> Forget that I'm an AD, because I'm not wearing any hats, but I'm having a really difficult time explaining to other people internally how a spin bit that's not in the IP header, but is part of a mostly-encrypted transport header, is better than putting something in an IP (extension? iOAM?) header that would be transport-independent. > The one advantage of the bit in transport header is that it is authenticated end to end. The other advantage is that it is automatically tied to a transport flow and its five tuple. Then there is the reality that IP header bits are commonly rewritten by a variety of middleboxes. > > The downside is that different encrypted transports will most likely end up adopting different encodings and conventions. > > But of course we could also repurpose one of the TOS bits Do you mean the DSCP field? - That would sound like a very odd proposal. > or one of the flow header bits for the purpose, to mirror the transport level bit. Mirror instead of replace: that would alleviate the need of parsing transport headers, but still allow end to end detection of IP header rewriting. > > -- Christian Huitema Gorry From nobody Wed Sep 19 06:57:40 2018 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 ED54313108F; Wed, 19 Sep 2018 06:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktwlOerLELld; Wed, 19 Sep 2018 06:57:28 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CA12C131073; Wed, 19 Sep 2018 06:57:27 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w8JDvLtE032454; Wed, 19 Sep 2018 15:57:21 +0200 Date: Wed, 19 Sep 2018 15:57:21 +0200 From: Willy Tarreau To: "Brian Trammell (IETF)" Cc: Tom Herbert , QUIC WG , tsvwg , IETF IPPM WG Message-ID: <20180919135721.GB32294@1wt.eu> References: <96100918-CCD7-447D-AF09-F4E60A733661@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96100918-CCD7-447D-AF09-F4E60A733661@trammell.ch> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 13:57:39 -0000 Hi Brian, On Wed, Sep 19, 2018 at 08:28:44AM -0400, Brian Trammell (IETF) wrote: > > > > On 18 Sep 2018, at 18:53, Tom Herbert wrote: > > > > On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) wrote: > >> Greetings, TSVWG, QUIC, and IPPM, > >> > >> I've just submitted a new I-D, "Why do we need passive measurement of round trip time?" (https://tools.ietf.org/html/draft-trammell-why-measure-rtt-00), which may be of some interest to each of these WGs. :) It presents a set of use cases for on-path passive RTT measurement, both generally, and specific to the facility described in "A Transport-Independent Explicit Signal for Hybrid RTT Measurement" (https://tools.ietf.org/html/draft-trammell-tsvwg-spin-00), or the "spin bit". > >> > > Hi Brian, > > > > I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to > > me how this mechanism is transport-independent. The draft shows how to > > do this in QUIC and TCP, but there's no support that I see for DCCP, > > SCTP, IPsec, other encapsulations, etc. > > Those bindings are future work -- and, indeed, the draft should be clearer > about that. Mea culpa, usual excuses about -00, and all that. > > > I would think that for > > something to be truly transport-independent the information would need > > to reside in the network layer. > > This is, architecturally speaking, my preference as well. The reasons we > propose this as a layer 4 signal, as opposed to a layer 3 signal, are > elaborated in section 5.1. The overwhelming one here is that ports are often > used in combination with addresses to make forwarding decisions, such that a > 2-tuple does not fully describe a "path" between two endpoints at any > instance in time. I think the mechanism described in the draft could be generalized to any transport layer. You could even imagine stuffing this into Websocket or H2 to provide measurements at *certain* layers if that made sense. I tend to think that the document should focus more on the algorithm itself and how to reliably implement it, and discuss application to existing transport layers only as examples of what an implementation could look like. It would address the reserves you've set regarding applicability to TCP in the real world and would possibly help other implementations adopt similar techniques. By the way I'm seeing an minor problem there related to how you decide how flips the bit : you need to know who's the connection initiator and who's the target. In TCP you have a simultaneous connect feature which allows two clients to connect to each other if they know their respective source ports (try it using netcat if you want), thus maybe there are other protocols where it's not that obvious who's the initiator. Maybe you should take this as a counter-example to try to figure a more robust mechanism to decide who flips the bit. Maybe it could be derived from other information such as the packet/sequence numbers, maybe it could be figured from the spin bit mechanism itself (spin after a certain VEC sequence or so). Regards, Willy From nobody Wed Sep 19 07:30:17 2018 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 22ECE131048; Wed, 19 Sep 2018 07:30:16 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf6khVlpGQ8Y; Wed, 19 Sep 2018 07:30:13 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79253130E1D; Wed, 19 Sep 2018 07:30:13 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7E5ED3411E9; Wed, 19 Sep 2018 16:30:11 +0200 (CEST) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/14501.11573); Wed, 19 Sep 2018 16:30:11 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 19 Sep 2018 16:30:11 +0200 (CEST) Received: from [216.240.30.11] (account ietf@trammell.ch HELO [10.26.178.170]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 67751188; Wed, 19 Sep 2018 16:30:11 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FE18DAB6-E411-4E4B-B826-563C4F7BA1CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 19 Sep 2018 10:30:05 -0400 In-Reply-To: <20180919135721.GB32294@1wt.eu> Cc: Tom Herbert , QUIC WG , tsvwg , IETF IPPM WG To: Willy Tarreau References: <96100918-CCD7-447D-AF09-F4E60A733661@trammell.ch> <20180919135721.GB32294@1wt.eu> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 14:30:16 -0000 --Apple-Mail=_FE18DAB6-E411-4E4B-B826-563C4F7BA1CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Willy, all, > On 19 Sep 2018, at 09:57, Willy Tarreau wrote: >=20 > Hi Brian, > I think the mechanism described in the draft could be generalized to > any transport layer. You could even imagine stuffing this into = Websocket > or H2 to provide measurements at *certain* layers if that made sense. Yes, but. The signal is only useful for passive measurement if it's = visible along the path, and anything beyond the encryption boundary is = not visible. So H2/WS spinning would not appear to be useful here. > I > tend to think that the document should focus more on the algorithm = itself > and how to reliably implement it, and discuss application to existing > transport layers only as examples of what an implementation could look > like. This is one approach we could take, but at least for the -00 revision we = wanted to show how this worked for both QUIC and TCP, because that's = what we implemented (see also our preprint, to appear at IMC: = https://mami-project.eu/wp-content/uploads/2018/09/spinbit.pdf). > It would address the reserves you've set regarding applicability > to TCP in the real world and would possibly help other implementations > adopt similar techniques. >=20 > By the way I'm seeing an minor problem there related to how you decide > how flips the bit : you need to know who's the connection initiator = and > who's the target. In TCP you have a simultaneous connect feature which > allows two clients to connect to each other if they know their = respective > source ports (try it using netcat if you want), thus maybe there are > other protocols where it's not that obvious who's the initiator. Yes, this is an issue we have not addressed yet, and is derived from the = fact that QUIC is explicitly asymmetric, as it is basically a transport = protocol wrapped around TLS, which is also explicitly asymmetric. > Maybe > you should take this as a counter-example to try to figure a more = robust > mechanism to decide who flips the bit. Maybe it could be derived from > other information such as the packet/sequence numbers, maybe it could > be figured from the spin bit mechanism itself (spin after a certain > VEC sequence or so) Without thinking too hard about it, one could break an = initiator/responder tie for simultaneous open by sorting two-tuples. Thanks, cheers, Brian --Apple-Mail=_FE18DAB6-E411-4E4B-B826-563C4F7BA1CB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluiXW0ACgkQihK3vwvq RqPBVg/+J1YQwRtSJlfjXTfzrvQXZz4ilw52CeWVMQ2dGi/rDOejRkYHEXTpIJ6X OlAyKhb1SmiBwpt4rx0RCW/4VCvpNjc4uU/kT6los+5xAnXINUwjyFrTdjuM1Qyi iiRZdrlLHUvL13Dp9PU9AqiUFPhAMdR0nG9EhV4oJ5HvSPeG95XPowBqOwCGjRMY 8knuU1Xe0kNGIHbFAd9GuzGkfjVq7oyG3XTu44ESFhpEBdh8MBcuM7rBNGdYFj6C WLqvzXql4dRMQyfELtCfGX5n7FJQJj39HxQ/y7qrWwA9uvBHMbobyl15Lr/oH/uM EzhcysB5A/mYQHa4ZFpElRhCGLC2boZuJeVGWnbQZnIHJNgqH0QOoJxBciW3hdZJ 75ub4f7Yr/nR8r7kijbYS9xXdsuMwPqlGITTO9xu7P/5IJRW8FwpLSUO+kY6NFLq eUyz+Ymu49IdhZnryMYEHfOLLO+jNcEySsvzSZ2vorO85zeLqlaYUhw65R7gptaR yBTke4zZMdNmoJQZF5nmUo9MIX453BmNI1N/9RROzz9DHyYfkLcyLSdWf8pQmRgU 30MaWSDX1vm4ijCLOZd33CgIak9F0PwwIT5FTBthymHebWzHPRFoi+UEHmK1/CVC FnKKGlBFzaPMUghVx0yHDCMWwPr9BIEz3qHODDBo3DtZy3lp1Ws= =Jk32 -----END PGP SIGNATURE----- --Apple-Mail=_FE18DAB6-E411-4E4B-B826-563C4F7BA1CB-- From nobody Wed Sep 19 07:47:29 2018 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 9C382131055; Wed, 19 Sep 2018 07:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45TJM6QQa0D3; Wed, 19 Sep 2018 07:47:08 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3801310E6; Wed, 19 Sep 2018 07:47:06 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w8JEl1hv032530; Wed, 19 Sep 2018 16:47:01 +0200 Date: Wed, 19 Sep 2018 16:47:01 +0200 From: Willy Tarreau To: "Brian Trammell (IETF)" Cc: Tom Herbert , QUIC WG , tsvwg , IETF IPPM WG Message-ID: <20180919144701.GB32514@1wt.eu> References: <96100918-CCD7-447D-AF09-F4E60A733661@trammell.ch> <20180919135721.GB32294@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 14:47:21 -0000 Hi Brian, On Wed, Sep 19, 2018 at 10:30:05AM -0400, Brian Trammell (IETF) wrote: > > I think the mechanism described in the draft could be generalized to > > any transport layer. You could even imagine stuffing this into Websocket > > or H2 to provide measurements at *certain* layers if that made sense. > > Yes, but. The signal is only useful for passive measurement if it's visible > along the path, and anything beyond the encryption boundary is not visible. > So H2/WS spinning would not appear to be useful here. It depends. Typically TLS is often stripped at the edge of an infrastructure, and providing an easy means of measuring some end-to-end performance can be useful. It could also be useful within the ends themselves. Right now if a server needs to measure the RTT on an H2 connection, I guess it has to actively send PING frames and implement its own mechanism. Maybe your mechanism could be used in a more natural way so that both ends constantly have access to that signal and know more accurate information in a passive way. These are just ideas, nothing more, but I see some value in this work that could be used beyond its initial design purpose. > > I > > tend to think that the document should focus more on the algorithm itself > > and how to reliably implement it, and discuss application to existing > > transport layers only as examples of what an implementation could look > > like. > > This is one approach we could take, but at least for the -00 revision we > wanted to show how this worked for both QUIC and TCP, because that's what we > implemented (see also our preprint, to appear at IMC: > https://mami-project.eu/wp-content/uploads/2018/09/spinbit.pdf). OK that makes sense of course. (...) > > By the way I'm seeing an minor problem there related to how you decide > > how flips the bit : you need to know who's the connection initiator and > > who's the target. In TCP you have a simultaneous connect feature which > > allows two clients to connect to each other if they know their respective > > source ports (try it using netcat if you want), thus maybe there are > > other protocols where it's not that obvious who's the initiator. > > Yes, this is an issue we have not addressed yet, and is derived from the fact > that QUIC is explicitly asymmetric, as it is basically a transport protocol > wrapped around TLS, which is also explicitly asymmetric. (...) > Without thinking too hard about it, one could break an initiator/responder > tie for simultaneous open by sorting two-tuples. Yes very likely, I just think that for completeness it deserves being studied a little bit if you want to see it adopted/adoptable anywhere. Thanks, Willy From nobody Wed Sep 19 07:59:57 2018 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 2E12B130F2F for ; Wed, 19 Sep 2018 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o15genMWvF5N for ; Wed, 19 Sep 2018 07:59:45 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE699130E78 for ; Wed, 19 Sep 2018 07:59:44 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id l42-v6so5332896qtf.13 for ; Wed, 19 Sep 2018 07:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x6+onw2g9EYmjPYlVBpVBorbPhIFyf1CRTvPYLPd3QA=; b=hzyZBaA+LFhrOVPj1twKsLEGtTpOey6W00C8cFc1ibDVqeNmRS1A+YhZ6k21PVtqKd Tml5TuGuTazDRHQhKXLT7dZbmHwbQ3skcp8zXNBEuP6EcoOBxPgrKUFSmMdItmIhuuFb B8xBmT65TNWGSws+dkielJc5Xi1ZEIBdsu7kMuQH9cxSfApK7gatX5g0v8AI9ckeI3ko bXoD90fqjKRg29ABXawqti3yosYF4GNgWQE/8aPjKJHZbXV16gka/W7d5t8Im+NWA4Hr HloDrWbPpslcsoGdDoM0ese5VVZVhkDbbId/e+ucmZwzF28ay18subwwMeSlOddPaHyE FC9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=x6+onw2g9EYmjPYlVBpVBorbPhIFyf1CRTvPYLPd3QA=; b=kDULXCCVHUU7R2yezBj/XHuuh//h1cFqCoUSazKnTOTPRR7Lyr5czyw/Cr6Z4YeabT ddTQcl7CvrMqzzrV9EjQAkXwyjNqzSn8IsO3NAYLmRe78YGl6MLXP66HYt5DGP+O9RKY c3Xd2MtEUIfUIU1+EncdFh15/AGkZB2JHzl5n9cpAFt4G6U1RpBpCUv4iczfH7nP8AOs HL/i9jGMuXR9xMZr+JM6aQW7kNbBD3oRY7W0DnVF/hNI69v9j7L0NEBs01rCeK1rsSLJ jb6U3Oa9XFG+gQOfjY2IBMBwmbOYDChUGvT/ljeaYFlFHsm0UDzhG1VVkdWdvaZewWUj rCFQ== X-Gm-Message-State: APzg51DB3GcuSvFnrQRfgHSz7l0/Sx9xiJVaoMgkCOsMgfqsmDqDEVZS UHkyHakI2+HjWms5t+hRHXrAvZrYG5x6VFgFuGnCng== X-Google-Smtp-Source: ANB0VdZs3CxDmV8YKlJmGQk9eZVNTzVuVL+CKx80kehZaFtvvpibGygKZc+KjjsoCbl1t66g0vXHS/7tr8eKTdYmjio= X-Received: by 2002:a0c:fa08:: with SMTP id q8-v6mr23718952qvn.179.1537369183576; Wed, 19 Sep 2018 07:59:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Wed, 19 Sep 2018 07:59:43 -0700 (PDT) In-Reply-To: <15454907-02C1-42C7-893B-EB2959FF18D8@lurchi.franken.de> References: <15454907-02C1-42C7-893B-EB2959FF18D8@lurchi.franken.de> From: Tom Herbert Date: Wed, 19 Sep 2018 07:59:43 -0700 Message-ID: To: Michael Tuexen Cc: "Brian Trammell (IETF)" , QUIC WG , tsvwg , IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 14:59:48 -0000 On Wed, Sep 19, 2018 at 4:46 AM, Michael Tuexen wrote: >> On 19. Sep 2018, at 00:53, Tom Herbert wrote: >> >> On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) wrote: >>> Greetings, TSVWG, QUIC, and IPPM, >>> >>> I've just submitted a new I-D, "Why do we need passive measurement of r= ound trip time?" (https://tools.ietf.org/html/draft-trammell-why-measure-rt= t-00), which may be of some interest to each of these WGs. :) It presents a= set of use cases for on-path passive RTT measurement, both generally, and = specific to the facility described in "A Transport-Independent Explicit Sig= nal for Hybrid RTT Measurement" (https://tools.ietf.org/html/draft-trammell= -tsvwg-spin-00), or the "spin bit". >>> >> Hi Brian, >> >> I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to >> me how this mechanism is transport-independent. The draft shows how to >> do this in QUIC and TCP, but there's no support that I see for DCCP, >> SCTP, IPsec, other encapsulations, etc. I would think that for >> something to be truly transport-independent the information would need >> to reside in the network layer. > I agree with Tom, right now this does not look like transport-independent= . > One could add a chunk for SCTP to expose the 3 bits, but I was wondering > why not just let the endpoints willing to expose the RTT signal let them > send the measured RTT explicitly? > Yes! The application or at least network stack will have this information and much more that might be of interest to the network-- they will also know RTT variance, packet loss on the flow, number of out of order packets received, etc. If the network needs this sort of information why not just ask the application for it instead of trying deduce it from a limited view of the transport layer and a couple of fundamentally insecure bits in the packet? Tom > Best regards > Michael >> >> Tom >> >>> - For QUIC, this draft addresses the second half of the risk/utility qu= estion raised by the spin bit and spin+VEC latency signal -- much of the co= ntent comes from the original QUIC spin bit document, but there are new sec= tions on using VEC for loss/reordering proxy metrics and exploiting correla= tions between RTT and other metrics to drive intraflow diagnostics from onl= y RTT signals. In particular, I'll talk about ongoing experimentation along= the lines of section 3 at the interim in New York. >>> >>> - For TSVWG and tsvarea, it addresses some of the "why design wire imag= es" questions raised in the tsvarea meeting in Montreal, with respect to th= e specific tasks for which RTT data is useful. >>> >>> - And for IPPM, it gives a bit more background on the "passive RTT" met= ric in the initial registry document. >>> >>> Feedback is much appreciated. :) >>> >>> Thanks, cheers, >>> >>> Brian (as an individual contributor) >>> >>> P.S. apologies for the resend: the previous message was not an obscure = joke about ubiquitous encryption: apparently the interaction among my MUA, = its bolt-on GPG, and the somewhat underprovisioned network in SIGCOMM led t= o an encrypted draft being posted to the list. :/ >>> >> > From nobody Wed Sep 19 08:14:21 2018 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 2782F130DD2; Wed, 19 Sep 2018 08:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8Vpu9P9X3FZ; Wed, 19 Sep 2018 08:14:14 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FAD130E03; Wed, 19 Sep 2018 08:14:14 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id t68-v6so5368945oie.12; Wed, 19 Sep 2018 08:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=hzWsbX6NYAKtkQ7zRjiFODtvlTXsTBWdFlMkrLlE8wI=; b=ShRY7omUGpY+S6LpMweek/QJtgWrqLHvatPLVUf13iecNaxJ2KiqAsmFQlaieGLNzL olFX/DW4668ZvvuQ2F5f4nF3WxjaRylQEfSjOAhgVgmAbBPCyWEYaUuMpu8zyt0vRHw3 Z98oKrDjDdfDVAra0ggHOinmS0PbbeKU94Mn4ISvOkbmqQN5Dat6FSgjU2QhApKRZ8os K5mHxqNfTF0PUfg8H5X62Zx8bCoxS8Nyf2IauDCW4RiA83eNbTxo1OcI1aVEBwjqEanw Tbaj+ZvGB2VVNuMDOCGEgc4IzdkpAYPur09ADZPkL4LqrZw6YurmPANVAQt73QCY96oJ sjsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=hzWsbX6NYAKtkQ7zRjiFODtvlTXsTBWdFlMkrLlE8wI=; b=JvMevk36bsS4KvqjabSIfe1dPJ2edegrLPXCwgtePlTjjBDumBK5pX463uiuEyzLgm 8BAjupUo6BvSqM5Xtm2fKMoY7pWF7VwhvC5r0l5KC2RQ8bDVljtzciV9EB7JIqDrflKW 8xa9LpiqnknslCJaZqxK8mFXsOBHeds0iEOXt5pn5ACNTsakwpQwPZZlvZlnvenXkdWy eUGEaYeK8/n94QqVHjvSDTt8g0u7C9o2yzvCRQHB+meqqXOFG7tT7Lj5Kwevyx7UANdz t4n1e1RMQHN48HUZHTE3MTwWtRPunErW2S9rnqVf2l4RP+ap6ut7Pa+J4TVbutKgtQF4 q1wg== X-Gm-Message-State: APzg51BMhWO9SujAjouL54AFJeAqjxNzYYz/qU82o9rLVn3LwzTilweX pnsQ+ZQZTZISXK9lKtpVDp5EAOkDR7OGHauE/44= X-Google-Smtp-Source: ANB0VdaACS/hncZ4cgapqgOVuq6TvYKpNLt2CPFr4dw+WyseyJJ2H3CRYQaSX0bK/29tA9AOWvr5DP5caj2wzFQ2PqQ= X-Received: by 2002:aca:57d4:: with SMTP id l203-v6mr1846226oib.329.1537370053947; Wed, 19 Sep 2018 08:14:13 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 19 Sep 2018 11:14:13 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <15454907-02C1-42C7-893B-EB2959FF18D8@lurchi.franken.de> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 19 Sep 2018 11:14:13 -0400 Message-ID: To: Tom Herbert , Michael Tuexen Cc: IETF IPPM WG , QUIC WG , "Brian Trammell (IETF)" , tsvwg Content-Type: multipart/alternative; boundary="000000000000f4378a05763adbb0" Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:14:18 -0000 --000000000000f4378a05763adbb0 Content-Type: text/plain; charset="UTF-8" Tom, it may be quite difficult to ask the application. An operator may have many thousands ongoing connections with mobile phones and want to measure the overall network quality. It would be quite impossible to discuss latency with all phones in the network. Additionally it would require a secure connection, trust, etc. etc. Passive measurement is invasive in the sense that it steals private information that could be abused without consent. So the balance is expose as little as possible, but enough to make it useful for reasonable purposes. Trammels paper shows that a very high quality can be achieved with 3 bits, which is a lot simpler than asking an application, whether the option existed or not. The question is more: would 8 bits, or a full sequence number be better? The answer, according to the paper is no - only in certain lossy conditions, and not by very much. On the other hand, more information leaks more private information. Furthermore, the simplicity of 3 bits make it possible to stuff the bits almost anywhere, so the concept is universal. There is almost no bad things to say about it, except the connection asymmetri mentioned, and the fact it must happen in the layer 4 packet rather than the IP packet. But then, it could be mirrored into a lower layer protocol header since it is space efficient. On 19 September 2018 at 17.00.33, Tom Herbert (tom@herbertland.com) wrote: On Wed, Sep 19, 2018 at 4:46 AM, Michael Tuexen wrote: >> On 19. Sep 2018, at 00:53, Tom Herbert wrote: >> >> On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) wrote: >>> Greetings, TSVWG, QUIC, and IPPM, >>> >>> I've just submitted a new I-D, "Why do we need passive measurement of round trip time?" ( https://tools.ietf.org/html/draft-trammell-why-measure-rtt-00), which may be of some interest to each of these WGs. :) It presents a set of use cases for on-path passive RTT measurement, both generally, and specific to the facility described in "A Transport-Independent Explicit Signal for Hybrid RTT Measurement" (https://tools.ietf.org/html/draft-trammell-tsvwg-spin-00), or the "spin bit". >>> >> Hi Brian, >> >> I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to >> me how this mechanism is transport-independent. The draft shows how to >> do this in QUIC and TCP, but there's no support that I see for DCCP, >> SCTP, IPsec, other encapsulations, etc. I would think that for >> something to be truly transport-independent the information would need >> to reside in the network layer. > I agree with Tom, right now this does not look like transport-independent.. > One could add a chunk for SCTP to expose the 3 bits, but I was wondering > why not just let the endpoints willing to expose the RTT signal let them > send the measured RTT explicitly? > Yes! The application or at least network stack will have this information and much more that might be of interest to the network-- they will also know RTT variance, packet loss on the flow, number of out of order packets received, etc. If the network needs this sort of information why not just ask the application for it instead of trying deduce it from a limited view of the transport layer and a couple of fundamentally insecure bits in the packet? Tom > Best regards > Michael >> >> Tom >> >>> - For QUIC, this draft addresses the second half of the risk/utility question raised by the spin bit and spin+VEC latency signal -- much of the content comes from the original QUIC spin bit document, but there are new sections on using VEC for loss/reordering proxy metrics and exploiting correlations between RTT and other metrics to drive intraflow diagnostics from only RTT signals. In particular, I'll talk about ongoing experimentation along the lines of section 3 at the interim in New York. >>> >>> - For TSVWG and tsvarea, it addresses some of the "why design wire images" questions raised in the tsvarea meeting in Montreal, with respect to the specific tasks for which RTT data is useful. >>> >>> - And for IPPM, it gives a bit more background on the "passive RTT" metric in the initial registry document. >>> >>> Feedback is much appreciated. :) >>> >>> Thanks, cheers, >>> >>> Brian (as an individual contributor) >>> >>> P.S. apologies for the resend: the previous message was not an obscure joke about ubiquitous encryption: apparently the interaction among my MUA, its bolt-on GPG, and the somewhat underprovisioned network in SIGCOMM led to an encrypted draft being posted to the list. :/ >>> >> > --000000000000f4378a05763adbb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Tom, it may be quite= difficult to ask the application. An operator may have many thousands ongo= ing connections with mobile phones and want to measure the overall network = quality. It would be quite impossible to discuss latency with all phones in= the network. Additionally it would require a secure connection, trust, etc= . etc.

Passive measur= ement is invasive in the sense that it steals private information that coul= d be abused without consent. So the balance is expose as little as possible= , but enough to make it useful for reasonable purposes.

Trammels paper shows that a very high qu= ality can be achieved with 3 bits, which is a lot simpler than asking an ap= plication, whether the option existed or not. The question is more: would 8= bits, or a full sequence number be better? The answer, according to the pa= per is no - only in certain lossy conditions, and not by very much. On the = other hand, more information leaks more private information.

Furthermore, the simplicity of 3 = bits make it possible to stuff the bits almost anywhere, so the concept is = universal.
There is a= lmost no bad things to say about it, except the connection asymmetri mentio= ned, and the fact it must happen in the layer 4 packet rather than the IP p= acket. But then, it could be mirrored into a lower layer protocol header si= nce it is space efficient.


On 19 September 2018 at 1= 7.00.33, Tom Herbert (tom@herbertlan= d.com) wrote:

On Wed, Sep 19, 2018 at 4:46 AM, Michael Tuexen
<michael.tuexen@= lurchi.franken.de> wrote:
>> On 19. Sep 2018, at 00:53, Tom Herbert <tom@herbertland.com> wrote:
>>
>> On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>>> Greetings, TSVWG, QUIC, and IPPM,
>>>
>>> I've just submitted a new I-D, "Why do we need pa= ssive measurement of round trip time?" (https://tools.ietf.org/html/dra= ft-trammell-why-measure-rtt-00), which may be of some interest to each = of these WGs. :) It presents a set of use cases for on-path passive RTT mea= surement, both generally, and specific to the facility described in "A= Transport-Independent Explicit Signal for Hybrid RTT Measurement" (https://= tools.ietf.org/html/draft-trammell-tsvwg-spin-00), or the "spin bi= t".
>>>
>> Hi Brian,
>>
>> I looked at that draft draft-trammell-tsvwg-spin-00. It's = unclear to
>> me how this mechanism is transport-independent. The draft show= s how to
>> do this in QUIC and TCP, but there's no support that I see= for DCCP,
>> SCTP, IPsec, other encapsulations, etc. I would think that for
>> something to be truly transport-independent the information wo= uld need
>> to reside in the network layer.
> I agree with Tom, right now this does not look like transport-inde= pendent..
> One could add a chunk for SCTP to expose the 3 bits, but I was won= dering
> why not just let the endpoints willing to expose the RTT signal le= t them
> send the measured RTT explicitly?
>
Yes! The application or at least network stack will have this
information and much more that might be of interest to the network--
they will also know RTT variance, packet loss on the flow, number of
out of order packets received, etc. If the network needs this sort of
information why not just ask the application for it instead of trying
deduce it from a limited view of the transport layer and a couple of
fundamentally insecure bits in the packet?

Tom


> Best regards
> Michael
>>
>> Tom
>>
>>> - For QUIC, this draft addresses the second half of the ri= sk/utility question raised by the spin bit and spin+VEC latency signal -- m= uch of the content comes from the original QUIC spin bit document, but ther= e are new sections on using VEC for loss/reordering proxy metrics and explo= iting correlations between RTT and other metrics to drive intraflow diagnos= tics from only RTT signals. In particular, I'll talk about ongoing expe= rimentation along the lines of section 3 at the interim in New York.
>>>
>>> - For TSVWG and tsvarea, it addresses some of the "wh= y design wire images" questions raised in the tsvarea meeting in Montr= eal, with respect to the specific tasks for which RTT data is useful.
>>>
>>> - And for IPPM, it gives a bit more background on the &quo= t;passive RTT" metric in the initial registry document.
>>>
>>> Feedback is much appreciated. :)
>>>
>>> Thanks, cheers,
>>>
>>> Brian (as an individual contributor)
>>>
>>> P.S. apologies for the resend: the previous message was no= t an obscure joke about ubiquitous encryption: apparently the interaction a= mong my MUA, its bolt-on GPG, and the somewhat underprovisioned network in = SIGCOMM led to an encrypted draft being posted to the list. :/
>>>
>>
>

--000000000000f4378a05763adbb0-- From nobody Wed Sep 19 10:13:13 2018 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 D17E7130E67 for ; Wed, 19 Sep 2018 10:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyxVS5qhVTsv for ; Wed, 19 Sep 2018 10:13:08 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8DB130EE2 for ; Wed, 19 Sep 2018 10:13:07 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id k38-v6so5775426qtk.11 for ; Wed, 19 Sep 2018 10:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jJR5Nl2/4Ht05QmyIhxpKGY5HTryHszLoo3nmgBGiwA=; b=xMjq7oqNLe6fJ3dccpw1/CEdfYZY0g6FpicAPYzvdtvERonzyiAaU5v09hFltSRgiU kMy1FFtySt9585TSAmsucJPrR3FYApD1VxVqNgzsWkW3px9rkpE34RUfZqyTS1abLSBs J2Tw5bfl9SMgP2ncVdv2XF2C5SqEH58r4MG9QmX8qQK2x9dO+BrsihGQLPnt6yzZ8+Cp LR3KF38VRDUF17GHGIj32loWeCdMQJiDUsiJW/psJlnONuHuRup78Ni0IBnCCi4V9r1x JkybK+Z7izQQ4nUnsTB07Nu3ziyNGxsBNcH7u1xS+4mBhwjPG+fAui475718uqSPVc1k pJOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jJR5Nl2/4Ht05QmyIhxpKGY5HTryHszLoo3nmgBGiwA=; b=IejV2I0UjzgfudJ/av1OlcOSgrzj5/aGS2G2x2UR/4U8ll8ZcTf4WikFeHupCxiCUL wIlAS1D6hT1Bv3+ModtjvBaF1E3CsaoVI+aJ7HfTnNBY4o2ef+YlDprN+jHnVXWVvsVg FfZInB2RTT7DfGt6SpTTFekb11hh8Htcg9CjZDxmKD/DCn5u+6GVE1aUmosVpca/vZPd WeISKKyxdWMrPbPbpwlYGNiVqencnIYe/zBJaeDjc+4mn/+Sb72QupB1+Ts5R9br/U5J /batveeEGhFifjqV0TpmVQn64D68JgwVW9ltehVECjkWzLIG93CFkiKcfsz70kTVPxuH BQOA== X-Gm-Message-State: APzg51CCc9aZqL8U8cRzHCSMn+uAdf3CLgU4DgvuYVeGR+8vFjkI4oxe ANMso2wFXoIhxNf2Swt4hiFI1BPh/7L78hybJ/bGag== X-Google-Smtp-Source: ANB0VdYlEnuMBYIuGxYbTDV0LvnLMrnstxW7p6TOEmajLDYEhd6NjhXnbox7DgEAlc/XG1Q/tfzsCNg/MkX5660XuXM= X-Received: by 2002:ac8:2c1a:: with SMTP id d26-v6mr25255601qta.291.1537377186778; Wed, 19 Sep 2018 10:13:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Wed, 19 Sep 2018 10:13:06 -0700 (PDT) In-Reply-To: <96100918-CCD7-447D-AF09-F4E60A733661@trammell.ch> References: <96100918-CCD7-447D-AF09-F4E60A733661@trammell.ch> From: Tom Herbert Date: Wed, 19 Sep 2018 10:13:06 -0700 Message-ID: To: "Brian Trammell (IETF)" Cc: tsvwg , QUIC WG , IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 17:13:10 -0000 On Wed, Sep 19, 2018 at 5:28 AM, Brian Trammell (IETF) w= rote: > > >> On 18 Sep 2018, at 18:53, Tom Herbert wrote: >> >> On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) wrote: >>> Greetings, TSVWG, QUIC, and IPPM, >>> >>> I've just submitted a new I-D, "Why do we need passive measurement of r= ound trip time?" (https://tools.ietf.org/html/draft-trammell-why-measure-rt= t-00), which may be of some interest to each of these WGs. :) It presents a= set of use cases for on-path passive RTT measurement, both generally, and = specific to the facility described in "A Transport-Independent Explicit Sig= nal for Hybrid RTT Measurement" (https://tools.ietf.org/html/draft-trammell= -tsvwg-spin-00), or the "spin bit". >>> >> Hi Brian, >> >> I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to >> me how this mechanism is transport-independent. The draft shows how to >> do this in QUIC and TCP, but there's no support that I see for DCCP, >> SCTP, IPsec, other encapsulations, etc. > > Those bindings are future work -- and, indeed, the draft should be cleare= r about that. Mea culpa, usual excuses about -00, and all that. > Hi Brian, The fact that every transport protocol can be changed to support this feature really doesn't make it transport independent. Besides, even if you did change a protocol like SCTP to support spin bit, it's useless until intermediate devices support the transport protocol-- it's simply a fantasy to think that vendors are going to rush out to support every possible transport protocol. At best, instead of the Internet being ossified around one transport protocol it might be ossified around two. IMO, QUIC encrypting all the transport layer was a big step forward in the fight against protocol ossification. Purposely leaking any transport layer information, like the spin bit, is a step backward in that regard. The obvious answer to make this transport independent is to put information into a Hop-by-Hop option. Not only does HBH work with any transport protocol, it also allows a rich set of information, and can correctly be interpreted and optionally changed at intermediate devices, and can be secured. This is why FAST uses it for instance. The predictable counter argument is of course that IPv6 options don't work on some paths in the Internet. But, I view that as a _current_ condition. I see nothing architecturally that prevents fixing the situation or applying "happy eyeballs" like mechanisms to mitigate the problem. In fact defining useful options could break deadlock where vendors aren't going to support options before useful ones have been defined. If given a choice between middlebox vendors trying to transport support every transport or working on generic transport-independent solutions, I'd much rather see the latter happen. Tom >> I would think that for >> something to be truly transport-independent the information would need >> to reside in the network layer. > > This is, architecturally speaking, my preference as well. The reasons we = propose this as a layer 4 signal, as opposed to a layer 3 signal, are elabo= rated in section 5.1. The overwhelming one here is that ports are often use= d in combination with addresses to make forwarding decisions, such that a 2= -tuple does not fully describe a "path" between two endpoints at any instan= ce in time. > > IOW, we're trying to solve the measurement problem it looks like we have,= not the one we'd like to. > > That said, the technique described here could also be applied to three bi= ts (theoretically clawed back) from the network layer header, with the logi= c to be applied to the flow aggregate of all packets sent between two IP ad= dresses. Since there's no two-tuple state structure that we could already h= ang this off (that I know of), this would require the design of new state s= tructures in the IP stack. > > Cheers, > > Brian > >> Tom >> >>> - For QUIC, this draft addresses the second half of the risk/utility qu= estion raised by the spin bit and spin+VEC latency signal -- much of the co= ntent comes from the original QUIC spin bit document, but there are new sec= tions on using VEC for loss/reordering proxy metrics and exploiting correla= tions between RTT and other metrics to drive intraflow diagnostics from onl= y RTT signals. In particular, I'll talk about ongoing experimentation along= the lines of section 3 at the interim in New York. >>> >>> - For TSVWG and tsvarea, it addresses some of the "why design wire imag= es" questions raised in the tsvarea meeting in Montreal, with respect to th= e specific tasks for which RTT data is useful. >>> >>> - And for IPPM, it gives a bit more background on the "passive RTT" met= ric in the initial registry document. >>> >>> Feedback is much appreciated. :) >>> >>> Thanks, cheers, >>> >>> Brian (as an individual contributor) >>> >>> P.S. apologies for the resend: the previous message was not an obscure = joke about ubiquitous encryption: apparently the interaction among my MUA, = its bolt-on GPG, and the somewhat underprovisioned network in SIGCOMM led t= o an encrypted draft being posted to the list. :/ >>> > From nobody Wed Sep 19 13:12:28 2018 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 5A1031310FB for ; Wed, 19 Sep 2018 13:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0hQeBRyt5iv for ; Wed, 19 Sep 2018 13:12:06 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61557131095 for ; Wed, 19 Sep 2018 13:12:04 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id z13-v6so296644qts.5 for ; Wed, 19 Sep 2018 13:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cdPqY1D4FJzqEA/mqubhNdhXu6k48hHLbfsBgH7eN4M=; b=dQBvVTgfN1G74y5CVedRdD0SkHcBHUpfQyOs1WfA94sNSKCWInGgndZcsEQlxkBd2b N5SZiMT7OdrWboN/v8UoGWoEJmzqqYSpVRKZZvTyGJTVMMN5hRLE21vhiMbf3I3/ha5K 9UXad9dZy1IAS0SqAX0y6NihUr7rVluOj2BZ2JROosnygKnMmFjEWJaUa2x/u8LhR5zX 5JaLWdJhxIAw8Fvamp0DgBtmmfZgqAsjFHbh5bJGp68UdNZXuPGZgKqC5XZjYkXFWd29 fFWF+KYH5/JaPFwb6FBI9mfn5hxJhf2anlqcNVHfRYQ3t4OfBkraiMpHNCyX40x7XukL UZUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cdPqY1D4FJzqEA/mqubhNdhXu6k48hHLbfsBgH7eN4M=; b=maCyGM0fzCPnnP4321vI9bPvZTKs5g1Hm/fxIMC7rCzslI1J3dbKTDdb/jq0DbIEQe 597iwoZXNJut+/Ox8Dbyq1duGk6JEpr9B/owSvAFjBhklOBMBvahyqpw2D6Z617vgAv2 16sgJo4PKbef4D6VkXTc+xODuRY0CgFR04Rydm5urb/tNO4Bsgnuc/h/wwNhPwCxdqmi i3Ly4lrcY5U52ebu8/fiEtd1vmNXKZomktXJf5c2JSDrhanV6DIszT1QiwQ2bPcwkxGZ fXGgCLmaYtiMyKUd6fqiXjnX0hFxVw4QuPL4J0Y2yRKawuWaCCWvBCqOA/WcraRgNN8B q0ag== X-Gm-Message-State: APzg51AhZi6ppMWblV3czyLysEsCbu+Cnlc0QouBvzn3rKixwRKRY6Xy awRfqHnYaETE2AzqdzqokNhquKSqP9i53+E73w+ZIQ== X-Google-Smtp-Source: ANB0Vdbn5ZkbqozgssXtU5SbcCrGkNqh1OC6TmP/5S2CyboIRqQXNFSNkPw/vlEZ+xPmJBFqXyPTOnriwtHvPkz2N7M= X-Received: by 2002:a0c:f685:: with SMTP id p5-v6mr25776669qvn.22.1537387923333; Wed, 19 Sep 2018 13:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Wed, 19 Sep 2018 13:12:02 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Wed, 19 Sep 2018 13:12:02 -0700 Message-ID: To: Christian Huitema Cc: Spencer Dawkins at IETF , Brian Trammell , IETF QUIC WG , tsvwg , IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 20:12:15 -0000 On Wed, Sep 19, 2018 at 5:24 AM, Christian Huitema wr= ote: > >> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF wrote: >> >> Forget that I'm an AD, because I'm not wearing any hats, but I'm having = a really difficult time explaining to other people internally how a spin bi= t that's not in the IP header, but is part of a mostly-encrypted transport = header, is better than putting something in an IP (extension? iOAM?) header= that would be transport-independent. > > The one advantage of the bit in transport header is that it is authentica= ted end to end. The other advantage is that it is automatically tied to a t= ransport flow and its five tuple. Then there is the reality that IP header = bits are commonly rewritten by a variety of middleboxes. > Christian, That only helps to a degree. Intermediate nodes wouldn't be able to authenticate those bits, so they'll just accept whatever is there regardless of whether packets might be ultimately be dropped at the endpoint. So it's still possible that if the bits are modified to (adversely?) affect the network state maintained for a flow. One disadvantage of QUIC spin bit compared to TCP is that the QUIC lies within a UDP payload which would mean that an intermediate device would need to parse the payload. Presumably, the only way an intermediate node could detect a QUIC packet is by matching port numbers to 80 or 443. But, as described in RFC7605 port numbers only have meaning at endpoints, so it's possible that an application might be using a QUIC assigned port for a completely different purpose and interpreting the payload as QUIC might be completely wrong. IP protocol numbers don't suffer from this ambiguity; if a next header is 0x6 it is considered a TCP packet anywhere in the network. This ambiguity should probably be mentioned in the QUIC spin bit draft. Tom > The downside is that different encrypted transports will most likely end = up adopting different encodings and conventions. > > But of course we could also repurpose one of the TOS bits or one of the f= low header bits for the purpose, to mirror the transport level bit. Mirror = instead of replace: that would alleviate the need of parsing transport head= ers, but still allow end to end detection of IP header rewriting. > > -- Christian Huitema From nobody Wed Sep 19 13:49:39 2018 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 9D9D1127332; Wed, 19 Sep 2018 13:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM5Z0gJ5gktR; Wed, 19 Sep 2018 13:49:36 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C58A120072; Wed, 19 Sep 2018 13:49:36 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id y4-v6so3295475pgp.9; Wed, 19 Sep 2018 13:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Do1ADqsxFWsTc918jDaDY3TcWXsGiPPJYVgLmg6uGOU=; b=qk/Sbke17i4lYh1A6SabTvo2PuhuPtX5RDHJ6gOXc7bF8CYFtW5zy+0+DYouYwnSv4 2L8Y0S+ymfVrkQpH82s3WOu1dUHz80nn3QkK54nDOsHZ2SFYbP+A8sWLQH+qRywRBnRY XO4e45PWvaTrnq1xrIGjhiNRSPlk+49aKsIGaTUlzK1obP/MoU25+62o8uOV3msAPlAK Td4RLTO4kAyYe3Ye1rXiNW+Tlkn0Nq89faEkJxc+mhL+Q2B/s+ySDuhDLdz9O2Acrknz 72W74K66mlU27ZrdAE1PWRc7iu482ZtgGqw4ka/ji/MEDweeKHbM9/lv2Bt2xWVpDvMA Gepg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Do1ADqsxFWsTc918jDaDY3TcWXsGiPPJYVgLmg6uGOU=; b=H86JdWCY1hfNu4/K0UdKPgnZ9YMn9xSjRpG/yIlxaxTFXGjwV5u8CpxHOQdmyeS1z4 j8siScRbJwiO8v59Y+wrPXFRxwPDXo6qPhNlFTH+y5CNJjnqSGuJspy4CUwCMDsxHI2b 1Z3joTNl9K2GD6V459aVvPqcAnLAB3s0x7Pzen33g+RCugSojVaNllFcgeiKk7Z/Dbkn N/1yhTl8qys/vKTWUiQmUCOrNYhu9mlhxk28YebmVVBzCdnQrN0YfCx+qLfuHVzpV+eh o1M2I4f511gRfMDJOL4IZ42gpXPFgyJFhMCEgdFPhJAzHZV6Ay3E57LpJn2RUb5E03bn xJEg== X-Gm-Message-State: APzg51BBWA5KNR1QZZA1vzpRIQ0/Co/PdHRuER5xysDkUjnrXkXkrmrl r89ya35k9MPXX0iPrKbiPz9C3NSM X-Google-Smtp-Source: ANB0VdareP0k6TL7YtGvUu8GDNiO5ec7tT9cp+FGTP5Og4mCVHkfxbe2Ex3HxpAYC8LWmqq58XZ3fw== X-Received: by 2002:a62:e08b:: with SMTP id d11-v6mr37770318pfm.214.1537390175577; Wed, 19 Sep 2018 13:49:35 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id f67-v6sm39809820pff.29.2018.09.19.13.49.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 13:49:34 -0700 (PDT) To: Gorry Fairhurst , Christian Huitema , Spencer Dawkins at IETF Cc: IETF QUIC WG , tsvwg@ietf.org, ippm@ietf.org References: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> From: Brian E Carpenter Message-ID: <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> Date: Thu, 20 Sep 2018 08:49:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 20:49:37 -0000 On 2018-09-20 01:56, Gorry Fairhurst wrote: > On 19/09/2018 13:24, Christian Huitema wrote: >> >>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF wrote: >>> >>> Forget that I'm an AD, because I'm not wearing any hats, but I'm having a really difficult time explaining to other people internally how a spin bit that's not in the IP header, but is part of a mostly-encrypted transport header, is better than putting something in an IP (extension? iOAM?) header that would be transport-independent. >> The one advantage of the bit in transport header is that it is authenticated end to end. The other advantage is that it is automatically tied to a transport flow and its five tuple. Then there is the reality that IP header bits are commonly rewritten by a variety of middleboxes. >> >> The downside is that different encrypted transports will most likely end up adopting different encodings and conventions. >> >> But of course we could also repurpose one of the TOS bits > Do you mean the DSCP field? - That would sound like a very odd proposal. To be clear, there are no free bits in the DSCP field, there are only free codepoints in the 6-bit space. And of course since DSCP values explicitly act as a QoS request, they also implicitly change the one-way latency and therefore the RTT. So the DSCP bits would be remarkably bad as a tool for RTT measurement. Brian C >> or one of the flow header bits for the purpose, to mirror the transport level bit. Mirror instead of replace: that would alleviate the need of parsing transport headers, but still allow end to end detection of IP header rewriting. >> >> -- Christian Huitema > > Gorry > > . > From nobody Wed Sep 19 14:18:12 2018 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 AA775130F05 for ; Wed, 19 Sep 2018 14:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9O1aUv8tdHx for ; Wed, 19 Sep 2018 14:17:53 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AD3131109 for ; Wed, 19 Sep 2018 14:17:51 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id c126-v6so3852528qkd.7 for ; Wed, 19 Sep 2018 14:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bvdjiY0RQUqbg7SoK22ho5xYq3EcyVOS3qnAO4Kdc8I=; b=he/0nBdyn3+GvQ2w4WEiqV2emkmXvEsPLzdjVphpRQgbU3kvI+yESk0VCgIIcAJlsq Ns6APSF3ezygY5teq0ZuGoyI7pO2AR3Kb119zOmUKjfhysm6idUand6GU4CSrZFkg54I VP7ZeXlqb2n2LR5l9KMjJ/9p72aWnVh2qQQ2VISvWKvrFM+aXWQHiQ6Zdf4q86oUAKic 5HGzepPXLkNQGrLZIbpkjgkfJDDQQR1qJd+4ofG+hh2xodM97iSMD75fZLi/HkqEUHXS zWr5w9r2lcwpDhz2qnKkWstjnin1ZDMqdHFmICixSD2Ny0MRJtrl7gNa2PO8jpzvJNOv KvIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bvdjiY0RQUqbg7SoK22ho5xYq3EcyVOS3qnAO4Kdc8I=; b=cn+/ALQGDEaAWoczod/7iC3eWacJmsMKSjjZHCvcJEppIGJk5Fr+BnZHZLtaGhAnn4 vjMSv8ZZiYkXSzGwARV4Yp/92jKK+sZcQSc3j/V2xQBzkO23f9PgC5wamNtQPN1+PqPP PnrCANWzPcV0gbbjKF6EQa0eaum6FgQ6xstpLogj9+NR1kLHU/iJVwrufhlXCZfHPgUR KYfSwoh6NZq1ZKuY4BRDHgkcf7eKfxAu238pEU/x8vJKEElKpY+9jUoL9KAqCamUxrtD TzFVU9JS7tEAxss0aKXVy3c81PczurP6p2S93mM8NKE6xS9ZeXi4F96GFxnKUNeYBzY5 3wFQ== X-Gm-Message-State: APzg51DSZjsqzH0Qy2MVPKjHnZ3o4kwWQWgT096KqRO9TqRkvOv6I+v6 70xKIf+RrffNMeBJr0WCZtBmR1VIR//bp6SX17R8IIcUqng= X-Google-Smtp-Source: ANB0Vda9UrgT1m2I8122lfDdLWbvK4O2EZgVHb8q5+qYPQVT1mBzPOenU3+9dciUk2QIdHIifVCvQOZVK8jDGk+vGKU= X-Received: by 2002:a37:a357:: with SMTP id m84-v6mr25317990qke.121.1537391870404; Wed, 19 Sep 2018 14:17:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Wed, 19 Sep 2018 14:17:49 -0700 (PDT) In-Reply-To: <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> References: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> From: Tom Herbert Date: Wed, 19 Sep 2018 14:17:49 -0700 Message-ID: To: Brian E Carpenter Cc: Gorry Fairhurst , Christian Huitema , Spencer Dawkins at IETF , IETF QUIC WG , tsvwg , IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 21:17:58 -0000 On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter wrote: > On 2018-09-20 01:56, Gorry Fairhurst wrote: >> On 19/09/2018 13:24, Christian Huitema wrote: >>> >>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF wrote: >>>> >>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm havin= g a really difficult time explaining to other people internally how a spin = bit that's not in the IP header, but is part of a mostly-encrypted transpor= t header, is better than putting something in an IP (extension? iOAM?) head= er that would be transport-independent. >>> The one advantage of the bit in transport header is that it is authenti= cated end to end. The other advantage is that it is automatically tied to a= transport flow and its five tuple. Then there is the reality that IP heade= r bits are commonly rewritten by a variety of middleboxes. >>> >>> The downside is that different encrypted transports will most likely en= d up adopting different encodings and conventions. >>> >>> But of course we could also repurpose one of the TOS bits >> Do you mean the DSCP field? - That would sound like a very odd proposal. > > To be clear, there are no free bits in the DSCP field, there are only > free codepoints in the 6-bit space. And of course since DSCP values > explicitly act as a QoS request, they also implicitly change the > one-way latency and therefore the RTT. So the DSCP bits would be > remarkably bad as a tool for RTT measurement. > > Brian C > >>> or one of the flow header bits for the purpose, to mirror the transport= level bit. Mirror instead of replace: that would alleviate the need of par= sing transport headers, but still allow end to end detection of IP header r= ewriting. Neither are there any flow label bits available. Re-purposing even a single bit would adversely effect deployed use cases where flow label is being used for packet steering or other purposes. Using the flow label for packet marking was discussed in https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01 Tom >>> >>> -- Christian Huitema >> >> Gorry >> >> . >> > From nobody Wed Sep 19 14:30:40 2018 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 CBC7C130E6F; Wed, 19 Sep 2018 14:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LngOe3rqf5oi; Wed, 19 Sep 2018 14:30:36 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB55130E47; Wed, 19 Sep 2018 14:30:36 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id 36-v6so7265863oth.11; Wed, 19 Sep 2018 14:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xXfgiz2YJF/QZe4IqbE2vEMoljv6XkAQCmTpyvl6gNY=; b=G4DHnvlJBh/xhrMpCgxUaTh+FiNTHdoPSfX3qQ9FH4TnTWtqpzA8HYLBXSRf7o3/Op +G5ueiDWbQIehJkfvPuYa4YylYKP0g0L6OA1PG6j035J+N7lPwQl8jfmNwpkWschVKwb 9E8TATSfo/lvUqkLXGaFpP1k7Gm26h2mDPo41stdyDpgxrdwiGsJqc7Uzu9W5asprK7o YTGfXlzAGCa3GOfi8Myurak1THyRDLIQ7puAtvZcgJcIRjZou2OTz0wQbXfW3rq8Qpom TmQQM+H+qnXkhzjJpGKCeUK5J93UrVEvuHvqVg3LwngagI+86BjjrFATxlE9/wR+Hgug KMpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xXfgiz2YJF/QZe4IqbE2vEMoljv6XkAQCmTpyvl6gNY=; b=SgHoRvZfw7bATxHni2F/BmlW83+bt4KJql8a2Nx2sYdrmnkIaxk3eg8lABgxWKgwzj sFnDPCoVCBFB64GmTQoiVqVoEQl+cBepX5//0qtM9gLc3ZVrn4UXkt9WHuFpXxez2OqM 6ipw/jTTCMYkeuES2OGnKls4vtwvY349H1n2sJqRPX4rS7LBDyCnRBrZTNYZaLh5ewuF 5CMM2N8QTSai5Xgz/tPAVoJsXV/SbC+q8faoEBSOmfvu/pGzin3qz/6D6T0uky+7xPad BsQFRB85V1e+etdqN3m1v0sBXB4zot3JU2fuPaj0tnR1qXa8IsjjH1pxWPreTStLMG7q lQKA== X-Gm-Message-State: APzg51BHgTqkuTsO6PXZlNwnym+/7aViWBklbH1gH/Q0qEVJ2uksOiQV EAW9Vr73Da53Tn2b/rwu542kKrf2OQXQIMfjFk3y8hGf X-Google-Smtp-Source: ANB0VdZy4j/m0h5CPpd5MDVj4PSNabSg9lhMqy1qLjyWkl6fiYJVVD4+7jDLtQGeNhhHzHUHwpKgBowwotBiWYkjN5E= X-Received: by 2002:a9d:689:: with SMTP id 9-v6mr19378714otx.149.1537392635930; Wed, 19 Sep 2018 14:30:35 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 19 Sep 2018 17:30:35 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 19 Sep 2018 17:30:35 -0400 Message-ID: To: Tom Herbert , Brian E Carpenter Cc: IETF IPPM WG , Gorry Fairhurst , Spencer Dawkins at IETF , IETF QUIC WG , Christian Huitema , tsvwg Content-Type: multipart/alternative; boundary="000000000000f1edf90576401d7e" Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 21:30:39 -0000 --000000000000f1edf90576401d7e Content-Type: text/plain; charset="UTF-8" On the actual experiments: has there been any work on patterns on a single bit? At some point we discussed various signals including square wave, PI, and fractal gray codes. If privacy or space is a concern with 3 bits, perhaps a gray code could solve the same problem trading space for time. On 19 September 2018 at 23.18.25, Tom Herbert (tom@herbertland.com) wrote: On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter wrote: > On 2018-09-20 01:56, Gorry Fairhurst wrote: >> On 19/09/2018 13:24, Christian Huitema wrote: >>> >>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: >>>> >>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm having a really difficult time explaining to other people internally how a spin bit that's not in the IP header, but is part of a mostly-encrypted transport header, is better than putting something in an IP (extension? iOAM?) header that would be transport-independent. >>> The one advantage of the bit in transport header is that it is authenticated end to end. The other advantage is that it is automatically tied to a transport flow and its five tuple. Then there is the reality that IP header bits are commonly rewritten by a variety of middleboxes. >>> >>> The downside is that different encrypted transports will most likely end up adopting different encodings and conventions. >>> >>> But of course we could also repurpose one of the TOS bits >> Do you mean the DSCP field? - That would sound like a very odd proposal. > > To be clear, there are no free bits in the DSCP field, there are only > free codepoints in the 6-bit space. And of course since DSCP values > explicitly act as a QoS request, they also implicitly change the > one-way latency and therefore the RTT. So the DSCP bits would be > remarkably bad as a tool for RTT measurement. > > Brian C > >>> or one of the flow header bits for the purpose, to mirror the transport level bit. Mirror instead of replace: that would alleviate the need of parsing transport headers, but still allow end to end detection of IP header rewriting. Neither are there any flow label bits available. Re-purposing even a single bit would adversely effect deployed use cases where flow label is being used for packet steering or other purposes. Using the flow label for packet marking was discussed in https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01 Tom >>> >>> -- Christian Huitema >> >> Gorry >> >> . >> > --000000000000f1edf90576401d7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On the actual experi= ments:

has there been= any work on patterns on a single bit? At some point we discussed various s= ignals including square wave, PI, and fractal gray codes.

If privacy or space is a concern with = 3 bits, perhaps a gray code could solve the same problem trading space for = time.

On 19 September 2018 at 23.18.25, T= om Herbert (tom@herbertland.com)= wrote:

On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter
<brian.e.carpenter@gm= ail.com> wrote:
> On 2018-09-20 01:56, Gorry Fairhurst wrote:
>> On 19/09/2018 13:24, Christian Huitema wrote:
>>>
>>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF &= lt;spencerdawkins.ietf@gma= il.com> wrote:
>>>>
>>>> Forget that I'm an AD, because I'm not wearing= any hats, but I'm having a really difficult time explaining to other p= eople internally how a spin bit that's not in the IP header, but is par= t of a mostly-encrypted transport header, is better than putting something = in an IP (extension? iOAM?) header that would be transport-independent.
>>> The one advantage of the bit in transport header is that i= t is authenticated end to end. The other advantage is that it is automatica= lly tied to a transport flow and its five tuple. Then there is the reality = that IP header bits are commonly rewritten by a variety of middleboxes.
>>>
>>> The downside is that different encrypted transports will m= ost likely end up adopting different encodings and conventions.
>>>
>>> But of course we could also repurpose one of the TOS bits
>> Do you mean the DSCP field? - That would sound like a very odd= proposal.
>
> To be clear, there are no free bits in the DSCP field, there are o= nly
> free codepoints in the 6-bit space. And of course since DSCP value= s
> explicitly act as a QoS request, they also implicitly change the
> one-way latency and therefore the RTT. So the DSCP bits would be
> remarkably bad as a tool for RTT measurement.
>
> Brian C
>
>>> or one of the flow header bits for the purpose, to mirror = the transport level bit. Mirror instead of replace: that would alleviate th= e need of parsing transport headers, but still allow end to end detection o= f IP header rewriting.

Neither are there any flow label bits available. Re-purposing even a
single bit would adversely effect deployed use cases where flow label
is being used for packet steering or other purposes. Using the flow
label for packet marking was discussed in
https://tools.ietf.org/html/draft-fioccola-spring-flow-label-= alt-mark-01

Tom

>>>
>>> -- Christian Huitema
>>
>> Gorry
>>
>> .
>>
>

--000000000000f1edf90576401d7e-- From nobody Wed Sep 19 14:37:51 2018 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 F008E130EA1; Wed, 19 Sep 2018 14:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu5rGSbLynju; Wed, 19 Sep 2018 14:37:40 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9BE130E02; Wed, 19 Sep 2018 14:37:40 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 42FtW64xvrz10YS; Wed, 19 Sep 2018 23:37:38 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 42FtW64DKgzFpWM; Wed, 19 Sep 2018 23:37:38 +0200 (CEST) Received: from [10.193.4.89] (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Sep 2018 23:37:38 +0200 To: Tom Herbert , Brian E Carpenter CC: Gorry Fairhurst , tsvwg , "IETF IPPM WG" , Christian Huitema , "Spencer Dawkins at IETF" , IETF QUIC WG References: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> From: Message-ID: <9096_1537393058_5BA2C1A2_9096_34_1_2a80b761-85b1-8835-6793-e756eb71df50@orange.com> Date: Wed, 19 Sep 2018 23:35:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: fr-xx-moderne Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.6] Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 21:37:42 -0000 On 09/19/18 23:17, Tom Herbert wrote: > >>>> or one of the flow header bits for the purpose, to mirror the transport level bit. Mirror instead of replace: that would alleviate the need of parsing transport headers, but still allow end to end detection of IP header rewriting. > > Neither are there any flow label bits available. Re-purposing even a > single bit would adversely effect deployed use cases where flow label > is being used for packet steering or other purposes. Using the flow > label for packet marking was discussed in > https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01 One very hackish way would be to use the TTL: Assuming that the number of L3 hops is constant long enough for a given 5-tuple, one can add a small varying offset to the TTL. The baseline can be learnt on the receiver by simple minimum extraction, assuming offset 0 is guaranteed to happen early in the connection's lifetime. For example, adding a value in [0,7] to the normal TTL of the sender's OS (1) is doable as long as the value is less than 248 (2) allows to encode 3 bits (3) will not upset the receiver nor any intervening node But granted, that's disgusting. -Alex _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Sep 19 14:42:55 2018 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 DE63D129AB8 for ; Wed, 19 Sep 2018 14:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p-vdc-NQ_Y1 for ; Wed, 19 Sep 2018 14:42:51 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357121294D0 for ; Wed, 19 Sep 2018 14:42:51 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx120.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1g2kFC-000P3J-Lr for ippm@ietf.org; Wed, 19 Sep 2018 23:42:48 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1g2kEv-0003ZQ-Su for ippm@ietf.org; Wed, 19 Sep 2018 17:42:45 -0400 Received: (qmail 890 invoked from network); 19 Sep 2018 21:42:29 -0000 Received: from unknown (HELO [172.20.6.146]) (Authenticated-user:_huitema@huitema.net@[207.110.29.138]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Sep 2018 21:42:28 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Wed, 19 Sep 2018 17:42:28 -0400 Cc: Brian E Carpenter , Gorry Fairhurst , Spencer Dawkins at IETF , IETF QUIC WG , tsvwg , IETF IPPM WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> To: Tom Herbert X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5oCK/5BrMlene/GFmLgbeBN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzeD5dlaABHsIv+xS3njCtZs1ujulqUFmMITHM77eiViqkm/iyZtADvBchmkehae187i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1RPScEHpAUegZl9l9jeRl05EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseytLy0an6SuH9Dnc48fGLITxB/2kIQu8EKhrGnpyzWchekvPDoQXGW9 SWsUI44T9FdqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1Z+7sPmjIM3bM0ihYRE0YjPM ySEj7fwLz33nMnt8v2VAeoz65OD2C5IJ2sa6HdMmGWCP6KnOBvL4JpDTCrFGRy20D7+0KApate85 0I5fJNUyxzHA8d1VA/QvgTJ1RzB4MCHqAeeZGuerhbgzLuS7t5v/pOdQlfBzqAqfm1gdq18TzM60 voqUUzJmvILAkkfgIO2X8z8ZLb0bgujKqKnA4A9Xgjmuntq3xZgBxhdNFJUcZu3d9ZNXJQW8HUxK X5uYJmvDK3PKrieG7T6bf9hS7hR0q7xASYaBUaOtmtSkj3iuxJhh7EHDojb6D9Mx+gs1+GHf4ys4 4rg2B8/9FmK9a1O9x7lsssuZ/53sObhu0YJN X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 21:42:54 -0000 > On Sep 19, 2018, at 5:17 PM, Tom Herbert wrote: >=20 > On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter > wrote: >> On 2018-09-20 01:56, Gorry Fairhurst wrote: >>>> On 19/09/2018 13:24, Christian Huitema wrote: >>>>=20 >>>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF wrote: >>>>>=20 >>>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm havin= g a really difficult time explaining to other people internally how a spin b= it that's not in the IP header, but is part of a mostly-encrypted transport h= eader, is better than putting something in an IP (extension? iOAM?) header t= hat would be transport-independent. >>>> The one advantage of the bit in transport header is that it is authenti= cated end to end. The other advantage is that it is automatically tied to a t= ransport flow and its five tuple. Then there is the reality that IP header b= its are commonly rewritten by a variety of middleboxes. >>>>=20 >>>> The downside is that different encrypted transports will most likely en= d up adopting different encodings and conventions. >>>>=20 >>>> But of course we could also repurpose one of the TOS bits >>> Do you mean the DSCP field? - That would sound like a very odd proposal.= >>=20 >> To be clear, there are no free bits in the DSCP field, there are only >> free codepoints in the 6-bit space. And of course since DSCP values >> explicitly act as a QoS request, they also implicitly change the >> one-way latency and therefore the RTT. So the DSCP bits would be >> remarkably bad as a tool for RTT measurement. >>=20 >> Brian C >>=20 >>>> or one of the flow header bits for the purpose, to mirror the transport= level bit. Mirror instead of replace: that would alleviate the need of pars= ing transport headers, but still allow end to end detection of IP header rew= riting. >=20 > Neither are there any flow label bits available. Re-purposing even a > single bit would adversely effect deployed use cases where flow label > is being used for packet steering or other purposes. Using the flow > label for packet marking was discussed in > https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01 OK. So basically, all the bits are taken for both v4 and v6. Spencer's origi= nal question why, should we put this kind of tracing bit in the transport he= ader or in the network header. In theory, there are some arguments for putti= ng common functions in the network header rather than in a variety of transp= ort headers. But in practice that would mean some kind of IP option, and tha= t's both more complicated and more error prone than reserving a bit in a tra= nsport header. -- Christian Huitema=20= From nobody Wed Sep 19 14:48:08 2018 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 A9753130E8B; Wed, 19 Sep 2018 14:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-SwDnbpFwsH; Wed, 19 Sep 2018 14:48:03 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98755130E02; Wed, 19 Sep 2018 14:48:03 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 42Ftl60h6fz8tTJ; Wed, 19 Sep 2018 23:48:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 42Ftl55dfsz5vN9; Wed, 19 Sep 2018 23:48:01 +0200 (CEST) Received: from [10.193.4.89] (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Sep 2018 23:48:01 +0200 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "Tom Herbert" , Brian E Carpenter CC: Gorry Fairhurst , tsvwg , "IETF IPPM WG" , Christian Huitema , "Spencer Dawkins at IETF" , IETF QUIC WG References: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> From: Message-ID: <4052_1537393681_5BA2C411_4052_19_1_32562795-59d1-eac3-743e-ef4fd320a738@orange.com> Date: Wed, 19 Sep 2018 23:46:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6DC3160CFA3F5B540B392832" Content-Language: fr-xx-moderne X-Originating-IP: [10.168.234.6] Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 21:48:07 -0000 --------------6DC3160CFA3F5B540B392832 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable We've spent some energy trying to get something from 1 bit indeed. The prob= lem=20 is twofold: =C2=A0(1) robustness to reordering =3D> only commutative things like unary= or average=20 (like 1-bit DACs) work =C2=A0(2) scarce outgoing flow =3D> as few as 2 ACKs per RTT happen =3D> m= ust spread the=20 info over a looong time if you're the receiver For an example with unary see the "E" bit in our 3-bit proposal (spin + 2 l= oss=20 bits) at page 15 of https://github.com/quicwg/wg-materials/blob/master/interim-18-09/Spin%20bit= %20and%20beyond%20%40%20Orange%20v1.pdf On 09/19/18 23:30, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > On the actual experiments: > > has there been any work on patterns on a single bit? At some point we=20 > discussed various signals including square wave, PI, and fractal gray cod= es. > > If privacy or space is a concern with 3 bits, perhaps a gray code could s= olve=20 > the same problem trading space for time. > > On 19 September 2018 at 23.18.25, Tom Herbert (tom@herbertland.com=20 > ) wrote: > >> On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter >> > wrote: >> > On 2018-09-20 01:56, Gorry Fairhurst wrote: >> >> On 19/09/2018 13:24, Christian Huitema wrote: >> >>> >> >>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF=20 >> > w= rote: >> >>>> >> >>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm ha= ving=20 >> a really difficult time explaining to other people internally how a spin= bit=20 >> that's not in the IP header, but is part of a mostly-encrypted transport= =20 >> header, is better than putting something in an IP (extension? iOAM?) hea= der=20 >> that would be transport-independent. >> >>> The one advantage of the bit in transport header is that it is=20 >> authenticated end to end. The other advantage is that it is automaticall= y=20 >> tied to a transport flow and its five tuple. Then there is the reality t= hat=20 >> IP header bits are commonly rewritten by a variety of middleboxes. >> >>> >> >>> The downside is that different encrypted transports will most likely= end=20 >> up adopting different encodings and conventions. >> >>> >> >>> But of course we could also repurpose one of the TOS bits >> >> Do you mean the DSCP field? - That would sound like a very odd propos= al. >> > >> > To be clear, there are no free bits in the DSCP field, there are only >> > free codepoints in the 6-bit space. And of course since DSCP values >> > explicitly act as a QoS request, they also implicitly change the >> > one-way latency and therefore the RTT. So the DSCP bits would be >> > remarkably bad as a tool for RTT measurement. >> > >> > Brian C >> > >> >>> or one of the flow header bits for the purpose, to mirror the transp= ort=20 >> level bit. Mirror instead of replace: that would alleviate the need of= =20 >> parsing transport headers, but still allow end to end detection of IP he= ader=20 >> rewriting. >> >> Neither are there any flow label bits available. Re-purposing even a >> single bit would adversely effect deployed use cases where flow label >> is being used for packet steering or other purposes. Using the flow >> label for packet marking was discussed in >> https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01 >> >> Tom >> >> >>> >> >>> -- Christian Huitema >> >> >> >> Gorry >> >> >> >> . >> >> >> > >> ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --------------6DC3160CFA3F5B540B392832 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
We've spent some energy trying to get something from 1 bit indeed. The problem is twofold:
=C2=A0(1) robustness to reordering =3D> only commutative things li= ke unary or average (like 1-bit DACs) work
=C2=A0(2) scarce outgoing flow =3D> as few as 2 ACKs per RTT happen =3D> must spread the info over a looong time if you're the receiver

For an example with unary see the "E" bit in our 3-bit proposal (spin + 2 loss bits) at page 15 of

https://github.com/quicwg/wg-materials/blob/master/interim-18-09/S= pin%20bit%20and%20beyond%20%40%20Orange%20v1.pdf

On 09/19/18 23:30, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
On the actual experiments:

has there been any work on patterns on a single bit? At some point we discussed various signals including square wave, PI, and fractal gray codes.

If privacy or space is a concern with 3 bits, perhaps a gray code could solve the same problem trading space for time.

On 19 September 2018 at 23.18.25, Tom Herbert (tom@herbertland.com) wrote:

On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 2018-09-20 01:56, Gorry Fairhurst wrote:
>> On 19/09/2018 13:24, Christian Huitema wrote:
>>>
>>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com&= gt; wrote:
>>>>
>>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm having a really difficult time explaining to other people internally how a spin bit that's not in the IP header, but is part of a mostly-encrypted transport header, is better than putting something in an IP (extension? iOAM?) header that would be transport-independent.
>>> The one advantage of the bit in transport header is that it is authenticated end to end. The other advantage is that it is automatically tied to a transport flow and its five tuple. Then there is the reality that IP header bits are commonly rewritten by a variety of middleboxes.
>>>
>>> The downside is that different encrypted transports will most likely end up adopting different encodings and conventions.
>>>
>>> But of course we could also repurpose one of the TOS bits
>> Do you mean the DSCP field? - That would sound like a very odd proposal.
>
> To be clear, there are no free bits in the DSCP field, there are only
> free codepoints in the 6-bit space. And of course since DSCP values
> explicitly act as a QoS request, they also implicitly change the
> one-way latency and therefore the RTT. So the DSCP bits would be
> remarkably bad as a tool for RTT measurement.
>
> Brian C
>
>>> or one of the flow header bits for the purpose, to mirror the transport level bit. Mirror instead of replace: that would alleviate the need of parsing transport headers, but still allow end to end detection of IP header rewriting.

Neither are there any flow label bits available. Re-purposing even a
single bit would adversely effect deployed use cases where flow label
is being used for packet steering or other purposes. Using the flow
label for packet marking was discussed in
https://tools.ietf.org/html/draft-= fioccola-spring-flow-label-alt-mark-01

Tom

>>>
>>> -- Christian Huitema
>>
>> Gorry
>>
>> .
>>
> 


____________________________________________________________________=
_____________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--------------6DC3160CFA3F5B540B392832-- From nobody Wed Sep 19 15:35:57 2018 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 D4D421286D9; Wed, 19 Sep 2018 15:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVACYZXbAeD7; Wed, 19 Sep 2018 15:35:42 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE20F124D68; Wed, 19 Sep 2018 15:35:41 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id w9-v6so212354pgc.12; Wed, 19 Sep 2018 15:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CEt44KBHBcz7L0wWS3aa3P6zKqU2iEQ4iOFFjA98kBg=; b=GI7lA+wEyajU6NaJ79OfTpEzrseWJxxKFIDDDzKxSjhMb7cwRYblPfeFoY2Xwy4ngD OHWK5IsCpOg7WISaXF6Orq9aiYMDUCpj+DSeoR5uNPrQ4Ouivw+OA/AUNrYeE0DbZed6 s+EdOwPMaalJ0ZDiqqVdhNlgggaFRLtsBwse9y4OiK6wrTcEBWf1xGJiJ7s4t6xhrXRG m8arW0HQ/fcP+Dgn1IgVllUCea7tS77DXzYP9BbvRc6rMU1QOlJhrSJmYgT2tDat1l4B yGREt8mfMrNcrt4DSH03DG8WWMz7uVxN6x760C1MR0mCQnbtYSWTm/R1LZRtP4Ptzk80 fngA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CEt44KBHBcz7L0wWS3aa3P6zKqU2iEQ4iOFFjA98kBg=; b=IkxvJKlbCZyW1GnUEZ7R3va1bSuOoEurv/IjjtA1iaQO9QgZ9F9OW7spTJE22MvfXP FCK1TPssCMDCJsBgXJUbUWJE4kzwlqp5jdJlvFjG1/PPP5WnK/AIlELxlJ1Vr9btBfmI HLV57PsX7EASyu4WZx3jOrdqZEDnv8TGWLFeBjDMK2mb91fNL44BSUme2t45DSyk9InN Oo/6rLjlNq+QMFFnSbjqwXWiw8+OmwIzVH1oiDtFaYhxzcTQXKv2WUpslQ2QwED9EKqs 3B74eoYGECZCZmRa+CYdLpdPdaO5U88zAOgwEb6sMnAc0+ISO1eTi7j27kJ+IRo5eH/D TtGg== X-Gm-Message-State: APzg51Dl9wH36h+MmmnmxMUdOJSJHHw9VFAHFfmPRfsNtqoQdK12x6EZ Ii+ymyDMdiRBjwv+m7Chrmbl6AjB X-Google-Smtp-Source: ANB0VdZ1VT/mO1tZAvhOc95FYYLHEXljCSAH4oxkRyH5SQbOMTr2f30HUkgTQuj0VWuUaNWlbd42sQ== X-Received: by 2002:a63:ec43:: with SMTP id r3-v6mr28014237pgj.295.1537396540953; Wed, 19 Sep 2018 15:35:40 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id p73-v6sm38945757pfk.186.2018.09.19.15.35.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 15:35:40 -0700 (PDT) To: Christian Huitema , Tom Herbert Cc: Gorry Fairhurst , Spencer Dawkins at IETF , IETF QUIC WG , tsvwg , IETF IPPM WG References: <4cc8764d-736b-5f54-0769-d26b98a8e2a3@erg.abdn.ac.uk> <5b05303b-317c-2405-9299-5aabeebe501d@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 20 Sep 2018 10:35:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ippm] [tsvwg] Why measure RTT passively? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 22:35:44 -0000 On 2018-09-20 09:42, Christian Huitema wrote: > >> On Sep 19, 2018, at 5:17 PM, Tom Herbert wrote: >> >> On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter >> wrote: >>> On 2018-09-20 01:56, Gorry Fairhurst wrote: >>>>> On 19/09/2018 13:24, Christian Huitema wrote: >>>>> >>>>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF wrote: >>>>>> >>>>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm having a really difficult time explaining to other people internally how a spin bit that's not in the IP header, but is part of a mostly-encrypted transport header, is better than putting something in an IP (extension? iOAM?) header that would be transport-independent. >>>>> The one advantage of the bit in transport header is that it is authenticated end to end. The other advantage is that it is automatically tied to a transport flow and its five tuple. Then there is the reality that IP header bits are commonly rewritten by a variety of middleboxes. >>>>> >>>>> The downside is that different encrypted transports will most likely end up adopting different encodings and conventions. >>>>> >>>>> But of course we could also repurpose one of the TOS bits >>>> Do you mean the DSCP field? - That would sound like a very odd proposal. >>> >>> To be clear, there are no free bits in the DSCP field, there are only >>> free codepoints in the 6-bit space. And of course since DSCP values >>> explicitly act as a QoS request, they also implicitly change the >>> one-way latency and therefore the RTT. So the DSCP bits would be >>> remarkably bad as a tool for RTT measurement. >>> >>> Brian C >>> >>>>> or one of the flow header bits for the purpose, to mirror the transport level bit. Mirror instead of replace: that would alleviate the need of parsing transport headers, but still allow end to end detection of IP header rewriting. >> >> Neither are there any flow label bits available. Re-purposing even a >> single bit would adversely effect deployed use cases where flow label >> is being used for packet steering or other purposes. Using the flow >> label for packet marking was discussed in >> https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01 > > OK. So basically, all the bits are taken for both v4 and v6. Spencer's original question why, should we put this kind of tracing bit in the transport header or in the network header. In theory, there are some arguments for putting common functions in the network header rather than in a variety of transport headers. But in practice that would mean some kind of IP option, and that's both more complicated and more error prone than reserving a bit in a transport header. I agree. The main references we have for this sort of thing turn out to be RFC3514 and RFC8136. Brian From nobody Mon Sep 24 14:53:46 2018 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 63F471310AC; Mon, 24 Sep 2018 14:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7lcIlmENVOk; Mon, 24 Sep 2018 14:53:43 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FC21310EF; Mon, 24 Sep 2018 14:53:42 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id d7-v6so14354702lfj.9; Mon, 24 Sep 2018 14:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OiT4S5dfRU7NWjFyaz/uvHouy+uz6i2l9VLjNvQQIzs=; b=Dzbn/AQnAYf4UZLbzVmlM03R7+dfPZENXfEsXrK4Dy6DYVqaNO0qf4N86qfVo50fD7 SfnB3nv/192NKGlBTN+ZFhRVqTamyM4/ciAyjWSVeBg+Y7MkDVfC3AeBtJNh7SFYa83G srhaOD6CliCtQq++KJf6+9UfQCKEYpqeSPQrFRLfJkXTuZLeIVuOvcbHYPsGjLH1yTBq 9uHVKONqNiXdcgeSSmD42PvUuyE2EugQr9Ay3LkTerJ8ordnsd2VJ6jZpiRtEbOX5GCP 4D+6SDAfr2w9TDQ61FkkH810usgKpPvj9E6+OfXkh2jzEBuvj57FE2EvFaTvqRh8Bvca eD3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OiT4S5dfRU7NWjFyaz/uvHouy+uz6i2l9VLjNvQQIzs=; b=oJ74EcwQRgNhyczkp8d+G/V7x3VXIzMTyWWM32LwHOrVpbr36MQjUw/0WphmVaZFRT l9jkX1abQU41CLGiOY6mwyqCEy3QBdra2Fn6uI5mq4QfgqQ15FRuNijYav2fj+ksJ/1U PhICknDXXmwyKf61drtoBQSJwO/0rgeOysQ+xUF3n5vJ0VCwEbDGnzFRva/M4tHN/NSh IbV4sGoj2xaS0GPZs9v36luKziHvH/UbSZUjQxGVptV3foSRbirnTUAQKhKYA9ZiPH3w Xn2liOfpwjtmSmdegrpF2oXHPOzoHkhwCWbG9bSurbRR4EKr/JmAtP1PJpzL7Ov385zP m5PA== X-Gm-Message-State: ABuFfoj7s5SHyNEd/4bNK2iI8WFKClf0M69yvzU6Tn55wQsCy0vgEg+7 cHOtZe85RZQ5/GZuX28X+eKFOJ16w1n/HyAA4a9vYA== X-Google-Smtp-Source: ACcGV61njDa+vmux2Tb4cwqcK2wgYf59jBJOm4i9kI98JgSV9f/Mk9a6kQRSYvlpwCoQe6Oqjq2Lqf99BFoPbHkxtlQ= X-Received: by 2002:a19:1346:: with SMTP id j67-v6mr488546lfi.93.1537826020364; Mon, 24 Sep 2018 14:53:40 -0700 (PDT) MIME-Version: 1.0 From: Greg Mirsky Date: Mon, 24 Sep 2018 14:53:27 -0700 Message-ID: To: IETF IPPM WG , NVO3 , Mirja Kuehlewind , Martin Vigoureux Content-Type: multipart/alternative; boundary="000000000000ab975d0576a50598" Archived-At: Subject: [ippm] iOAM drafts discussion at IPPM WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 24 Sep 2018 21:53:44 -0000 --000000000000ab975d0576a50598 Content-Type: text/plain; charset="UTF-8" Dear All, a number of drafts that define encapsulation of iOAM data for the various overlay networks had been presented and requested adoption by the IPPM WG. I have one scenario to discuss: - all proposed encapsulations of iOAM data use the field that explicitly indicates the type of the payload that immediately follows the overlay header. In all proposals iOAM data identified either as End-to-end iOAM or Hop-by-hop iOAM; - iOAM data uses its own shim that includes the Next Protocol field. The value of the Next protocol field identifies the type of the payload, the user payload; - now consider the situation when a node in the overlay network that doesn't support iOAM receives an iOAM data, i.e., doesn't recognize iOAM payload types. The node will drop the iOAM data and the user packet with it. If my analysis is correct, then here are a couple of questions: - how useful is the technology that requires an upgrade of the whole network in order to work; - should we return the discussion of iOAM data encapsulation in overlay networks to the WGs that define these overlay networks. Regards, Greg --000000000000ab975d0576a50598 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
a=C2=A0number of drafts that define encapsul= ation of iOAM data for=C2=A0the various overlay networks had been presented= and requested adoption by the IPPM WG. I have one scenario to discuss:
  • all proposed encapsulations of iOAM data use the field that = explicitly indicates the type of the payload that immediately follows the o= verlay header. In all proposals iOAM data identified either as End-to-end i= OAM or Hop-by-hop iOAM;
  • iOAM data uses its own shim that includes t= he Next Protocol field. The value of the Next protocol field identifies the= type of the payload, the user payload;
  • now consider the situation = when a node in the overlay network that doesn't support iOAM receives a= n iOAM data, i.e., doesn't recognize iOAM payload types. The node will = drop the iOAM data and the user packet with it.
If my analysis is = correct, then here are a couple of=C2=A0questions:
  • how us= eful is the technology that requires an upgrade of the whole network in ord= er to work;
  • should we return the discussion of iOAM data encapsulat= ion in overlay networks to the WGs that define these overlay networks.
    <= /li>
Regards,
Greg
--000000000000ab975d0576a50598-- From nobody Mon Sep 24 18:12:09 2018 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 AB1C71311B6; Mon, 24 Sep 2018 18:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_bZe4doC2pt; Mon, 24 Sep 2018 18:12:02 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80BF13115B; Mon, 24 Sep 2018 18:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6250; q=dns/txt; s=iport; t=1537837921; x=1539047521; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jHfOrcgaI15sTeLClB9RVi0BLmHIIoqnMz4dv2/Lc+0=; b=YW99dorogmctemj+icp8cw6Fn3xcg/AJtR0poO4cbAMLy8RLw1jvHGLp Nuu8tjcI95Ln0zOy0FbEghtEsJqi6EGIHhDMZAt7s+P0xRpF/DJPa5Z4Y Yblhspu0/jeGC6jNWpFMr/Uj06Mfp6VZ5CAUT0ITbRcb2xBKkh95gRoMc w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAAziqlb/5NdJa1bGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUYEXd4FkKAqDaogVjC6BaIkDiDWFPIF6C4RsAheDQiE0GAE?= =?us-ascii?q?DAQECAQECbSiFOQYjVhACAQg/AwICAh8RFBECBA4FgyGBHkwDFaN8gS6HOg2?= =?us-ascii?q?CUYp4F4FBP4ESJwwTgkyCVoIngwIxgiYCiHWEdYV1iHQsCQKJSINGgxkXgUW?= =?us-ascii?q?EUYkWjGeFOoJBAhEUgSUdOIFVcBVlAYJBPpAWb4wLgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,300,1534809600"; d="scan'208,217";a="176189494" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2018 01:12:00 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w8P1C0cL031698 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Sep 2018 01:12:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 24 Sep 2018 21:11:59 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1395.000; Mon, 24 Sep 2018 21:11:59 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: IETF IPPM WG , NVO3 , Mirja Kuehlewind , Martin Vigoureux Thread-Topic: [ippm] iOAM drafts discussion at IPPM WG Thread-Index: AQHUVFEbh0Za10G96E+WCerjLb1WLaUAc/CA Date: Tue, 25 Sep 2018 01:11:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.9.1) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.132] Content-Type: multipart/alternative; boundary="_000_D0EA9647F55E4476978A6751633CAB30ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.157, xch-rtp-017.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [ippm] iOAM drafts discussion at IPPM WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 01:12:04 -0000 --_000_D0EA9647F55E4476978A6751633CAB30ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBTZXAgMjQsIDIwMTgsIGF0IDU6NTMgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBn bWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCiAgKiAg IHNob3VsZCB3ZSByZXR1cm4gdGhlIGRpc2N1c3Npb24gb2YgaU9BTSBkYXRhIGVuY2Fwc3VsYXRp b24gaW4gb3ZlcmxheSBuZXR3b3JrcyB0byB0aGUgV0dzIHRoYXQgZGVmaW5lIHRoZXNlIG92ZXJs YXkgbmV0d29ya3MuDQoNCk5vLg0KDQpbYW5kIHdoYXQgd291bGQgYmUgdGhlIGludGVudGlvbiBv ZiB0aGlzIGRlY2lzaW9uLXJldmlzaXRpbmcgZXhlcmNpc2UsIGJlc2lkZXMgZGVsYXlpbmcgd29y ayBmb3Igd2hpY2ggdGhlcmUgaXMgYWxyZWFkeSBhbiBhZ3JlZWQgZm9yd2FyZCBwYXRoP10NCg0K ICAqICAgaG93IHVzZWZ1bCBpcyB0aGUgdGVjaG5vbG9neSB0aGF0IHJlcXVpcmVzIGFuIHVwZ3Jh ZGUgb2YgdGhlIHdob2xlIG5ldHdvcmsgaW4gb3JkZXIgdG8gd29yazsNCg0KSW4gdGhlc2UgZ2Vu ZXJhbCB0ZXJtcywgYXJlIHlvdSB0YWxraW5nIGFib3V0IElQdjY/IE9yIE1QTFMgTFNQIFBpbmc/ IE9yIEJJRVI/IE9yLi4uPw0KDQpbSGludDogc2FtZSBhbnN3ZXIgYXBwbGllc10NCg0KR3JlZzog cGxlYXNlIHNlYXJjaCBmb3Ig4oCcRGVwbG95bWVudCBjb25zaWRlcmF0aW9uc+KAnSBpbiBlYWNo IG9mIHRoZSBJT0FNIGRvY3VtZW50cy4NCg0KUmVnYXJkcywNCkdyZWcNCg0KDQpJIGhvcGUgYWxs IGlzIHdlbGwhDQoNCkJlc3QsDQoNCuKAlA0KQ2FybG9zIFBpZ25hdGFybywgY2FybG9zQGNpc2Nv LmNvbTxtYWlsdG86Y2FybG9zQGNpc2NvLmNvbT4NCg0K4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3 b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5k IG1vcmUgcGhvdG9zeW50aGVzaXMuIg0KDQo= --_000_D0EA9647F55E4476978A6751633CAB30ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1E376F345085B84F946BD8474FE0EA12@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDI0LCAyMDE4 LCBhdCA1OjUzIFBNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5 QGdtYWlsLmNvbSIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9IiI+DQo8bGkgY2xhc3M9IiI+ c2hvdWxkIHdlIHJldHVybiB0aGUgZGlzY3Vzc2lvbiBvZiBpT0FNIGRhdGEgZW5jYXBzdWxhdGlv biBpbiBvdmVybGF5IG5ldHdvcmtzIHRvIHRoZSBXR3MgdGhhdCBkZWZpbmUgdGhlc2Ugb3Zlcmxh eSBuZXR3b3Jrcy48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQpOby48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlthbmQgd2hh dCB3b3VsZCBiZSB0aGUgaW50ZW50aW9uIG9mIHRoaXMgZGVjaXNpb24tcmV2aXNpdGluZyBleGVy Y2lzZSwgYmVzaWRlcyBkZWxheWluZyB3b3JrIGZvciB3aGljaCB0aGVyZSBpcyBhbHJlYWR5IGFu IGFncmVlZCBmb3J3YXJkIHBhdGg/XTxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PHVsIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSIiPmhvdyB1c2VmdWwgaXMgdGhlIHRlY2hub2xvZ3kg dGhhdCByZXF1aXJlcyBhbiB1cGdyYWRlIG9mIHRoZSB3aG9sZSBuZXR3b3JrIGluIG9yZGVyIHRv IHdvcms7PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+SW4g dGhlc2UgZ2VuZXJhbCB0ZXJtcywgYXJlIHlvdSB0YWxraW5nIGFib3V0IElQdjY/IE9yIE1QTFMg TFNQIFBpbmc/IE9yIEJJRVI/IE9yLi4uPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+W0hpbnQ6IHNhbWUgYW5zd2VyIGFwcGxpZXNdPC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5HcmVnOiBwbGVhc2Ugc2VhcmNoIGZvciDigJxEZXBsb3ltZW50 IGNvbnNpZGVyYXRpb25z4oCdIGluIGVhY2ggb2YgdGhlIElPQU0gZG9jdW1lbnRzLjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5HcmVnPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi Pjwvc3Bhbj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQpJIGhvcGUgYWxsIGlzIHdlbGwhDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+QmVzdCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K4oCUPGJyIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25hdGFy bywmbmJzcDs8YSBocmVmPSJtYWlsdG86Y2FybG9zQGNpc2NvLmNvbSIgY2xhc3M9IiI+Y2FybG9z QGNpc2NvLmNvbTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8aSBjbGFzcz0iIj7i gJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFu ZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4mcXVvdDs8L2k+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvaT48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D0EA9647F55E4476978A6751633CAB30ciscocom_-- From nobody Tue Sep 25 00:29:44 2018 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 AC1A71311FF for ; Tue, 25 Sep 2018 00:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW_vPTwrHlge for ; Tue, 25 Sep 2018 00:29:39 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003033.outbound.protection.outlook.com [40.92.3.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE7E131229 for ; Tue, 25 Sep 2018 00:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pMs9qknnRmiImLNwzV0OzxfyeSo0N5+rrQvhfWPckf4=; b=Kb3q5jPkz5eDIUt2Woo1loL7thNN6kqeV6EZRmh4pwC4cDtDjNNqhJLGpZFvBEIGpt9j5yXpdNeu4r/erE5Yo4ioW4G619Kbz1EGYA/LfDoPx1NUKphwx63dbg7ksb3OIYSSuMFTT7yYZMm9omrNwO0+D5wA3keyFvliq6XR/V/e0WztzVqZmBH1wErwwG2x/A8tk9FQGzlMnX/jjy83lndkJ5Nlu+vJln+IYbvNugRp80xJreG0km19X9iMVZFcNI+8+UKa2Y+D1/gunSVyy1GwCKGnsl2WXMsfM3OSfFI2k04nTLzTH9thNqcTB59YLG2jrqiEY2gz+HdgcHzbNA== Received: from SN1NAM02FT007.eop-nam02.prod.protection.outlook.com (10.152.72.57) by SN1NAM02HT104.eop-nam02.prod.protection.outlook.com (10.152.73.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1185.13; Tue, 25 Sep 2018 07:29:37 +0000 Received: from DM6SPR01MB12.namprd15.prod.outlook.com (10.152.72.59) by SN1NAM02FT007.mail.protection.outlook.com (10.152.72.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1185.13 via Frontend Transport; Tue, 25 Sep 2018 07:29:37 +0000 Received: from DM6SPR01MB12.namprd15.prod.outlook.com ([fe80::dde3:f00d:6e8d:b880]) by DM6SPR01MB12.namprd15.prod.outlook.com ([fe80::dde3:f00d:6e8d:b880%4]) with mapi id 15.20.1164.024; Tue, 25 Sep 2018 07:29:37 +0000 From: Wenfei Wu To: "ippm@ietf.org" Thread-Topic: [SOSR 2019]: Call For Papers Thread-Index: AQHUVKGDU5jbi47QLkellPRAq1ROrg== Date: Tue, 25 Sep 2018 07:29:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:C42F224E87CAE0465F5A74E1E7672186A100D900FFFA237FC6CD44355E165550; UpperCasedChecksum:AE30818EB8CF4F2223D1C404806C776382BFF7180258AA87DE5FFCA871AE8DB0; SizeAsReceived:6816; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [bUstUuNeA+xHtgtzG6rZAnWkzNGa0jUh] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM02HT104; 6:l0r9frathrkNMVk/uRvIYqEKWbRCuhhtNwdQ0Ip8C3i/l1FBrDM8NBhtw2D9DeWdV9l1FeiBFPOtygubWYZbz3RauAy+XW8gGVroRduKEySpRrm0s39vgcNSvg4DhQnOAMME6CMLLsfOdW4YV2JpQmdHzZShgID50arTS+FqmbniJrX3QqEovpWZKeVz8oD79fdqBBiCyeI7SRHh8gYsalf4lyqBBWjj703HJ50GOD855EzhsSORr4jlA4iGgQoYT3c/tjeRQiqpFHwx28x1Wf8uGu4+RaYg6A+iZztwUJbjXk9fs+cfCKVvXvHOtxmshsnEUAevOtenfjiE/xbIAtUlqupMbxJTnSNMUa9yG5Qm1xOTu9VjchqgK+JIaBuNszfQVahSg46xsbdWqnibH7HCJ1qK3MXef7SQW7I3sudV7oAb08zoelmjvmltkDyllSTZx54+PSAq21HG0py9ww==; 5:rxTmowze72p9AU2wiOL694hhhrFh+A7AQrt7c6gA+LOONjn5r9jMZcMVTYJPR49FXbKh+52GrUldqgEDSohrnS+zRTZ3xDGSnO/kXj4W9sVbeJa6mjDufmhl+t/NuiH2tZmMW3egk7pbI+/LJHsQF/UftGQxuVnmmG/DmCq3UJE=; 7:lu9JhQR4tiJpCpu/xDqprJNxPxtOyQBWZM3z47FNKA91Abniqt/90NzULCBFnqBc0m7dn4eHA7YHKHMeVi6ineISTLWpvCVQ4eYoIeMehrjXsSu0mEYdV85Awg3vgvlJVrcnR0JPp1Y0c/yi/YSzJNP9adS7rf9Xp1PR/BYjn7IfNE/teabLY/icvwUJvF9kxo1lPSAAIodS+QZQ7uMS92piCsmOSjlG4D03/wRdYju0FO0doZt4MLmxQkil8ptX x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM02HT104; x-ms-traffictypediagnostic: SN1NAM02HT104: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM02HT104; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT104; x-forefront-prvs: 08062C429B x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(56003)(82202002)(26005)(6346003)(8676002)(426003)(6916009)(476003)(71190400001)(71200400001)(5660300001)(256004)(105004)(99286004)(5250100002)(104016004)(2900100001)(2501003)(7696005)(102836004)(86362001)(14454004)(68736007)(87572001)(54896002)(966005)(55016002)(6306002)(5640700003)(25786009)(413944005)(347745004)(97736004)(8936002)(19627405001)(2351001)(486006)(74316002)(106356001)(105586002)(20460500001)(81156014)(6436002)(1730700003)(33656002)(225293001); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT104; H:DM6SPR01MB12.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: outlook.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=wenfeiwu@outlook.com; x-microsoft-antispam-message-info: QtpVMEhjwZa+93wYNmhO7dOoUsP+4h8WjXRRylxlt/gUE1KX8/1LIY2YtLMb6ygBwizxUOcIDAMx1J+/D5DYzSfHLhbRZimJ28j7k5w9/eKc06ifnuwEQI4gyp+04zuYxlUwXoeTxRFY4cT9O+sUlbgB18e5oBCKPin3LKo3nabkoLNzBu9eTumhuLErXoXPZNmrS5gj3eZcjdQhWUzqjGSwESvIhOVDf2ZAL39HZnw= Content-Type: multipart/alternative; boundary="_000_DM6SPR01MB1287205D97B5ADE8D0B50AC8160DM6SPR01MB12namprd_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: b6587b75-6f1a-4db7-b0b6-5cad10ef59a7 X-MS-Exchange-CrossTenant-Network-Message-Id: 026c8ebb-8cd5-43c6-7ce3-08d622b8a614 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: b6587b75-6f1a-4db7-b0b6-5cad10ef59a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2018 07:29:37.4580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT104 Archived-At: Subject: [ippm] [SOSR 2019]: Call For Papers X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 07:29:43 -0000 --_000_DM6SPR01MB1287205D97B5ADE8D0B50AC8160DM6SPR01MB12namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleague, We cordially invite you to submit your papers/posters for the upcoming ACM = Symposium on SDN Research (SOSR) in 2019. The Symposium on SDN Research (SOSR) is the premiere venue for research pub= lications on SDN, building on past years' successful SOSR and HotSDN (Hot T= opics in Software Defined Networking) workshops. The ACM SOSR 2019 will be = held in San Jose, CA in April of 2019. Like previous years, SOSR will be he= ld at same time as the Open Networking Summit (ONS). We invite researchers and practitioners to submit both long and short previ= ously unpublished papers, choosing the length appropriate to the level of c= ompleteness and detail in the work. We particularly encourage position pape= rs, radical ideas, and papers on real applications and experiences of SDN. We also pleased to announce that we will again be giving out the SOSR Softw= are Systems Award at this year's SOSR, which recognizes software that has s= ignificantly impacted SDN. Conference Info: Abstracts due: November 8, 2018 (5pm PT) Paper submission: November 15, 2018 (5pm PT) Location: San Jose, CA, USA Conference Date: April, 2019 Website: https://conferences.sigcomm.org/sosr/2019/index.html Call for papers: https://conferences.sigcomm.org/sosr/2019/calls.html Regards, SOSR'19 Organizing Committee --_000_DM6SPR01MB1287205D97B5ADE8D0B50AC8160DM6SPR01MB12namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Colleague,

We cordially invite you to submit your papers/posters for the upcoming= ACM Symposium on SDN Research (SOSR) in 2019.

The Symposium on SDN Research (SOSR) is the premiere venue for researc= h publications on SDN, building on past years' successful SOSR and HotSDN (= Hot Topics in Software Defined Networking) workshops. The ACM SOSR 2019 wil= l be held in San Jose, CA in April of 2019. Like previous years, SOSR will be held at same time as the Open N= etworking Summit (ONS).

We invite researchers and practitioners to submit both long and short = previously unpublished papers, choosing the length appropriate to the level= of completeness and detail in the work. We particularly encourage position= papers, radical ideas, and papers on real applications and experiences of SDN.

We also pleased to announce that we will again be giving out the SOSR = Software Systems Award at this year's SOSR, which recognizes software that = has significantly impacted SDN.


Conference Info:
Abstracts due:    November 8, 2018 (5pm PT)
Paper submission:    November 15, 2018 (5pm PT)
Location: San Jose, CA, USA
Conference Date: April, 2019
Website: https://conferences.sigcomm.org/sosr/2019/index.html
Call for papers: https://conferences.sigcomm.org/sosr/2019/calls.html<= br>

Regards,
SOSR'19 Organizing Committee
--_000_DM6SPR01MB1287205D97B5ADE8D0B50AC8160DM6SPR01MB12namprd_--