From nobody Fri Nov 2 07:41:27 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF2D130DCE for ; Fri, 2 Nov 2018 07:41:25 -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 1CeLO_n0lUr1 for ; Fri, 2 Nov 2018 07:41:24 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 1FAF0130DC1 for ; Fri, 2 Nov 2018 07:41:23 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id x3-v6so1932509lji.13 for ; Fri, 02 Nov 2018 07:41:23 -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=laxkGtzjlTIM1MdV4vgpUzNG0ZuUK3j7zrgefVgayCc=; b=VD4Esy3NJvKJXCv03nlQ8KwTDbRouu+q8bopXa11oHjleiYYygbopuT7Hi+2VncDMJ luUBB2E/RIcfeodIujmr+/tb+SR2G+bIwmqvz1hDj8/zp0iam1BFiEQCbReJIXZg5jHU 4+ux9HTT3f7451PKBfXmat97BXSdK7qcuVhpuWUhJHMQNfVHL8zuChcJtnAcDWC8e6Ne 8l0XBC9PvMjUghynVZYyplkuQHLZ+fSTjaGDPvQs5CLKtEhwrVIrNnqh56tLSmZtRQPD aWe/+bmzw1ImvEseScFaDiGBOUozG1eayTNe5HPjYyMNW+/utPsSjfx7+JE9igL5Z6BP AinQ== 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=laxkGtzjlTIM1MdV4vgpUzNG0ZuUK3j7zrgefVgayCc=; b=dbd5zRD+Wy3QGzU2xLv9//nJpVcBAmgUU80lPC+sL1E/4Meu1ekNbru/X7FtVcQYU9 F3gUFGP3p0iZ4fgycgu2UeYisrQlQ7PNthy0BH6nn0vkOIA2qK1+CIkVIIt1PWQjFjgU yeqSgSGNl5ti27JAXelRo/3D4vIHxC+Pv8QH8pR9m12DFGPx1Ym4/06LAkHFI6JCVq3e 2m328HSC1KQ/kl85MRkB/SG/d/bqO37OAyqSGB1dRwqXH8gsma8sY4WVLoxSO8xn8Pb7 DGIgfQileea6dvomAIzAxMWRrxuHYH9YSpKc+EOmcmQKGZdTbscp6uJ10ZOThxN+dXPZ gasQ== X-Gm-Message-State: AGRZ1gJiOZIYkfkD/AIQQzlIi3uo2WTQG4327CkW/G97g9RJatOsERMb UgCcJMsYRQN17f1ftl5bifkBBZgqW2kupwmMaT4roso+ X-Google-Smtp-Source: AJdET5eaHEK5HZ64i/jvOXc5h+ae0bsA+B7AdY8sjihrf0vxRIFgLltc47Amc69PLzLMJzFv8zzTasN3y+WLqAjvGxQ= X-Received: by 2002:a2e:95c6:: with SMTP id y6-v6mr7643885ljh.59.1541169679628; Fri, 02 Nov 2018 07:41:19 -0700 (PDT) MIME-Version: 1.0 From: Piers Powlesland Date: Fri, 2 Nov 2018 14:41:08 +0000 Message-ID: To: din@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 14:41:26 -0000 I think it may be possible to improve the chances of nodes being able to accept ballots as committed during the prepare phase. The following instructions are given to update cCounter. > * If either "(prepared > c && prepared.value != c.value)" or > "(preparedPrime > c && preparedPrime.value != c.value)", then > reset "c = NULL". > > * If "c == NULL" and "hCounter == ballot.counter" (meaning > "ballot" is confirmed prepared), then set "c" to "ballot". If we consider an example where a node has the following state. ballot = (8,x) prepared = (8,x) preparedPrime = (3,y) cCounter = 4 hCounter = 8 If the node accepts prepared (4,z) then using the update steps above c will be set to NULL and then c will be set to ballot. This means that the node will transition from voting to commit ballots with value == x and counters 4...8 to just the single ballot (8,x). Out of the ballots that the node was previously voting to commit only (4,x) has been accepted aborted due to setting preparedPrime = (4,z), so it seems that it would still be legal to vote to commit ballots with value == x and counters 5...8. So I am proposing that the first part of the above update step is changed to the following, to allow for that. > * If c != NULL set c.counter to the counter of the lowest ballot with value == > h.value and not accepted aborted according to p and p'. If c.counter > > hCounter, then set c=NULL From nobody Fri Nov 2 07:59:53 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E61E12785F for ; Fri, 2 Nov 2018 07:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 0_dZ6d9IBzTw for ; Fri, 2 Nov 2018 07:59:50 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 29E941294D7 for ; Fri, 2 Nov 2018 07:59:50 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.29/8.16.0.21) with ESMTP id wA2ExmW4061271; Fri, 2 Nov 2018 07:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1541170788; bh=jAjUAuQheXoYqh3+fq0S4IecS99jGBd9UIwFysA+kfk=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=j4L3J7qnSBuNvp8qUStnf/u/szxEFR0pvGGrR0NKZmxnoZ94m7HZNyF1Ce7iDZhgC jo+YZNCadaeLxYbQFZfA0cb5g/m4heNrpqX6zuhwXEwTlWkzhW+4pxflKLYPKKF1Qp qKPSI+nQSmTkXYKTDSeT9tjPNZ2KoMUdIm2LzxU8= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.29/8.16.0.29/Submit) id wA2ExmkN015649; Fri, 2 Nov 2018 07:59:48 -0700 (PDT) From: David Mazieres To: Piers Powlesland , din@irtf.org In-Reply-To: References: Reply-To: David Mazieres expires 2019-01-31 PST Date: Fri, 02 Nov 2018 07:59:48 -0700 Message-ID: <87va5fsexn.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 14:59:52 -0000 Piers Powlesland writes: > I think it may be possible to improve the chances of nodes being able > to accept ballots as committed during the prepare phase. > > The following instructions are given to update cCounter. > >> * If either "(prepared > c && prepared.value != c.value)" or >> "(preparedPrime > c && preparedPrime.value != c.value)", then >> reset "c = NULL". >> >> * If "c == NULL" and "hCounter == ballot.counter" (meaning >> "ballot" is confirmed prepared), then set "c" to "ballot". > > > If we consider an example where a node has the following state. > > ballot = (8,x) > prepared = (8,x) > preparedPrime = (3,y) > cCounter = 4 > hCounter = 8 > > If the node accepts prepared (4,z) then using the update steps above c > will be set to NULL and then c will be set to ballot. That's correct. This is because the messages only encode cCounter instead of c. Since c.value is implicit, you don't want to vote to commit the wrong ballot. (In fact, I will change preparedPrime to be preparedPrimeCounter in the next version, too.) > This means that the node will transition from voting to commit ballots > with value == x and counters 4...8 to just the single ballot (8,x). You mean transition to voting to commit nothing? (Though still vote-or-confirm (n,x) for 4 <= n <= 8.) > Out of the ballots that the node was previously voting to commit only > (4,x) has been accepted aborted due to setting preparedPrime = (4,z), > so it seems that it would still be legal to vote to commit ballots > with value == x and counters 5...8. Not necessarily. Whether or not it's safe to commit (5,x) depends on history. It's only safe to vote to commit a ballot b if ballot == b at the time b was confirmed prepared. If, for instance, hCounter jumps from 0 to 8 in the history, then the node has no memory of whether it is, say voted to prepare (4,z), which would make it illegal to vote to commit (4,x). > So I am proposing that the first part of the above update step is > changed to the following, to allow for that. > >> * If c != NULL set c.counter to the counter of the lowest ballot with value == >> h.value and not accepted aborted according to p and p'. If c.counter > >> hCounter, then set c=NULL To be correct, you might also need to raise h such that you've never voted to abort anything between h and the new c, but I don't think nodes have enough state to do that. So the current algorithm is safe but "wasteful" of potentially useful ballots. David From nobody Fri Nov 2 10:38:38 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1354126DBF for ; Fri, 2 Nov 2018 10:38:37 -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 NiXA_JznGXH2 for ; Fri, 2 Nov 2018 10:38:35 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 763191252B7 for ; Fri, 2 Nov 2018 10:38:35 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id u6-v6so2468996ljd.1 for ; Fri, 02 Nov 2018 10:38:35 -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=35cdMl7D75bEaoyfA+laszA1rlvJsATP4ImYYkzwiH0=; b=MrALNpQl6cEafq6OdIp+AUqYrBYuyEfZPuTPT0N3loX2rKAn2nixm/89ZGwWgdTn5Q aAGcyzbHaMcJKmBJucwUlVFEvd3neJMY+UQjoGsxrzbLseiZCjMYegj8icWjXQoxnlje yRskacNldqQH+TPvdurKZOdOaDhV57ocvJn57+9AyNRgS0ej8dN7gOPVmSxbKGLgQEMK EKDQ7hYvWB/yiq17F+2JqtNVBON/W7jd1bUIEvDBIIMAGpj2BTgsUSvxdZDtJh3qoRzv 69nH7iz4882JfI8EKboNhRQfubGEbE7k/805KIFXnm787Mp+cziUjyuQRmLg1z0SVisu cs8Q== 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=35cdMl7D75bEaoyfA+laszA1rlvJsATP4ImYYkzwiH0=; b=j7mBdsRKhgbLQNAna9Kce4aLA0kJ9Auq31zWq9+iT2G8OEUls6RbmMoWXeZRPz9qm8 vY3tJFssGWM++8eO2EJ16xkVW0lKHiQpW5uEA+eHxgKjASbdYV5ydTmWC1nWZYnu+sTh 4WaTkqOU9EIPG6RwOMbI+zLsJgRi7wuS7LLgMtHAvG1Obtnxi8mnhxWzLQrJuW32Gt97 uSa09XuyfdRXgeyopyJEQXIx5Io09dQVq5OnDt48qKPNA+6oceZA7sVj/emLaGnMkmla NLuNoaW6oS/WGz0QJ4jKJ9X39KNhX3Req7M3keNncP50ONSR3jziDtK1decSGdI+PkHB H7JA== X-Gm-Message-State: AGRZ1gJ9xotSqO7VFO/WLB94+gkE93j/cEHsBYKXWfGChZEkCTaM3xuu qeKdileyK6LRYJbW3MaijrVtjHyAWzk40GWgKP+2GNgs X-Google-Smtp-Source: AJdET5e9ceWdrFV+FWFKjKeaZ7Zwf+AMK3SFJAkp7jBl0UdElAotuyEjh6BPw2Tom8Pw3BnXUjOKhcksF/AiMkF06/o= X-Received: by 2002:a2e:9e10:: with SMTP id e16-v6mr8271987ljk.169.1541180313333; Fri, 02 Nov 2018 10:38:33 -0700 (PDT) MIME-Version: 1.0 References: <87va5fsexn.fsf@ta.scs.stanford.edu> In-Reply-To: <87va5fsexn.fsf@ta.scs.stanford.edu> From: Piers Powlesland Date: Fri, 2 Nov 2018 17:38:21 +0000 Message-ID: To: mazieres-z84dy9p9kp8ehixwsvr9w28cns@temporary-address.scs.stanford.edu Cc: din@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 17:38:38 -0000 I have a few things I'm not clear on. I don't see that this statement is correct. >You mean transition to voting to commit nothing? (Though still >vote-or-confirm (n,x) for 4 <= n <= 8.) So following the update steps for c, first the c will be set to NULL and then the next step will be executed. > * If "c == NULL" and "hCounter == ballot.counter" (meaning > "ballot" is confirmed prepared), then set "c" to "ballot". Resulting in the following node state. ballot = (8,x) prepared = (8,x) preparedPrime = (4,z) cCounter = 8 hCounter = 8 Which as described in the IETF document would I think means the node now is voting to commit(8,x) ? > * If "cCounter != 0": "vote commit()" for every "cCounter <= n <= hCounter" Also what is "vote-or-confirm" ? >> Out of the ballots that the node was previously voting to commit only >> (4,x) has been accepted aborted due to setting preparedPrime = (4,z), >> so it seems that it would still be legal to vote to commit ballots >> with value == x and counters 5...8. > >Not necessarily. Whether or not it's safe to commit (5,x) depends on >history. It's only safe to vote to commit a ballot b if ballot == b at >the time b was confirmed prepared. If, for instance, hCounter jumps >from 0 to 8 in the history, then the node has no memory of whether it >is, say voted to prepare (4,z), which would make it illegal to vote to >commit (4,x). I can imagine the following scenario that seems to be allowable via the IETF update rules that would allow a node to illegally vote for a range of ballots that the node has never set its ballot equal to. The node starts with the following state. It is currently voting to commit(2,x) among other things. ballot =(2,x) prepared =(2,x) preparedPrime =(1,y) cCounter =2 hCounter =2 Now we see blocking threshold for accept prepare(8,x) ballot =(8,x) // ballot.counter was also updated by the blocking threshold. prepared =(8,x) preparedPrime =(1,y) cCounter =2 hCounter =8 Now we see quorum threshold for accept prepare(8,x) (we have confirmed prepared (8,x) and h.value == b.value so we set hCounter to 8) ballot =(8,x) prepared =(8,x) preparedPrime =(1,y) cCounter =2 hCounter =8 So now we are voting to commit, 2...8 with value == x but ballot has never been set to a ballot with counter 3...7 and value == x. Doesn't this make it illegal to vote to commit (3,x)...(7,x)? On Fri, Nov 2, 2018 at 2:59 PM David Mazieres wrote: > > Piers Powlesland writes: > > > I think it may be possible to improve the chances of nodes being able > > to accept ballots as committed during the prepare phase. > > > > The following instructions are given to update cCounter. > > > >> * If either "(prepared > c && prepared.value != c.value)" or > >> "(preparedPrime > c && preparedPrime.value != c.value)", then > >> reset "c = NULL". > >> > >> * If "c == NULL" and "hCounter == ballot.counter" (meaning > >> "ballot" is confirmed prepared), then set "c" to "ballot". > > > > > > If we consider an example where a node has the following state. > > > > ballot = (8,x) > > prepared = (8,x) > > preparedPrime = (3,y) > > cCounter = 4 > > hCounter = 8 > > > > If the node accepts prepared (4,z) then using the update steps above c > > will be set to NULL and then c will be set to ballot. > > That's correct. This is because the messages only encode cCounter > instead of c. Since c.value is implicit, you don't want to vote to > commit the wrong ballot. (In fact, I will change preparedPrime to be > preparedPrimeCounter in the next version, too.) > > > This means that the node will transition from voting to commit ballots > > with value == x and counters 4...8 to just the single ballot (8,x). > > You mean transition to voting to commit nothing? (Though still > vote-or-confirm (n,x) for 4 <= n <= 8.) > > > Out of the ballots that the node was previously voting to commit only > > (4,x) has been accepted aborted due to setting preparedPrime = (4,z), > > so it seems that it would still be legal to vote to commit ballots > > with value == x and counters 5...8. > > Not necessarily. Whether or not it's safe to commit (5,x) depends on > history. It's only safe to vote to commit a ballot b if ballot == b at > the time b was confirmed prepared. If, for instance, hCounter jumps > from 0 to 8 in the history, then the node has no memory of whether it > is, say voted to prepare (4,z), which would make it illegal to vote to > commit (4,x). > > > So I am proposing that the first part of the above update step is > > changed to the following, to allow for that. > > > >> * If c != NULL set c.counter to the counter of the lowest ballot with value == > >> h.value and not accepted aborted according to p and p'. If c.counter > > >> hCounter, then set c=NULL > > To be correct, you might also need to raise h such that you've never > voted to abort anything between h and the new c, but I don't think nodes > have enough state to do that. So the current algorithm is safe but > "wasteful" of potentially useful ballots. > > David From nobody Sat Nov 3 00:22:25 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C171127332 for ; Sat, 3 Nov 2018 00:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 bzj3vVe1UJ8L for ; Sat, 3 Nov 2018 00:22:21 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 C3495124BE5 for ; Sat, 3 Nov 2018 00:22:21 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.29/8.16.0.21) with ESMTP id wA37MKen049401; Sat, 3 Nov 2018 00:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1541229740; bh=U7vjEeEF922k0Sqn8IXaaeX3WLXqdsZ+yVQS7EuusaY=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=g7/OTTjgaZmkYNx679i7ficS3+OSxMQF5nUUXhSXdgcv5/AYHmbsz6kll37qYGn41 Y3TrR1NOKCMK9KLlsYOx4z0PwMbUfoYLKbrb5gCmUnsB/xqvlRS4kP1Xp8HupwuxZF /29GtFhlftMtziJRM/DbTgo4MpClFXN2ITO0z3JQ= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.29/8.16.0.29/Submit) id wA37MKEX043594; Sat, 3 Nov 2018 00:22:20 -0700 (PDT) From: David Mazieres To: Piers Powlesland Cc: din@irtf.org In-Reply-To: References: <87va5fsexn.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2019-01-31 PST Date: Sat, 03 Nov 2018 00:22:19 -0700 Message-ID: <875zxezkus.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 07:22:23 -0000 Piers Powlesland writes: > I have a few things I'm not clear on. > > I don't see that this statement is correct. > >>You mean transition to voting to commit nothing? (Though still >>vote-or-confirm (n,x) for 4 <= n <= 8.) > > So following the update steps for c, first the c will be set to NULL > and then the next step will be executed. > >> * If "c == NULL" and "hCounter == ballot.counter" (meaning >> "ballot" is confirmed prepared), then set "c" to "ballot". > > Resulting in the following node state. > > ballot = (8,x) > prepared = (8,x) > preparedPrime = (4,z) > cCounter = 8 > hCounter = 8 > > Which as described in the IETF document would I think means the node > now is voting to commit(8,x) ? Oh, yes, sorry. But importantly you are no longer voting to commit (5,x) and (6,x). >> * If "cCounter != 0": "vote commit()" for every "cCounter <= n <= hCounter" > > Also what is "vote-or-confirm" ? Sorry, another mistake on my part. I meant vote-or-accept. > I can imagine the following scenario that seems to be allowable via > the IETF update rules that would allow a node to illegally vote for a > range of ballots that the node has never set its ballot equal to. > > The node starts with the following state. It is currently voting to > commit(2,x) among other things. > > ballot =(2,x) > prepared =(2,x) > preparedPrime =(1,y) > cCounter =2 > hCounter =2 > > Now we see blocking threshold for accept prepare(8,x) > > ballot =(8,x) // ballot.counter was also updated by the blocking threshold. > prepared =(8,x) > preparedPrime =(1,y) > cCounter =2 > hCounter =8 > > Now we see quorum threshold for accept prepare(8,x) (we have confirmed > prepared (8,x) and h.value == b.value so we set hCounter to 8) > > ballot =(8,x) > prepared =(8,x) > preparedPrime =(1,y) > cCounter =2 > hCounter =8 Sorry, what's the difference between this and above? I'm assuming you meant hCounter=2 above, and hCounter=8 here. > So now we are voting to commit, 2...8 with value == x but ballot has > never been set to a ballot with counter 3...7 and value == x. Doesn't > this make it illegal to vote to commit (3,x)...(7,x)? No, that's okay. The thing we actually need to avoid is voting to abort and commit the same ballot b. In this case that's fine because you never voted to abort any of (3,x)...(7,x). The protocol could of course keep track of very vote you have ever cast to make sure this is okay. Instead, to keep the state small, it uses the trick that you reset c to 0 whenever the ballot might contain a new value, and then you have to set c to the current ballot number, because the (conservative) assumption is that if c == 0, then you might have voted to abort any ballot less than the current ballot. Does that make sense? Maybe some of this rationale needs to go into the document... David From nobody Sun Nov 4 19:19:30 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1B130EB9 for ; Sun, 4 Nov 2018 19:19:23 -0800 (PST) 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] 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 1mHR5X236uC8 for ; Sun, 4 Nov 2018 19:19:22 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 9D73D130E93 for ; Sun, 4 Nov 2018 19:19:21 -0800 (PST) Received: from [31.133.129.25] ([31.133.129.25]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1N332D-1fXpsJ0pCv-013LFD; Mon, 05 Nov 2018 04:19:18 +0100 Received: from [31.133.129.25] ([31.133.129.25]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1N332D-1fXpsJ0pCv-013LFD; Mon, 05 Nov 2018 04:19:18 +0100 From: "Dirk Kutscher" To: din@irtf.org Cc: "Melinda Shore" Date: Mon, 05 Nov 2018 04:19:14 +0100 X-Mailer: MailMate (1.12.1r5552) Message-ID: <71CDEF3A-C9AF-4D19-ACD4-7EF154CA3AA9@dkutscher.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:x1W0QvInjKHPYSAC8t4BgouY4Hk8JlL4Ml8baqKELyt9IGAyKCA dehdq9XrGPpH/Jj2NkI4Yq1mBVkWeSoeoZgYaA97ifqxUmA6iUXYJhEaE9xpkiGlz7EbcTG utvVyx9EzBImL1VDNRn5B3Hk0hHppEpIc0S/KmMq2M1yiPRkb3vX09OeCcAXnYBHHm5Pp09 hcyvAUF0q5ZfQOJqUpnHg== X-UI-Out-Filterresults: notjunk:1;V01:K0:L8cLCUXGW9A=:ssrF+xYnHB6IwYqsF3t5pg v4gc+dl0paQrsZL9jyWnHpaEJ7mpGUQuLcU4rvPTQuyYXomFAFyFJwtySEIngcSom/Mjmw/Q3 Y3zETj3Gfbcj/gD/8s6X4X1wvC/+A7Z7hanXnm6W5sNmxuotglKaBVK1oy2kXVL+gXtXZeDUr VFBQQShq4AVTIlh1pArHS+K3M+Hgv7ZgYIqfIMXh0N1/hP772f/QSwty/N/RrYtoG3DQSmEA8 B+I17YEIutwJXK8y4+FnPNoBpJUM6GFBj/c/ZfmyDt2Ubvacxwctzs2eej8TMfULMV2b5k7Fu dqe5J4q0ljcX/NcwloL5zQfbS8KuMph6owWp8hWpjGUgl+OnNobmZoyGbSZdP/+0coLnxRYiG JR4fRTwOhrqoF4ovSl9jsS2rXTQoSuLTJrTwSsmitrhm6syL2nchBovkkkWGcyIo2EDhwE5I+ YcC73E/FV+nFA+vsZ1FmbGva1Y+uKwsUu0EVzHEf/+u8VMk8GRV9bi/eOYEudqhgaQzTfM1IN ME1gbL9NnIaqicFMyqDSXJUKqlPEpDczC7rW1zt6usCgMrfpxi3YXrsqWOnmmzQ4Fcu5NhOFS NlTPoB7kQvEtIWhLrPEmMMlU0gBZTQgd1uxhv9gFpRP9znY75jqPqvPuLUOOWBLl0RsuG32/q ZCUcai220qmLgWh/DVFL7ExnNuRD+vX7Z6AiaRyMN+tZ8afgJBZpTNxLqRvz2P9XB4u0ZNQdP G9KmQPC+VTD4EPg4/mMsaa0b4auexO2a9LY+Cmousrrju3lyakh97VCHsARvdqRGr+CzXxTXI QWG6bg0MoPi7VIL9FwdDohnKJaGsg== Archived-At: Subject: [Din] please send presentations for DINRG sessions X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 03:19:29 -0000 Dear presenters at Tuesday’s DINRG meeting, Please send us your presentation material today so that we can upload it to the system. We’ll have some people attending remotely — it’ll make it much easier for them if they can access the slides… Thanks, Melinda & Dirk From nobody Thu Nov 8 04:30:34 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E9F128A5C for ; Thu, 8 Nov 2018 04:30:33 -0800 (PST) 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=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 B7Tua_-zUumN for ; Thu, 8 Nov 2018 04:30:31 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 B940312D4E8 for ; Thu, 8 Nov 2018 04:30:30 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id i26so14050591lfc.0 for ; Thu, 08 Nov 2018 04:30:30 -0800 (PST) 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=p7T3tzYL8Nn0KuphjC+WdMmww9HBkun9ijOKGceKEIM=; b=NNssBlXRFzcN9Q55BQp3y31eDHFzI4By5FwftROlrU2IUgzE41jV0UYpeH7jI5jBd8 BPoeAXb0CtoUd67P3gK2XBYG55FWRhYq/JxcUtyHqt5glp9/p+R1JIIA6IKyERoVAmDl VlAGCUG0rgYm/AS8N5ucs/hKlqU60gJDc1W4owyqtpFBTX1i3C+Xd6Mq6V7JofaqFIRG O6LY0ogVNBqb33P0eFjj0c005sFrNlph0d3QLqRwkVsa2/RXkiB16+Fbl3eGzIH0jaan ZEWOODg12KzVOykpSL+VFOkcncc9cmHOQ/Ppotrz0mqNcHrzN/riY8ejFewe12gQClRV ip+w== 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=p7T3tzYL8Nn0KuphjC+WdMmww9HBkun9ijOKGceKEIM=; b=EyshUAS8t0AG1+IhG+oNxWPEgzq0LEMUaHt2hOjeF3MnNZ5oZRVBxBVIhCNQ6n1bKZ XDN4+pyTqalzQ+DsQLFHxFV0UkrxgjcrNUjoc841u77KPsm1k/jxr0MRMHsS3tM7oZvL WsPNBylMWiPCye5ZlliT6cNiVzgFuBuuERteXphVyYj2L1D+SZ2PRNb9ptJqlqg17lQM DgOUpVJIsug+ifacp41jgiJJxVfkIBukYG2TSOWzFUdX/XH+YpC51XxxyU4PVQNBCkc6 z97TjIXk6GFDPmW54xYRTmi/LGwqcn+kKS68cS10nFRk3NIsqv+zrfvKFY997HA/ywq/ ht1w== X-Gm-Message-State: AGRZ1gI0CPqywm9K4T300g9Sfa3/7NuWn7L+WrUYlBYNbvpn+1C4m4IR 8UodG1ziwrqNMdZhxM0N3lxL8ZwkcOSOiXqqYsLoSqo/ X-Google-Smtp-Source: AJdET5cKsi9j9juDrMNyjnPZjbul4eC875KYt5oARVh2Dch4uSpc16VmSxPAsxrQyRswfnv3vkDwcwKd10US3j3h4nY= X-Received: by 2002:a19:7111:: with SMTP id m17mr2587761lfc.64.1541680228495; Thu, 08 Nov 2018 04:30:28 -0800 (PST) MIME-Version: 1.0 References: <87va5fsexn.fsf@ta.scs.stanford.edu> <875zxezkus.fsf@ta.scs.stanford.edu> In-Reply-To: <875zxezkus.fsf@ta.scs.stanford.edu> From: Piers Powlesland Date: Thu, 8 Nov 2018 12:30:17 +0000 Message-ID: To: mazieres-upwjsxfjp64x9ptkyhebxjqata@temporary-address.scs.stanford.edu Cc: din@irtf.org Content-Type: multipart/alternative; boundary="000000000000608a27057a26663c" Archived-At: Subject: Re: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 12:30:33 -0000 --000000000000608a27057a26663c Content-Type: text/plain; charset="UTF-8" Yes I did mix up the hCounters in my example, your interpretation was correct. Your last explanation does make sense but seems to be at odds with your previous statement which confused me. >It's only safe to vote to commit a ballot b if >ballot == b at the time b was confirmed prepared I think that statement is too strict, since it precludes voting to commit ballots (3,x)...(7,x) from my previous example. In fact I think this statement would be correct if it is describing the point at which a node starts voting to commit a ballot. (I.E when c changes from NULL to some integer) So instead we can say it is only safe to vote to commit a ballot if the ballot has been confirmed prepared and we have not voted or accepted abort for it. So put simply, my original suggestion, was to modify the algorithm to vote to commit all confirmed prepared ballots that have not been voted or accepted aborted. I see that my proposed update step doesn't quite achieve that, since as you pointed out it might set c such that we are voting to commit a ballot that we previously voted to abort. I've modified the update step again, I think this would work correctly. Replacing the first update step for c with the following three steps. > * If "c != NULL" and "(preparedPrime > c && preparedPrime.value != c.value)" > raise c.counter to the lowest value such that c > preparedPrime. > > * If "c != NULL" and "(prepared > c && prepared.value != c.value)" > raise c.counter to the lowest value such that c > prepared. > > * If c.counter > hCounter then reset "c = NULL" We can see that this update step precludes voting to commit and voting to abort the same ballot. Since when c != NULL we know that a ballot has been confirmed prepared (we know this because c cannot be set unless hCounter is set and hCounter represents a confirmed prepared ballot). Given that a ballot has been confirmed prepared, we know nomination has stopped, so the only way that this node can change it's ballot.value is to accept an incompatible *higher* ballot prepared via blocking threshold and then confirm it, the next time ballot.counter changes ballot.value will take the value of the newly confirmed prepared ballot. So we can see that given a state where cCounter and hCounter have been set, it is impossible to vote to abort any ballot we are currently voting to commit without first accepting it prepared and when it is accepted prepared c will be updated to ensure that we are no longer voting to commit that ballot. So the full set of update steps for c would then be. > * If "c != NULL" and "(preparedPrime > c && preparedPrime.value != c.value)" > raise c.counter to the lowest value such that c > preparedPrime. > > * If "c != NULL" and "(prepared > c && prepared.value != c.value)" > raise c.counter to the lowest value such that c > prepared. > > * If c.counter > hCounter then reset "c = NULL" > > * If "c == NULL" and "hCounter == ballot.counter" (meaning > "ballot" is confirmed prepared), then set "c" to "ballot". I hope that makes sense. And yes I think putting this rationale into the document would make it much easier to understand. The way the algorithm is presented currently gives you a lot of isolated update steps but it is not clear how they are linked to each other and it is even less clear why they are as they are. For myself at least it would have been really useful to see a derivation of sorts from the high level concepts behind the protocol to the very compact form in which the protocol is specified in the IETF document. On Sat, 3 Nov 2018, 07:22 David Mazieres Piers Powlesland writes: > > > I have a few things I'm not clear on. > > > > I don't see that this statement is correct. > > > >>You mean transition to voting to commit nothing? (Though still > >>vote-or-confirm (n,x) for 4 <= n <= 8.) > > > > So following the update steps for c, first the c will be set to NULL > > and then the next step will be executed. > > > >> * If "c == NULL" and "hCounter == ballot.counter" (meaning > >> "ballot" is confirmed prepared), then set "c" to "ballot". > > > > Resulting in the following node state. > > > > ballot = (8,x) > > prepared = (8,x) > > preparedPrime = (4,z) > > cCounter = 8 > > hCounter = 8 > > > > Which as described in the IETF document would I think means the node > > now is voting to commit(8,x) ? > > Oh, yes, sorry. But importantly you are no longer voting to commit > (5,x) and (6,x). > > >> * If "cCounter != 0": "vote commit()" for every > "cCounter <= n <= hCounter" > > > > Also what is "vote-or-confirm" ? > > Sorry, another mistake on my part. I meant vote-or-accept. > > > I can imagine the following scenario that seems to be allowable via > > the IETF update rules that would allow a node to illegally vote for a > > range of ballots that the node has never set its ballot equal to. > > > > The node starts with the following state. It is currently voting to > > commit(2,x) among other things. > > > > ballot =(2,x) > > prepared =(2,x) > > preparedPrime =(1,y) > > cCounter =2 > > hCounter =2 > > > > Now we see blocking threshold for accept prepare(8,x) > > > > ballot =(8,x) // ballot.counter was also updated by the blocking > threshold. > > prepared =(8,x) > > preparedPrime =(1,y) > > cCounter =2 > > hCounter =8 > > > > Now we see quorum threshold for accept prepare(8,x) (we have confirmed > > prepared (8,x) and h.value == b.value so we set hCounter to 8) > > > > ballot =(8,x) > > prepared =(8,x) > > preparedPrime =(1,y) > > cCounter =2 > > hCounter =8 > > Sorry, what's the difference between this and above? I'm assuming you > meant hCounter=2 above, and hCounter=8 here. > > > So now we are voting to commit, 2...8 with value == x but ballot has > > never been set to a ballot with counter 3...7 and value == x. Doesn't > > this make it illegal to vote to commit (3,x)...(7,x)? > > No, that's okay. The thing we actually need to avoid is voting to abort > and commit the same ballot b. In this case that's fine because you > never voted to abort any of (3,x)...(7,x). The protocol could of course > keep track of very vote you have ever cast to make sure this is okay. > Instead, to keep the state small, it uses the trick that you reset c to > 0 whenever the ballot might contain a new value, and then you have to > set c to the current ballot number, because the (conservative) > assumption is that if c == 0, then you might have voted to abort any > ballot less than the current ballot. > > Does that make sense? Maybe some of this rationale needs to go into the > document... > > David > --000000000000608a27057a26663c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Y= es I did mix up the hCounters in my example, your interpretation was correc= t. Your last explanation does=C2=A0m= ake sense but seems=C2=A0to be at odds with your previous statement = which confused me.

