From nobody Thu Feb 9 07:10:02 2017 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D6F129426; Thu, 9 Feb 2017 07:09:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148665298718.20582.12448967677193038623.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 07:09:47 -0800 Archived-At: Cc: ben@nostrum.com, ari.keranen@ericsson.com, ice@ietf.org, ice-chairs@ietf.org Subject: [Ice] ice - Not having a session at IETF 98 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:09:47 -0000 Ari Keränen, a chair of the ice working group, indicated that the ice working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Fri Feb 17 13:46:52 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4433129BF1 for ; Fri, 17 Feb 2017 13:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 HDTAWv_t-6K7 for ; Fri, 17 Feb 2017 13:46:50 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 7E1C6129BF4 for ; Fri, 17 Feb 2017 13:46:50 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id t8so36704814vke.3 for ; Fri, 17 Feb 2017 13:46:50 -0800 (PST) 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=aAw18ui3Q91SFA9FOXz9f4C6S9djvXR5n90ZIGfasVs=; b=NYiDWE9eW699ZFvB6r+2vn5IHFTuKH38jK9WbnOI2yVhGhDLyOWqlzEsXK4fSNRdnV ExXBdlszd+ALAWP0COyDs7MrokiXf3ZEBraTknZPiqO19vp09AubmUC/QYmvLXP6dgyl KvtvKNNKjYV48N5aV7qiwTf7PwoKuq5dkfD6VJ+iJ5NsAyOtCtRK2pgXkTfwJ/hInVfR /pvxkwNlmXtvLi8S6dkfCWciyTbVBItdX5DeY/fxooOiQ2KVQF0HFwO9Nfa1hLQiMbiC T8iR83k8Yluat81Aj41wNylhLY1WzYKCIEQNryhtHJwvKMasGCEJ75WovT8E1qX1YeRe b19Q== 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=aAw18ui3Q91SFA9FOXz9f4C6S9djvXR5n90ZIGfasVs=; b=dQSIvQ+J2HLphpS6rTnDRE8+9ZkSnZfdmJBgnL4tURnEDMOMn7PLSFsz1/+i+2ER4H HYlsdy87S4XH7cTXttuprJtqPdbmbIfxIznnJAJtx+mSdkJPpe9kAcKWKrFJc20KAoiR qXmc90cRnVEmSNNn1jttQmzzBFKiSDgkMDEUzChSNKdb9Q6ZDhSiQdJGOdz2axEX+ftG SV0q1jEenhc1eqxn5bZHIQb0sePRpNut6iWg4BrW6Xw54vmizFJf6yqE9SNcZe/+oC3H LlBa+fY3JqkerySKa7GnIuMDw1NKnzFyIpr6Riy7Ni4pU79Cks8rN6gSxJbhAsN1cGhq 4/og== X-Gm-Message-State: AMke39kwBiGsWeS3wBlmnyrfMxRR8qQk+o1CjY/fEnP/WGJ++8Uo1d3AcASngKke8rPBUn2W7OfBEfTmCI4riQ== X-Received: by 10.31.227.193 with SMTP id a184mr4984111vkh.106.1487368009162; Fri, 17 Feb 2017 13:46:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Fri, 17 Feb 2017 13:46:28 -0800 (PST) From: Bernard Aboba Date: Fri, 17 Feb 2017 13:46:28 -0800 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114df80ad627c40548c0d93a Archived-At: Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 21:46:52 -0000 --001a114df80ad627c40548c0d93a Content-Type: text/plain; charset=UTF-8 Roman said: "We have encountered a few large corporate installations that only allowed TLS connections to port 443." [BA] We have also encountered these deployments, and initially implemented a "fake" TLS handshake along the lines that Peter describes. However, we found that some customers had installed deep packet inspection boxes that could tell the difference between a "fake" TLS handshake and a real one. So having a standardized way to do TLS candidates would be a good idea. On Tue, Jan 24, 2017 at 4:21 PM, Peter Thatcher wrote: > Our implementation of ICE has a type of candidate called "SSLTCP" which > does a fake TLS handshake to get through firewalls that only allow TLS > connections. We've been using it for years. And I'm guessing some of our > web products would appreciate that being in other browsers as well, so we > may be interested in seeing it as part of the standard (or a less fake > version of it). But I don't have any stats about how often those work but > normal TCP candidates don't, so I can't say for sure how useful it really > is. --001a114df80ad627c40548c0d93a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Roman said:=C2=A0


"We have encountered a few larg= e corporate installations that only allowed TLS connections to port 443." 
[BA] We have also encountered these deployments, and initially imple=
mented a "fake" TLS handshake along the lines that Peter describe=
s. However, we found that some customers had installed deep packet inspecti=
on boxes that could tell the difference between a "fake" TLS hand=
shake and a real one. So having a standardized way to do TLS candidates wou=
ld be a good idea.
On Tue, Ja=
n 24, 2017 at 4:21 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> Our implementation of ICE has a type of candidate called "SSLTCP&=
quot; which
> does a fake TLS handshake to get through firewalls that only allow TLS
> connections.  We've been using it for years.  And I'm guessing=
 some of our
> web products would appreciate that being in other browsers as well, so=
 we
> may be interested in seeing it as part of the standard (or a less fake
> version of it).  But I don't have any stats about how often those =
work but
> normal TCP candidates don't, so I can't say for sure how usefu=
l it really
> is.
--001a114df80ad627c40548c0d93a-- From nobody Fri Feb 17 13:56:02 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734CB1299C8 for ; Fri, 17 Feb 2017 13:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 ki2GpT9GJhC8 for ; Fri, 17 Feb 2017 13:55:58 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 9019C1296DC for ; Fri, 17 Feb 2017 13:55:58 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id t8so36810790vke.3 for ; Fri, 17 Feb 2017 13:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NsP8fO22sJyej7XpLXsuhBTTOVHDTYbtFxSvlrwNOZ4=; b=Wy4HwhBsil4u+aARjypSIPlLXfyRWGRBFR7gv3TrdIjC4BsZHW6DOPYDcgNHQ/xCir iT3QQd/lmXgVtxaxfYRr1vFe2PaymP6YRIKYzJLV52U7bzNc126DvYnEqyeFSQYlvLso ze40/UwPTUj/BAhguSX7gKJ45bvwPAbp/lCOId3ayMgtLv1dtyOCXF4D+BiSPNNVQcqE KeMkYK51p+pn2UKMFSJp0Z4rrU6FAH2CGRvgM0w3LRJy0EZkd1mQqAfVyixRnry36vYK mjrQ8BTZ+SF+ogBi6NRRW7Kcm3khZ82cv0PhDiOTli4DjVpiVpO+cKjAe1/PyB5IhfwA UPCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NsP8fO22sJyej7XpLXsuhBTTOVHDTYbtFxSvlrwNOZ4=; b=aB2IzZnc+bnmGDYqGS2+5UikEravF0tvymUQMIiuxgcYcp8hVkIDvouktlL9yYUr+v dgqHdF84o689YCf40JeJm714WmcxCUSCpNSVRVcYmTK40u5H8avc0lgAtM159teN84Pe 2Ra4Jb7TozlHr5KAXWIibUov0qcnY1AbG7Xt/pSsfuMODWgmxPn/cIyDXWRoZQgvVABX +q32+vxYexdOvqHCUV3PqQIJALYWMLtsJWu72PfG0il9BfkRwygx+93e6bBMJiRHHykx xCG8+KTb+NHECeNg9XCAbLYc+mCFZA0/lLcmRM/yDErmR12hl2kSdN1U/tZjBhwahTmS r6Sw== X-Gm-Message-State: AMke39kDYUjKjTZ/uUF1G28RmrKtoMil5C1Y+ZmyyRZ2hTIZ5vj19xO1pg2YbxVRoM7ShPVqg2EtWlCV86yzRQ== X-Received: by 10.31.125.76 with SMTP id y73mr5078793vkc.5.1487368557602; Fri, 17 Feb 2017 13:55:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Fri, 17 Feb 2017 13:55:37 -0800 (PST) In-Reply-To: <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> References: <148491768993.13355.16722423940569276403.idtracker@ietfa.amsl.com> <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> From: Bernard Aboba Date: Fri, 17 Feb 2017 13:55:37 -0800 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=94eb2c14996286b23b0548c0fae7 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 21:56:00 -0000 --94eb2c14996286b23b0548c0fae7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have read this draft, and like it. In practice there are enough customers restricting connectivity via UDP or TLS to make it worthwhile to implement TLS candidates. My experience is that customers who only allow TLS to port 443 also tend to impose other restrictions, such as forcing connections through an HTTPS proxy of some kind. So the considerations discussed in Section 6 are quite important. On Mon, Jan 23, 2017 at 11:28 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi all, > > There is a need for TLS candidates. We did an implementations, so we > thought is was a good idea to write up a draft. > > Is this something others are interested in as well? > (As there seems to be no ICE meeting next IETF it would be nice to get th= e > discussion started on the list) > > .-. > P=C3=A5l-Erik > > Begin forwarded message: > > *From: * > *Subject: **New Version Notification for > draft-martinsen-ice-tls-candidates-00.txt* > *Date: *20 January 2017 at 14:08:09 GMT+1 > *To: *Nathan Buckles , Paal-Erik Martinsen < > palmarti@cisco.com> > > > A new version of I-D, draft-martinsen-ice-tls-candidates-00.txt > has been successfully submitted by Paal-Erik Martinsen and posted to the > IETF repository. > > Name: draft-martinsen-ice-tls-candidates > Revision: 00 > Title: TLS Candidates for ICE > Document date: 2017-01-20 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft- > martinsen-ice-tls-candidates-00.txt > Status: https://datatracker.ietf.org/doc/draft-martinsen- > ice-tls-candidates/ > Htmlized: https://tools.ietf.org/html/draft-martinsen-ice-tls- > candidates-00 > > > Abstract: > This document introduces TLS candidates to ICE. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --94eb2c14996286b23b0548c0fae7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read this draft, and like it.=C2=A0 In practice the= re are enough customers restricting connectivity via UDP or TLS to make it = worthwhile to implement TLS candidates.

