From shengjiang@huawei.com Sun Nov 8 21:53:56 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51D93A68FA for ; Sun, 8 Nov 2009 21:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvWMuMh-ZFIb for ; Sun, 8 Nov 2009 21:53:56 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 13A813A68CB for ; Sun, 8 Nov 2009 21:53:56 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KST0040FV2BZ6@szxga04-in.huawei.com> for grobj@ietf.org; Mon, 09 Nov 2009 13:54:11 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KST004QBV2BZT@szxga04-in.huawei.com> for grobj@ietf.org; Mon, 09 Nov 2009 13:54:11 +0800 (CST) Received: from [133.93.19.88] (host-19-88.meeting.ietf.org [133.93.19.88]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KST00CU0V2AVO@szxml01-in.huawei.com>; Mon, 09 Nov 2009 13:54:11 +0800 (CST) Date: Mon, 09 Nov 2009 13:54:12 +0800 From: Sheng Jiang To: grobj@ietf.org, Dan Wing Message-id: <4AF7AE84.6090405@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Subject: [grobj] Updated GROB Agenda, 15:10~16:10, Wednesday, November 11, 2009 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:53:56 -0000 ------------------------------------------------------------------- GROBJ BoF agenda WEDNESDAY, November 11, 2009 1510-1610 Afternoon Session II ------------------------------------------------------------------- CHAIRS: Sheng Jiang, Dan Wing AGENDA: 1. Administrivia (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Presentation - Why we are here & Clarification questions (Dan Wing, BoF Chair, 10 mins) - Referral requirements (Bo Zhou, 5 mins) draft-bo-behave-ref-req - Problem and strawman proposal (Brian Carpenter, 20 mins) draft-carpenter-behave-referral-object 3. Open discussion (15 min) 4. Conclusions and Next Steps (Chairs/ADs, 5 min) From simon.perreault@viagenie.ca Wed Nov 11 02:27:54 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815BE3A69A5 for ; Wed, 11 Nov 2009 02:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn0LMuKiSywM for ; Wed, 11 Nov 2009 02:27:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8356D3A6833 for ; Wed, 11 Nov 2009 02:27:50 -0800 (PST) Received: from host-16-233.meeting.ietf.org (unknown [IPv6:2001:dfb:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 00AB821159 for ; Wed, 11 Nov 2009 05:28:17 -0500 (EST) Message-ID: <4AFA91BF.2010808@viagenie.ca> Date: Wed, 11 Nov 2009 19:28:15 +0900 From: Simon Perreault User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: grobj@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:27:54 -0000 Hello, So today at the BoF meeting people felt that the problem was not clearly defined. This was also my feeling. Right now, the problem that application developers have is simple: they want to do something ICE-like but they end up mostly recreating the wheel every time. A clear and easy to understand problem. And clearly solvable too: rip ICE out of the SIP world and create a stand-alone, versatile protocol for communicating candidates and performing connectivity checks. In comparison, I'm not convinced that exchanging bunches of pointers to a host in a standard format is a problem that application developers have currently. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From zhouboyj@gmail.com Wed Nov 11 02:35:31 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00003A6A69 for ; Wed, 11 Nov 2009 02:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=0.919, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzUZfjwyDheG for ; Wed, 11 Nov 2009 02:35:30 -0800 (PST) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id B10253A69DC for ; Wed, 11 Nov 2009 02:35:30 -0800 (PST) Received: by iwn16 with SMTP id 16so825805iwn.29 for ; Wed, 11 Nov 2009 02:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PS5tsCfeSU6HQZjOBXFkdNCRMwhDJ/TbXR1ABDUhAtI=; b=p722v3Sb7ng490X084DmRZ9PW/XyQ9B/N/op7LhkvGnHsg+T4kC6W187EN8v2r6qCW 74PDs/0kzWoKItberbMGT2MeJJ2VeuGkZtYCZtYQYB0UXeylSvFQXePa94YKVIFhdXlX g7kNnfBz2jXLaKHKpLe96XgYSpvnhP4glPJC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jgKhJJCpN0Pgli4/3GhIGZfjtUGYjtkqkzlg1qIBVXuKK4BKYbNt1b6QKDU/2R9s45 g7dJm8IDZq7kAijFgdU7tls0MXJq5YjlentbfVfVJyUG7mSnMq2h5THtVBw2xdSyXbkH ncmB5ltHJg5tktJotJWQMpIY6FjYmA6p0gOlU= MIME-Version: 1.0 Received: by 10.231.161.138 with SMTP id r10mr556738ibx.34.1257935755139; Wed, 11 Nov 2009 02:35:55 -0800 (PST) In-Reply-To: <4AFA91BF.2010808@viagenie.ca> References: <4AFA91BF.2010808@viagenie.ca> Date: Wed, 11 Nov 2009 18:35:55 +0800 Message-ID: <36a593230911110235o3875c022i93e83c12f5556c6c@mail.gmail.com> From: bo zhou To: Simon Perreault Content-Type: multipart/alternative; boundary=001636c5971bd5d9e6047815fda8 Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:35:31 -0000 --001636c5971bd5d9e6047815fda8 Content-Type: text/plain; charset=ISO-8859-1 As chair said, maybe we should define the problem more clearly if we really want to make this as a work in IETF. I can support this problem statement work voluntarily. Regards, Bo On Wed, Nov 11, 2009 at 6:28 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Hello, > > So today at the BoF meeting people felt that the problem was not clearly > defined. > > This was also my feeling. Right now, the problem that application > developers have is simple: they want to do something ICE-like but they > end up mostly recreating the wheel every time. A clear and easy to > understand problem. And clearly solvable too: rip ICE out of the SIP > world and create a stand-alone, versatile protocol for communicating > candidates and performing connectivity checks. > > In comparison, I'm not convinced that exchanging bunches of pointers to > a host in a standard format is a problem that application developers > have currently. > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj > -- Regards, Bo Zhou China Mobile --001636c5971bd5d9e6047815fda8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As chair said, maybe we should define the problem more clearly if we r= eally want to make this as a work in IETF.
I can support this=A0problem statement work=A0voluntarily.
=A0
Regards,
=A0
Bo

On Wed, Nov 11, 2009 at 6:28 PM, Simon Perreault= <simon= .perreault@viagenie.ca> wrote:
Hello,

So today at the Bo= F meeting people felt that the problem was not clearly
defined.

This was also my feeling. Right now, the problem that application
develo= pers have is simple: they want to do something ICE-like but they
end up = mostly recreating the wheel every time. A clear and easy to
understand p= roblem. And clearly solvable too: rip ICE out of the SIP
world and create a stand-alone, versatile protocol for communicating
can= didates and performing connectivity checks.

In comparison, I'm n= ot convinced that exchanging bunches of pointers to
a host in a standard= format is a problem that application developers
have currently.

Simon
--
DNS64 open-so= urce =A0 --> h= ttp://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0--> http://numb.viagenie.ca
vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org
___________________________= ____________________
grobj mailing list
grobj@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/grobj



--
Regards,

Bo Zhou
China Mobile --001636c5971bd5d9e6047815fda8-- From brian.e.carpenter@gmail.com Wed Nov 11 14:29:58 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8990B3A6A3A for ; Wed, 11 Nov 2009 14:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlKpmKGnzXX5 for ; Wed, 11 Nov 2009 14:29:57 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 53DEE3A6966 for ; Wed, 11 Nov 2009 14:29:57 -0800 (PST) Received: by fxm7 with SMTP id 7so1587579fxm.29 for ; Wed, 11 Nov 2009 14:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qWww1ScYgv41XG/0qw7Waru8U+4Q/Mgid2eUQuf4Ty8=; b=QfFe2TjdWLfyLeQgg7J0YYfZHmItJUpb6E+b99Gqybe9dk0ju2jBZ6q7hWRwdkoja1 4WorJ92wDb5qUp0kacCJotalPGnanYnOTS4n0wj5JJ/sqq11rgnL4OdRRDVh0rrrUpZQ q3zB5ytMTzh8CGCpND1VMAyNb3/79VpbpY/a0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=iw59U3tQG6+yp448UcRJP7Vm71BJjOPjek6VfjC3If1hHw5TBsvkdMVaXXskCzIHFR Ed+T2gQApNt7EqoNokoOcnRSFztqhsdsmhqmgurZxdy2STVfrhiDw8pVJt3Lx8JxQUXm x+0D0bGMV9/lTzxOtP3zG+4cwgaqC81EzwIro= Received: by 10.204.34.84 with SMTP id k20mr2174988bkd.199.1257978619281; Wed, 11 Nov 2009 14:30:19 -0800 (PST) Received: from ?133.93.128.64? (host-128-64.meeting.ietf.org [133.93.128.64]) by mx.google.com with ESMTPS id 14sm708537bwz.5.2009.11.11.14.30.16 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 14:30:18 -0800 (PST) Message-ID: <4AFB3AEC.5010608@gmail.com> Date: Thu, 12 Nov 2009 11:30:04 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: bo zhou References: <4AFA91BF.2010808@viagenie.ca> <36a593230911110235o3875c022i93e83c12f5556c6c@mail.gmail.com> In-Reply-To: <36a593230911110235o3875c022i93e83c12f5556c6c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 22:29:58 -0000 Yes, it's clear that a problem statement is the next step, and it is very important to avoid "solutionism" in that work. Both the existing draft, and Simon's note below, show clear evidence of solutionism ;-) I think getting a clear common understanding of the problem between Layer 3 and Apps people is the most important thing. Regards Brian Carpenter On 2009-11-11 23:35, bo zhou wrote: > As chair said, maybe we should define the problem more clearly if we really > want to make this as a work in IETF. > I can support this problem statement work voluntarily. > > Regards, > > Bo > > On Wed, Nov 11, 2009 at 6:28 PM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > >> Hello, >> >> So today at the BoF meeting people felt that the problem was not clearly >> defined. >> >> This was also my feeling. Right now, the problem that application >> developers have is simple: they want to do something ICE-like but they >> end up mostly recreating the wheel every time. A clear and easy to >> understand problem. And clearly solvable too: rip ICE out of the SIP >> world and create a stand-alone, versatile protocol for communicating >> candidates and performing connectivity checks. >> >> In comparison, I'm not convinced that exchanging bunches of pointers to >> a host in a standard format is a problem that application developers >> have currently. >> >> Simon >> -- >> DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> vCard 4.0 --> http://www.vcarddav.org >> _______________________________________________ >> grobj mailing list >> grobj@ietf.org >> https://www.ietf.org/mailman/listinfo/grobj >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj From swb@employees.org Wed Nov 11 15:31:47 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0E13A6B5E for ; Wed, 11 Nov 2009 15:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7biIbnw8KrNC for ; Wed, 11 Nov 2009 15:31:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BF4813A696C for ; Wed, 11 Nov 2009 15:31:46 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEALbY+kpAZnwM/2dsb2JhbACBTcN3mAuEPASCZg X-IronPort-AV: E=Sophos;i="4.44,726,1249257600"; d="scan'208";a="67526404" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2009 23:32:14 +0000 Received: from host-24-56.meeting.ietf.org (rtp-vpn5-189.cisco.com [10.82.232.189]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABNWDcH018039; Wed, 11 Nov 2009 23:32:14 GMT Message-ID: <4AFB497D.1080901@employees.org> Date: Thu, 12 Nov 2009 08:32:13 +0900 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simon Perreault References: <4AFA91BF.2010808@viagenie.ca> In-Reply-To: <4AFA91BF.2010808@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:31:47 -0000 Simon Perreault allegedly wrote on 11/11/2009 7:28 PM: > So today at the BoF meeting people felt that the problem was not clearly > defined. > > This was also my feeling. Right now, the problem that application > developers have is simple: they want to do something ICE-like I disagree that this is what app developers want. If ICE was not necessary for some apps, those app developers would be pleased not to have to use it. As Brian said, let's avoid point solutionism. But it is good to point out scenarios where there are problems with referrals, and that is what should go into the draft in order to guide it. Scott From brian.e.carpenter@gmail.com Wed Nov 11 19:57:48 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69C028C1E5 for ; Wed, 11 Nov 2009 19:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv0qB+kjtcRa for ; Wed, 11 Nov 2009 19:57:48 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 041A628C1DA for ; Wed, 11 Nov 2009 19:57:47 -0800 (PST) Received: by gxk28 with SMTP id 28so1704877gxk.9 for ; Wed, 11 Nov 2009 19:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DML5F3IHsJK2M0xXJSfut5UyKLhP+u2EtS1JCAodye8=; b=sPxwQz2WOT+p8R6Qo5/7FSzC0/E4quyWYNvw1pRj5XGOzFh7wGUYcEq21+ghiDjLMq K5E5Uu5SDqR4VJD9QBVJKcMYHUc0xxBXmKpPSHyf2eN+JQnMDweYQpxb9sZGppDXCEcv HWSLY1faJIeHhyK0iA5Vd/g+OdS0m26G4lXw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Q/fc3jPwan0vQRhDPe1RYLUd2BGQCQk+JdwEsKmmHFJ+mqejv64qNh0Qq9DroKNlw4 L/dy2HKVkem70qVXC8zEG2ZhjedXy5qEezfCmVEj5Popv1rMb+OIGb0fdGnVNYKYT178 MoDqAhTI7hSz0a4uU4y5/DQgVfJ+XNQu7lvdU= Received: by 10.150.44.2 with SMTP id r2mr4331426ybr.77.1257998293939; Wed, 11 Nov 2009 19:58:13 -0800 (PST) Received: from ?133.93.16.203? (host-16-203.meeting.ietf.org [133.93.16.203]) by mx.google.com with ESMTPS id 16sm60770gxk.7.2009.11.11.19.58.11 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 19:58:13 -0800 (PST) Message-ID: <4AFB87CD.6030507@gmail.com> Date: Thu, 12 Nov 2009 16:58:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jan Melen References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org, Joel Halpern Subject: Re: [grobj] HI and HIT comments on draft-carpenter-behave-referral-object X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:57:49 -0000 Thanks Jan. That's very hepful. I suspect that we'll be focussed on the requirements aspect for a while, so we'll keep your message for later. Regards Brian Carpenter On 2009-11-12 15:06, Jan Melen wrote: > Hi, > > I read the draft quickly through and saw some discussion that was wanted > on HI and HITs and their necessity on the HIP base exchange. The HI is > needed in the base exchange in order for host to verify the signatures > in the packets and to verify that the HIT presented in the HIP headers > really corresponds to the private which the host holds. In the future > there might be versions of HIP based on ECC crypto that do not actually > carry the HI inside the HIP messages but current version needs it. What > comes to the different formats HI, there exists two types of HIs which > are DSA and RSA and additionally the HI may be followed by Network > Address Identifier specified by RFC4282. The NAI could be taken out and > presented as a separate GRO object so that the current HI could be > presented by 2 GROs instead of 1 large GRO of course this would require > bis version 5201 but anyway that will revised. GRO then again would need > to be able to accommodate NAI which is a format of username@realm (not > just FQDN). > > Then another thing is that HIT is actually defined as a subtype of > Overlay Routable Cryptographic Hash Identifier (ORCHID) RFC4282. So one > might add a reference to that RFC in addition to 5201 or even make the > ORCHID the actual type and HIT as a subtype. > > Regards, > Jan > > From brian.e.carpenter@gmail.com Wed Nov 11 19:58:02 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113133A67D3 for ; Wed, 11 Nov 2009 19:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBoQcW2lxNDO for ; Wed, 11 Nov 2009 19:58:01 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 239CC3A67D2 for ; Wed, 11 Nov 2009 19:58:01 -0800 (PST) Received: by yxe30 with SMTP id 30so1917180yxe.29 for ; Wed, 11 Nov 2009 19:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TomV96IDjbjiBoiGqq+CoeOCnmAXM9cBgwCyx742mwM=; b=GRxemcPgJd8L/0P0zXm7N+4Yozi1jQ/R7EI9C6rrjj+Xr0MGOUfxv9JwbBq6JYVZ80 H5haWRNaLXCevMy9GPfqC1d1ljQFxMXFSpgKAPBPjXxIwE9rjEG/8k6sgndXP7WV2H3c FbQbrlkf+xpxd77abTwIxCgUNmXEQ0v0m0YUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=xKQKTk9edf4AQeiIxcD2mjkhGqiZF+TIwoms64+y38R1s9LDdfwnWa+3RhHmKlsVnE QVUN7fJo9ndIsneOMBmsNBgaoThpgiuk1k2vXFXfd/9qovJB1CYs1cDAYyPpWP/FqrOz ehbctQ8GVIo5Zh6JIK0r7WXL0RWrKe7j+PuR8= Received: by 10.150.174.40 with SMTP id w40mr4305990ybe.123.1257998307138; Wed, 11 Nov 2009 19:58:27 -0800 (PST) Received: from ?133.93.16.203? (host-16-203.meeting.ietf.org [133.93.16.203]) by mx.google.com with ESMTPS id 14sm1086692gxk.2.2009.11.11.19.58.24 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 19:58:26 -0800 (PST) Message-ID: <4AFB87DB.6060606@gmail.com> Date: Thu, 12 Nov 2009 16:58:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jan Melen References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org, Joel Halpern Subject: Re: [grobj] HI and HIT comments on draft-carpenter-behave-referral-object X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:58:02 -0000 Thanks Jan. That's very helpful. I suspect that we'll be focussed on the requirements aspect for a while, so we'll keep your message for later. Regards Brian Carpenter On 2009-11-12 15:06, Jan Melen wrote: > Hi, > > I read the draft quickly through and saw some discussion that was wanted > on HI and HITs and their necessity on the HIP base exchange. The HI is > needed in the base exchange in order for host to verify the signatures > in the packets and to verify that the HIT presented in the HIP headers > really corresponds to the private which the host holds. In the future > there might be versions of HIP based on ECC crypto that do not actually > carry the HI inside the HIP messages but current version needs it. What > comes to the different formats HI, there exists two types of HIs which > are DSA and RSA and additionally the HI may be followed by Network > Address Identifier specified by RFC4282. The NAI could be taken out and > presented as a separate GRO object so that the current HI could be > presented by 2 GROs instead of 1 large GRO of course this would require > bis version 5201 but anyway that will revised. GRO then again would need > to be able to accommodate NAI which is a format of username@realm (not > just FQDN). > > Then another thing is that HIT is actually defined as a subtype of > Overlay Routable Cryptographic Hash Identifier (ORCHID) RFC4282. So one > might add a reference to that RFC in addition to 5201 or even make the > ORCHID the actual type and HIT as a subtype. > > Regards, > Jan > > From jan.melen@nomadiclab.com Wed Nov 11 18:06:30 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11FB3A6B11 for ; Wed, 11 Nov 2009 18:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhkkFxfwdGPf for ; Wed, 11 Nov 2009 18:06:29 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 5A5C43A6AA3 for ; Wed, 11 Nov 2009 18:06:27 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 10D4E1EF1EA; Thu, 12 Nov 2009 04:06:55 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWw2Fjc2Xz7O; Thu, 12 Nov 2009 04:06:54 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id CF0AB1EF12E; Thu, 12 Nov 2009 04:06:51 +0200 (EET) From: Jan Melen Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 12 Nov 2009 04:06:49 +0200 Message-Id: To: brian.e.carpenter@gmail.com, mohamed.boucadair@orange-ftgroup.com, Joel Halpern , shengjiang@huawei.com, moore@network-heretics.com Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Wed, 11 Nov 2009 20:00:34 -0800 Cc: grobj@ietf.org Subject: [grobj] HI and HIT comments on draft-carpenter-behave-referral-object X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:06:30 -0000 Hi, I read the draft quickly through and saw some discussion that was wanted on HI and HITs and their necessity on the HIP base exchange. The HI is needed in the base exchange in order for host to verify the signatures in the packets and to verify that the HIT presented in the HIP headers really corresponds to the private which the host holds. In the future there might be versions of HIP based on ECC crypto that do not actually carry the HI inside the HIP messages but current version needs it. What comes to the different formats HI, there exists two types of HIs which are DSA and RSA and additionally the HI may be followed by Network Address Identifier specified by RFC4282. The NAI could be taken out and presented as a separate GRO object so that the current HI could be presented by 2 GROs instead of 1 large GRO of course this would require bis version 5201 but anyway that will revised. GRO then again would need to be able to accommodate NAI which is a format of username@realm (not just FQDN). Then another thing is that HIT is actually defined as a subtype of Overlay Routable Cryptographic Hash Identifier (ORCHID) RFC4282. So one might add a reference to that RFC in addition to 5201 or even make the ORCHID the actual type and HIT as a subtype. Regards, Jan From zhouboyj@gmail.com Wed Nov 18 23:40:06 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCAE3A6932 for ; Wed, 18 Nov 2009 23:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-hx0VHWB2cA for ; Wed, 18 Nov 2009 23:40:06 -0800 (PST) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id F05EC3A6784 for ; Wed, 18 Nov 2009 23:40:05 -0800 (PST) Received: by iwn16 with SMTP id 16so1547175iwn.29 for ; Wed, 18 Nov 2009 23:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NpGUsw7vMt/4KCyu35DgvpOC8+XZLQ5Uyw2cYnToWbU=; b=tUKG/RUPheknlO2/9TqnEYV+SqeQSqtXireObLibEARuaLYDQfOPdfE/rNlrRcz0fe FHbtFLfZzMWtI8/mgjvfJvfvhbHAM7dGOplTXvmh28AEqJOIP5k9JYedyuEwkQIuRoG4 uJ5p68rO2BGdBBcxmgLg0oVeZ716uWLZjpjmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PYNPBZkBKJZF8M1VvcF4aoJsUURNm5LasGh+CKBz1HceU5oGH793B3mQzpxrHlhnGo Mf8Lfiuk7p/6jeSyzrRLdsjqr+wdCeiZzl4FPXd6bRVsUffYs2FwuhTN2PJbwO9q1xqX pChmRL8CiYItZ/zrynbTBXaVaKo+IcoPf2Evo= MIME-Version: 1.0 Received: by 10.231.121.69 with SMTP id g5mr3146597ibr.44.1258616401351; Wed, 18 Nov 2009 23:40:01 -0800 (PST) In-Reply-To: <4AFB497D.1080901@employees.org> References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> Date: Thu, 19 Nov 2009 15:40:01 +0800 Message-ID: <36a593230911182340l267d0a89l90580b6e272c5fa0@mail.gmail.com> From: bo zhou To: Scott Brim Content-Type: multipart/alternative; boundary=0016e644cd9682d3a30478b4777f Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 07:40:06 -0000 --0016e644cd9682d3a30478b4777f Content-Type: text/plain; charset=ISO-8859-1 Agree with Scott. So shall we draw potential scenarios for the referrals issue at first, then identfy problem more clearly? regards, Bo On Thu, Nov 12, 2009 at 7:32 AM, Scott Brim wrote: > Simon Perreault allegedly wrote on 11/11/2009 7:28 PM: > > So today at the BoF meeting people felt that the problem was not clearly > > defined. > > > > This was also my feeling. Right now, the problem that application > > developers have is simple: they want to do something ICE-like > > I disagree that this is what app developers want. If ICE was not > necessary for some apps, those app developers would be pleased not to > have to use it. As Brian said, let's avoid point solutionism. But it > is good to point out scenarios where there are problems with referrals, > and that is what should go into the draft in order to guide it. > > Scott > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj > -- Regards, Bo Zhou China Mobile --0016e644cd9682d3a30478b4777f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree with Scott.
So shall we draw potential scenarios for the referrals issue at first,= then identfy problem more clearly?
=A0
regards,
=A0
Bo

=A0
On Thu, Nov 12, 2009 at 7:32 AM, Scott Brim <swb@employees.org> wrote:
Simon Perreault allegedly wrote = on 11/11/2009 7:28 PM:
> So today at the BoF meeting people felt that the pro= blem was not clearly
> defined.
>
> This was also my feel= ing. Right now, the problem that application
> developers have is sim= ple: they want to do something ICE-like

I disagree that this is what app developers want. =A0If ICE was n= ot
necessary for some apps, those app developers would be pleased not to=
have to use it. =A0As Brian said, let's avoid point solutionism. = =A0But it
is good to point out scenarios where there are problems with referrals,
= and that is what should go into the draft in order to guide it.

Scott



--
Regards,
Bo Zhou
China Mobile
--0016e644cd9682d3a30478b4777f-- From simon.perreault@viagenie.ca Thu Nov 19 06:11:58 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BA23A68AF for ; Thu, 19 Nov 2009 06:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eFUHTyLbUyk for ; Thu, 19 Nov 2009 06:11:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 3D1533A6859 for ; Thu, 19 Nov 2009 06:11:55 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 4818720E37; Thu, 19 Nov 2009 09:11:52 -0500 (EST) Message-ID: <4B055227.3090902@viagenie.ca> Date: Thu, 19 Nov 2009 09:11:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Scott Brim References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> In-Reply-To: <4AFB497D.1080901@employees.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:11:58 -0000 Scott Brim wrote, on 2009-11-11 18:32: > But it > is good to point out scenarios where there are problems with referrals, > and that is what should go into the draft in order to guide it. Let me try to feed this discussion... Some problems that come to mind with draft-carpenter-behave-referral-object: - The "scope" of an address (I'm still not fully understanding the concept) does not guarantee that that the address is reachable from anyone in that scope. For example, the address of a NAT binding (called a "reflexive transport address" in RFC5389) can be reached by a subset of peers in the NAT's scope which depends on the type of NAT (see e.g. RFC4787 for types of NATs). - If someone hands me a net10 address, and I am also in net10, is it the same net10 or a different one? How can I know? Should I even care? - How are referrals used? It's clear in the draft that this is out of scope. But I'm wondering if generic referrals are useful at all if this is left out of scope. - How to prioritize items in a GRO? The draft says this is out of scope, but I don't know how to use GRO without it. Basically, for me it all boils down to "I don't understand what GRO is good for." Some problems that come to mind with draft-bo-behave-ref-req: - R1: "The referral formats need to be standardized." Are you sure about that? I'm not convinced. Real-life examples would help. - R2: "Simplify ALG during NAT traversal" Isn't the goal to remove the need for ALGs completely instead of making creating them easier? - To me the biggest drawback of this document is that it really doesn't try to explain what the problem is. It jumps right into requirements for solutions. How can we say we need a solution when we don't even agree on the problem? Again, and now I'll try to refrain from using the term ICE to not be called a "solutionist" ;-), one problem I see everyone having is doing NAT traversal without reinventing the wheel. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Thu Nov 19 10:31:13 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C5E3A69A2 for ; Thu, 19 Nov 2009 10:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tCxxB7IWZoZ for ; Thu, 19 Nov 2009 10:31:12 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0FA8A3A698B for ; Thu, 19 Nov 2009 10:31:12 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEADsdBUurRN+J/2dsb2JhbACKMrQTl3OEOwSBbw X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="51689997" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2009 18:31:09 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAJIV9b0004724; Thu, 19 Nov 2009 18:31:09 GMT From: "Dan Wing" To: "'Simon Perreault'" , "'Scott Brim'" References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> Date: Thu, 19 Nov 2009 10:31:09 -0800 Message-ID: <0d9f01ca6946$76f42760$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B055227.3090902@viagenie.ca> Thread-Index: AcppIkKPFyWfU4NeQxC+88PHmDJkdgAInVvA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:31:13 -0000 > -----Original Message----- > From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] > On Behalf Of Simon Perreault > Sent: Thursday, November 19, 2009 6:12 AM > To: Scott Brim > Cc: grobj@ietf.org > Subject: Re: [grobj] Problem statement > > Scott Brim wrote, on 2009-11-11 18:32: > > But it > > is good to point out scenarios where there are problems > with referrals, > > and that is what should go into the draft in order to guide it. > > Let me try to feed this discussion... > > > Some problems that come to mind with > draft-carpenter-behave-referral-object: > > - The "scope" of an address (I'm still not fully > understanding the concept) does > not guarantee that that the address is reachable from anyone > in that scope. Agreed. But nothing can provide such a guarantee anyway. The scope has a different purpose, which is to provide hints that we *might* be on the same network. For example, if my scope says "I'm on the cisco.com corporate network", and your application knows (or has reason to believe) that its host is not on that corporate network, the application need not bother trying to access it. The application knows this scope is not a candidate path -- that is, this path is unlikely to work. Mistakes happen; it could work, but it should not be tried first. For example, if my scope says "I know this is on the Internet", and your application knows it can also access the Internet, the application knows this scope is a candidate path -- that is, a path that might work. Mistakes happen; it might not work, but an evaluation of the scopes indicates it should work. > For > example, the address of a NAT binding (called a "reflexive > transport address" in > RFC5389) can be reached by a subset of peers in the NAT's > scope which depends on > the type of NAT (see e.g. RFC4787 for types of NATs). > > - If someone hands me a net10 address, and I am also in > net10, is it the same > net10 or a different one? How can I know? Should I even care? You can't know for sure. But various things can give you hints. For example, the default domain name that is returned via DHCP. If they differ, you're more likely on different networks. This is never guaranteed to prove you're on different networks, but there aren't any guarantees. > - How are referrals used? It's clear in the draft that this > is out of scope. But > I'm wondering if generic referrals are useful at all if this > is left out of scope. Agreed. > - How to prioritize items in a GRO? The draft says this is > out of scope, but I don't know how to use GRO without it. That ties into 'how to do a referral'. > Basically, for me it all boils down to "I don't understand > what GRO is good for." It's the middle part of the 3 prongs that Dave Thaler described at the end of meeting: - get/construct scope zone id - GRO, a way to communicate it - path selection > Some problems that come to mind with draft-bo-behave-ref-req: > > - R1: "The referral formats need to be standardized." Are you > sure about that? > I'm not convinced. Real-life examples would help. > > - R2: "Simplify ALG during NAT traversal" Isn't the goal to > remove the need for > ALGs completely instead of making creating them easier? > > - To me the biggest drawback of this document is that it > really doesn't try to > explain what the problem is. It jumps right into requirements > for solutions. How > can we say we need a solution when we don't even agree on the problem? > > Again, and now I'll try to refrain from using the term ICE to > not be called a > "solutionist" ;-), one problem I see everyone having is doing > NAT traversal without reinventing the wheel. That's the problem I see, too. I think GRO is part of the solution and we need to flesh out the solution (into three or possibly four parts), but you're right we need to flesh out the problem better. To me, the problem is easy: we want to provide guidance, and maybe even a library, to applications so they can more easily handle multi-homed hosts, IPv6/IPv4 translation, IPv4 NAT, tunnels, and a myrid of other cool things that make it complex for applications to work well with such complex networks. We have lots of nifty layer 3 and layer 4 things we have specified and vendors have built, but many applications are stymied trying to work with them at all; yet, we want them to work well. -d From simon.perreault@viagenie.ca Thu Nov 19 10:52:20 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84D128C105 for ; Thu, 19 Nov 2009 10:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr1kxPZZSmCX for ; Thu, 19 Nov 2009 10:52:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 737633A6972 for ; Thu, 19 Nov 2009 10:52:15 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id E05ED21107; Thu, 19 Nov 2009 13:52:12 -0500 (EST) Message-ID: <4B0593DC.3090104@viagenie.ca> Date: Thu, 19 Nov 2009 13:52:12 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Dan Wing References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> In-Reply-To: <0d9f01ca6946$76f42760$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:52:20 -0000 Dan Wing wrote, on 2009-11-19 13:31: > For example, if my scope says "I'm on the cisco.com corporate > network", and your application knows (or has reason to believe) that > its host is not on that corporate network, the application need not > bother trying to access it. The application knows this scope is > not a candidate path -- that is, this path is unlikely to work. > Mistakes happen; it could work, but it should not be tried first. > > For example, if my scope says "I know this is on the Internet", > and your application knows it can also access the Internet, the > application knows this scope is a candidate path -- that is, > a path that might work. Mistakes happen; it might not work, but > an evaluation of the scopes indicates it should work. So I understand that scope would be one criteria for determining priorities of candidates. Makes sense. But is it solving a problem we have? Does experience with ICE show that it would be a nice feature to have? I'm trying to understand the need for communicating scope IDs... > To me, the problem is easy: we want to provide guidance, and maybe > even a library, to applications so they can more easily handle > multi-homed hosts, IPv6/IPv4 translation, IPv4 NAT, tunnels, and a > myrid of other cool things that make it complex for applications > to work well with such complex networks. YES! +1 I want to do this: my $gro = $server->request('GETPEER'); my $connection = $gro->connect(); # <-- MAGIC! print $connection "We are peer-to-peer networking!\n"; Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Thu Nov 19 11:05:03 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F077C3A672E for ; Thu, 19 Nov 2009 11:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COxY9QMeuHuH for ; Thu, 19 Nov 2009 11:05:01 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E00EF3A6962 for ; Thu, 19 Nov 2009 11:05:01 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAG4lBUurRN+J/2dsb2JhbACKMrQRl3eEOwSBbw X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="51712337" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2009 19:04:58 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAJJ4xPq005989; Thu, 19 Nov 2009 19:04:59 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> Date: Thu, 19 Nov 2009 11:04:59 -0800 Message-ID: <0de301ca694b$30e26ed0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B0593DC.3090104@viagenie.ca> Thread-Index: AcppSWkVyBfkaJoLTjSFDygsLOA8vwAAOkPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:05:03 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Thursday, November 19, 2009 10:52 AM > To: Dan Wing > Cc: 'Scott Brim'; grobj@ietf.org > Subject: Re: [grobj] Problem statement > > Dan Wing wrote, on 2009-11-19 13:31: > > For example, if my scope says "I'm on the cisco.com corporate > > network", and your application knows (or has reason to believe) that > > its host is not on that corporate network, the application need not > > bother trying to access it. The application knows this scope is > > not a candidate path -- that is, this path is unlikely to work. > > Mistakes happen; it could work, but it should not be tried first. > > > > For example, if my scope says "I know this is on the Internet", > > and your application knows it can also access the Internet, the > > application knows this scope is a candidate path -- that is, > > a path that might work. Mistakes happen; it might not work, but > > an evaluation of the scopes indicates it should work. > > So I understand that scope would be one criteria for > determining priorities of > candidates. Makes sense. > > But is it solving a problem we have? Does experience with ICE > show that it would be a nice feature to have? It's useful to connect quickly so users are happy with the experience. If there are a lot of candidate addresses and candidate transports it's time-consuming to try all of them. > I'm trying to understand the need for communicating scope IDs... > > > To me, the problem is easy: we want to provide guidance, and maybe > > even a library, to applications so they can more easily handle > > multi-homed hosts, IPv6/IPv4 translation, IPv4 NAT, tunnels, and a > > myrid of other cool things that make it complex for applications > > to work well with such complex networks. > > YES! +1 > > I want to do this: > > my $gro = $server->request('GETPEER'); > my $connection = $gro->connect(); # <-- MAGIC! > print $connection "We are peer-to-peer networking!\n"; Yep, that's the level I would really love to see. And the library can evolve separate from the application. For example, if/when the OSs can do draft-savolainen-mif-dns-server-selection (if that achieves IETF consensus) the library would begin supporting it -- rather than applications having to diddle with that level of (what I will call) "nonsense". -d From simon.perreault@viagenie.ca Thu Nov 19 11:26:05 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5077C28C15E for ; Thu, 19 Nov 2009 11:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxWkZn7-3JvW for ; Thu, 19 Nov 2009 11:26:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 67FCC28C16E for ; Thu, 19 Nov 2009 11:26:04 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 45F0921BAA; Thu, 19 Nov 2009 14:26:01 -0500 (EST) Message-ID: <4B059BC8.9020809@viagenie.ca> Date: Thu, 19 Nov 2009 14:26:00 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Dan Wing References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> <0de301ca694b$30e26ed0$c2f0200a@cisco.com> In-Reply-To: <0de301ca694b$30e26ed0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:26:05 -0000 Dan Wing wrote, on 2009-11-19 14:04: > If there are a lot of candidate addresses and > candidate transports it's time-consuming to try all of them. Why not try all of them simultaneously? It would waste bandwidth, but probably not a significant amount. If concerned you can impose a concurrency limit. Then you use the equivalent of ICE's aggressive nomination but make it choose the highest priority candidate (instead of the first successful one) that is successful within a given time window following the first successful check. Ok, now we're well into solutionist territory... ;) >> I want to do this: >> >> my $gro = $server->request('GETPEER'); >> my $connection = $gro->connect(); # <-- MAGIC! >> print $connection "We are peer-to-peer networking!\n"; > > Yep, that's the level I would really love to see. And the > library can evolve separate from the application. For example, > if/when the OSs can do draft-savolainen-mif-dns-server-selection > (if that achieves IETF consensus) the library would begin > supporting it -- rather than applications having to diddle with > that level of (what I will call) "nonsense". We're on the same wavelength here. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Thu Nov 19 11:37:12 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D79C28C112 for ; Thu, 19 Nov 2009 11:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnqEnMocT+wR for ; Thu, 19 Nov 2009 11:37:11 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9558128C0DE for ; Thu, 19 Nov 2009 11:37:11 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAO8sBUurRN+K/2dsb2JhbACKMrQFl3SEOwQ X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="106800716" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Nov 2009 19:37:09 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAJJb9we017749; Thu, 19 Nov 2009 19:37:09 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> <0de301ca694b$30e26ed0$c2f0200a@cisco.com> <4B059BC8.9020809@viagenie.ca> Date: Thu, 19 Nov 2009 11:37:09 -0800 Message-ID: <0e3901ca694f$af2fd1c0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B059BC8.9020809@viagenie.ca> Thread-Index: AcppTiFEFaQPqBB5Qpe+T3iunpcPFgAAOWCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 19:37:12 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Thursday, November 19, 2009 11:26 AM > To: Dan Wing > Cc: 'Scott Brim'; grobj@ietf.org > Subject: Re: [grobj] Problem statement > > Dan Wing wrote, on 2009-11-19 14:04: > > If there are a lot of candidate addresses and > > candidate transports it's time-consuming to try all of them. > > Why not try all of them simultaneously? It would waste > bandwidth, but probably not a significant amount. The transport area directors get into a tizzy. > If concerned you can impose a concurrency limit. Then > you use the equivalent of ICE's aggressive nomination but > make it choose the > highest priority candidate (instead of the first successful > one) that is > successful within a given time window following the first > successful check. Yeah, and that's the sort of thing that removes the transport area worry about flooding the network and harming existing TCP-friendly flows. And that's what we would want applications to do. But they will do the naive thing (flood the network) and harm other flows on their network -- including the IPTV between the media player downstairs and the TV upstairs, including the TCP streaming video coming down the Internet (TCP ACKs get lost with aggressive probes), and so on. All solved by adding more bandwidth, but the industry keeps inventing new applications that use that additional bandwidth! > Ok, now we're well into solutionist territory... ;) :-) > >> I want to do this: > >> > >> my $gro = $server->request('GETPEER'); > >> my $connection = $gro->connect(); # <-- MAGIC! > >> print $connection "We are peer-to-peer networking!\n"; > > > > Yep, that's the level I would really love to see. And the > > library can evolve separate from the application. For example, > > if/when the OSs can do draft-savolainen-mif-dns-server-selection > > (if that achieves IETF consensus) the library would begin > > supporting it -- rather than applications having to diddle with > > that level of (what I will call) "nonsense". > > We're on the same wavelength here. Cool. Is Dave Thaler's suggestion for splitting the problem into three things sufficient? 1 get/construct scope zone id 2 GRO, a way to communicate it 3 path selection If so, are there volunteers to start crafting outlines for (1) and (3)? -d From joel.halpern@ericsson.com Thu Nov 19 06:44:20 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49123A69CB for ; Thu, 19 Nov 2009 06:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbpleLhjK6QA for ; Thu, 19 Nov 2009 06:44:19 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A9BD23A681F for ; Thu, 19 Nov 2009 06:44:19 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAJEh8U8005298; Thu, 19 Nov 2009 08:43:08 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.199]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 19 Nov 2009 09:43:07 -0500 From: Joel Halpern To: Simon Perreault , Scott Brim Date: Thu, 19 Nov 2009 09:43:05 -0500 Thread-Topic: [grobj] Problem statement Thread-Index: AcppIk4T06LXv0SVSwWiSkarGakmagAA8hBQ Message-ID: <49044C2B7F64814BAA8D09EA7B8D723201137F7481@EUSAACMS0701.eamcs.ericsson.se> References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> In-Reply-To: <4B055227.3090902@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 19 Nov 2009 12:04:38 -0800 Cc: "grobj@ietf.org" Subject: Re: [grobj] Problem statement X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:44:20 -0000 The whole point of the scope indication is to address you second bullet. T= hat is, with private addresses (or privately re-used public addresses), the= y can only be used in the specific scope (typically a company, although tha= t is changing) over which they are defined. If I am reading your first point correctly, there is a complication tucked = in there which we can not solve, but need to acknowledge. If a=20 "global" scope address is allocated by a NAT, it may not be usable blobally= . The NAT description documents cover many behaviors, and only a few of th= em are arbitrarily usable addresses. There are two paths for dealing with = this. The simpler, which is where I would start, is just to note that and = move one. The alternative requries far more coupling with STUN/TURN/ICE, a= nd more active participation of all parties in the referral to make it work= . Yours, Joel -----Original Message----- From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] On Behalf Of S= imon Perreault Sent: Thursday, November 19, 2009 9:12 AM To: Scott Brim Cc: grobj@ietf.org Subject: Re: [grobj] Problem statement Scott Brim wrote, on 2009-11-11 18:32: > But it > is good to point out scenarios where there are problems with=20 > referrals, and that is what should go into the draft in order to guide it= . Let me try to feed this discussion... Some problems that come to mind with draft-carpenter-behave-referral-object= : - The "scope" of an address (I'm still not fully understanding the concept)= does not guarantee that that the address is reachable from anyone in that = scope. For example, the address of a NAT binding (called a "reflexive trans= port address" in RFC5389) can be reached by a subset of peers in the NAT's scope which depen= ds on the type of NAT (see e.g. RFC4787 for types of NATs). - If someone hands me a net10 address, and I am also in net10, is it the sa= me net10 or a different one? How can I know? Should I even care? - How are referrals used? It's clear in the draft that this is out of scope= . But I'm wondering if generic referrals are useful at all if this is left = out of scope. - How to prioritize items in a GRO? The draft says this is out of scope, bu= t I don't know how to use GRO without it. Basically, for me it all boils down to "I don't understand what GRO is good= for." Some problems that come to mind with draft-bo-behave-ref-req: - R1: "The referral formats need to be standardized." Are you sure about th= at? I'm not convinced. Real-life examples would help. - R2: "Simplify ALG during NAT traversal" Isn't the goal to remove the need= for ALGs completely instead of making creating them easier? - To me the biggest drawback of this document is that it really doesn't try= to explain what the problem is. It jumps right into requirements for solut= ions. How can we say we need a solution when we don't even agree on the pro= blem? Again, and now I'll try to refrain from using the term ICE to not be called= a "solutionist" ;-), one problem I see everyone having is doing NAT traver= sal without reinventing the wheel. Simon --=20 DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org _______________________________________________ grobj mailing list grobj@ietf.org https://www.ietf.org/mailman/listinfo/grobj From brian.e.carpenter@gmail.com Thu Nov 19 12:15:44 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BD83A6860 for ; Thu, 19 Nov 2009 12:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl2+MoqMp7iO for ; Thu, 19 Nov 2009 12:15:44 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id F289B3A67AF for ; Thu, 19 Nov 2009 12:15:43 -0800 (PST) Received: by pwi6 with SMTP id 6so1742047pwi.29 for ; Thu, 19 Nov 2009 12:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3vR4jjXp7hsQc5QxlKmXwFn+42OalLPoIf3Gr9qPOE8=; b=iw6d8M+PKKuDLQYpe0g4+K9A3fyhn4+rOgNupbKhNl888j+IONq/SgKlUpqflVlD7q 1umRqd/sY8cp8UDGbgTsIaYGP0T4JceLsahT2xTJU0nzx1yyvP6nigdYc44hgyYxZ2vm 35E4AOV999pGVraiflGZ3Zh9Zjl7hnHv6hnT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=aQ/EEHPxLcP9UEXNA7lVnuhLkcKDMqwGRB1UuXHKN7eKrGZ5d/yFsl6qcvTRU88iG5 3cuL0HZrMNDKhhFNrgKSQoKyB4x9OtKuXqJ1NRNuLju4S0aQ1TAqKMMXuWQRVWJ+ZdPj jyIMlM/37dPCPtXUGbxp2Xs3ptEybuOOMX7pg= Received: by 10.114.45.2 with SMTP id s2mr448031was.122.1258661739063; Thu, 19 Nov 2009 12:15:39 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm529111pzk.15.2009.11.19.12.15.37 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:15:38 -0800 (PST) Message-ID: <4B05A76E.5020101@gmail.com> Date: Fri, 20 Nov 2009 09:15:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> In-Reply-To: <4B0593DC.3090104@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: [grobj] Value and meaning of scope X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:15:45 -0000 (Trying to use separate subjects for separate topics; at some point we may even need an issue tracker.) The basic problem in my mind is that, since we destroyed address transparency, you simply cannot tell by looking at an address whether it is meaningfully reachable. This applies whether the address is 10.1.1.1 or 9.1.1.1 (both of which are actually out of scope where I am sitting at the moment, although RFC1918 only tells me about one of them). Similarly for IPv6, you cannot tell by looking at a globally unique address or a ULA whether or not it's meaningfully reachable. So, this in fact part of the problem statement: when a 3rd party receives an IP address (communicated at application level), it does not automatically know whether that address is meaningfully reachable from its (the 3rd party's) location. We abbreviate that by saying "the address is in/out of scope". Brian On 2009-11-20 07:52, Simon Perreault wrote: > Dan Wing wrote, on 2009-11-19 13:31: >> For example, if my scope says "I'm on the cisco.com corporate >> network", and your application knows (or has reason to believe) that >> its host is not on that corporate network, the application need not >> bother trying to access it. The application knows this scope is >> not a candidate path -- that is, this path is unlikely to work. >> Mistakes happen; it could work, but it should not be tried first. >> >> For example, if my scope says "I know this is on the Internet", >> and your application knows it can also access the Internet, the >> application knows this scope is a candidate path -- that is, >> a path that might work. Mistakes happen; it might not work, but >> an evaluation of the scopes indicates it should work. > > So I understand that scope would be one criteria for determining priorities of > candidates. Makes sense. > > But is it solving a problem we have? Does experience with ICE show that it would > be a nice feature to have? > > I'm trying to understand the need for communicating scope IDs... > >> To me, the problem is easy: we want to provide guidance, and maybe >> even a library, to applications so they can more easily handle >> multi-homed hosts, IPv6/IPv4 translation, IPv4 NAT, tunnels, and a >> myrid of other cool things that make it complex for applications >> to work well with such complex networks. > > YES! +1 > > I want to do this: > > my $gro = $server->request('GETPEER'); > my $connection = $gro->connect(); # <-- MAGIC! > print $connection "We are peer-to-peer networking!\n"; > > Simon From brian.e.carpenter@gmail.com Thu Nov 19 12:21:34 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18F33A6A0E for ; Thu, 19 Nov 2009 12:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FNR4aGGH3uL for ; Thu, 19 Nov 2009 12:21:34 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 187043A6A0D for ; Thu, 19 Nov 2009 12:21:34 -0800 (PST) Received: by pzk6 with SMTP id 6so1757729pzk.29 for ; Thu, 19 Nov 2009 12:21:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oXQzGI2hkD66Dx7zidrGkoZc0H6od0z8udvi/w4t5PI=; b=APn3FPRYSVgMT2nUWTotYkU1KRJQe5DTkkAdsEGCAEY5Z9EesFfNklslwovJv9Akj9 XxR+v/BNNYlHgOz40Hbo3FzUdLdn3Qz2XLxP1y44o0xJi56jfmHWwa8ygc4dX7gcgwls rUrCrFiuc2+XBfi8/0OhRSpKQlOfjhUjHODaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=C6s2DI6uzEn6KP1oGLhaM+Bkd3K/cmnnQqalX1SjToDDstc9xFzkBJvgcW4YPi7WS5 rjE4BqbfyIHsB3AUGw9BIWYD1l17x23uCfLOHzmt8C5s1no9fI+kvGbi4J/hsKiaHEWp ACYPNlk7aKVfus1591DhJfwSkic155JIQSvhc= Received: by 10.115.112.40 with SMTP id p40mr427465wam.182.1258662089529; Thu, 19 Nov 2009 12:21:29 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm531839pzk.9.2009.11.19.12.21.28 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:21:29 -0800 (PST) Message-ID: <4B05A8CD.5020804@gmail.com> Date: Fri, 20 Nov 2009 09:21:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> In-Reply-To: <4B055227.3090902@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: [grobj] NATs and scope X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:21:34 -0000 On 2009-11-20 03:11, Simon Perreault wrote: > - The "scope" of an address (I'm still not fully understanding the concept) does > not guarantee that that the address is reachable from anyone in that scope. For > example, the address of a NAT binding (called a "reflexive transport address" in > RFC5389) can be reached by a subset of peers in the NAT's scope which depends on > the type of NAT (see e.g. RFC4787 for types of NATs). So, given what I just said about scope (with no reference to NATs), I think Simon needs to tell us what he means by "in the NAT's scope". To me an address scope is a set of mutually reachable addresses, which means that a NAT automatically forms (part of) the boundary of a scope. I don't understand what is meant by "a subset of peers" - surely all the peers behind a given NAT (more precisely, behind a given interface of a given NAT) are in the same address space? Brian From brian.e.carpenter@gmail.com Thu Nov 19 12:32:57 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9793A6A1C for ; Thu, 19 Nov 2009 12:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjL6s4YVhSzC for ; Thu, 19 Nov 2009 12:32:56 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 379513A6847 for ; Thu, 19 Nov 2009 12:32:56 -0800 (PST) Received: by pwi6 with SMTP id 6so1752006pwi.29 for ; Thu, 19 Nov 2009 12:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JxX9o+tfJp+Y3qnLwz+K5FeBe+bvrLEqWJ5szkQ1a7s=; b=CFf3659cZc2/U7iUYF1sKLpQ7A9NXQbVPWnCcUhWbzofWKj5cveiSndZhkPXE/bII5 Gy6eVGeb+yyMffb/ziAOMnB1OvMK6Gs9AIEro5vN8NL78aD2rawqQbjW4FDES5wDkjfL 0hlcDWvkM15DLSdXaRzAwoar0X5PWuyBDkNzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=AHHrSPTSAwi62W6gtYTreejShLxodn5+BMRw0GvdP0Uc/u/tc25uYysQwYs/ZEV+0f lvN8zTFI+97devW6FgyklcnF7aVRyBtPe0lTxcBv6dGOrR2u3+t/WhktwU0VMWGgfpym fM18glgwMSEvmsplmgsARpI3xZLNdK5bRZB9Q= Received: by 10.114.3.29 with SMTP id 29mr448812wac.208.1258662771561; Thu, 19 Nov 2009 12:32:51 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm560296pxi.15.2009.11.19.12.32.49 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:32:50 -0800 (PST) Message-ID: <4B05AB77.8040800@gmail.com> Date: Fri, 20 Nov 2009 09:32:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> <0de301ca694b$30e26ed0$c2f0200a@cisco.com> <4B059BC8.9020809@viagenie.ca> In-Reply-To: <4B059BC8.9020809@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: [grobj] Trying all addresses X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:32:57 -0000 On 2009-11-20 08:26, Simon Perreault wrote: > Dan Wing wrote, on 2009-11-19 14:04: >> If there are a lot of candidate addresses and >> candidate transports it's time-consuming to try all of them. > > Why not try all of them simultaneously? It would waste bandwidth, but probably > not a significant amount. If concerned you can impose a concurrency limit. Then > you use the equivalent of ICE's aggressive nomination but make it choose the > highest priority candidate (instead of the first successful one) that is > successful within a given time window following the first successful check. Actually this has been discussed quite a bit in the context of "what's wrong with RFC3484?" It's also been implemented in the REAP protocol which is associated with SHIM6. My student Habib Naderi is currently simulating REAP's behaviour when exploring various numbers of address pairs. The work isn't quite cooked enough yet to give numbers, but one of his conclusions is that the actual amount of probe traffic caused by REAP is not a big problem. However, the recovery time for a TCP session when an address pair fails can be pretty long (tens of seconds to minutes), and I suspect that using a probing method to make the initial choice of address pair would also be slow. So, circling back to the problem statement: the objective is to make the best possible initial guess at the best address pair to use, and the value of a GRO is to help the receiving entity make that best guess. Brian From brian.e.carpenter@gmail.com Thu Nov 19 12:36:02 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6745A3A687B for ; Thu, 19 Nov 2009 12:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqoXPv50FlyE for ; Thu, 19 Nov 2009 12:36:01 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id B3E4D3A6841 for ; Thu, 19 Nov 2009 12:36:01 -0800 (PST) Received: by pxi16 with SMTP id 16so1779325pxi.29 for ; Thu, 19 Nov 2009 12:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=+ZcwjPs6JkwIsWAMP8oPHBkuoHzG22Mfb+6Zt7hBqbM=; b=ltSiwzukZDS8U77MT4k1T7PHvyxvQXhMAyOuWPBAcnbi6jZ3TBdVFw7GQrjOqh44gI 5rSu1p7mt4kwQ/7pH3eCGR1yXgxlKE6eEscuRo9MNr57Ba8/ZoV+ceaaAhrs5CN+5j3S aiHowEnJlwaYfSuNoPNDpdNBce9LTO1wTria8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=gcobjnBNGgDFqnIIO28efP7+8g57RuY5a4Z5QRi5KqAu5CLWmO+c9hGDOCcPhBW3LQ 1zSbcTz4i3e/9ZbWUpgtGcR9HS9UUqWAN+HDJShv7vSFzW1rsb1VrfwLvhyRQcbcO6qo 95hGJ0YPhzbe9JnAdF7OrFZ0z2XJ6tu+1mCZ4= Received: by 10.115.66.35 with SMTP id t35mr489530wak.87.1258662956810; Thu, 19 Nov 2009 12:35:56 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm543247pzk.0.2009.11.19.12.35.55 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 12:35:56 -0800 (PST) Message-ID: <4B05AC31.9090708@gmail.com> Date: Fri, 20 Nov 2009 09:36:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: grobj@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [grobj] Minutes? And how to proceed? X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:36:02 -0000 Are the draft minutes from the BOF ready? I suggest that we have some free form discussion for a week or two. Then I volunteer to start sketching out a bullet list of problems/requirements. It's *really* helpful to set a subject field for your message that clearly identifies the main issue. Brian From dwing@cisco.com Thu Nov 19 12:42:12 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19503A6828 for ; Thu, 19 Nov 2009 12:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzfn2NHw+j22 for ; Thu, 19 Nov 2009 12:42:09 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1FDA53A67CC for ; Thu, 19 Nov 2009 12:42:09 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAN48BUurRN+J/2dsb2JhbACKMrNtl3qEOwQ X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="51755301" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2009 20:42:07 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAJKg669001371; Thu, 19 Nov 2009 20:42:07 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , References: <4B05AC31.9090708@gmail.com> Date: Thu, 19 Nov 2009 12:42:06 -0800 Message-ID: <0e8a01ca6958$c24d3a00$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B05AC31.9090708@gmail.com> Thread-Index: AcppV+ipDeVvoG88Q2qkvXtH6SDdxgAAMs2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [grobj] Minutes? And how to proceed? X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:42:12 -0000 > -----Original Message----- > From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] > On Behalf Of Brian E Carpenter > Sent: Thursday, November 19, 2009 12:36 PM > To: grobj@ietf.org > Subject: [grobj] Minutes? And how to proceed? > > Are the draft minutes from the BOF ready? Not yet. I am hoping to do minutes for both of my BoFs and BEHAVE today. -d > I suggest that we have some free form discussion for a week > or two. Then I volunteer to start sketching out a bullet list > of problems/requirements. > > It's *really* helpful to set a subject field for your message > that clearly identifies the main issue. > > Brian > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj From dwing@cisco.com Thu Nov 19 12:44:43 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C5A3A67E1 for ; Thu, 19 Nov 2009 12:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkGtWQXPdh8h for ; Thu, 19 Nov 2009 12:44:43 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 144383A67CC for ; Thu, 19 Nov 2009 12:44:43 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAN48BUurRN+K/2dsb2JhbACKMrNtl3qEOwQ X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="51756497" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2009 20:44:41 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAJKiejp021756; Thu, 19 Nov 2009 20:44:40 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , "'Simon Perreault'" References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org><4B055227.3090902@viagenie.ca> <4B05A8CD.5020804@gmail.com> Date: Thu, 19 Nov 2009 12:44:40 -0800 Message-ID: <0e8b01ca6959$1e118170$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B05A8CD.5020804@gmail.com> Thread-Index: AcppVeNLIgFGMllcRyWR911RCD3JFwAAusig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: grobj@ietf.org Subject: Re: [grobj] NATs and scope X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:44:43 -0000 > -----Original Message----- > From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] > On Behalf Of Brian E Carpenter > Sent: Thursday, November 19, 2009 12:22 PM > To: Simon Perreault > Cc: grobj@ietf.org > Subject: [grobj] NATs and scope > > On 2009-11-20 03:11, Simon Perreault wrote: > > > - The "scope" of an address (I'm still not fully > understanding the concept) does > > not guarantee that that the address is reachable from > anyone in that scope. For > > example, the address of a NAT binding (called a "reflexive > transport address" in > > RFC5389) can be reached by a subset of peers in the NAT's > scope which depends on > > the type of NAT (see e.g. RFC4787 for types of NATs). > > So, given what I just said about scope (with no reference to > NATs), I think > Simon needs to tell us what he means by "in the NAT's scope". > > To me an address scope is a set of mutually reachable addresses, which > means that a NAT automatically forms (part of) the boundary > of a scope. > I don't understand what is meant by "a subset of peers" - surely all > the peers behind a given NAT (more precisely, behind a given interface > of a given NAT) are in the same address space? Maybe, if the topology is like: Internet | | "A Given NAT" / \ Host-A Host-B but not, if the topology is like: Internet | | "A Given NAT" / \ Host-A "Another NAT" | Host-B -d From simon.perreault@viagenie.ca Thu Nov 19 13:00:26 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52523A6855 for ; Thu, 19 Nov 2009 13:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBXfsHotoZS6 for ; Thu, 19 Nov 2009 13:00:26 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id E9E8A3A67CC for ; Thu, 19 Nov 2009 13:00:25 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 5FF6E20E37; Thu, 19 Nov 2009 16:00:23 -0500 (EST) Message-ID: <4B05B1E6.2000702@viagenie.ca> Date: Thu, 19 Nov 2009 16:00:22 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Brian E Carpenter References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <4B05A8CD.5020804@gmail.com> In-Reply-To: <4B05A8CD.5020804@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] NATs and scope X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:00:27 -0000 Brian E Carpenter wrote, on 2009-11-19 15:21: > On 2009-11-20 03:11, Simon Perreault wrote: > >> - The "scope" of an address (I'm still not fully understanding the concept) does >> not guarantee that that the address is reachable from anyone in that scope. For >> example, the address of a NAT binding (called a "reflexive transport address" in >> RFC5389) can be reached by a subset of peers in the NAT's scope which depends on >> the type of NAT (see e.g. RFC4787 for types of NATs). > > So, given what I just said about scope (with no reference to NATs), I think > Simon needs to tell us what he means by "in the NAT's scope". I meant the scope of the interface on the NAT that is usually labeled "WAN". That's usually Internet-scope, but it's common to have multiple layers of NAT, in which case the scope would be different. > To me an address scope is a set of mutually reachable addresses, which > means that a NAT automatically forms (part of) the boundary of a scope. > I don't understand what is meant by "a subset of peers" - surely all > the peers behind a given NAT (more precisely, behind a given interface > of a given NAT) are in the same address space? Here's an example: LAN --------|NAT|---- WAN 10.0.0.0/8 Internet A host in the LAN initiates a UDP "connection" to the WAN. The NAT allocates a binding on its WAN interface, e.g. 192.0.2.1:1234. The scope of this is "Internet" I would presume. For some kinds of NAT devices, any host on the Internet can reach the host on the LAN by sending packets to 192.0.2.1:1234. For other kinds, only hosts to which the host in the LAN has previously talked using this binding can reach it. So even if hosts are in the same scope as 192.0.2.1:1234, they may not be able to use it. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From brian.e.carpenter@gmail.com Thu Nov 19 13:51:33 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5413A69BE for ; Thu, 19 Nov 2009 13:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaLUqKOgYgsD for ; Thu, 19 Nov 2009 13:51:32 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id B66223A699E for ; Thu, 19 Nov 2009 13:51:32 -0800 (PST) Received: by pzk6 with SMTP id 6so1806956pzk.29 for ; Thu, 19 Nov 2009 13:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FOUrUy8q1atJ6FZ2bHrK/rvLFYQuDxqksTpvmRgMCPw=; b=maMbUpL+WCgtyHzq8zdAXNWPj0ucsVhTonsEeGNb5fDUJ40EFyFXmXL7poPrQQhmOB BMpHWtcc4WwyJT16xE82tJnPwa/EdIKzpSolDqYuQSGhw7tl2g2UVg0X4NYGzJRX7oRp X8jdPUrqjtAahinTUSBfVu2lRe4ogLReKYyPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=W7YeDCn1/5+n/i4gKwjZpumUHSBcILq0OahvFQJAWC0zHDt6b6xrANjdyLAdy+URqR iATsZdOcdbTyPOqGI7yMY9/RSBmBuatny7ibJqGgPynAkel3vqF2xGRk96yCaYRQ/xeb e7mY1z/O1f97xiXDGDDy8LYCjLieOcjW/tdS4= Received: by 10.114.18.29 with SMTP id 29mr563152war.147.1258667487198; Thu, 19 Nov 2009 13:51:27 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm572433pzk.3.2009.11.19.13.51.25 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 13:51:26 -0800 (PST) Message-ID: <4B05BDDD.1040505@gmail.com> Date: Fri, 20 Nov 2009 10:51:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <4B05A8CD.5020804@gmail.com> <4B05B1E6.2000702@viagenie.ca> In-Reply-To: <4B05B1E6.2000702@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] NATs and scope X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:51:33 -0000 On 2009-11-20 10:00, Simon Perreault wrote: > Brian E Carpenter wrote, on 2009-11-19 15:21: >> On 2009-11-20 03:11, Simon Perreault wrote: >> >>> - The "scope" of an address (I'm still not fully understanding the concept) does >>> not guarantee that that the address is reachable from anyone in that scope. For >>> example, the address of a NAT binding (called a "reflexive transport address" in >>> RFC5389) can be reached by a subset of peers in the NAT's scope which depends on >>> the type of NAT (see e.g. RFC4787 for types of NATs). >> So, given what I just said about scope (with no reference to NATs), I think >> Simon needs to tell us what he means by "in the NAT's scope". > > I meant the scope of the interface on the NAT that is usually labeled "WAN". > That's usually Internet-scope, but it's common to have multiple layers of NAT, > in which case the scope would be different. > >> To me an address scope is a set of mutually reachable addresses, which >> means that a NAT automatically forms (part of) the boundary of a scope. >> I don't understand what is meant by "a subset of peers" - surely all >> the peers behind a given NAT (more precisely, behind a given interface >> of a given NAT) are in the same address space? > > Here's an example: > > LAN --------|NAT|---- WAN > 10.0.0.0/8 Internet > > A host in the LAN initiates a UDP "connection" to the WAN. The NAT allocates a > binding on its WAN interface, e.g. 192.0.2.1:1234. The scope of this is > "Internet" I would presume. > > For some kinds of NAT devices, any host on the Internet can reach the host on > the LAN by sending packets to 192.0.2.1:1234. > > For other kinds, only hosts to which the host in the LAN has previously talked > using this binding can reach it. > > So even if hosts are in the same scope as 192.0.2.1:1234, they may not be able > to use it. OK. So, in my personal view of the universe, "in scope" means reachable directly and without translation. We need to be precise about some of these definitions, clearly. Brian From moore@network-heretics.com Thu Nov 19 14:35:52 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144133A6896 for ; Thu, 19 Nov 2009 14:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9T1Z9+5pamj for ; Thu, 19 Nov 2009 14:35:51 -0800 (PST) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 30A2F3A6894 for ; Thu, 19 Nov 2009 14:35:51 -0800 (PST) Received: from lust.indecency.org (70-11-255-119.pools.spcsdns.net [70.11.255.119]) by m1.imap-partners.net (MOS 4.1.7-GA) with ESMTP id BBW22857 (AUTH admin@network-heretics.com); Thu, 19 Nov 2009 14:35:42 -0800 Message-ID: <4B05C837.1010609@network-heretics.com> Date: Thu, 19 Nov 2009 17:35:35 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Brian E Carpenter References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> <0de301ca694b$30e26ed0$c2f0200a@cisco.com> <4B059BC8.9020809@viagenie.ca> <4B05AB77.8040800@gmail.com> In-Reply-To: <4B05AB77.8040800@gmail.com> Content-Type: multipart/alternative; boundary="------------080009030003030602080503" Cc: grobj@ietf.org Subject: Re: [grobj] Trying all addresses X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:35:52 -0000 This is a multi-part message in MIME format. --------------080009030003030602080503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > On 2009-11-20 08:26, Simon Perreault wrote: >> Dan Wing wrote, on 2009-11-19 14:04: >>> If there are a lot of candidate addresses and >>> candidate transports it's time-consuming to try all of them. >> Why not try all of them simultaneously? It would waste bandwidth, but probably >> not a significant amount. If concerned you can impose a concurrency limit. Then >> you use the equivalent of ICE's aggressive nomination but make it choose the >> highest priority candidate (instead of the first successful one) that is >> successful within a given time window following the first successful check. > > Actually this has been discussed quite a bit in the context of "what's wrong > with RFC3484?" It's also been implemented in the REAP protocol which is > associated with SHIM6. My student Habib Naderi is currently simulating > REAP's behaviour when exploring various numbers of address pairs. The work > isn't quite cooked enough yet to give numbers, but one of his conclusions > is that the actual amount of probe traffic caused by REAP is not a big > problem. However, the recovery time for a TCP session when an address pair > fails can be pretty long (tens of seconds to minutes), and I suspect that > using a probing method to make the initial choice of address pair would > also be slow. > > So, circling back to the problem statement: the objective is to make the > best possible initial guess at the best address pair to use, and the > value of a GRO is to help the receiving entity make that best guess. "Picking the best" address is not the only viable strategy. It makes sense, for some applications, to concurrently utilize multiple paths. e.g. If your application is transferring large data sets, and it finds that it has multiple paths between the endpoints available to it, it makes sense to send data over each of those paths, and adjust the amount of data sent over each according to the characteristics of each path, to get the fastest transfer. As a bonus you get the ability to survive failures of individual paths. Keith --------------080009030003030602080503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: 
On 2009-11-20 08:26, Simon Perreault wrote:

Dan Wing wrote, on 2009-11-19 14:04:

If there are a lot of candidate addresses and 
candidate transports it's time-consuming to try all of them.

Why not try all of them simultaneously? It would waste bandwidth, but probably
not a significant amount. If concerned you can impose a concurrency limit. Then
you use the equivalent of ICE's aggressive nomination but make it choose the
highest priority candidate (instead of the first successful one) that is
successful within a given time window following the first successful check.


Actually this has been discussed quite a bit in the context of "what's wrong
with RFC3484?" It's also been implemented in the REAP protocol which is
associated with SHIM6. My student Habib Naderi is currently simulating
REAP's behaviour when exploring various numbers of address pairs. The work
isn't quite cooked enough yet to give numbers, but one of his conclusions
is that the actual amount of probe traffic caused by REAP is not a big
problem. However, the recovery time for a TCP session when an address pair
fails can be pretty long (tens of seconds to minutes), and I suspect that
using a probing method to make the initial choice of address pair would
also be slow.

So, circling back to the problem statement: the objective is to make the
best possible initial guess at the best address pair to use, and the
value of a GRO is to help the receiving entity make that best guess.
"Picking the best" address is not the only viable strategy.  It makes sense, for some applications, to concurrently utilize multiple paths.  e.g. If your application is transferring large data sets, and it finds that it has multiple paths between the endpoints available to it, it makes sense to send data over each of those paths, and adjust the amount of data sent over each according to the characteristics of each path, to get the fastest transfer.   As a bonus you get the ability to survive failures of individual paths.

Keith

--------------080009030003030602080503-- From zhangdong_rh@huaweisymantec.com Thu Nov 19 17:28:36 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94393A69AE for ; Thu, 19 Nov 2009 17:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lOlofqI+f6q for ; Thu, 19 Nov 2009 17:28:36 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 332443A6983 for ; Thu, 19 Nov 2009 17:28:36 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTD002JXW3BAV20@hstga02-in.huaweisymantec.com> for grobj@ietf.org; Fri, 20 Nov 2009 09:28:23 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTD00K6WW3ANZ10@hstml02-in.huaweisymantec.com> for grobj@ietf.org; Fri, 20 Nov 2009 09:28:23 +0800 (CST) Date: Fri, 20 Nov 2009 09:28:22 +0800 From: Dong Zhang To: Brian E Carpenter , Simon Perreault References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> <0de301ca694b$30e26ed0$c2f0200a@cisco.com> <4B059BC8.9020809@viagenie.ca> <4B05AB77.8040800@gmail.com> Message-id: <200911200928221750259@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: "grobj@ietf.org" Subject: Re: [grobj] Trying all addresses X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 01:28:37 -0000 Hi, Brian E Carpenter 2009-11-20 Wrote: > >So, circling back to the problem statement: the objective is to make the >best possible initial guess at the best address pair to use, and the >value of a GRO is to help the receiving entity make that best guess. Imho, having a little information is better than nothing, although the objective is not enough to make the decision solely. Thanks. > > Brian >_______________________________________________ >grobj mailing list >grobj@ietf.org >https://www.ietf.org/mailman/listinfo/grobj ------------------ Dong Zhang 2009-11-20 From brian.e.carpenter@gmail.com Thu Nov 19 18:29:26 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E5E3A6966 for ; Thu, 19 Nov 2009 18:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhJ1gw1KKw+G for ; Thu, 19 Nov 2009 18:29:26 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 273EA3A68AC for ; Thu, 19 Nov 2009 18:29:26 -0800 (PST) Received: by pwi6 with SMTP id 6so1933041pwi.29 for ; Thu, 19 Nov 2009 18:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8U4o1a+/9lJpbI/wI/iLd+qZPxh6tEn3buvVCsu1LNU=; b=g0YouP8b/EXJTC4WLvfJAbwwtk2XZuRMK02kBOczDmlklrc/htJMyqPlssRkzreGQ3 h3oUL/YqZuP5AAO/RDTBiD1zN5IhOtZhuMKZdtjF33zMlBrgAGwTW6GbBNKxxLh+iqa8 yjWXAEHXSOcgsYL4jNA/by2vQ6oXU7Bs9C5ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=sm2ja1qUWXrR6vSlnG+qxNSOS6cuCC9RCdyZphtvtzSnR+aQcIdGGwj8HPib/8Ngai 77Ohe8cNFzzxJYpJpak0C8PnOzh4Jw0H1FpDhImM+gwrw300hP9qX25KcUV0AOcFiDdG kP/xsZumiVThvXpBYC7ii38dS95/GCP55d+SE= Received: by 10.115.24.10 with SMTP id b10mr1016932waj.127.1258684156281; Thu, 19 Nov 2009 18:29:16 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm667549pzk.5.2009.11.19.18.29.15 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 18:29:15 -0800 (PST) Message-ID: <4B05FEF8.5060807@gmail.com> Date: Fri, 20 Nov 2009 15:29:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> <0de301ca694b$30e26ed0$c2f0200a@cisco.com> <4B059BC8.9020809@viagenie.ca> <4B05AB77.8040800@gmail.com> <4B05C837.1010609@network-heretics.com> In-Reply-To: <4B05C837.1010609@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Trying all addresses X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 02:29:27 -0000 On 2009-11-20 11:35, Keith Moore wrote: > Brian E Carpenter wrote: >> On 2009-11-20 08:26, Simon Perreault wrote: >>> Dan Wing wrote, on 2009-11-19 14:04: >>>> If there are a lot of candidate addresses and >>>> candidate transports it's time-consuming to try all of them. >>> Why not try all of them simultaneously? It would waste bandwidth, but probably >>> not a significant amount. If concerned you can impose a concurrency limit. Then >>> you use the equivalent of ICE's aggressive nomination but make it choose the >>> highest priority candidate (instead of the first successful one) that is >>> successful within a given time window following the first successful check. >> Actually this has been discussed quite a bit in the context of "what's wrong >> with RFC3484?" It's also been implemented in the REAP protocol which is >> associated with SHIM6. My student Habib Naderi is currently simulating >> REAP's behaviour when exploring various numbers of address pairs. The work >> isn't quite cooked enough yet to give numbers, but one of his conclusions >> is that the actual amount of probe traffic caused by REAP is not a big >> problem. However, the recovery time for a TCP session when an address pair >> fails can be pretty long (tens of seconds to minutes), and I suspect that >> using a probing method to make the initial choice of address pair would >> also be slow. >> >> So, circling back to the problem statement: the objective is to make the >> best possible initial guess at the best address pair to use, and the >> value of a GRO is to help the receiving entity make that best guess. > "Picking the best" address is not the only viable strategy. It makes > sense, for some applications, to concurrently utilize multiple paths. > e.g. If your application is transferring large data sets, and it finds > that it has multiple paths between the endpoints available to it, it > makes sense to send data over each of those paths, and adjust the amount > of data sent over each according to the characteristics of each path, to > get the fastest transfer. As a bonus you get the ability to survive > failures of individual paths. Absolutely. I don't see why a GRO can't be used to "prime" multipath TCP. Brian From dwing@cisco.com Thu Nov 19 19:05:16 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CCF3A6809 for ; Thu, 19 Nov 2009 19:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDEBazGRjYgJ for ; Thu, 19 Nov 2009 19:05:15 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6A5BB3A67A4 for ; Thu, 19 Nov 2009 19:05:15 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAO+VBUtAZnwN/2dsb2JhbACKM7QHl2iEOwQ X-IronPort-AV: E=Sophos;i="4.44,774,1249257600"; d="scan'208";a="69027439" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2009 03:05:12 +0000 Received: from dwingwxp01 ([10.32.240.194]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAK35BqK015890; Fri, 20 Nov 2009 03:05:11 GMT From: "Dan Wing" To: Date: Thu, 19 Nov 2009 19:05:10 -0800 Message-ID: <012a01ca698e$46800cf0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcppjkV8itKiWzAnRyaqbu218wIgWA== Subject: [grobj] draft GROBJ minutes posted X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 03:05:16 -0000 http://www.ietf.org/proceedings/09nov/minutes/grobj.txt