>I= t's only safe to vote to commit a ballot b if
&g= t;ballot =3D=3D b at the=C2=A0time b was confirmed prepared

I think that statement is too strict, since it pre= cludes voting to commit ballots=C2=A0(3,x)...(7,x) from my previous example. In fact I think this statement wou= ld be correct if it is describing the point at which a node starts voting t= o commit a ballot. (I.E when c changes from NULL to some integer)

So instead we can say it is o= nly safe to vote to commit a ballot if the ballot has been confirmed prepar= ed and we have not voted or accepted abort for it.

So put simply, my original suggestion, was t= o modify the algorithm=C2=A0to vote to commit all confirmed prepared ballot= s that have not been voted or accepted aborted. I see that my proposed upda= te step doesn't quite achieve that, since as you pointed out it might s= et c such that we are voting to commit a ballot that we previously voted to= abort.

I've modified the = update step again, I think this would work correctly.

<= div>Replacing the first update step for c with the following three steps.

> * = If "c !=3D NULL" and "(preparedPrime > c && prepa= redPrime.value !=3D c.value)"
>=C2=A0 =C2=A0= raise c.counter to the lowest value such that c > preparedPrime.
>=C2=A0 =C2=A0
> * If "c = !=3D NULL" and "(prepared > c && prepared.value !=3D c= .value)"
>=C2=A0 =C2=A0raise c.counter to th= e lowest value such that c > prepared.
>=C2=A0= =C2=A0
> * If c.counter > hCounter then reset= "c =3D NULL"