My experience is= that customers who only allow TLS to port 443 also tend to impose other re= strictions, such as forcing connections through an HTTPS proxy of some kind= .=C2=A0 So the considerations discussed in Section 6 are quite important.= =C2=A0

On Mon, Jan 23, 2017 at 11:28 AM, Pal Martinsen (palmarti) <palmarti@cis= co.com> wrote:
Hi all,

There is a need for TLS candidates. We did an implementations, so we t= hought is was a good idea to write up a draft.

Is this something others are interested in as well?
(As there seems to be no ICE meeting next IETF it would be nice to get= the discussion started on the list)

.-.
P=C3=A5l-Erik

Begin forwarded message:

Subject: New Version Notification for draft-martinsen-ice-tls= -candidates-00.txt
Date: 20 January 2017 at 14:08:09 GMT+1
To: Nathan Buckles <nbuckles@cisco.com>, Paal-Erik Martinsen <palmarti@cisco.com= >


A new version of I-D, draft-martinsen-ice-tls-candidates-00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository.

Name: draft-martinsen-ice-tls-candidat= es
Revision: 00
Title: TLS Candidates for ICE
Document date: 2017-01-20
Group: Individual Submission
Pages: 6
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/dra= ft-martinsen-ice-tls-candidates-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-martinsen-ice-tls-can= didates/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://= tools.ietf.org/html/draft-martinsen-ice-tls-candidates-00


Abstract:
=C2=A0=C2=A0This document introduces TLS candidates to ICE.




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

The IETF Secretariat



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