We can see that this updat= e step precludes voting to commit and voting to abort the same ballot. Sinc= e when c !=3D NULL we know that a ballot has been confirmed prepared (we kn= ow this because c cannot be set unless hCounter is set and hCounter represe= nts a confirmed prepared ballot). Given that a ballot has been confirmed pr= epared, we know nomination has stopped, so the only way that this node can = change it's ballot.value is to accept an incompatible *higher* ballot p= repared via blocking threshold and then confirm it, the next time ballot.co= unter changes ballot.value will take the value of the newly confirmed prepa= red ballot. So we can see that given a state where cCounter and hCounter ha= ve been set, it is impossible to vote to abort any ballot we are currently = voting to commit without first accepting it prepared and when it is accepte= d prepared c will be updated to ensure that we are no longer voting to comm= it that ballot.

So the full set of update step= s for c would then be.

> * If "c !=3D NULL= " and "(preparedPrime > c && preparedPrime.value !=3D = c.value)"
>=C2=A0 =C2=A0raise c.counter to the lowest val= ue such that c > preparedPrime.
>
> * If "= ;c !=3D NULL" and "(prepared > c && prepared.value != =3D c.value)"
>=C2=A0 =C2=A0raise c.counter to the lowest= value such that c > prepared.
>
> * If c.coun= ter > hCounter then reset "c =3D NULL"
>
> *=C2=A0 If "c =3D=3D NULL" and "hCounter =3D=3D ballo= t.counter" (meaning
>=C2=A0 =C2=A0 "ballot" is = confirmed prepared), then set "c" to "ballot".