--94eb2c14996286b23b0548c0fae7-- From nobody Wed Feb 22 13:05:45 2017 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 918C6129B57; Wed, 22 Feb 2017 13:05:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 13:05:43 -0800 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-trickle-06.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 21:05:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Peter Saint-Andre Filename : draft-ietf-ice-trickle-06.txt Pages : 28 Date : 2017-02-22 Abstract: This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 27 01:13:16 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5F128E19 for ; Mon, 27 Feb 2017 01:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 qY0PD99gzLgZ for ; Mon, 27 Feb 2017 01:13:12 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 7B634128824 for ; Mon, 27 Feb 2017 01:13:12 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id v186so56191701wmd.0 for ; Mon, 27 Feb 2017 01:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=keCQZLomd7uDVIzUBIUcVZY+w87qQhO5jFlifYY6s0g=; b=tENuO6s3m6GnZfduc4A2TJXKlP+HiainoBVOlWVDlanc5Rd18sSZcQpmJdWKzZUSQM a5GwiKNy5vTxOBPQGk0fv9ZJAoQDXiAxW/p2KdLOSVCzh7jVF7v1+xPZ2YNVgSawHX5X pbxT+9c5nCswRdf8oFSVj4NgTgD68LediZYbmlaBKNFQcqTcQiblikeVmKA/Is6W+lfJ 95P9a66WYNH48/cvV2Ij/vfbR8KuAHvAp+Z+uvAoxSXd867mQz8jeM5ZHioUs9LNmCkB Jgc5H5J+E4OIZR8QZ7xnIWFPd7EekfzP/6XvLT8LyQnp14Q6yWcDcje6uj0us8n5zUR+ lfzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=keCQZLomd7uDVIzUBIUcVZY+w87qQhO5jFlifYY6s0g=; b=MhnglrUa9YBEsJA4YLh8fgMOoaIqkZDUsDJTqAsM74oA5dlnoFAkI5akdkDmTIu6kw x7IAC/PBtCq5fhHw2B2KiGYWJlVbf3ANrMb2Bui/WdQzEFzxlVq/tkZ7EmJyEL7AgPLQ yUwfqIxOhikaEuVTs0VQl+W5T9RNGVt4YaXUnejz89StRzUHWsysTp1d/rZ+2Y7szwl5 ZUKHpli9UuJAOH8zW0f5/9gUFMefqnNNgSA3i1YUUVCyPMy7WvirVzUPk4y7DK2Tkw1F Q0BpOCorbToDQBbHQ6QhThn3mgRY07FF7HjJwteOBAaxwoYHC06AuhlwJvm2xeQCIlYZ QLFw== X-Gm-Message-State: AMke39lc4tzHX2Nbtvh5OSsmW4mLKcA1iE21WGcJ6UrxtJyyon0mToXb3o8Uu9gJ0Iw4QA== X-Received: by 10.28.63.15 with SMTP id m15mr13146758wma.119.1488186790804; Mon, 27 Feb 2017 01:13:10 -0800 (PST) Received: from [192.168.2.114] (dsl-linz7-19-68.utaonline.at. [81.189.19.68]) by smtp.googlemail.com with ESMTPSA id i189sm13465684wmg.7.2017.02.27.01.13.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 01:13:10 -0800 (PST) To: ice@ietf.org References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> From: Thomas Stach Message-ID: Date: Mon, 27 Feb 2017 10:13:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 09:13:14 -0000 Hi, I'm a bit confused about the definition of an ICE Generation and how it is used in Section 14 Generation: The complete set of candidates sent within an ICE negotiation session. Section 14 and the definition of Half/Full Trickle then uses terms like "first generation" "complete generation", "the responder can respond with an incomplete generation of candidates", "full generation" This seems to imply that the generation is not necessarily the complete set of candidates, but could grow during aICE Negotiation Session until end-of-candidates is signalled. So the generation rather seems to be the extensible set of currently known/exchanged candidates. It is also not clear to me if the candidates sent by the ICE initiator and the ICE responder belong to different generations or if the generation is the union of both candidate sets. Could you please clarify? Regards Thomas On 2017-02-22 22:05, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interactive Connectivity Establishment of the IETF. > > Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol > Authors : Emil Ivov > Eric Rescorla > Justin Uberti > Peter Saint-Andre > Filename : draft-ietf-ice-trickle-06.txt > Pages : 28 > Date : 2017-02-22 > > Abstract: > This document describes "Trickle ICE", an extension to the > Interactive Connectivity Establishment (ICE) protocol that enables > ICE agents to send and receive candidates incrementally rather than > exchanging complete lists. With such incremental provisioning, ICE > agents can begin connectivity checks while they are still gathering > candidates and considerably shorten the time necessary for ICE > processing to complete. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ice-trickle-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > From nobody Mon Feb 27 13:53:38 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F61293FF for ; Mon, 27 Feb 2017 13:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=UUNvKe1E; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=bxxSWo8f 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 YDzngxO-Otip for ; Mon, 27 Feb 2017 13:53:35 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62631279EB for ; Mon, 27 Feb 2017 13:53:35 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 282B711BB; Mon, 27 Feb 2017 16:53:35 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 27 Feb 2017 16:53:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=r12pJev7jeMHWVk EG/QL8lgWvPk=; b=UUNvKe1El8zEY00su9rTczgdTAw2h16FC7etrIxhNLXBtgc EWM+3qUrhoTq93fcCSJPqvEOYmLzYP/BsFB/VeiQgFgLpAOu+AXeuuirqwiykUGO YEUrxIGck2InjgZh8YKJc55G3GETQgyZRD5oW7in3566yA8NkyA5Y1KEiA9w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=r12pJev7jeMHWVkEG/QL8lgWvPk=; b=bxxSWo8fnKv/Ex2CPKUI uxB/3Hhp2ILp52lLkVXSj+A4IXLiwfWjxFgOa4HgAg9ShRwJ6Jsu3grgh4wEADbn VQ7rl3/5ruRmGKUKG2NNYrzrjwzNTKxFfy+MgSvkP3wNA9bainYpW6vdewvPDe8T oAhP1+LjUEF0m+cLUrjo2Vs= X-ME-Sender: X-Sasl-enc: ro2Ksx1huld7nvyJ+uCl53F8CJZeKOxrmTmsY9ARtwOp 1488232414 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F3AC241DA; Mon, 27 Feb 2017 16:53:34 -0500 (EST) To: Thomas Stach , ice@ietf.org References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: Date: Mon, 27 Feb 2017 14:53:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:53:37 -0000 On 2/27/17 2:13 AM, Thomas Stach wrote: > Hi, > > I'm a bit confused about the definition of an ICE Generation and how it > is used in Section 14 To be clear for folks on the list, this is in reference to the trickle draft. > Generation: The complete set of candidates sent within an ICE > negotiation session. > > > > Section 14 and the definition of Half/Full Trickle then uses terms like > "first generation" > "complete generation", For half trickle purposes, I think it would be best to use the phrase "full generation" or even "complete set of candidates". That is: under half trickle, in the initial ICE description the initiator sends all the candidates it might possibly send. > "the responder can respond with an incomplete generation of candidates", > > "full generation" > > This seems to imply that the generation is not necessarily the complete > set of candidates, The generation is as defined above: the complete set of candidates sent within an ICE negotiation session. It would be better here to use the phrase "incomplete set of candidates". > but could grow during aICE Negotiation Session until end-of-candidates > is signalled. > So the generation rather seems to be the extensible set of currently > known/exchanged candidates. No, the generation is everything sent before an ICE restart (if any). In trickle the set can grow over time, whereas in regular ICE it can't. > It is also not clear to me if the candidates sent by the ICE initiator > and the ICE responder > belong to different generations or if the generation is the union of > both candidate sets. It is the union. Peter From nobody Mon Feb 27 13:55:57 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0B2129401 for ; Mon, 27 Feb 2017 13:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.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 VzJCS97cb-C3 for ; Mon, 27 Feb 2017 13:55:54 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 43B841279EB for ; Mon, 27 Feb 2017 13:55:54 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id n127so119963139qkf.0 for ; Mon, 27 Feb 2017 13:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bKj02d3S/kvrP4MH09BsAjmFNlxhjxAwNYN/dQsgxsE=; b=hNRqEbPYCVQZgGzFDtU3K/vVL4EiwdlCoUVA464yAmNvFllKM/dyYCVE8U9vVRNCCN 4+Tf0i+TC6XI5nEyd88vOxqSBoNSkibEe/cPIcE/qKChbMgUG0ZLW0TjvckA2+zWuKAY AHXjEfHBuLRW+jK9oDErkijEneU0kcQCSxiMWsr63xpYehAoK73194Pk2990F7a9474l WNoOlqKi/nHgKJvTpftfVrx9J1+CoJS0derZe4umBYO0HaGMgDOr93ixHm7rYJsJnaiw P5xgkWEMFSDA1S41Q0+pooowdYDha8TibY/HOn/+kYfZChx17KvA8xYPqdRZqn0sZSvK CVYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bKj02d3S/kvrP4MH09BsAjmFNlxhjxAwNYN/dQsgxsE=; b=Q1wWQL3myT3nnD+PMUCGVfxf4JVPLHCVgWOgc3dgAvrLyOMmRLVNy34We+wxc4Soul iykvla9bfYyjxqIJt+J09pyzyKaQ67WnUNXbgxC0uVQPrl72fXMqS0Nd/wM+PdrdWjpe iVqVYAobOoBc798J9Mj690vYZze4uUU5A4bim1n9X9sZ+a50BOJLniHnePE1a5G+n31n FoPUGQPqoxTtdhTOdaHctnsi18GqbDE3h8xVRKGncheB4AF02K7J6NycLcSVfOB+v5Tb csFO8daoXWcWgzWEXFw05qGqOsM+i35qNYgWxu0uFoaTa9MgQFoH6CyXskhZJRxAkMTn 8gUA== X-Gm-Message-State: AMke39l3nHqwVMOmfejMRLJMVHHWl5B8SG7y5sY1IkiPQLBS/fd7EgOS6pwtSiM8fIha/5dkDGSaVyfYw2+bvkX+ X-Received: by 10.55.166.210 with SMTP id p201mr3235910qke.142.1488232553336; Mon, 27 Feb 2017 13:55:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.163 with HTTP; Mon, 27 Feb 2017 13:55:52 -0800 (PST) In-Reply-To: References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> From: Taylor Brandstetter Date: Mon, 27 Feb 2017 13:55:52 -0800 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=94eb2c06efbcafb3c505498a24a9 Archived-At: Cc: Thomas Stach , ice@ietf.org Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:55:56 -0000 --94eb2c06efbcafb3c505498a24a9 Content-Type: text/plain; charset=UTF-8 Another way of looking at it is that a given generation is identified by a local/remote ufrag pair, which will change on ICE restart. On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre wrote: > On 2/27/17 2:13 AM, Thomas Stach wrote: > > Hi, > > > > I'm a bit confused about the definition of an ICE Generation and how it > > is used in Section 14 > > To be clear for folks on the list, this is in reference to the trickle > draft. > > > Generation: The complete set of candidates sent within an ICE > > negotiation session. > > > > > > > > Section 14 and the definition of Half/Full Trickle then uses terms like > > "first generation" > > "complete generation", > > For half trickle purposes, I think it would be best to use the phrase > "full generation" or even "complete set of candidates". That is: under > half trickle, in the initial ICE description the initiator sends all the > candidates it might possibly send. > > > "the responder can respond with an incomplete generation of candidates", > > > > "full generation" > > > > This seems to imply that the generation is not necessarily the complete > > set of candidates, > > The generation is as defined above: the complete set of candidates sent > within an ICE negotiation session. It would be better here to use the > phrase "incomplete set of candidates". > > > but could grow during aICE Negotiation Session until end-of-candidates > > is signalled. > > So the generation rather seems to be the extensible set of currently > > known/exchanged candidates. > > No, the generation is everything sent before an ICE restart (if any). In > trickle the set can grow over time, whereas in regular ICE it can't. > > > It is also not clear to me if the candidates sent by the ICE initiator > > and the ICE responder > > belong to different generations or if the generation is the union of > > both candidate sets. > > It is the union. > > Peter > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --94eb2c06efbcafb3c505498a24a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another way of looking at it is that a given generation is= identified by a local/remote ufrag pair, which will change on ICE restart.=

On Mon, Feb= 27, 2017 at 1:53 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 2/27/17 2:13= AM, Thomas Stach wrote:
> Hi,
>
> I'm a bit confused about the definition of an ICE Generation and h= ow it
> is used in Section 14

To be clear for folks on the list, this is in reference to the trick= le
draft.

>=C2=A0 =C2=A0 Generation:=C2=A0 The complete set of candidates sent wit= hin an ICE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0negotiation session.
>
>
>
> Section 14 and the definition of Half/Full Trickle then uses terms lik= e
> "first generation"
> "complete generation",

For half trickle purposes, I think it would be best to use the phras= e
"full generation" or even "complete set of candidates".= That is: under
half trickle, in the initial ICE description the initiator sends all the candidates it might possibly send.

> "the responder can respond with an incomplete generation of candi= dates",
>
> "full generation"
>
> This seems to imply that the generation is not necessarily the complet= e
> set of candidates,

The generation is as defined above: the complete set of candidates s= ent
within an ICE negotiation session. It would be better here to use the
phrase "incomplete set of candidates".

> but could grow during aICE Negotiation Session until end-of-candidates=
> is signalled.
> So the generation rather seems to be the extensible set of currently > known/exchanged candidates.

No, the generation is everything sent before an ICE restart (if any)= . In
trickle the set can grow over time, whereas in regular ICE it can't.
> It is also not clear to me if the candidates sent by the ICE initiator=
> and the ICE responder
> belong to=C2=A0 different generations or if the generation is the unio= n of
> both candidate sets.

It is the union.

Peter


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

--94eb2c06efbcafb3c505498a24a9-- From nobody Mon Feb 27 13:58:00 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D574129405 for ; Mon, 27 Feb 2017 13:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=MV85tMWQ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=dPfdSW+p 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 WMIQWWUXNNpi for ; Mon, 27 Feb 2017 13:57:58 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAC9129401 for ; Mon, 27 Feb 2017 13:57:57 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 459B3125D; Mon, 27 Feb 2017 16:57:57 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 27 Feb 2017 16:57:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=3L9/B21vlxdKp7y 9+9jwcau7DTc=; b=MV85tMWQ0yNaS59lZsCm9UDBhlh7PZZEcggipyojIGeflZj qpyjqKgWIfoOPeK43eQ8xO3avXI7S8Jwy4APLplsp+y3p/B7+VmsIyng/lWqgL/y fyHzCmlVuargVhQmDvKUYy8wuGDmbOX5xugDsax0gHYObSySu8/R5pRLdwAs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=3L9/B21vlxdKp7y9+9jwcau7DTc=; b=dPfdSW+p1gmqovQ1kkcv klxU+VPGyBG/2sKerCutNrV1H/KWlBXzBLMrFeMTzezpxBNzeSFf/e4k8LzIrDP+ +irEM1VR61AwX1qP3ErsSYltgOFzOnQfVf7zuFTHsBphyB310Esu6gESLWUIdaAO sC89YiwszoRiJkLmfWrGKpw= X-ME-Sender: X-Sasl-enc: 5JgM9B1ti8arZhkCUHeVWsAlY46ydbzpGp+6jgADQR00 1488232676 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 753322428D; Mon, 27 Feb 2017 16:57:56 -0500 (EST) To: Taylor Brandstetter References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <73898e41-dd66-e0be-0415-e5753880f0d1@stpeter.im> Date: Mon, 27 Feb 2017 14:57:55 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Thomas Stach , ice@ietf.org Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:57:59 -0000 Exactly. Would it help to describe it that way or at least note the connection? On 2/27/17 2:55 PM, Taylor Brandstetter wrote: > Another way of looking at it is that a given generation is identified by > a local/remote ufrag pair, which will change on ICE restart. > > On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre > wrote: > > On 2/27/17 2:13 AM, Thomas Stach wrote: > > Hi, > > > > I'm a bit confused about the definition of an ICE Generation and how it > > is used in Section 14 > > To be clear for folks on the list, this is in reference to the trickle > draft. > > > Generation: The complete set of candidates sent within an ICE > > negotiation session. > > > > > > > > Section 14 and the definition of Half/Full Trickle then uses terms like > > "first generation" > > "complete generation", > > For half trickle purposes, I think it would be best to use the phrase > "full generation" or even "complete set of candidates". That is: under > half trickle, in the initial ICE description the initiator sends all the > candidates it might possibly send. > > > "the responder can respond with an incomplete generation of candidates", > > > > "full generation" > > > > This seems to imply that the generation is not necessarily the complete > > set of candidates, > > The generation is as defined above: the complete set of candidates sent > within an ICE negotiation session. It would be better here to use the > phrase "incomplete set of candidates". > > > but could grow during aICE Negotiation Session until end-of-candidates > > is signalled. > > So the generation rather seems to be the extensible set of currently > > known/exchanged candidates. > > No, the generation is everything sent before an ICE restart (if any). In > trickle the set can grow over time, whereas in regular ICE it can't. > > > It is also not clear to me if the candidates sent by the ICE initiator > > and the ICE responder > > belong to different generations or if the generation is the union of > > both candidate sets. > > It is the union. > > Peter > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > From nobody Mon Feb 27 14:39:01 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9425812943B for ; Mon, 27 Feb 2017 14:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.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 tUmjxfNSeOmj for ; Mon, 27 Feb 2017 14:38:58 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9972E1293FE for ; Mon, 27 Feb 2017 14:38:58 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n186so44850422qkb.3 for ; Mon, 27 Feb 2017 14:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HGaAPq7/OfbHs4Lil4plPPVdR4A5j5AriPka5ECGhmE=; b=NKXlqJXdaFN+B/SgAv3JjTayM42i8+6PtHHOheJdD7aG6QbdsDZ0Wj9pEm9BizzbcF avwPi6N+nWM5dJeX9UbGNHNbZpRefpophgPRw4eUihPWlhxBVdkY6E8GVnUM8PCKIR0I MDHUK8gkaybBhKPiM2gdFplWzTtLvmLWJoGzN8z6NgnDsJt18xV465GY9Zw3tsB9cwwY j8hu2q9+0AX94PZBLWAnzp+x8HUuwmPyFdd8h4zepDwyOjCW/+3EZvD8r1GLf8wQSeaQ 1w74kbVKDUZPGuEYuzu2mvAt+rpzqWR2W62fKS/pWxatN+gnV2OPb+Udg16IuxpKLS13 eTFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HGaAPq7/OfbHs4Lil4plPPVdR4A5j5AriPka5ECGhmE=; b=FD/kA5yiBql7NlxoYMxArzbH6gi+3ZKHxw/1T0vcUir5VkOSarVhufre6LVcErZX2S enbdDxAFUGez0d00dDC5XajO2wfy1faCb/HAavwjhKpPhsiHo60OzE7xKvauieOd8hwS nylhqnPASTniDwmo0U7Cl2GJrf5iArxwRsm9u1PZCLeRs6WP9E2vUWnlPPI6yt3jBfqY hlC5G5QlArIsULTk+hKI14ufLGKUWOm0WhRwdOr8AafyY5IQQ6wRJcCZyoAWMnsrwvNz 82CT+RMHGcEw+zpjzHfD0Aba56UdkcrzkBf96i9vsAj+W3Ivtdtc9BmWFeqD1Cfh8JNT eSIg== X-Gm-Message-State: AMke39kjX9R9LdXGO3NwNI85bMocF9YchVGd7UNq6h+ptINBMMMdrg9TH7sgsk6XLv2DGk1GZIXr8UPUfr4PL6YG X-Received: by 10.237.54.162 with SMTP id f31mr18103396qtb.2.1488235137552; Mon, 27 Feb 2017 14:38:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.163 with HTTP; Mon, 27 Feb 2017 14:38:57 -0800 (PST) In-Reply-To: <73898e41-dd66-e0be-0415-e5753880f0d1@stpeter.im> References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> <73898e41-dd66-e0be-0415-e5753880f0d1@stpeter.im> From: Taylor Brandstetter Date: Mon, 27 Feb 2017 14:38:57 -0800 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a1146f022b7996505498abe2d Archived-At: Cc: Thomas Stach , ice@ietf.org Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:39:00 -0000 --001a1146f022b7996505498abe2d Content-Type: text/plain; charset=UTF-8 Noting the connection sounds good. On Mon, Feb 27, 2017 at 1:57 PM, Peter Saint-Andre wrote: > Exactly. Would it help to describe it that way or at least note the > connection? > > On 2/27/17 2:55 PM, Taylor Brandstetter wrote: > > Another way of looking at it is that a given generation is identified by > > a local/remote ufrag pair, which will change on ICE restart. > > > > On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre > > wrote: > > > > On 2/27/17 2:13 AM, Thomas Stach wrote: > > > Hi, > > > > > > I'm a bit confused about the definition of an ICE Generation and > how it > > > is used in Section 14 > > > > To be clear for folks on the list, this is in reference to the > trickle > > draft. > > > > > Generation: The complete set of candidates sent within an ICE > > > negotiation session. > > > > > > > > > > > > Section 14 and the definition of Half/Full Trickle then uses terms > like > > > "first generation" > > > "complete generation", > > > > For half trickle purposes, I think it would be best to use the phrase > > "full generation" or even "complete set of candidates". That is: > under > > half trickle, in the initial ICE description the initiator sends all > the > > candidates it might possibly send. > > > > > "the responder can respond with an incomplete generation of > candidates", > > > > > > "full generation" > > > > > > This seems to imply that the generation is not necessarily the > complete > > > set of candidates, > > > > The generation is as defined above: the complete set of candidates > sent > > within an ICE negotiation session. It would be better here to use the > > phrase "incomplete set of candidates". > > > > > but could grow during aICE Negotiation Session until > end-of-candidates > > > is signalled. > > > So the generation rather seems to be the extensible set of > currently > > > known/exchanged candidates. > > > > No, the generation is everything sent before an ICE restart (if > any). In > > trickle the set can grow over time, whereas in regular ICE it can't. > > > > > It is also not clear to me if the candidates sent by the ICE > initiator > > > and the ICE responder > > > belong to different generations or if the generation is the union > of > > > both candidate sets. > > > > It is the union. > > > > Peter > > > > > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > https://www.ietf.org/mailman/listinfo/ice > > > > > > > > --001a1146f022b7996505498abe2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Noting the connection sounds good.