I hope that makes sense. And yes I think putting this rati= onale into the document would make it much easier to understand. The way th= e algorithm is presented currently gives you a lot of isolated update steps= but it is not clear how they are linked to each other and it is even less = clear why they are as they are. For myself at least it would have been real= ly useful to see a derivation of sorts from the high level concepts behind = the protocol to the very compact form in which the protocol is specified in= the IETF document.
=C2=A0
On Sat, 3 Nov 2018, 07:22 D= avid Mazieres <dm-list-ietf-ilc@scs.stanford.= edu wrote:
P= iers Powlesland <pierspowlesland@gmail.com<= /a>> writes:

> I have a few things I'm not clear on.
>
> I don't see that this statement is correct.
>
>>You mean transition to voting to commit nothing?=C2=A0 (Though stil= l
>>vote-or-confirm (n,x) for 4 <=3D n <=3D 8.)
>
> So following the update steps for c, first the c will be set to NULL > and then the next step will be executed.
>
>> * If "c =3D=3D NULL" and "hCounter =3D=3D ballot.co= unter" (meaning
>>=C2=A0 =C2=A0 "ballot" is confirmed prepared), then set &= quot;c" to "ballot".
>
> Resulting in the following node state.
>
> ballot =3D (8,x)
> prepared =3D (8,x)
> preparedPrime =3D (4,z)
> cCounter =3D 8
> hCounter =3D 8
>
> Which as described in the IETF document would I think means the node > now is voting to commit(8,x) ?

Oh, yes, sorry.=C2=A0 But importantly you are no longer voting to commit (5,x) and (6,x).

>> * If "cCounter !=3D 0": "vote commit(<n, ballot.= value>)" for every "cCounter <=3D n <=3D hCounter"<= br> >
> Also what is "vote-or-confirm" ?

Sorry, another mistake on my part.=C2=A0 I meant vote-or-accept.

> I can imagine the following scenario that seems to be allowable via > the IETF update rules that would allow a node to illegally vote for a<= br> > range of ballots that the node has never set its ballot equal to.
>
> The node starts with the following state. It is currently voting to > commit(2,x) among other things.
>
> ballot =3D(2,x)
> prepared =3D(2,x)
> preparedPrime =3D(1,y)
> cCounter =3D2
> hCounter =3D2
>
> Now we see blocking threshold for accept prepare(8,x)
>
> ballot =3D(8,x) // ballot.counter was also updated by the blocking thr= eshold.
> prepared =3D(8,x)
> preparedPrime =3D(1,y)
> cCounter =3D2
> hCounter =3D8
>
> Now we see quorum threshold for accept prepare(8,x) (we have confirmed=
> prepared (8,x) and h.value =3D=3D b.value so we set hCounter to 8)
>
> ballot =3D(8,x)
> prepared =3D(8,x)
> preparedPrime =3D(1,y)
> cCounter =3D2
> hCounter =3D8

Sorry, what's the difference between this and above?=C2=A0 I'm assu= ming you
meant hCounter=3D2 above, and hCounter=3D8 here.

> So now we are voting to commit, 2...8 with value =3D=3D x but ballot h= as
> never been set to a ballot with counter=C2=A0 3...7 and value =3D=3D x= . Doesn't
> this make it illegal to vote to commit (3,x)...(7,x)?

No, that's okay.=C2=A0 The thing we actually need to avoid is voting to= abort
and commit the same ballot b.=C2=A0 In this case that's fine because yo= u
never voted to abort any of (3,x)...(7,x).=C2=A0 The protocol could of cour= se
keep track of very vote you have ever cast to make sure this is okay.
Instead, to keep the state small, it uses the trick that you reset c to
0 whenever the ballot might contain a new value, and then you have to
set c to the current ballot number, because the (conservative)
assumption is that if c =3D=3D 0, then you might have voted to abort any ballot less than the current ballot.

Does that make sense?=C2=A0 Maybe some of this rationale needs to go into t= he
document...

David
--000000000000608a27057a26663c-- From nobody Thu Nov 8 06:03:24 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD2126CB6 for ; Thu, 8 Nov 2018 06:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 EU3WGnc687mY for ; Thu, 8 Nov 2018 06:03:21 -0800 (PST) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 21B3D126BED for ; Thu, 8 Nov 2018 06:03:21 -0800 (PST) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.29/8.16.0.21) with ESMTP id wA8E3Jv9047842; Thu, 8 Nov 2018 06:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1541685799; bh=+hOJCkDiZOlMaiKEaue7fKKWXBN1wcLlO/+FRnyQtvg=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=c/w0O18a3GZCN6Otzt644xrutI9+ztZqtKuQccAr7AvXDnPzMzsYti1uy1c0VGVVH 6A5+p7B189hyHviEtJTN11OXlwo26LwVGSerdr2NH53PHRAsyBizepVKtabEApdtgm 8VNpi5R/GuoKegXMNerUcvR4Z3j82z259FyMp74A= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.29/8.16.0.29/Submit) id wA8E3JoE070175; Thu, 8 Nov 2018 06:03:19 -0800 (PST) From: David Mazieres To: Piers Powlesland Cc: din@irtf.org In-Reply-To: References: <87va5fsexn.fsf@ta.scs.stanford.edu> <875zxezkus.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2019-02-06 PST Date: Thu, 08 Nov 2018 06:03:18 -0800 Message-ID: <87muqj7jkp.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 14:03:23 -0000 Piers Powlesland writes: > Yes I did mix up the hCounters in my example, your interpretation was > correct. Your last explanation does make sense but seems to be at odds with > your previous statement which confused me. > >>It's only safe to vote to commit a ballot b if >>ballot == b at the time b was confirmed prepared > > I think that statement is too strict, since it precludes voting to commit > ballots (3,x)...(7,x) from my previous example. In fact I think this > statement would be correct if it is describing the point at which a node > starts voting to commit a ballot. (I.E when c changes from NULL to some > integer) > > So instead we can say it is only safe to vote to commit a ballot if the > ballot has been confirmed prepared and we have not voted or accepted abort > for it. Yes, what you say is correct, but not possible to verify with the fixed amount of state that SCP keeps around. So the rule I stated is a conservative approximation. Maybe I shouldn't have said only. I should have said it is safe to vote in this case, and you can check this case. > So put simply, my original suggestion, was to modify the algorithm to vote > to commit all confirmed prepared ballots that have not been voted or > accepted aborted. I see that my proposed update step doesn't quite achieve > that, since as you pointed out it might set c such that we are voting to > commit a ballot that we previously voted to abort. > > I've modified the update step again, I think this would work correctly. > > Replacing the first update step for c with the following three steps. > >> * If "c != NULL" and "(preparedPrime > c && preparedPrime.value != > c.value)" >> raise c.counter to the lowest value such that c > preparedPrime. >> >> * If "c != NULL" and "(prepared > c && prepared.value != c.value)" >> raise c.counter to the lowest value such that c > prepared. >> >> * If c.counter > hCounter then reset "c = NULL" I think this is correct, but not necessarily more efficient. If h is the highest confirmed prepared ballot, then prepared >= h. So if you suddenly raise prepared to be greater than and incompatible h, that means you are now trying to confirm something prepared that has a different value from h, meaning h.value is no longer your best guess as to the value to externalize, so I don't see much point in continuing to vote to commit ballots with value h.value. With preparedPrime, there is a similar argument, that after confirming c prepared, a quorum confirmed an incompatible preparedPrime prepared. So maybe by coincidence after that everyone went back to c.value, but c.value is no more likely to be the ultimate consensus value than anything else. Basically the only reason it might be a win to avoid setting c to NULL is if you still think everyone is working on confirming c.value, which won't be the case if something incompatible but higher was prepared. David From nobody Thu Nov 8 09:02:54 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0701310A9 for ; Thu, 8 Nov 2018 09:02:49 -0800 (PST) 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 vgmPbXEWJknU for ; Thu, 8 Nov 2018 09:02:42 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 97E33130F62 for ; Thu, 8 Nov 2018 09:02:41 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id j4-v6so18621658ljc.12 for ; Thu, 08 Nov 2018 09:02:41 -0800 (PST) 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=+yDCPDNiDid9Y9zr8ao9FwSnCBKUM9TzV9PzmgDmhC4=; b=Nt6Xw+/v6rNm/sGK+tW5WMVa8ETE6YuVlRo11C3bYxGrhQM+clCsjWau2UpWKKSzMA oVIM2Q5ZIRWkcwEbRvjC+hZMBKzjScFbmV8g9oXbyGWmYNIsbdJOmbsgfDhJ/gpYq550 PpqUbpE8qlI+vfPH9PtUoxvPnhkYcXY5bQKEvNRdJHp0Nt4fo/4oUr5wfzwjgS+pkXBs p1eQDDwgk6p3VJ4u3j1H9ll1Z/ilHtSM9UUg4KqmJvT4AncQec3GBlmKhQjoo5BNvooK lNRHdyEOGERd8Adl9Wf+aMrqg/N0ZVbC7gJNK8XH7w5EvpbWyc6zYuyOtz9BYcLaVmul 7m3Q== 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=+yDCPDNiDid9Y9zr8ao9FwSnCBKUM9TzV9PzmgDmhC4=; b=Ax+RU0snKU5HcgvBTrmq35M/ZbK1uRjl8S35eNE7JAk3f43Ae0YupObAXG0f7sYPiK ppK2LjN9jR5UEfris+5A+g4h97Hq3EGpbltPZ46G4w412D/CMqE4S1o5gz0oT575Mj6p TLzX/lq5V6vr7aTRsRIVWaiowdt2wuCqk/5cQE6rr5TdiU1T1mFGUGfYItIblYfA6ptw LGTQPo6dzhaMbI5i7DHWPZhZL95pHuJziBBVhXyheoGD9GfyDcVV4tPaxWySV03XucEk 0h4mWghuk3PsYki3p/GHcTo6pyaGB6efUv9xjVMC/x3TyWUhWWikQSXDnBuUenK33XsN he8A== X-Gm-Message-State: AGRZ1gK1X0AS+4UvV0eF6XYdNkTkuIpDIlDFxgCyBLE/vIoL/+FhkGi6 aqFulrb6Sb53OlHrGuKDt+velyD6HKlcch2/fCVcN4DF X-Google-Smtp-Source: AJdET5fUtHEeH1cEWQfqIS5HVYuLmHfgPlGsoGOeETZk4vmajRx21RgahxD0EaC7QxDoDoiwA5UoSjFkMAcOOEk3l3M= X-Received: by 2002:a2e:9e10:: with SMTP id e16-v6mr3366057ljk.169.1541696559426; Thu, 08 Nov 2018 09:02:39 -0800 (PST) MIME-Version: 1.0 References: <87va5fsexn.fsf@ta.scs.stanford.edu> <875zxezkus.fsf@ta.scs.stanford.edu> <87muqj7jkp.fsf@ta.scs.stanford.edu> In-Reply-To: <87muqj7jkp.fsf@ta.scs.stanford.edu> From: Piers Powlesland Date: Thu, 8 Nov 2018 17:02:28 +0000 Message-ID: To: mazieres-sy3tdz4cdzgjttyvjih579mqfw@temporary-address.scs.stanford.edu Cc: din@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 17:02:53 -0000 So to clarify > I think this is correct, but not necessarily more efficient. If h is > the highest confirmed prepared ballot, then prepared >= h. So if you > suddenly raise prepared to be greater than and incompatible h, that > means you are now trying to confirm something prepared that has a > different value from h, meaning h.value is no longer your best guess as > to the value to externalize, so I don't see much point in continuing to > vote to commit ballots with value h.value. In the case where either prepared or preparedPrime are greater than or incompatible to h then c is set to NULL, so the node stops voting for anything. The case where I envisage this being a win is: After a node confirms c and has subsequently gone on to confirm several higher and compatible ballots, such that the node is now voting to commit several ballots. The node then accepts a preparedPrime that is greater than and incompatible to c but less than h. Rather than dropping everything and starting to vote to commit just the highest ballot that it was previously voting to commit, it just stops voting to commit any ballots that are now considered aborted due to the new preparedPrime. In this case everyone is still working on confirming committed c.value, we have just updated our "lower bound" below which we consider everything aborted. Using this approach provides more opportunities for the network to come to agreement and so in certain situations, I think, could reduce the time taken to agree on a value. On Thu, Nov 8, 2018 at 2:03 PM David Mazieres wrote: > > Piers Powlesland writes: > > > Yes I did mix up the hCounters in my example, your interpretation was > > correct. Your last explanation does make sense but seems to be at odds with > > your previous statement which confused me. > > > >>It's only safe to vote to commit a ballot b if > >>ballot == b at the time b was confirmed prepared > > > > I think that statement is too strict, since it precludes voting to commit > > ballots (3,x)...(7,x) from my previous example. In fact I think this > > statement would be correct if it is describing the point at which a node > > starts voting to commit a ballot. (I.E when c changes from NULL to some > > integer) > > > > So instead we can say it is only safe to vote to commit a ballot if the > > ballot has been confirmed prepared and we have not voted or accepted abort > > for it. > > Yes, what you say is correct, but not possible to verify with the fixed > amount of state that SCP keeps around. So the rule I stated is a > conservative approximation. Maybe I shouldn't have said only. I should > have said it is safe to vote in this case, and you can check this case. > > > So put simply, my original suggestion, was to modify the algorithm to vote > > to commit all confirmed prepared ballots that have not been voted or > > accepted aborted. I see that my proposed update step doesn't quite achieve > > that, since as you pointed out it might set c such that we are voting to > > commit a ballot that we previously voted to abort. > > > > I've modified the update step again, I think this would work correctly. > > > > Replacing the first update step for c with the following three steps. > > > >> * If "c != NULL" and "(preparedPrime > c && preparedPrime.value != > > c.value)" > >> raise c.counter to the lowest value such that c > preparedPrime. > >> > >> * If "c != NULL" and "(prepared > c && prepared.value != c.value)" > >> raise c.counter to the lowest value such that c > prepared. > >> > >> * If c.counter > hCounter then reset "c = NULL" > > I think this is correct, but not necessarily more efficient. If h is > the highest confirmed prepared ballot, then prepared >= h. So if you > suddenly raise prepared to be greater than and incompatible h, that > means you are now trying to confirm something prepared that has a > different value from h, meaning h.value is no longer your best guess as > to the value to externalize, so I don't see much point in continuing to > vote to commit ballots with value h.value. > > With preparedPrime, there is a similar argument, that after confirming c > prepared, a quorum confirmed an incompatible preparedPrime prepared. So > maybe by coincidence after that everyone went back to c.value, but > c.value is no more likely to be the ultimate consensus value than > anything else. > > Basically the only reason it might be a win to avoid setting c to NULL > is if you still think everyone is working on confirming c.value, which > won't be the case if something incompatible but higher was prepared. > > David From nobody Wed Nov 14 03:16:47 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2172412958B for ; Wed, 14 Nov 2018 03:16:46 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 68ngTD8K1EGc for ; Wed, 14 Nov 2018 03:16:44 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 DBA95124408 for ; Wed, 14 Nov 2018 03:16:43 -0800 (PST) Received: from [192.168.44.207] ([82.113.121.5]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MFK8N-1gGcpl1EKn-00FkPE for ; Wed, 14 Nov 2018 12:16:40 +0100 From: "Dirk Kutscher" To: din@irtf.org Date: Wed, 14 Nov 2018 12:16:37 +0100 X-Mailer: MailMate (1.12.1r5552) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Provags-ID: V03:K1:rRq8jejFd+3BuRBKC/pTDrAnsQ22Fgu3xwLN9kiwP727psAzVJk mHByK7DoCxMsQjDFT/KyWbrZq/doYTpSaDN0nPeiRlvHnInMRqYx+p2Nfak4MP0h98JHj4t 7jE6wFQzgOmKtjK7wWOwpod7mFittIq4Q/0gWPkkvCPVIgFubAbmytWig+SeD+nXM34xy75 jKUj5iXgqmN3OHdUiCiJw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5yIeayCRG1Q=:nTpyjen2w3dLMxT+CBkPTO BizEPE72f+39gvhVPMN8i8jxPKDDLe+L1V2aLX8thH3DJMGs8JRd07d7XcLFr5pqV+9Pc3jNy gNBrL0bOL4MVl0Owr6AXw9exofBwONszSB/mSHVc8mx9qtDfo0WMiPMdSxXHWfbxx8jH67/ZB R+xTU0xVPBZCcR8z0BZyC+8VF53nhi9WXcog4JQlkrmouBZJC/O+Qd88B0lYXksbIhbuhIkmn mhNNHQIzlbSm4hOgXD0MAYhJvH0wzzfvTKPF8tyrvSoqyR/ACJPwFJRddv0cxv8y56b2XUuOi JaWUkoEnZsyAYjn53SXsJHEAYsAIwLKSxft1dA2ZhuAT0b3L2LpBcejZk+upgRzgPL6uM0nyE ENvr3W1oLrU2pRP/VcH/bHqxNQnpzLvszIYBpDsIb6s36vaABsMlCBtJaCgqhPPY52Ymg7sft t5DTOA3wyPgz0gwby7YtbXN40e8mNpmsrGJ5tszu2xWHl6D9XkgOBe8zs1Q3vAfjTufPEBC8X VBb5t7cNk+cajaWtNQAm2T7i1O4PxQx2V6Js3MVzKrERR9KI1/TOtSmorcnrGn3R1P5aXnTnb E5+bCKXsK6eRbxvqoZCpSiqMg8JZhp6k7dSbrP3c2z1rODu4PQHLmRtI2PEwTm6KoZgCxMkgO 5YSmvMjOA1wJ151BQdW1XrkvskBLs4nCM3FJG0OInkThm5fNaZbOqfEtlwsy849ulvf7AAeZV ss2IO5alHt4qAtayeot9FKKaCwoxt2UVoXPyWKlT5jRIfMfgQEVsAu4NTR2RxIA1gtnTvhe0c avtQ58ofLCDMjPioalBxE+T+Ztnsw== Archived-At: Subject: [Din] draft DINRG@IETF-103 meeting minutes X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 11:16:46 -0000 Hello, We have posted a first draft of the minutes of our meeting at IETF-103. Please have a look and let us know in case you want to propose corrections/additions: https://datatracker.ietf.org/meeting/103/materials/minutes-103-dinrg-00 Thanks to Marie-Jose Montpetit for taking the notes! Best regards, Melinda & Dirk From nobody Wed Nov 14 08:05:41 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BF6130DD7 for ; Wed, 14 Nov 2018 08:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 5D_2u3WDfB-X for ; Wed, 14 Nov 2018 08:05:35 -0800 (PST) Received: from mailservice.tudelft.nl (mailservice.tudelft.nl [130.161.131.5]) (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 3F477128D09 for ; Wed, 14 Nov 2018 08:05:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id AA285240107 for ; Wed, 14 Nov 2018 17:05:32 +0100 (CET) X-Virus-Scanned: amavisd-new at tudelft.nl Received: from mailservice.tudelft.nl ([130.161.131.71]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FS3nz9OZpmFo for ; Wed, 14 Nov 2018 17:05:31 +0100 (CET) Received: from SRV221.tudelft.net (mailboxcluster.tudelft.net [131.180.6.21]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by mx4.tudelft.nl (Postfix) with ESMTPS id 5120D2400D3 for ; Wed, 14 Nov 2018 17:05:30 +0100 (CET) Received: from SRV221.tudelft.net (131.180.6.21) by SRV221.tudelft.net (131.180.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.1531.3; Wed, 14 Nov 2018 17:05:28 +0100 Received: from SRV221.tudelft.net ([fe80::1db0:d95:8ac1:d760]) by SRV221.tudelft.net ([fe80::1db0:d95:8ac1:d760%13]) with mapi id 15.01.1531.003; Wed, 14 Nov 2018 17:05:28 +0100 From: Aaron Ding To: "din@irtf.org" Thread-Topic: ACM EdgeSys 2019 Thread-Index: AQHUfDPcTdhgREmUo0ekKV0KWnc7IQ== Date: Wed, 14 Nov 2018 16:05:28 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A656174231184F3EA968EA01B7EA41F0tudelftnl_" MIME-Version: 1.0 Archived-At: Subject: [Din] ACM EdgeSys 2019 X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 16:05:39 -0000 --_000_A656174231184F3EA968EA01B7EA41F0tudelftnl_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCk9uZSByZWxldmFudCBjYWxsIGZvciBESU5SRyBjb2xsZWFndWVzLCBmcm9tIEVk Z2VTeXMgMjAxOSAoRHJlc2RlbiwgR2VybWFueSkNCg0KaHR0cHM6Ly9lZGdlc3lzMTkuY20uaW4u dHVtLmRlLw0KDQpUaGUgMm5kIEludGVybmF0aW9uYWwgV29ya3Nob3Agb24gRWRnZSBTeXN0ZW1z LCBBbmFseXRpY3MgYW5kIE5ldHdvcmtpbmcgKEVkZ2VTeXMgMjAxOSksIGluIGNvbmp1bmN0aW9u IHdpdGggQUNNIEV1cm9TeXMgMjAxOSwgYWltcyB0byBicmluZyB0b2dldGhlciBzeXN0ZW0gcmVz ZWFyY2hlcnMsIGRhdGEgc2NpZW50aXN0cywgZW5naW5lZXJzIGFuZCBwcmFjdGl0aW9uZXJzIHRv IGlkZW50aWZ5IG9wZW4gZGlyZWN0aW9ucyBhbmQgZGlzY3VzcyB0aGUgbGF0ZXN0IHJlc2VhcmNo IGlkZWFzIGFuZCByZXN1bHRzIG9uIGVkZ2Ugc3lzdGVtcywgYW5hbHl0aWNzIGFuZCBuZXR3b3Jr aW5nLCBlc3BlY2lhbGx5IHRob3NlIHJlbGF0ZWQgdG8gbm92ZWwgYW5kIGVtZXJnaW5nIHRlY2hu b2xvZ2llcyBhbmQgdXNlIGNhc2VzLiBUaGUgRWRnZVN5cyAnMTkgd29ya3Nob3AgZm9jdXNlcyBv biBzeXN0ZW1zLCBhbmFseXRpY3MgYW5kIG5ldHdvcmtpbmcgYXNwZWN0cywgY292ZXJpbmcgc3lz dGVtIGFyY2hpdGVjdHVyZSwgZGlzdHJpYnV0ZWQgTUwgYWxnb3JpdGhtcywgZGVjZW50cmFsaXpl ZCBuZXR3b3JraW5nLCBkaXN0cmlidXRlZCBjb25zZW5zdXMgYW5kIGxlZGdlciB0ZWNobmlxdWVz LCBlZGdlIHNlcnZpY2VzIGFuZCBkYXRhIGFuYWx5c2lzLiBUaGUgdG9waWNzIGluY2x1ZGUgYnV0 IGFyZSBub3QgbGltaXRlZCB0byB0aGUgZm9sbG93aW5nOg0KDQotIFN5c3RlbSBBcmNoaXRlY3R1 cmUgZm9yIEVkZ2UgQ29tcHV0aW5nDQotIENvbW11bmljYXRpb24gYW5kIENvbXB1dGF0aW9uIEFi c3RyYWN0aW9ucw0KLSBEaXN0cmlidXRlZCBNYWNoaW5lIExlYXJuaW5nIGZvciBFZGdlIEFuYWx5 dGljcyBhbmQgU2VydmljZXMNCi0gRWRnZS1kcml2ZW4gRGF0YSBBbmFseXRpY3MNCi0gTm92ZWwg U3lzdGVtIGFuZCBOZXR3b3JraW5nIERlc2lnbiBmb3IgRGF0YS1pbnRlbnNpdmUgU2VydmljZXMN Ci0gRWRnZSBTZWN1cml0eSBhbmQgUHJpdmFjeQ0KLSBMaWdodHdlaWdodCBWaXJ0dWFsaXphdGlv biBmb3IgRWRnZSBDb21wdXRpbmcNCi0gRGlzdHJpYnV0ZWQgQ29uc2Vuc3VzIEFsZ29yaXRobXMg YW5kIExlZGdlciBUZWNobm9sb2dpZXMNCi0gSW5mcmFzdHJ1Y3R1cmUgYW5kIFRvb2xraXQgZm9y IEVkZ2UgQ29tcHV0aW5nIGFuZCBBbmFseXRpY3MNCi0gU3lzdGVtIFBlcmZvcm1hbmNlIGFuZCBN ZWFzdXJlbWVudA0KLSBFZGdlIE5ldHdvcmtpbmcgYW5kIENvbW11bmljYXRpb25zDQotIEVkZ2Ut ZW5hYmxlZCBJb1QgU2VydmljZXMgYW5kIEFwcGxpY2F0aW9uIFRheG9ub215DQotIChBdXRvbm9t b3VzKSBNYW5hZ2VtZW50IGZvciBFZGdlIFN5c3RlbXMNCi0gU2VjdXJpdHkgYW5kIFRydXN0IE1h bmFnZW1lbnQNCg0KDQpXb3Jrc2hvcCBhbmQgVFBDIENoYWlyczoNCkFhcm9uIFlpIERpbmcgKFRV IERlbGZ0LCBOZXRoZXJsYW5kcykNClJpY2hhcmQgTW9ydGllciAoVW5pdmVyc2l0eSBvZiBDYW1i cmlkZ2UsIFVLKQ0KDQpTdGVlcmluZyBDb21taXR0ZWU6DQpKb24gQ3Jvd2Nyb2Z0IChVbml2ZXJz aXR5IG9mIENhbWJyaWRnZSwgVUspDQpIZW5uaW5nIFNjaHVsenJpbm5lIChDb2x1bWJpYSBVbml2 ZXJzaXR5LCBVU0EpDQpTdGV2ZSBVaGxpZyAoUXVlZW4gTWFyeSBVbml2ZXJzaXR5IG9mIExvbmRv biwgVUspDQpQZXRlciBQaWV0enVjaCAoSW1wZXJpYWwgQ29sbGVnZSBMb25kb24sIFVLKQ0KRGll dGVyIEtyYW56bG3DvGxsZXIgKFVuaXZlcnNpdHkgb2YgTXVuaWNoICYgTFJaLCBHZXJtYW55KQ0K RGlyayBLdXRzY2hlciAoSHVhd2VpLCBHZXJtYW55KQ0KDQpUZWNobmljYWwgUHJvZ3JhbSBDb21t aXR0ZWU6DQpTaGVoYXIgQmFubyAoVUNMLCBVSykNCkNocmlzdGlhbiBCZWNrZXIgKFVuaXZlcnNp dHkgb2YgTWFubmhlaW0sIEdlcm1hbnkpDQpOaWNrbGFzIEJlaWphciAoRXJpY3Nzb24sIEZpbmxh bmQpDQpaaGVuIENhbyAoSHVhd2VpLCBDaGluYSkNCllvbmcgQ3VpIChUc2luZ2h1YSBVbml2ZXJz aXR5LCBDaGluYSkNClRpbSBEZWVnYW4gKEFtYXpvbiwgVUspDQpJb25lbCBHb2cgKFVDIEJlcmtl bGV5LCBVU0EpDQpWb2xrZXIgSGlsdCAoTm9raWEgQmVsbCBMYWJzLCBHZXJtYW55KQ0KWGlhb2Nv bmcgSmluIChHb29nbGUsIFVTQSkNCkFudG9pbmUgS2F1Zm1hbm4gKE1heCBQbGFuY2sgSW5zdGl0 dXRlLCBHZXJtYW55KQ0KSWxpYXMgTGVvbnRpYWRpcyAoVGVsZWbDs25pY2EsIFNwYWluKQ0KU2hl biBMaSAoSUJNLCBVU0EpDQpEb25ndGFvIExpdSAoVHdpdHRlciwgVVNBKQ0KSm9uYXRoYW4gTWFj ZSAoTWF4IFBsYW5jayBJbnN0aXR1dGUsIEdlcm1hbnkpDQpJcWJhbCBNb2hvbWVkIChTYW1zdW5n LCBVU0EpDQpSb2xmIE5ldWdlYmF1ZXIgKEFtYXpvbiwgVUspDQpTaGFkaSBOb2doYWJpIChNaWNy b3NvZnQgUmVzZWFyY2gsIFVTQSkNCkRpZWdvIFBlcmlubyAoVGVsZWbDs25pY2EsIFNwYWluKQ0K SmFuIFJlbGxlcm1leWVyIChUVSBEZWxmdCwgTmV0aGVybGFuZHMpDQpNYWx0ZSBTY2h3YXJ6a29w ZiAoTUlULCBVU0EpDQpTYW5kcmEgU2VydmlhIChVbml2ZXJzaXR5IG9mIENhbWJyaWRnZSwgVUsp DQpZdWFuY2hhbyBTaHUgKE1pY3Jvc29mdCBSZXNlYXJjaCwgVVNBKQ0KTGluIFdhbmcgKFRVIERh cm1zdGFkdCwgR2VybWFueSkNCktsYXVzIFdlaHJsZSAoUldUSCBBYWNoZW4sIEdlcm1hbnkpDQpD aGVucmVuIFh1IChQZWtpbmcgVW5pdmVyc2l0eSwgQ2hpbmEpDQpUaWFueWluIFh1IChVSVVDLCBV U0EpDQpZdWVkb25nIFh1IChGdWRhbiBVbml2ZXJzaXR5LCBDaGluYSkNCkVubmFuIFpoYWkgKEFs aWJhYmEsIFVTQSkNCg0KUHVibGljaXR5IENoYWlyOg0KRGltaXRyaXMgQ2hhdHpvcG91bG9zIChI S1VTVCwgSG9uZyBLb25nIFNBUikNCg0KV2ViIENoYWlyOg0KVml0dG9yaW8gQ296em9saW5vIChU VSBNdW5pY2gsIEdlcm1hbnkpDQoNClN1Ym1pc3Npb24gR3VpZGVsaW5lczoNCkF1dGhvcnMgYXJl IGVuY291cmFnZWQgdG8gc3VibWl0IHBhcGVycyBkZXNjcmliaW5nIG9yaWdpbmFsIGFuZCB1bnB1 Ymxpc2hlZCByZXNlYXJjaCwgbm90IGN1cnJlbnRseSB1bmRlciByZXZpZXcgaW4gb3RoZXIgdmVu dWVzLiBJbiBwYXJ0aWN1bGFyLCBpbm5vdmF0aXZlLCBlYXJseS1zdGFnZSBpZGVhcyBhbmQgcHJl bGltaW5hcnkgcmVzdWx0cyBhcmUgd2VsY29tZS4gUGFwZXJzIG11c3QgYmUgc3VibWl0dGVkIGVs ZWN0cm9uaWNhbGx5IGFzIFBERiBmaWxlcywgZm9ybWF0dGVkIGZvciA4LjV4MTEtaW5jaCBwYXBl ci4gVGhlIGxlbmd0aCBvZiB0aGUgcGFwZXIgbXVzdCBiZSBubyBtb3JlIHRoYW4gNiBwYWdlcyBp biB0aGUgQUNNIGRvdWJsZS1jb2x1bW4gZm9ybWF0ICgxMC1wdCBmb250KSwgaW5jbHVkaW5nIHJl ZmVyZW5jZXMgYW5kIGV2ZXJ5dGhpbmcuIEF1dGhvcnMgYXJlIHN1Z2dlc3RlZCB0byB1c2UgdGhl IEFDTSBNYXN0ZXIgYXJ0aWNsZSB0ZW1wbGF0ZS4gVGhlIHJldmlld3Mgd2lsbCBiZSBzaW5nbGUg YmxpbmQuIFRoZSBmaXJzdCBwYWdlIG11c3QgY29udGFpbiBhbiBhYnN0cmFjdCwgdGhlIG5hbWUo cykgYW5kIGFmZmlsaWF0aW9uKHMpIG9mIHRoZSBhdXRob3IocyksIGFzIHdlbGwgYXMgdGhlIGNv cnJlc3BvbmRpbmcgY29udGFjdCBpbmZvcm1hdGlvbi4gRWFjaCBzdWJtaXNzaW9uIHdpbGwgcmVj ZWl2ZSBpbmRlcGVuZGVudCwgYmxpbmQgcGVlciByZXZpZXdzIGZyb20gdGhlIHByb2dyYW0gY29t bWl0dGVlLiBBY2NlcHRlZCBwYXBlcnMgd2lsbCBiZSBwdWJsaXNoZWQgaW4gdGhlIEFDTSBEaWdp dGFsIExpYnJhcnkuIEF0IGxlYXN0IG9uZSBvZiB0aGUgYXV0aG9ycyBvZiBldmVyeSBhY2NlcHRl ZCBwYXBlciBtdXN0IHJlZ2lzdGVyIGFuZCBwcmVzZW50IHRoZSBwYXBlciBhdCB0aGUgd29ya3No b3AuIFRoZSBwcm9ncmFtIGNvbW1pdHRlZSB3aWxsIGVsZWN0IG9uZSBwYXBlciBmb3IgdGhlIEJl c3QgUGFwZXIgQXdhcmQuDQoNClN1Ym1pc3Npb24gZGVhZGxpbmU6IDIwIEphbnVhcnkgMjAxOQ0K QWNjZXB0YW5jZSBub3RpZmljYXRpb246IDE0IEZlYnJ1YXJ5IDIwMTkNCkNhbWVyYSByZWFkeTog MSBNYXJjaCAyMDE5DQpXb3Jrc2hvcCBkYXRlOiAyNSBNYXJjaCAyMDE5DQoNClN1Ym1pc3Npb24g TGluazogaHR0cHM6Ly9lZGdlc3lzMTkuaG90Y3JwLmNvbS8NCg0KQ2hlZXJzLA0KQWFyb24NCg0K LS0NCkFzc2lzdGFudCBQcm9mZXNzb3IsIFRVIERlbGZ0DQpodHRwOi8vaG9tZXBhZ2UudHVkZWxm dC5ubC84ZTc5dC8NCg== --_000_A656174231184F3EA968EA01B7EA41F0tudelftnl_ Content-Type: text/html; charset="utf-8" Content-ID: <1DD26F7D787A8847A3E844F823DBE6D0@forest.intra> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PbmUg cmVsZXZhbnQgY2FsbCBmb3IgRElOUkcgY29sbGVhZ3VlcywgZnJvbSBFZGdlU3lzIDIwMTkgKERy ZXNkZW4sIEdlcm1hbnkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmh0dHBzOi8vZWRnZXN5czE5LmNtLmluLnR1bS5k ZS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+VGhlIDJuZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIEVkZ2UgU3lz dGVtcywgQW5hbHl0aWNzIGFuZCBOZXR3b3JraW5nIChFZGdlU3lzIDIwMTkpLCBpbiBjb25qdW5j dGlvbiB3aXRoIEFDTSBFdXJvU3lzIDIwMTksIGFpbXMgdG8gYnJpbmcgdG9nZXRoZXIgc3lzdGVt IHJlc2VhcmNoZXJzLCBkYXRhIHNjaWVudGlzdHMsIGVuZ2luZWVycw0KIGFuZCBwcmFjdGl0aW9u ZXJzIHRvIGlkZW50aWZ5IG9wZW4gZGlyZWN0aW9ucyBhbmQgZGlzY3VzcyB0aGUgbGF0ZXN0IHJl c2VhcmNoIGlkZWFzIGFuZCByZXN1bHRzIG9uIGVkZ2Ugc3lzdGVtcywgYW5hbHl0aWNzIGFuZCBu ZXR3b3JraW5nLCBlc3BlY2lhbGx5IHRob3NlIHJlbGF0ZWQgdG8gbm92ZWwgYW5kIGVtZXJnaW5n IHRlY2hub2xvZ2llcyBhbmQgdXNlIGNhc2VzLiBUaGUgRWRnZVN5cyAnMTkgd29ya3Nob3AgZm9j dXNlcyBvbiBzeXN0ZW1zLA0KIGFuYWx5dGljcyBhbmQgbmV0d29ya2luZyBhc3BlY3RzLCBjb3Zl cmluZyBzeXN0ZW0gYXJjaGl0ZWN0dXJlLCBkaXN0cmlidXRlZCBNTCBhbGdvcml0aG1zLCBkZWNl bnRyYWxpemVkIG5ldHdvcmtpbmcsIGRpc3RyaWJ1dGVkIGNvbnNlbnN1cyBhbmQgbGVkZ2VyIHRl Y2huaXF1ZXMsIGVkZ2Ugc2VydmljZXMgYW5kIGRhdGEgYW5hbHlzaXMuIFRoZSB0b3BpY3MgaW5j bHVkZSBidXQgYXJlIG5vdCBsaW1pdGVkIHRvIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0g U3lzdGVtIEFyY2hpdGVjdHVyZSBmb3IgRWRnZSBDb21wdXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPi0gQ29tbXVuaWNhdGlvbiBhbmQgQ29tcHV0YXRpb24gQWJzdHJhY3Rpb25z PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIERpc3RyaWJ1dGVkIE1hY2hpbmUgTGVh cm5pbmcgZm9yIEVkZ2UgQW5hbHl0aWNzIGFuZCBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+LSBFZGdlLWRyaXZlbiBEYXRhIEFuYWx5dGljczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+LSBOb3ZlbCBTeXN0ZW0gYW5kIE5ldHdvcmtpbmcgRGVzaWduIGZvciBE YXRhLWludGVuc2l2ZSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBF ZGdlIFNlY3VyaXR5IGFuZCBQcml2YWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4t IExpZ2h0d2VpZ2h0IFZpcnR1YWxpemF0aW9uIGZvciBFZGdlIENvbXB1dGluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+LSBEaXN0cmlidXRlZCBDb25zZW5zdXMgQWxnb3JpdGhtcyBh bmQgTGVkZ2VyIFRlY2hub2xvZ2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBJ bmZyYXN0cnVjdHVyZSBhbmQgVG9vbGtpdCBmb3IgRWRnZSBDb21wdXRpbmcgYW5kIEFuYWx5dGlj czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBTeXN0ZW0gUGVyZm9ybWFuY2UgYW5k IE1lYXN1cmVtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIEVkZ2UgTmV0d29y a2luZyBhbmQgQ29tbXVuaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0g RWRnZS1lbmFibGVkIElvVCBTZXJ2aWNlcyBhbmQgQXBwbGljYXRpb24gVGF4b25vbXk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gKEF1dG9ub21vdXMpIE1hbmFnZW1lbnQgZm9yIEVk Z2UgU3lzdGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBTZWN1cml0eSBhbmQg VHJ1c3QgTWFuYWdlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPldvcmtzaG9wIGFuZCBUUEMgQ2hhaXJzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+QWFyb24gWWkgRGluZyAoVFUgRGVsZnQsIE5ldGhlcmxhbmRzKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UmljaGFyZCBNb3J0aWVyIChVbml2ZXJzaXR5IG9mIENhbWJy aWRnZSwgVUspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlN0ZWVyaW5nIENvbW1pdHRlZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkpvbiBDcm93Y3JvZnQgKFVuaXZlcnNpdHkgb2YgQ2FtYnJpZGdlLCBV Syk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbm5pbmcgU2NodWx6cmlubmUgKENv bHVtYmlhIFVuaXZlcnNpdHksIFVTQSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlN0 ZXZlIFVobGlnIChRdWVlbiBNYXJ5IFVuaXZlcnNpdHkgb2YgTG9uZG9uLCBVSyk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBldGVyIFBpZXR6dWNoIChJbXBlcmlhbCBDb2xsZWdlIExv bmRvbiwgVUspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EaWV0ZXIgS3JhbnpsbcO8 bGxlciAoVW5pdmVyc2l0eSBvZiBNdW5pY2ggJmFtcDsgTFJaLCBHZXJtYW55KTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+RGlyayBLdXRzY2hlciAoSHVhd2VpLCBHZXJtYW55KTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5UZWNobmljYWwgUHJvZ3JhbSBDb21taXR0ZWU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5TaGVoYXIgQmFubyAoVUNMLCBVSyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkNocmlzdGlhbiBCZWNrZXIgKFVuaXZlcnNpdHkgb2YgTWFubmhlaW0sIEdlcm1hbnkp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OaWNrbGFzIEJlaWphciAoRXJpY3Nzb24s IEZpbmxhbmQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5aaGVuIENhbyAoSHVhd2Vp LCBDaGluYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllvbmcgQ3VpIChUc2luZ2h1 YSBVbml2ZXJzaXR5LCBDaGluYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRpbSBE ZWVnYW4gKEFtYXpvbiwgVUspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Jb25lbCBH b2cgKFVDIEJlcmtlbGV5LCBVU0EpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Wb2xr ZXIgSGlsdCAoTm9raWEgQmVsbCBMYWJzLCBHZXJtYW55KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+WGlhb2NvbmcgSmluIChHb29nbGUsIFVTQSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkFudG9pbmUgS2F1Zm1hbm4gKE1heCBQbGFuY2sgSW5zdGl0dXRlLCBHZXJtYW55 KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWxpYXMgTGVvbnRpYWRpcyAoVGVsZWbD s25pY2EsIFNwYWluKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2hlbiBMaSAoSUJN LCBVU0EpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Eb25ndGFvIExpdSAoVHdpdHRl ciwgVVNBKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Sm9uYXRoYW4gTWFjZSAoTWF4 IFBsYW5jayBJbnN0aXR1dGUsIEdlcm1hbnkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5JcWJhbCBNb2hvbWVkIChTYW1zdW5nLCBVU0EpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5Sb2xmIE5ldWdlYmF1ZXIgKEFtYXpvbiwgVUspPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5TaGFkaSBOb2doYWJpIChNaWNyb3NvZnQgUmVzZWFyY2gsIFVTQSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRpZWdvIFBlcmlubyAoVGVsZWbDs25pY2EsIFNwYWluKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SmFuIFJlbGxlcm1leWVyIChUVSBEZWxmdCwg TmV0aGVybGFuZHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NYWx0ZSBTY2h3YXJ6 a29wZiAoTUlULCBVU0EpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TYW5kcmEgU2Vy dmlhIChVbml2ZXJzaXR5IG9mIENhbWJyaWRnZSwgVUspPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5ZdWFuY2hhbyBTaHUgKE1pY3Jvc29mdCBSZXNlYXJjaCwgVVNBKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+TGluIFdhbmcgKFRVIERhcm1zdGFkdCwgR2VybWFueSk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPktsYXVzIFdlaHJsZSAoUldUSCBBYWNoZW4sIEdl cm1hbnkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaGVucmVuIFh1IChQZWtpbmcg VW5pdmVyc2l0eSwgQ2hpbmEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaWFueWlu IFh1IChVSVVDLCBVU0EpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ZdWVkb25nIFh1 IChGdWRhbiBVbml2ZXJzaXR5LCBDaGluYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkVubmFuIFpoYWkgKEFsaWJhYmEsIFVTQSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UHVibGljaXR5IENoYWlyOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGltaXRyaXMgQ2hhdHpvcG91bG9zIChIS1VT VCwgSG9uZyBLb25nIFNBUik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2ViIENoYWlyOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Vml0dG9yaW8gQ296em9saW5vIChUVSBNdW5pY2gsIEdlcm1hbnkpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlN1Ym1pc3Npb24gR3VpZGVsaW5lczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkF1dGhvcnMgYXJlIGVuY291cmFnZWQgdG8gc3VibWl0IHBhcGVycyBkZXNjcmliaW5n IG9yaWdpbmFsIGFuZCB1bnB1Ymxpc2hlZCByZXNlYXJjaCwgbm90IGN1cnJlbnRseSB1bmRlciBy ZXZpZXcgaW4gb3RoZXIgdmVudWVzLiBJbiBwYXJ0aWN1bGFyLCBpbm5vdmF0aXZlLCBlYXJseS1z dGFnZSBpZGVhcyBhbmQgcHJlbGltaW5hcnkgcmVzdWx0cw0KIGFyZSB3ZWxjb21lLiBQYXBlcnMg bXVzdCBiZSBzdWJtaXR0ZWQgZWxlY3Ryb25pY2FsbHkgYXMgUERGIGZpbGVzLCBmb3JtYXR0ZWQg Zm9yIDguNXgxMS1pbmNoIHBhcGVyLiBUaGUgbGVuZ3RoIG9mIHRoZSBwYXBlciBtdXN0IGJlIG5v IG1vcmUgdGhhbiA2IHBhZ2VzIGluIHRoZSBBQ00gZG91YmxlLWNvbHVtbiBmb3JtYXQgKDEwLXB0 IGZvbnQpLCBpbmNsdWRpbmcgcmVmZXJlbmNlcyBhbmQgZXZlcnl0aGluZy4gQXV0aG9ycyBhcmUg c3VnZ2VzdGVkDQogdG8gdXNlIHRoZSBBQ00gTWFzdGVyIGFydGljbGUgdGVtcGxhdGUuIFRoZSBy ZXZpZXdzIHdpbGwgYmUgc2luZ2xlIGJsaW5kLiBUaGUgZmlyc3QgcGFnZSBtdXN0IGNvbnRhaW4g YW4gYWJzdHJhY3QsIHRoZSBuYW1lKHMpIGFuZCBhZmZpbGlhdGlvbihzKSBvZiB0aGUgYXV0aG9y KHMpLCBhcyB3ZWxsIGFzIHRoZSBjb3JyZXNwb25kaW5nIGNvbnRhY3QgaW5mb3JtYXRpb24uIEVh Y2ggc3VibWlzc2lvbiB3aWxsIHJlY2VpdmUgaW5kZXBlbmRlbnQsDQogYmxpbmQgcGVlciByZXZp ZXdzIGZyb20gdGhlIHByb2dyYW0gY29tbWl0dGVlLiBBY2NlcHRlZCBwYXBlcnMgd2lsbCBiZSBw dWJsaXNoZWQgaW4gdGhlIEFDTSBEaWdpdGFsIExpYnJhcnkuIEF0IGxlYXN0IG9uZSBvZiB0aGUg YXV0aG9ycyBvZiBldmVyeSBhY2NlcHRlZCBwYXBlciBtdXN0IHJlZ2lzdGVyIGFuZCBwcmVzZW50 IHRoZSBwYXBlciBhdCB0aGUgd29ya3Nob3AuIFRoZSBwcm9ncmFtIGNvbW1pdHRlZSB3aWxsIGVs ZWN0IG9uZSBwYXBlcg0KIGZvciB0aGUgQmVzdCBQYXBlciBBd2FyZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U3Vi bWlzc2lvbiBkZWFkbGluZTogMjAgSmFudWFyeSAyMDE5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkFjY2VwdGFuY2Ugbm90aWZpY2F0aW9uOiAxNCBGZWJydWFyeSAyMDE5DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNhbWVyYSByZWFkeTogMSBNYXJjaCAyMDE5DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldvcmtzaG9wIGRhdGU6IDI1IE1hcmNoIDIw MTk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+U3VibWlzc2lvbiBMaW5rOiBodHRwczovL2VkZ2VzeXMxOS5ob3RjcnAu Y29tLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5B YXJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkFzc2lzdGFudCBQcm9mZXNzb3IsIFRVIERlbGZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHA6Ly9ob21lcGFnZS50dWRlbGZ0Lm5sLzhlNzl0LyI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHA6Ly9ob21lcGFnZS50dWRlbGZ0Lm5sLzhl Nzl0Lzwvc3Bhbj48L2E+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A656174231184F3EA968EA01B7EA41F0tudelftnl_-- From nobody Thu Nov 15 02:05:22 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420911252B7 for ; Thu, 15 Nov 2018 02:05:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 JZJCbUCllUAK for ; Thu, 15 Nov 2018 02:05:17 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 AFBDB12D4ED for ; Thu, 15 Nov 2018 02:05:16 -0800 (PST) Received: from [192.168.44.207] ([82.113.121.164]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M9Evp-1gQp9a3kEJ-006PBT for ; Thu, 15 Nov 2018 11:05:14 +0100 From: "Dirk Kutscher" To: din@irtf.org Date: Thu, 15 Nov 2018 11:05:10 +0100 X-Mailer: MailMate (1.12.1r5552) Message-ID: <732916E0-AA93-4A97-B894-8C85F6676AF5@dkutscher.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_CE4F67FD-7AC8-4387-BF68-CF557D1721AC_=" Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:R/SO0pAZQQ3kEl34BMVHMOe1Ue4vjkVC8vph8W+GTk7uFTaV74y UXfYqNZigW193YSspAbDWLLjUSq/a1zq1zY1lXFEUXMIGDZShMvj/lhjFkJt5ewK/U1KIVs 8cafWNP1hCvIAA56AfsSi+URDp5xpclMWpQ5bVP9hJHe3B39EiJJb/CnkOeBCEe9Q+faUgV B/zDf7kKP7KbHJP4mqAyQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:dEU+tzwhh/U=:vuz2tqdYv55H6Zp5T5AmES xVoa1ShaNc1IbvqmfePpUh74rPWb75IrWecek/tPpRK0p6yekDrM/6DjZv4O+obBhl3tZDG75 ZqPlEcOjAZUtYQyZmB9/8+Ni6VwZ1sNrvtUpVSysuIb0bm5KgqZrOrtAp6dHdbH857xuj6iV0 k6sVt6yddLyxZOjbKXUz3OwjTyrNYJiZ6JiAzH0GiWaHK8zMo0nN9stogXasCrShkC/mAMeL/ CphUAZzRAV2CDpn29tjsq3NLdAjw1H8lJfsbB+N5yyAjZZNxFPnPviPJ0/id1EP2M/BDl+DZq yMVTSqLrjycZqGZmKJBZIu/ZVBwP/IdJ5Zdg90RXsSm/bHltzjG8wqLu24bj6YrsSqRW0Hfr4 ygxE9W9e55xDMjcAetGUGFNR9E4MTHzY4Cz/Mt0R+hLwxDs6fPS4kzZ+eIRFk4ZGm8r6cSmk3 p1fuKOsp8uGlYeqnJxHOg54D+5qdlLfgefvNNWJRVejUNDBU8cBhrj1qKVea5N5blumeKlEdh pTXi17lGkZwpubiKCZv08Il+Y//wtRB1qNeerp3TRFYTC4LyhjSxlCUS4fX3RJ5eb7XgJkQku KAROKN824QphqwLiexoWo6CF8+CULNG4pmZb2VkHzoDO2GxIdoZvw4YvHOkjAyxRUVTvYokZx 2TUW1RGskfUj9dO52qrjBZmtwYt9If1k5llpCxLG+qW6gIrybcj1mzcsUUVMR+9DpdFHtoysY KXT1R17zJDWA07UdoF9bs2C9ZeDo6W0LsJpw13C/HXBZiYTmAddBzfSH9XIr+gjhVL69YHC58 KXmIDJE7pFmTRmLRBn9aGNgfyJQ+w== Archived-At: Subject: [Din] Call for Papers: Workshop on Decentralized Internet Infrastructure X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 10:05:20 -0000 --=_MailMate_CE4F67FD-7AC8-4387-BF68-CF557D1721AC_= Content-Type: text/plain; charset=utf-8; markup=markdown Content-Transfer-Encoding: 8bit [Apologies if you receive multiple copies of this] Call for Papers: Workshop on Decentralized Internet Infrastructure ========================================== https://www.ndss-symposium.org/ndss2019/cfp-din-2019/ Background The internet was designed as a distributed, decentralized system. For example, intra- and inter-domain routing, DNS, and so on were designed to operate in a distributed manner. However, over time the dominant deployment model for applications and some infrastructure services evolved to become more centralized and hierarchical. Some of the increase in centralization is due to business models that rely on centralized accounting and administration. However, we are simultaneously seeing the evolution of use cases (e.g., certain IoT deployments) that have difficulties scaling up and/or establishing trust in centralized deployment scenarios, along with the evolution of decentralized technologies which leverage new cryptographic infrastructures, such as DNSSEC, or which use novel, cryptographically-based distributed consensus mechanisms, such as a number of different ledger technologies. While there is currently intensive research and development taking place around decentralized applications, the problem of decentralized infrastructure is receiving relatively less attention, despite the research challenges in this space. Some of these challenges include: ● Scalability - what are the problems that prevent decentralized infrastructure services from achieving global scale? ● Trust management in decentralized communication settings ● Privacy and targeted, verifiable disclosure ● Applicability of distributed ledger and related technologies to different use cases and environments ● Consensus algorithms for specific scenarios with a focus on Internet infrastructure services ● Distributed Trust and Delegated Computing ● Economic drivers and roadblocks for decentralizing network infrastructure Although the term "decentralized" tends to suggest distributed ledger-based approaches, our interest in decentralized infrastructure is not limited to the use of ledgers. This workshop will address open research issues in decentralizing Internet infrastructure services such as trust management, name resolution, resource ownership management, and resource discovery. Location and Important Dates Paper submission: 14 December 2018, anywhere in the world Notification: 14 January 2019 Camera-ready copy due: 3 February 2019 Workshop: 24 February 2019 (co-located with NDSS 2019) Location: Catamaran Resort Hotel & Spa in San Diego, California, USA Submission Instructions Submissions should be non-anonymous, and consist of a main body and, optionally, well-marked appendices. For papers that have already been published, submission should include a cover letter (at most 2 pages) commenting on what the workshop presentation would contain, appended with the published paper. For papers not already formally published, the main body should be about 12 pages in length with reasonable margins and fonts. Appendices are optional and unlimited in length; however, Workshop Technical Program Committee members may base their decisions solely on the contents of the main bodies of submissions. We also invite short papers of up to 6 pages covering work in progress, short communications, as well as novel or provocative ideas. Short papers will be selected based on their potential to spark interesting discussions during the workshop. They should be about 6 pages in length. We expect to be flexible on length and format given relevant submissions. Papers should be submitted at https://din19.hotcrp.com Technical Programm Committee * Melinda Shore, Fastly (co-chair) * Dirk Kutscher, Huawei (co-chair) * Marcelo Bagnulo, UC3M * Shehar Bano, University College London * Carsten Bormann, Universität Bremen * Jon Crowcroft, University of Cambridge * Thomas Hardjono, MIT Trust::Data Consortium * Christian Huitema, Private Octopus * Liubingyang, Huawei * Paulo Mendes, Universidade Lusófona de Humanidades e Tecnologias * Dave Oran, Network Systems Research & Design * Jörg Ott, TU Munich * Christian Esteve Rothenberg, University of Campinas * Keshav Srinivasan, University of Waterloo * Jean-Luc Watson, University of California, Berkely * Lixia Zhang, UCLA --=_MailMate_CE4F67FD-7AC8-4387-BF68-CF557D1721AC_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