On Mon, Feb 27, 2017 at 1:57 PM, Pe= ter Saint-Andre <stpeter@stpeter.im> wrote:
Exactly. Would it help to describe it that way or at lea= st note the
connection?

On 2/27/17 2:55 PM, Taylor Brandstetter wrote:
> Another way of looking at it is that a given generation is identified = by
> a local/remote ufrag pair, which will change on ICE restart.
>
> On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stpeter@stpeter.im>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 2/27/17 2:13 AM, Thomas Stach wrote:
>=C2=A0 =C2=A0 =C2=A0> Hi,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I'm a bit confused about the definition of= an ICE Generation and how it
>=C2=A0 =C2=A0 =C2=A0> is used in Section 14
>
>=C2=A0 =C2=A0 =C2=A0To be clear for folks on the list, this is in refer= ence to the trickle
>=C2=A0 =C2=A0 =C2=A0draft.
>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Generation:=C2=A0 The complete se= t of candidates sent within an ICE
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0negotiation session.=
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 14 and the definition of Half/Full Tri= ckle then uses terms like
>=C2=A0 =C2=A0 =C2=A0> "first generation"
>=C2=A0 =C2=A0 =C2=A0> "complete generation",
>
>=C2=A0 =C2=A0 =C2=A0For half trickle purposes, I think it would be best= to use the phrase
>=C2=A0 =C2=A0 =C2=A0"full generation" or even "complete = set of candidates". That is: under
>=C2=A0 =C2=A0 =C2=A0half trickle, in the initial ICE description the in= itiator sends all the
>=C2=A0 =C2=A0 =C2=A0candidates it might possibly send.
>
>=C2=A0 =C2=A0 =C2=A0> "the responder can respond with an incomp= lete generation of candidates",
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> "full generation"
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This seems to imply that the generation is not= necessarily the complete
>=C2=A0 =C2=A0 =C2=A0> set of candidates,
>
>=C2=A0 =C2=A0 =C2=A0The generation is as defined above: the complete se= t of candidates sent
>=C2=A0 =C2=A0 =C2=A0within an ICE negotiation session. It would be bett= er here to use the
>=C2=A0 =C2=A0 =C2=A0phrase "incomplete set of candidates". >
>=C2=A0 =C2=A0 =C2=A0> but could grow during aICE Negotiation Session= until end-of-candidates
>=C2=A0 =C2=A0 =C2=A0> is signalled.
>=C2=A0 =C2=A0 =C2=A0> So the generation rather seems to be the exten= sible set of currently
>=C2=A0 =C2=A0 =C2=A0> known/exchanged candidates.
>
>=C2=A0 =C2=A0 =C2=A0No, the generation is everything sent before an ICE= restart (if any). In
>=C2=A0 =C2=A0 =C2=A0trickle the set can grow over time, whereas in regu= lar ICE it can't.
>
>=C2=A0 =C2=A0 =C2=A0> It is also not clear to me if the candidates s= ent by the ICE initiator
>=C2=A0 =C2=A0 =C2=A0> and the ICE responder
>=C2=A0 =C2=A0 =C2=A0> belong to=C2=A0 different generations or if th= e generation is the union of
>=C2=A0 =C2=A0 =C2=A0> both candidate sets.
>
>=C2=A0 =C2=A0 =C2=A0It is the union.
>
>=C2=A0 =C2=A0 =C2=A0Peter
>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Ice mailing list
>=C2=A0 =C2=A0 =C2=A0Ice@iet= f.org <mailto:Ice@ietf.org> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/ice
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/ice>
>
>


--001a1146f022b7996505498abe2d-- From nobody Mon Feb 27 14:42:37 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17D7129443 for ; Mon, 27 Feb 2017 14:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=TOyCdkz/; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Ver1HgCW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-oxiznwTVtV for ; Mon, 27 Feb 2017 14:42:33 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67123129442 for ; Mon, 27 Feb 2017 14:42:33 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id C5979C71; Mon, 27 Feb 2017 17:42:32 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 27 Feb 2017 17:42:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=3Jmt6EVu7YOK27P Qg3UvSXW+Z+8=; b=TOyCdkz/jLFuXCDh+Q0nBI4CQgeQF03Yc/5NjaAIlnrxYEk ceJWwmKcDXZyQaYP7ADi9cje7MzoNrtYyCn+NGGAGFwoUAoZ81WDonVbU4FemUhl NFLL8FSBtuYiCYaVScAw4QkeXLtMJdbRDyrPmwuont5dY/vx0UxhXKLDWopU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=3Jmt6EVu7YOK27PQg3UvSXW+Z+8=; b=Ver1HgCWx7mfB5VLnUIL mAZqYM2Wh5LmsfuNSVMKYWqzJEdvPXn0E2xX4FU6uUpkTqkT8VYEzRJrEuRUusck KuE4JT/JKQoF2GahSjXhAgrAY/WHBwHb+d2FghQgU0n5+f27kg6VS6H7+ZvmIGi/ 76fqbZjds2uIkKN5aIgJH0Q= X-ME-Sender: X-Sasl-enc: PWrgx1exZgV2GE8/az3hnMuRpaN1r9vYFlns952Hpvz/ 1488235352 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id EC50E24526; Mon, 27 Feb 2017 17:42:31 -0500 (EST) To: Taylor Brandstetter References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> <73898e41-dd66-e0be-0415-e5753880f0d1@stpeter.im> From: Peter Saint-Andre Message-ID: <44a40b79-b6c5-2abd-3a82-4e05a3831001@stpeter.im> Date: Mon, 27 Feb 2017 15:42:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Thomas Stach , ice@ietf.org Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:42:35 -0000 I'm going to quickly submit -07 with relevant adjustments. On 2/27/17 3:38 PM, Taylor Brandstetter wrote: > Noting the connection sounds good. > > On Mon, Feb 27, 2017 at 1:57 PM, Peter Saint-Andre > wrote: > > Exactly. Would it help to describe it that way or at least note the > connection? > > On 2/27/17 2:55 PM, Taylor Brandstetter wrote: > > Another way of looking at it is that a given generation is identified by > > a local/remote ufrag pair, which will change on ICE restart. > > > > On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre > > >> wrote: > > > > On 2/27/17 2:13 AM, Thomas Stach wrote: > > > Hi, > > > > > > I'm a bit confused about the definition of an ICE Generation > and how it > > > is used in Section 14 > > > > To be clear for folks on the list, this is in reference to the > trickle > > draft. > > > > > Generation: The complete set of candidates sent within > an ICE > > > negotiation session. > > > > > > > > > > > > Section 14 and the definition of Half/Full Trickle then uses > terms like > > > "first generation" > > > "complete generation", > > > > For half trickle purposes, I think it would be best to use the > phrase > > "full generation" or even "complete set of candidates". That > is: under > > half trickle, in the initial ICE description the initiator > sends all the > > candidates it might possibly send. > > > > > "the responder can respond with an incomplete generation of > candidates", > > > > > > "full generation" > > > > > > This seems to imply that the generation is not necessarily > the complete > > > set of candidates, > > > > The generation is as defined above: the complete set of > candidates sent > > within an ICE negotiation session. It would be better here to > use the > > phrase "incomplete set of candidates". > > > > > but could grow during aICE Negotiation Session until > end-of-candidates > > > is signalled. > > > So the generation rather seems to be the extensible set of > currently > > > known/exchanged candidates. > > > > No, the generation is everything sent before an ICE restart > (if any). In > > trickle the set can grow over time, whereas in regular ICE it > can't. > > > > > It is also not clear to me if the candidates sent by the ICE > initiator > > > and the ICE responder > > > belong to different generations or if the generation is the > union of > > > both candidate sets. > > > > It is the union. > > > > Peter > > > > > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > > https://www.ietf.org/mailman/listinfo/ice > > > > > > > > > > From nobody Mon Feb 27 14:55:18 2017 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C708E129443; Mon, 27 Feb 2017 14:55:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148823611680.13787.5875994564257689476.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 14:55:16 -0800 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-trickle-07.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:55:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Peter Saint-Andre Filename : draft-ietf-ice-trickle-07.txt Pages : 28 Date : 2017-02-27 Abstract: This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 27 22:43:12 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9FF1294CD for ; Mon, 27 Feb 2017 22:43:10 -0800 (PST) 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 NiNLOa1Sp-0L for ; Mon, 27 Feb 2017 22:43:09 -0800 (PST) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 853171293F4 for ; Mon, 27 Feb 2017 22:43:09 -0800 (PST) Received: by mail-wr0-x242.google.com with SMTP id g10so359348wrg.0 for ; Mon, 27 Feb 2017 22:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=E8YSg9D3zteMhDk5IfdtENtr8RSS1L77E3r/fD2R450=; b=AtriMT+u3lIaUBoWXeQwrEvNR1bQlCZKESlgse8co5jzt5YX0hwNDWGgzI4U5/4uzf 7oxSTa8xXZD3B2+v6dkx5AP8rycJHmh0P0xQBYPdw6AIY46nq/T7N5CkIdy3XOWJgS3O bp6Tuqwntr8HwzurLg7VpGFxRjchS7xs7XVuqFxri3Laz6GjzUvPFl7cYELKGGAfOFQh f8NxV9l0RHADJF9QPMwEUs2UO7KJtuINBj+H05HqCqWQYth7vy3T7QiG7ieF1sUIerDs LdAmB3wK6gtMBv7AtbU87RlTtWPJo3pSYc95ykWnkU5fmvAK/HOM1JPJgfP5r9C8ghgH BXkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=E8YSg9D3zteMhDk5IfdtENtr8RSS1L77E3r/fD2R450=; b=l8FMX0x1b9790mEfkaynI7uf/nu3pRaX/CQ5xUermYc9o3o/NHBb54m0OKUaetbUdN zeAUCEH5BXnES7/cj9mg9HrqW5ndJpF1QaEIhbTcgIdNmAkH4diwtsaXy1zD5QK+Ohdy qny2RPXRw8vlDoMHhbkp+NuX7y//QCyLwGHozwEn4YLzkZGSihyugsvrBRErJN7qOuPA S0BdPabnThWQzZWxHJVLNkgZ5qOSpNpy749zBaJWSy0Z/ZPOfYA3fUTgXGM+qgLHFFUz hFQ4hiP9SeYzuSuGkkDAVNc3uszkGLJltZi2EmWssOlcFzMq9cJdZimU9iewSI0Ea3Lq f9mw== X-Gm-Message-State: AMke39nJoM6sNbRwqpUyVUjEcbbJ5qC4Sra+mmAPdPzO8zLIlT/OzzL0963ovftU0gQJaQ== X-Received: by 10.223.171.237 with SMTP id s100mr606663wrc.23.1488264187860; Mon, 27 Feb 2017 22:43:07 -0800 (PST) Received: from [192.168.2.114] (dsl-linz7-19-68.utaonline.at. [81.189.19.68]) by smtp.googlemail.com with ESMTPSA id i189sm17239819wmg.7.2017.02.27.22.43.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 22:43:07 -0800 (PST) To: Peter Saint-Andre , ice@ietf.org References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> From: Thomas Stach Message-ID: Date: Tue, 28 Feb 2017 07:43:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 06:43:11 -0000 Peter, thanks for the reply. More inline On 2017-02-27 22:53, Peter Saint-Andre wrote: > On 2/27/17 2:13 AM, Thomas Stach wrote: >> Hi, >> >> I'm a bit confused about the definition of an ICE Generation and how it >> is used in Section 14 > To be clear for folks on the list, this is in reference to the trickle > draft. > >> Generation: The complete set of candidates sent within an ICE >> negotiation session. >> >> >> >> Section 14 and the definition of Half/Full Trickle then uses terms like >> "first generation" >> "complete generation", > For half trickle purposes, I think it would be best to use the phrase > "full generation" or even "complete set of candidates". That is: under > half trickle, in the initial ICE description the initiator sends all the > candidates it might possibly send. OK. Since I learned from below that the generation is the union, the term "set of candidates" seems to be the better choice when it comes to describing what the initiator/responder sends. > >> "the responder can respond with an incomplete generation of candidates", >> >> "full generation" >> >> This seems to imply that the generation is not necessarily the complete >> set of candidates, > The generation is as defined above: the complete set of candidates sent > within an ICE negotiation session. It would be better here to use the > phrase "incomplete set of candidates". Agree > >> but could grow during aICE Negotiation Session until end-of-candidates >> is signalled. >> So the generation rather seems to be the extensible set of currently >> known/exchanged candidates. > No, the generation is everything sent before an ICE restart (if any). In > trickle the set can grow over time, whereas in regular ICE it can't. Understood > >> It is also not clear to me if the candidates sent by the ICE initiator >> and the ICE responder >> belong to different generations or if the generation is the union of >> both candidate sets. > It is the union. Thanks for clarifying. Thomas > > Peter > > From nobody Mon Feb 27 22:43:37 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BAB1293F4 for ; Mon, 27 Feb 2017 22:43:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi8VgOzDEt0a for ; Mon, 27 Feb 2017 22:43:34 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 986581294CD for ; Mon, 27 Feb 2017 22:43:33 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id g10so1936784wrg.2 for ; Mon, 27 Feb 2017 22:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=UCDE7zFRnkz45bUTyPW3WhrliQy7NbccRVirlFeuTV8=; b=l73nxtmXaJGCA1iXnLS8iUhWWpjDSXP7zvxumI3gv7wV9DlB0lNJVtPSCYJ53rtWGv RCUlMxjellpAQK5X33pxJruUzlMLTGhk1cm3npabUxX2fGUCg/HdksNJX9qIluO8MKyj B3g9CbrOoTqYkpgedbGtxf6jTS2VWFOSduNWx6c/48/gbV0+sd7g5DPySlp+2F4sU3Ag AzuKgg14OK3GxDW+oM/av0OMbXjZYDIuiHJMFSFqf4orzcc59G9Up1HnWt5+Ou5SRqZ4 xpboRSS1RZmkR8io3YMj8a/ieIHpdupUBuXpGrlpuyzXpQ0kVA8eICVfOKj98UjeZH7z fM8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=UCDE7zFRnkz45bUTyPW3WhrliQy7NbccRVirlFeuTV8=; b=KXB6PALNbdIahFTJK5R4hebLxYtyzbPXiPzcC6S4VLACZnk5hYWfJOynQzgP8tKu7A LfklhgxspLfee3zAOQwzxFAjyUq2nWoNv0wO4EI+UbFE0mS/yOMgVy1fWVPgg7OgkO/E kazvSaAnuZ2OTuhPWiiqSkq7uXXpHFyH3NCfHuAM3kkRezoN5AAIQDszwv1x8vb/j26/ 3zrcbJNNZlEanvb09jA8MwcnN13gfboeG1dZj9SRYRfLhlscnJ34DHipJ2x4M5IJ7C12 ELEoR3TtBfJdmt55WTufl09F7+IuDN+Ieudu4blH6uvsVRqIuoowVk8c1namYTfNhdMf xFXg== X-Gm-Message-State: AMke39l6KLu7U8SuF6fsSHPGQFwdDHPfo30aLEHwVf4i9UEGUQH0FVKphkjOVF4plJewvQ== X-Received: by 10.223.167.138 with SMTP id j10mr644544wrc.178.1488264212173; Mon, 27 Feb 2017 22:43:32 -0800 (PST) Received: from [192.168.2.114] (dsl-linz7-19-68.utaonline.at. [81.189.19.68]) by smtp.googlemail.com with ESMTPSA id v1sm891727wra.65.2017.02.27.22.43.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 22:43:31 -0800 (PST) To: Taylor Brandstetter , Peter Saint-Andre References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> <73898e41-dd66-e0be-0415-e5753880f0d1@stpeter.im> From: Thomas Stach Message-ID: <2156e67b-7711-691e-2a47-9445646fab9d@gmail.com> Date: Tue, 28 Feb 2017 07:43:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------53CABE59838164DE992CCA6F" Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 06:43:35 -0000 This is a multi-part message in MIME format. --------------53CABE59838164DE992CCA6F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit +1 On 2017-02-27 23:38, Taylor Brandstetter wrote: > Noting the connection sounds good. > > On Mon, Feb 27, 2017 at 1:57 PM, Peter Saint-Andre > wrote: > > Exactly. Would it help to describe it that way or at least note the > connection? > > On 2/27/17 2:55 PM, Taylor Brandstetter wrote: > > Another way of looking at it is that a given generation is > identified by > > a local/remote ufrag pair, which will change on ICE restart. > > > > On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre > > > >> wrote: > > > > On 2/27/17 2:13 AM, Thomas Stach wrote: > > > Hi, > > > > > > I'm a bit confused about the definition of an ICE > Generation and how it > > > is used in Section 14 > > > > To be clear for folks on the list, this is in reference to > the trickle > > draft. > > > > > Generation: The complete set of candidates sent within > an ICE > > > negotiation session. > > > > > > > > > > > > Section 14 and the definition of Half/Full Trickle then > uses terms like > > > "first generation" > > > "complete generation", > > > > For half trickle purposes, I think it would be best to use > the phrase > > "full generation" or even "complete set of candidates". That > is: under > > half trickle, in the initial ICE description the initiator > sends all the > > candidates it might possibly send. > > > > > "the responder can respond with an incomplete generation > of candidates", > > > > > > "full generation" > > > > > > This seems to imply that the generation is not necessarily > the complete > > > set of candidates, > > > > The generation is as defined above: the complete set of > candidates sent > > within an ICE negotiation session. It would be better here > to use the > > phrase "incomplete set of candidates". > > > > > but could grow during aICE Negotiation Session until > end-of-candidates > > > is signalled. > > > So the generation rather seems to be the extensible set of > currently > > > known/exchanged candidates. > > > > No, the generation is everything sent before an ICE restart > (if any). In > > trickle the set can grow over time, whereas in regular ICE > it can't. > > > > > It is also not clear to me if the candidates sent by the > ICE initiator > > > and the ICE responder > > > belong to different generations or if the generation is > the union of > > > both candidate sets. > > > > It is the union. > > > > Peter > > > > > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > > https://www.ietf.org/mailman/listinfo/ice > > > > > > > > > > --------------53CABE59838164DE992CCA6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