[Apologies if you receive multiple copies of this]

Call for Papers: Workshop on Decentralized Internet Infrastructure

https://www.ndss-symposium.org/ndss2019/cfp-din-2019/

Background

The internet was designed as a distributed, decentralized= system. For
example, intra- and inter-domain routing, DNS, and so on were designed to operate in a distributed manner. However, over time the dominant
deployment model for applications and some infrastructure services
evolved to become more centralized and hierarchical. Some of the
increase in centralization is due to business models that rely on
centralized accounting and administration.

However, we are simultaneously seeing the evolution of us= e cases
(e.g., certain IoT deployments) that have difficulties scaling up
and/or establishing trust in centralized deployment scenarios, along
with the evolution of decentralized technologies which leverage new
cryptographic infrastructures, such as DNSSEC, or which use novel,
cryptographically-based distributed consensus mechanisms, such as a
number of different ledger technologies.

While there is currently intensive research and developme= nt taking
place around decentralized applications, the problem of decentralized
= infrastructure is receiving relatively less attention, despite the
research challenges in this space. Some of these challenges include:

=E2=97=8F Scalability - what are the problems that preven= t decentralized
infrastructure services from achieving global scale?
=E2=97=8F Trust management in decentralized communication settings
=E2=97=8F Privacy and targeted, verifiable disclosure
=E2=97=8F Applicability of distributed ledger and related technologies to=
different use cases and environments
=E2=97=8F Consensus algorithms for specific scenarios with a focus on Int= ernet
infrastructure services
=E2=97=8F Distributed Trust and Delegated Computing
=E2=97=8F Economic drivers and roadblocks for decentralizing network
infrastructure