+1


On 2017-02-27 23:38, Taylor Brandstetter wrote:
Noting the connection sounds good.

On Mon, Feb 27, 2017 at 1:57 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
Exactly. Would it help to describe it that way or at least note the
connection?

On 2/27/17 2:55 PM, Taylor Brandstetter wrote:
> Another way of looking at it is that a given generation is identified by
> a local/remote ufrag pair, which will change on ICE restart.
>
> On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stpeter@stpeter.im>> wrote:
>
>     On 2/27/17 2:13 AM, Thomas Stach wrote:
>     > Hi,
>     >
>     > I'm a bit confused about the definition of an ICE Generation and how it
>     > is used in Section 14
>
>     To be clear for folks on the list, this is in reference to the trickle
>     draft.
>
>     >    Generation:  The complete set of candidates sent within an ICE
>     >       negotiation session.
>     >
>     >
>     >
>     > Section 14 and the definition of Half/Full Trickle then uses terms like
>     > "first generation"
>     > "complete generation",
>
>     For half trickle purposes, I think it would be best to use the phrase
>     "full generation" or even "complete set of candidates". That is: under
>     half trickle, in the initial ICE description the initiator sends all the
>     candidates it might possibly send.
>
>     > "the responder can respond with an incomplete generation of candidates",
>     >
>     > "full generation"
>     >
>     > This seems to imply that the generation is not necessarily the complete
>     > set of candidates,
>
>     The generation is as defined above: the complete set of candidates sent
>     within an ICE negotiation session. It would be better here to use the
>     phrase "incomplete set of candidates".
>
>     > but could grow during aICE Negotiation Session until end-of-candidates
>     > is signalled.
>     > So the generation rather seems to be the extensible set of currently
>     > known/exchanged candidates.
>
>     No, the generation is everything sent before an ICE restart (if any). In
>     trickle the set can grow over time, whereas in regular ICE it can't.
>
>     > It is also not clear to me if the candidates sent by the ICE initiator
>     > and the ICE responder
>     > belong to  different generations or if the generation is the union of
>     > both candidate sets.
>
>     It is the union.
>
>     Peter
>
>
>     _______________________________________________
>     Ice mailing list
>     Ice@ietf.org <mailto:Ice@ietf.org>
>     https://www.ietf.org/mailman/listinfo/ice
>     <https://www.ietf.org/mailman/listinfo/ice>
>
>



--------------53CABE59838164DE992CCA6F-- From nobody Tue Feb 28 12:58:31 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324FD1296EE for ; Tue, 28 Feb 2017 12:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=C5EVr+eY; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=fnDPMnOk 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 WRXLesVEszks for ; Tue, 28 Feb 2017 12:58:28 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681BA1296E9 for ; Tue, 28 Feb 2017 12:58:28 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 345C615B3; Tue, 28 Feb 2017 15:58:25 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 28 Feb 2017 15:58:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=HlnpVqnwqiL7B02 6/+y6k6+Vd5A=; b=C5EVr+eYf8UlEhHroAtMs/st6Q7QgYbAJ1RLf9vBD587cN4 D8UMFePaQ+x0ixjmo0F9ZO9jCjT16HViyz0QIQ/YmIE8hvgARhtPOFOCAS9hpPaw XKhQIRHRAvevWYPWRletMsPBouN8nMGV9gh+AeTmE3B+HJjxgqrR9aRdDXmg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=HlnpVqnwqiL7B026/+y6k6+Vd5A=; b=fnDPMnOkbJzS4YhroXEt EqjcatWnMC34KwSLEBYS34n95Gy04/pmBo7aR62ywiA38r7jzVKCgvAKQWQU7bCP DlOpnP+T3HP2h2tPYJh5YhQNrvz+EHinZQVIOX/CQC64SWfS1i6CgtCvVQpt+meU lP+o2FBtjsd7jBv/ctwOPBg= X-ME-Sender: X-Sasl-enc: VsmhWwDT+qczSiSalWLTaytK6af4Udg0xvVvxWxduMGx 1488315504 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 3643D7E0D2; Tue, 28 Feb 2017 15:58:24 -0500 (EST) To: Thomas Stach , Taylor Brandstetter References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> <73898e41-dd66-e0be-0415-e5753880f0d1@stpeter.im> <2156e67b-7711-691e-2a47-9445646fab9d@gmail.com> From: Peter Saint-Andre Message-ID: <52d540f2-806d-4a42-1b63-acee92238e33@stpeter.im> Date: Tue, 28 Feb 2017 13:58:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2156e67b-7711-691e-2a47-9445646fab9d@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:58:30 -0000 Hi Thomas, please check the diff to see if I've addressed your concerns: https://tools.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-07.txt Thanks! Peter On 2/27/17 11:43 PM, Thomas Stach wrote: > +1 > > > On 2017-02-27 23:38, Taylor Brandstetter wrote: >> Noting the connection sounds good. >> >> On Mon, Feb 27, 2017 at 1:57 PM, Peter Saint-Andre > > wrote: >> >> Exactly. Would it help to describe it that way or at least note the >> connection? >> >> On 2/27/17 2:55 PM, Taylor Brandstetter wrote: >> > Another way of looking at it is that a given generation is >> identified by >> > a local/remote ufrag pair, which will change on ICE restart. >> > >> > On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre >> >> > >> wrote: >> > >> > On 2/27/17 2:13 AM, Thomas Stach wrote: >> > > Hi, >> > > >> > > I'm a bit confused about the definition of an ICE >> Generation and how it >> > > is used in Section 14 >> > >> > To be clear for folks on the list, this is in reference to >> the trickle >> > draft. >> > >> > > Generation: The complete set of candidates sent within >> an ICE >> > > negotiation session. >> > > >> > > >> > > >> > > Section 14 and the definition of Half/Full Trickle then >> uses terms like >> > > "first generation" >> > > "complete generation", >> > >> > For half trickle purposes, I think it would be best to use >> the phrase >> > "full generation" or even "complete set of candidates". That >> is: under >> > half trickle, in the initial ICE description the initiator >> sends all the >> > candidates it might possibly send. >> > >> > > "the responder can respond with an incomplete generation >> of candidates", >> > > >> > > "full generation" >> > > >> > > This seems to imply that the generation is not necessarily >> the complete >> > > set of candidates, >> > >> > The generation is as defined above: the complete set of >> candidates sent >> > within an ICE negotiation session. It would be better here >> to use the >> > phrase "incomplete set of candidates". >> > >> > > but could grow during aICE Negotiation Session until >> end-of-candidates >> > > is signalled. >> > > So the generation rather seems to be the extensible set of >> currently >> > > known/exchanged candidates. >> > >> > No, the generation is everything sent before an ICE restart >> (if any). In >> > trickle the set can grow over time, whereas in regular ICE >> it can't. >> > >> > > It is also not clear to me if the candidates sent by the >> ICE initiator >> > > and the ICE responder >> > > belong to different generations or if the generation is >> the union of >> > > both candidate sets. >> > >> > It is the union. >> > >> > Peter >> > >> > >> > _______________________________________________ >> > Ice mailing list >> > Ice@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/ice >> >> > > > >> > >> > >> >> > From nobody Tue Feb 28 23:02:04 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330AC1294B5 for ; Tue, 28 Feb 2017 23:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 4AdbFzrN3rOl for ; Tue, 28 Feb 2017 23:02:01 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6661294A7 for ; Tue, 28 Feb 2017 23:02:01 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id v77so5638267wmv.0 for ; Tue, 28 Feb 2017 23:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5v0nRPVpDKeQZPIMzK4hW3gt1bIx0Zpddyo8NqpHOCQ=; b=bPDVQAAvN9lxubgEILbOO6kQ0MJv+QirfDq6aOPqE4M0DA2nRRNt7kt1c6Nec2mQfu PoYwr55p0Ku7wbpmqO2BCwENSrv5JGNDtFiquz+YmfvLgaPpyLkCEQ7ZJLXIjhLFApxN b1MR6OoNBnBxSUePNnk4xU+eAjB1wkGTQxqEhUnEmufFTZ9kG1O0eDHosj7Vu6FxC9T3 5em+XxuG3Ds0gb1PY6szwuq/3VUa2kCa7Lbf7IW280f3BweOMKQGdk2RuWTUGpuyBG2P dgeO3jFnBrplTvJScCH9bMW1hkmCOxsy83mCJ3AWgft4PPfoDtTtrLdOnrRJ1DO1m64d WemA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5v0nRPVpDKeQZPIMzK4hW3gt1bIx0Zpddyo8NqpHOCQ=; b=QMX9jf77+dN8+CjsQuacNHatsvBpVJONq47iapNhMXBPjNYaeu2JwD4WqhxpP9hw7Q x/7rtWPs2sWD8xO5ns+gcCEk2ycfKynDb5h2sJkIpl9mTFVKh6qh23INzr5QSzSYykE8 6AQOHPn3WEpFKBzaf3VkHyT5vgtmna1rR/Pe/o8HWxbFC3qAVVMi9j3Bh03zj6IUMxAa 5DIU5Mqhw6aZMi8LTdXto06nzdVWfZojlKLKmPFWJ1L1TGwmwTjliHS92v9Y8x7lXANM hpqJ5MdAnliVLskBvk2y0ydmeKdSxKAieG5tszJmLLRP7lmHQCdgXQuSkPnFeC1ZGgR/ K7Jw== X-Gm-Message-State: AMke39kdMSYw6s9Mh5/YHqbZjDu8FMO67hByXwhl0m+K8JqC/Y0MrW84G7ohc1gyh0XoFQ== X-Received: by 10.28.226.215 with SMTP id z206mr1756029wmg.92.1488351719581; Tue, 28 Feb 2017 23:01:59 -0800 (PST) Received: from [192.168.2.114] (dsl-linz7-19-68.utaonline.at. [81.189.19.68]) by smtp.googlemail.com with ESMTPSA id y1sm5591679wme.15.2017.02.28.23.01.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 23:01:58 -0800 (PST) To: Peter Saint-Andre , Taylor Brandstetter References: <148779754359.31167.11057689797490201951.idtracker@ietfa.amsl.com> <73898e41-dd66-e0be-0415-e5753880f0d1@stpeter.im> <2156e67b-7711-691e-2a47-9445646fab9d@gmail.com> <52d540f2-806d-4a42-1b63-acee92238e33@stpeter.im> From: Thomas Stach Message-ID: Date: Wed, 1 Mar 2017 08:01:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <52d540f2-806d-4a42-1b63-acee92238e33@stpeter.im> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] ICE Generation clarification questions X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 07:02:03 -0000 Peter, this addresses my comments. "something less than a full generation" is probably not the most elegant term, but it does the job. Thanks Thomas On 2017-02-28 21:58, Peter Saint-Andre wrote: > Hi Thomas, please check the diff to see if I've addressed your concerns: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-07.txt > > Thanks! > > Peter > > On 2/27/17 11:43 PM, Thomas Stach wrote: >> +1 >> >> >> On 2017-02-27 23:38, Taylor Brandstetter wrote: >>> Noting the connection sounds good. >>> >>> On Mon, Feb 27, 2017 at 1:57 PM, Peter Saint-Andre >> > wrote: >>> >>> Exactly. Would it help to describe it that way or at least note the >>> connection? >>> >>> On 2/27/17 2:55 PM, Taylor Brandstetter wrote: >>> > Another way of looking at it is that a given generation is >>> identified by >>> > a local/remote ufrag pair, which will change on ICE restart. >>> > >>> > On Mon, Feb 27, 2017 at 1:53 PM, Peter Saint-Andre >>> >>> > >> wrote: >>> > >>> > On 2/27/17 2:13 AM, Thomas Stach wrote: >>> > > Hi, >>> > > >>> > > I'm a bit confused about the definition of an ICE >>> Generation and how it >>> > > is used in Section 14 >>> > >>> > To be clear for folks on the list, this is in reference to >>> the trickle >>> > draft. >>> > >>> > > Generation: The complete set of candidates sent within >>> an ICE >>> > > negotiation session. >>> > > >>> > > >>> > > >>> > > Section 14 and the definition of Half/Full Trickle then >>> uses terms like >>> > > "first generation" >>> > > "complete generation", >>> > >>> > For half trickle purposes, I think it would be best to use >>> the phrase >>> > "full generation" or even "complete set of candidates". That >>> is: under >>> > half trickle, in the initial ICE description the initiator >>> sends all the >>> > candidates it might possibly send. >>> > >>> > > "the responder can respond with an incomplete generation >>> of candidates", >>> > > >>> > > "full generation" >>> > > >>> > > This seems to imply that the generation is not necessarily >>> the complete >>> > > set of candidates, >>> > >>> > The generation is as defined above: the complete set of >>> candidates sent >>> > within an ICE negotiation session. It would be better here >>> to use the >>> > phrase "incomplete set of candidates". >>> > >>> > > but could grow during aICE Negotiation Session until >>> end-of-candidates >>> > > is signalled. >>> > > So the generation rather seems to be the extensible set of >>> currently >>> > > known/exchanged candidates. >>> > >>> > No, the generation is everything sent before an ICE restart >>> (if any). In >>> > trickle the set can grow over time, whereas in regular ICE >>> it can't. >>> > >>> > > It is also not clear to me if the candidates sent by the >>> ICE initiator >>> > > and the ICE responder >>> > > belong to different generations or if the generation is >>> the union of >>> > > both candidate sets. >>> > >>> > It is the union. >>> > >>> > Peter >>> > >>> > >>> > _______________________________________________ >>> > Ice mailing list >>> > Ice@ietf.org >> > >>> > https://www.ietf.org/mailman/listinfo/ice >>> >>> > >> > >>> > >>> > >>> >>> >