Although the term "decentralized" tends to suggest distri= buted
ledger-based approaches, our interest in decentralized infrastructure
= is not limited to the use of ledgers.

This workshop will address open research issues in decent= ralizing
Internet infrastructure services such as trust management, name
resolution, resource ownership management, and resource discovery.

Location and Important Dates
Paper submission: 14 December 2018, anywhere in the world
Notification: 14 January 2019
Camera-ready copy due: 3 February 2019
Workshop: 24 February 2019 (co-located with NDSS 2019)
Location: Catamaran Resort Hotel & Spa in San Diego, California, USA=

Submission Instructions

Submissions should be non-anonymous, and consist of a mai= n body and,
optionally, well-marked appendices. For papers that have already been
= published, submission should include a cover letter (at most 2 pages)
= commenting on what the workshop presentation would contain, appended
with the published paper. For papers not already formally published,
the main body should be about 12 pages in length with reasonable
margins and fonts. Appendices are optional and unlimited in length;
however, Workshop Technical Program Committee members may base their
decisions solely on the contents of the main bodies of submissions.

We also invite short papers of up to 6 pages covering wor= k in
progress, short communications, as well as novel or provocative ideas. Short papers will be selected based on their potential to spark
interesting discussions during the workshop. They should be about 6
pages in length. We expect to be flexible on length and format given
relevant submissions.

Papers should be submitted at https://din19.hotcrp.com

Technical Programm Committee

  • Melinda Shore, Fastly (co-chair)
  • Dirk Kutscher, Huawei (co-chair)
  • Marcelo Bagnulo, UC3M
  • Shehar Bano, University College London
  • Carsten Bormann, Universit=C3=A4t Bremen
  • Jon Crowcroft, University of Cambridge
  • Thomas Hardjono, MIT Trust::Data Consortium
  • Christian Huitema, Private Octopus
  • Liubingyang, Huawei
  • Paulo Mendes, Universidade Lus=C3=B3fona de Humanidades e Tecnologias=
  • Dave Oran, Network Systems Research & Design
  • J=C3=B6rg Ott, TU Munich
  • Christian Esteve Rothenberg, University of Campinas
  • Keshav Srinivasan, University of Waterloo
  • Jean-Luc Watson, University of California, Berkely
  • Lixia Zhang, UCLA

--=_MailMate_CE4F67FD-7AC8-4387-BF68-CF557D1721AC_=--