From dean.willis@softarmor.com Wed Apr 1 11:01:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4513A6DD9 for ; Wed, 1 Apr 2009 11:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 iUzcErIOpJl7 for ; Wed, 1 Apr 2009 11:01:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B08863A6C83 for ; Wed, 1 Apr 2009 11:01:29 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n31I2MAj026291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2009 13:02:24 -0500 Message-Id: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> From: Dean Willis To: Salman Abdul Baset In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 13:02:17 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:01:30 -0000 On Mar 26, 2009, at 10:53 PM, Salman Abdul Baset wrote: > >> Your alternate solution is an assumption that the overlay will >> contain >> enough TCP open-access nodes that are able to identify themselves as >> open-access nodes and willing to bear the burden of their role on >> behalf of all the other peers. What I've seen is that UDP actually >> works, and TCP doesn't. > > Skype works. It has enough nodes that can provide relay services. The Skype operators apparently pay to put their supernodes into places from which they can provide relay services. This isn't inexpensive. You have funding to support RELOAD supernodes? -- Dean From davidbryan@gmail.com Wed Apr 1 12:32:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3075E3A6BD5 for ; Wed, 1 Apr 2009 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 n9QL07v9enuI for ; Wed, 1 Apr 2009 12:32:21 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 65A8B3A6BC8 for ; Wed, 1 Apr 2009 12:32:21 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so226730yxm.49 for ; Wed, 01 Apr 2009 12:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O/kylvkMK5HokjicxIv3QdDpTnU6wWGEmM5V2RHQ1gg=; b=NdRipc8abx/cSJrr77JZ30sgWmjFYSA+Xz7fsO0zLCppzMRv8yD+5NdctN6C4fioPC fAFULaU/IH8Z06/6vJcjSjn8bBjyyl/mvd2kGFlDR8/LIqYpHKVLGm/ffl2u7PcWgNao g+t5ZMxaU0p77LJU5GiQEQCErMS+w5QYO/5/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=LMMlbFbBEFuLrXNFQdI7BkxoITc0TtAkAFbMcWtqh7fha3SgwRMUZGin3hfFgUT9mS g62I0nHYf0P33cRIKy4XuDqCNOwyfmfJ1AFbT0Mdw8gZE2ZLaeeShrfkdF0CgII5CINF X2QRqy5afdPsufNMVgoAkyEjjzJmV/rjF0HMg= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.43.19 with SMTP id v19mr14961037ybj.125.1238614401849; Wed, 01 Apr 2009 12:33:21 -0700 (PDT) Date: Wed, 1 Apr 2009 15:33:21 -0400 X-Google-Sender-Auth: c6ac8a9fdc1be979 Message-ID: <8b2769930904011233u67088689ob22ba6752cf5e5b3@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Draft minutes from the San Francisco meeting X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:32:22 -0000 I have put up draft minutes from the San Francisco meeting on the meeting materials page. Please review and comment on these when you have a moment. https://datatracker.ietf.org/meeting/74/materials.html Thanks, David (as chair) From sa2086@columbia.edu Wed Apr 1 13:05:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C303A68C8 for ; Wed, 1 Apr 2009 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2COkNmpdgpLd for ; Wed, 1 Apr 2009 13:05:40 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 6F9213A68AA for ; Wed, 1 Apr 2009 13:05:40 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n31K6ZU0016057; Wed, 1 Apr 2009 16:06:36 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n31K6ZIV005613; Wed, 1 Apr 2009 16:06:35 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n31K6ZIi005610; Wed, 1 Apr 2009 16:06:35 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 1 Apr 2009 16:06:35 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Dean Willis In-Reply-To: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> Message-ID: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:05:41 -0000 On Wed, 1 Apr 2009, Dean Willis wrote: > > On Mar 26, 2009, at 10:53 PM, Salman Abdul Baset wrote: > >> >>> Your alternate solution is an assumption that the overlay will contain >>> enough TCP open-access nodes that are able to identify themselves as >>> open-access nodes and willing to bear the burden of their role on >>> behalf of all the other peers. What I've seen is that UDP actually >>> works, and TCP doesn't. >> >> Skype works. It has enough nodes that can provide relay services. > > The Skype operators apparently pay to put their supernodes into places from > which they can provide relay services. This isn't inexpensive. > > You have funding to support RELOAD supernodes? > I don't. I am a Ph.D. student -:) Just to be clear, I was refering to the relaying of RELOAD messages and not the media. An insight from our Skype analysis is that the Skype application fails to join the Skype network if it cannot establish a TCP connection with any Skype super node. Nevertheless, relaying of p2p+signaling+media raises some important issues: 1) Why would Skype pay to put their super nodes into places where they could provide relay services? 2) How do we know if these 'paid' nodes are being heavily or sparingly used as media relays? For (1) Skype would do that because they do not want calls to fail if they are unable to find an altruistic Skype node that can relay media. That is just a smart of designing a system. Failed calls = bad publicity. For (2) Clearly, Skype knows this. However, since we do not have this information, the next best thing is to perform measurements. We performed experiments where two Skype nodes were forced to select a relay for about ~18,000 calls and we found 9,584 unique media relays. About 46% of calls were relayed through nodes in educational institutions. These two statistics seem to indicate that the likelihood of paid Skype nodes being heavily used as relays is fairly low. Meaning, that Skype has no shortage of altruistic media relays. (See slide 8) http://www1.cs.columbia.edu/~salman/presentations/skyperelay-gi08.ppt and http://www1.cs.columbia.edu/~salman/publications/skyperelay-gi08.pdf I wonder how much money Skype is paying to operators for relay services. My guess is that it should be significantly smaller than say what MSN messenger has to pay. Regards, Salman From ekr@rtfm.com Wed Apr 1 13:09:58 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1C63A684A for ; Wed, 1 Apr 2009 13:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 YcKRQckQiPnU for ; Wed, 1 Apr 2009 13:09:57 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 612A53A6AA2 for ; Wed, 1 Apr 2009 13:09:52 -0700 (PDT) Received: by qyk36 with SMTP id 36so458462qyk.29 for ; Wed, 01 Apr 2009 13:10:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.203 with SMTP id t11mr4008980vcl.108.1238616652379; Wed, 01 Apr 2009 13:10:52 -0700 (PDT) In-Reply-To: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> Date: Wed, 1 Apr 2009 13:10:50 -0700 Message-ID: From: Eric Rescorla To: Salman Abdul Baset Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:09:58 -0000 On Wed, Apr 1, 2009 at 1:06 PM, Salman Abdul Baset wrote: > For (2) > Clearly, Skype knows this. However, since we do not have this information, > the next best thing is to perform measurements. We performed experiments > where two Skype nodes were forced to select a relay for about ~18,000 calls > and we found 9,584 unique media relays. About 46% of calls were relayed > through nodes in educational institutions. These two statistics seem to > indicate that the likelihood of paid Skype nodes being heavily used as > relays is fairly low. Meaning, that Skype has no shortage of altruistic > media relays. It's important to recognize one very significant difference between RELOAD and Skype: Skype controls the software you run and so can make you act as a supernode--or at least make it fairly difficult to opt out. By contrast, RELOAD will presumably be open software (at least the protocols will be open) so you cannot force users to run relays. -Ekr From sa2086@columbia.edu Wed Apr 1 13:26:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073A03A6B22 for ; Wed, 1 Apr 2009 13:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boTS6RA33Ozw for ; Wed, 1 Apr 2009 13:26:43 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id D8DD63A6988 for ; Wed, 1 Apr 2009 13:26:42 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n31KRgqL014704; Wed, 1 Apr 2009 16:27:42 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n31KRgE7008573; Wed, 1 Apr 2009 16:27:42 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n31KRfdu008570; Wed, 1 Apr 2009 16:27:42 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 1 Apr 2009 16:27:41 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Eric Rescorla In-Reply-To: Message-ID: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:26:44 -0000 On Wed, 1 Apr 2009, Eric Rescorla wrote: > On Wed, Apr 1, 2009 at 1:06 PM, Salman Abdul Baset wrote: > >> For (2) >> Clearly, Skype knows this. However, since we do not have this information, >> the next best thing is to perform measurements. We performed experiments >> where two Skype nodes were forced to select a relay for about ~18,000 calls >> and we found 9,584 unique media relays. About 46% of calls were relayed >> through nodes in educational institutions. These two statistics seem to >> indicate that the likelihood of paid Skype nodes being heavily used as >> relays is fairly low. Meaning, that Skype has no shortage of altruistic >> media relays. > > It's important to recognize one very significant difference between > RELOAD and Skype: > Skype controls the software you run and so can make you act as a > supernode--or at > least make it fairly difficult to opt out. By contrast, RELOAD will > presumably be open > software (at least the protocols will be open) so you cannot force > users to run relays. > > -Ekr Skype does make an active effort to avoid media relaying. These include techniques like ICE-UDP and media-over-TCP for UDP-blocking firewalls. So in terms of designing protocols for directly sending media, Skype and RELOAD are no different. Starting with v3.2, Skype provides a mechanism to turn off the super node feature. See this: http://www.skype.com/security/universities/ -s From enrico.marocco@telecomitalia.it Wed Apr 1 14:17:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD453A6911 for ; Wed, 1 Apr 2009 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 AL2yU37DuVR3 for ; Wed, 1 Apr 2009 14:17:29 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id B23333A6A15 for ; Wed, 1 Apr 2009 14:17:28 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 1 Apr 2009 23:18:24 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 1 Apr 2009 23:18:25 +0200 Message-ID: <49D3DA20.70602@telecomitalia.it> Date: Wed, 1 Apr 2009 23:18:24 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Eric Rescorla References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050600060704050407080407" Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:17:30 -0000 --------------ms050600060704050407080407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > It's important to recognize one very significant difference between > RELOAD and Skype: Skype controls the software you run and so can make > you act as a supernode--or at least make it fairly difficult to opt > out. By contrast, RELOAD will presumably be open software (at least > the protocols will be open) so you cannot force users to run relays. Well, most BitTorrent clients are open source software and users have full control of the resources they share, but that doesn't prevent them to share often more than what they consume. Of course file-sharing and realtime communications are quite different beasts, but I don't think that if Skype allowed users to turn the local relay off, many would actually do that. -- Ciao, Enrico --------------ms050600060704050407080407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICEBtZixsKeF4i2Os0viEP+ncwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMyOTE2Mjg1OVoX DTEwMDMyOTE2Mjg1OVowUTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALhn5sIqd2hv7B6UBs4823vUHLamD/+tFSXZKQ4Yw5oQ 5hOdPUoJazGMDOyB9tWcqXdJxt0WqHxdgeCeAS0zV85Uf6cQcvkSe//umVkZvPuAYTKWRBJw 8rLfVuYhk9t2KraXyVfWIdoceZP0/v4eIoLyPw2/wQS3AvxujvkyL2N94S7IOmPCP6WXZmmW zNRzabSLLl50UA2jKbcYcWpKfQUFma9B1S3hAZTDiQTvXIJVmRdwYmnuwId9QTsm+7RB7oiy EC7+zeOORQk1Y6NjKinZmLb/C0tq40NIIPpBqNaZ+V6UmQ0jtYIlBQrlG6OpSPgjAS9IWsMg 7mbratVpsNkCAwEAAaM8MDowKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0 YWxpYS5pdDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADfh68XGwHIccDd0a+Fw D7LEP2QxLEqgP/gR73fsvT6y1COD7vGZY4BkYvryiU5sPkW4ulizN1ASSMJJIVMkQdzzKS+H e4dR5CpiPqz8b1LJdae8G7CUsBZ9KHYN4n6pGpdcq9YsGtfELp1W25MMppJcpKniscResCQF BWmw3EsAMIIC+DCCAmGgAwIBAgIQG1mLGwp4XiLY6zS+IQ/6dzANBgkqhkiG9w0BAQUFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDkwMzI5 MTYyODU5WhcNMTAwMzI5MTYyODU5WjBRMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMS4wLAYJKoZIhvcNAQkBFh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuGfmwip3aG/sHpQGzjzbe9QctqYP/60V JdkpDhjDmhDmE509SglrMYwM7IH21Zypd0nG3RaofF2B4J4BLTNXzlR/pxBy+RJ7/+6ZWRm8 +4BhMpZEEnDyst9W5iGT23YqtpfJV9Yh2hx5k/T+/h4igvI/Db/BBLcC/G6O+TIvY33hLsg6 Y8I/pZdmaZbM1HNptIsuXnRQDaMptxhxakp9BQWZr0HVLeEBlMOJBO9cglWZF3Biae7Ah31B Oyb7tEHuiLIQLv7N445FCTVjo2MqKdmYtv8LS2rjQ0gg+kGo1pn5XpSZDSO1giUFCuUbo6lI +CMBL0hawyDuZutq1Wmw2QIDAQABozwwOjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAN+HrxcbA chxwN3Rr4XAPssQ/ZDEsSqA/+BHvd+y9PrLUI4Pu8ZljgGRi+vKJTmw+Rbi6WLM3UBJIwkkh UyRB3PMpL4d7h1HkKmI+rPxvUsl1p7wbsJSwFn0odg3ifqkal1yr1iwa18QunVbbkwymklyk qeKxxF6wJAUFabDcSwAwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20CAQEwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBtZixsKeF4i 2Os0viEP+ncwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDkwNDAxMjExODI0WjAjBgkqhkiG9w0BCQQxFgQUoX/tvPdfkMqxbAjD dMok+4BaDfQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6 dzANBgkqhkiG9w0BAQEFAASCAQAcZCd7rpt2yFvYi6940t+LjqwVXCff/9FsIfCd0ssAyzMR y7qddENWj9RxdpqSISPH3YeWhawbnmbO5CfmIIMWe0P+xuFariM8wjLG/QUnxzLQAWSGSoTm We+87cpC1Giet8IvFd28QYyJUGQ1sqV6tlwB3bzd2NcQfscscU83Z7iVPSXB5FbOB0UDv4vA Lu1PnhsrrWwwtupauPd7XTyraKXsye4y4CEjA2NPfN1NfWb7ng4W4G74LlqYuXqiD1y3+72H ZpILfUSmOSc7sX6dLeK2hvZa1J1bW77aODefkmq403YoZLnw14sEw0v1lqrIU4xqUGr6J/e6 N+z7D3YIAAAAAAAA --------------ms050600060704050407080407-- From bbl@lowekamp.net Wed Apr 1 16:54:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF9F3A6BC1 for ; Wed, 1 Apr 2009 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 opNthEQjWzst for ; Wed, 1 Apr 2009 16:54:02 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 9674D3A69A9 for ; Wed, 1 Apr 2009 16:54:02 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so322069qwb.31 for ; Wed, 01 Apr 2009 16:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.74.17 with SMTP id s17mr3407773qcj.75.1238630103104; Wed, 01 Apr 2009 16:55:03 -0700 (PDT) In-Reply-To: <49D3DA20.70602@telecomitalia.it> References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> Date: Wed, 1 Apr 2009 19:55:02 -0400 Message-ID: From: Bruce Lowekamp To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 23:54:03 -0000 I really feel like this conversation has diverged from any useful purpose. The first question we need to answer is: - Do we need to support peers behind NATs? Based on the charter and the concepts draft, this is true. If you wish to contest this, please start a new thread to revisit this question in the concepts draft and charter. 2nd question: Do we need to have direct connections between peers most of the time, or can we rely on relays most of the time? This is a use case or application scenario question. Unfortunately, the group never adopted a draft, although there were several drafts that listed various scenarios. However, if you want believe p2psip work should only address use cases that have plenty of relays available, this should still be in a conversation thread labeled for that purpose and probably intended to update the concepts draft. 3rd question: What protocols work in scenarios with peers behind NATs trying to establish direct connections. If you believe this is anything other than TCP when possible, but UDP in an awful lot of cases, please direct your effort toward making ICE-TCP work in MMUSIC, and refer to discussions in MMUSIC for experiences with other solutions. My reading of the current charter, concepts draft, and state of the art for NAT traversal makes me believe that the RELOAD must define a UDP-based overlay link protocol. I hope we can discuss solutions to this problem. But if there is agreement that the requirements are different or need to be changed, let's be explicit in what question we're asking and what draft(s) need(s) to be changed. Those aren't RELOAD questions. Bruce From sa2086@columbia.edu Wed Apr 1 20:10:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C259A28C1B1 for ; Wed, 1 Apr 2009 20:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VunfPUdv1kWa for ; Wed, 1 Apr 2009 20:10:26 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id AAA9028C161 for ; Wed, 1 Apr 2009 20:10:26 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n323BQxh028807; Wed, 1 Apr 2009 23:11:26 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n323BQv0021701; Wed, 1 Apr 2009 23:11:26 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n323BQEu021688; Wed, 1 Apr 2009 23:11:26 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 1 Apr 2009 23:11:26 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 03:10:27 -0000 Assuming TCP-over-UDP is needed, my understanding from the list discussion and from the meeting is that our options are: 1) Design TCP-over-UDP in TSV. RELOAD refers to it. 2) If that may not be possible, then a) Design TCP-over-UDP as a seperate draft in P2PSIP WG. RELOAD refers to it. b) Define TCP-over-UDP in the base document. A custom protocol that only RELOAD can use. Now, what should be the performance requirements of TCP-over-UDP as compared to regular TCP? -Clearly, it should not exceed the performance of TCP. -It should not *only* rely on timeouts to recover losses. Otherwise, the performance is horrible. -It should not assume anything about the number of fragments. Do you think (1-3) are our only options for a TCP-over-UDP solution or did I miss something? Do you agree with the performance requirements of a TCP-over-UDP solution? If TCP-over-UDP is the solution, I prefer (1) or (2-a) as they are less likely to stall progress on the RELOAD base document. Now, the tricky question :) > 3rd question: What protocols work in scenarios with peers behind NATs > trying to establish direct connections. > > If you believe this is anything other than TCP when possible, but UDP > in an awful lot of cases, please direct your effort toward making > ICE-TCP work in MMUSIC, and refer to discussions in MMUSIC for > experiences with other solutions. > > My reading of the current charter, concepts draft, and state of the > art for NAT traversal makes me believe that the RELOAD must define a > UDP-based overlay link protocol. I hope we can discuss solutions to > this problem. But if there is agreement that the requirements are > different or need to be changed, let's be explicit in what question > we're asking and what draft(s) need(s) to be changed. Those aren't > RELOAD questions. I am totally willing to believe what you are saying but I want to arrive at the conclusion in a more systematic manner. Specifically, I am looking for a paper or a draft, that will exactly list the problems with the existing approaches (including Characterizing paper), and conclude that these approaches don't work or using these approaches is much expensive than a TCP-over-UDP solution. However, I am not able to find such a paper, or a draft in the BEHAVE WG. If there was a mailing list discussion, it will be helpful to have it in a draft form. Regards, Salman From bbl@lowekamp.net Sun Apr 5 20:06:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECCE28C0FD for ; Sun, 5 Apr 2009 20:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 CDTP0G9c8qZ6 for ; Sun, 5 Apr 2009 20:06:24 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 08A4F28C0FC for ; Sun, 5 Apr 2009 20:06:23 -0700 (PDT) Received: by fxm2 with SMTP id 2so1689599fxm.37 for ; Sun, 05 Apr 2009 20:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.103.133 with SMTP id k5mr3287813fao.23.1238987247913; Sun, 05 Apr 2009 20:07:27 -0700 (PDT) In-Reply-To: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> Date: Sun, 5 Apr 2009 23:07:27 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 03:06:25 -0000 Salman, We're not doing TCP over UDP. If you want to do that, then please by all means go do it in TSVWG. We have the option of simpy saying "use TFRC." That will be good enough performance, and require relatively little specification since TSV has already put a lot of work into it. It's also a bit complicated. A lot more complicated than is really needed for most p2psip implementations/deployments. So the motivation of the other options was to provide simpler options that are going to provide enough performance for many/most deployments. You seem very focused on thinking that they're trying to duplicate TCP. They're not. They are trying to be something that a fairly typical development team can build and get right, and get enough performance for their deployment scenarios to work. They are addressing congestion and reliability just like *every* UDP protocol needs to. If they need TCP-level performance out of UDP, they can implement TFRC. We can debate which features are needed or useful for performance without being too complicated for a long time, but that doesn't change the basic focus of what we're doing. (I think there may need to be a tweak in the receiver algorithm as speced now to let TFRCs reach full performance, but the intention is certainly to make sure TFRC implementations have the information they need.) Bruce On Wed, Apr 1, 2009 at 11:11 PM, Salman Abdul Baset wrote: > > Assuming TCP-over-UDP is needed, my understanding from the list discussio= n > and from the meeting is that our options are: > > 1) Design TCP-over-UDP in TSV. RELOAD refers to it. > 2) If that may not be possible, then > =C2=A0a) Design TCP-over-UDP as a seperate draft in P2PSIP WG. RELOAD ref= ers to > it. > =C2=A0b) Define TCP-over-UDP in the base document. A custom protocol that= only > =C2=A0 =C2=A0RELOAD can use. > > > Now, what should be the performance requirements of TCP-over-UDP as compa= red > to regular TCP? > > -Clearly, it should not exceed the performance of TCP. > -It should not *only* rely on timeouts to recover losses. Otherwise, the > performance is horrible. > -It should not assume anything about the number of fragments. > > Do you think (1-3) are our only options for a TCP-over-UDP solution or di= d I > miss something? Do you agree with the performance requirements of a > TCP-over-UDP solution? > > If TCP-over-UDP is the solution, I prefer (1) or (2-a) as they are less > likely to stall progress on the RELOAD base document. > > > Now, the tricky question :) > >> 3rd question: What protocols work in scenarios with peers behind NATs >> trying to establish direct connections. >> >> If you believe this is anything other than TCP when possible, but UDP >> in an awful lot of cases, please direct your effort toward making >> ICE-TCP work in MMUSIC, and refer to discussions in MMUSIC for >> experiences with other solutions. >> >> My reading of the current charter, concepts draft, and state of the >> art for NAT traversal makes me believe that the RELOAD must define a >> UDP-based overlay link protocol. =C2=A0I hope we can discuss solutions t= o >> this problem. =C2=A0But if there is agreement that the requirements are >> different or need to be changed, let's be explicit in what question >> we're asking and what draft(s) need(s) to be changed. =C2=A0Those aren't >> RELOAD questions. > > I am totally willing to believe what you are saying but I want to arrive = at > the conclusion in a more systematic manner. Specifically, I am looking fo= r a > paper or a draft, that will exactly list the problems with the existing > approaches (including Characterizing paper), and conclude that these > approaches don't work or using these approaches is much expensive than a > TCP-over-UDP solution. However, I am not able to find such a paper, or a > draft in the BEHAVE WG. If there was a mailing list discussion, it will b= e > helpful to have it in a draft form. > > > Regards, > Salman > From sa2086@columbia.edu Sun Apr 5 21:08:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E823A69BF for ; Sun, 5 Apr 2009 21:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 u-6hi4DNwOxZ for ; Sun, 5 Apr 2009 21:08:28 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id BFCE63A685E for ; Sun, 5 Apr 2009 21:08:28 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3649XF0008998; Mon, 6 Apr 2009 00:09:33 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3649Xfb017567; Mon, 6 Apr 2009 00:09:33 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n3649WP2017564; Mon, 6 Apr 2009 00:09:33 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Mon, 6 Apr 2009 00:09:32 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-824023566-1238990973=:13775" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 04:08:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-824023566-1238990973=:13775 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT I am worried about the situation in which packets traversing peers that run TCP have to be sent to a peer behind NAT using RELOAD's custom transport and cc protocol. Some unexpected failures may happen if this reliable and cc protocol is not properly designed. In the light of WG discussion, the questions I mentioned before need to be addressed before a full-blown solution, i.e., What are the performance requirements of this protocol? Where should this protocol be specified? -s On Sun, 5 Apr 2009, Bruce Lowekamp wrote: > Salman, > > We're not doing TCP over UDP. If you want to do that, then please by > all means go do it in TSVWG. > > We have the option of simpy saying "use TFRC." That will be good > enough performance, and require relatively little specification since > TSV has already put a lot of work into it. It's also a bit > complicated. A lot more complicated than is really needed for most > p2psip implementations/deployments. > > So the motivation of the other options was to provide simpler options > that are going to provide enough performance for many/most > deployments. You seem very focused on thinking that they're trying to > duplicate TCP. They're not. They are trying to be something that a > fairly typical development team can build and get right, and get > enough performance for their deployment scenarios to work. They are > addressing congestion and reliability just like *every* UDP protocol > needs to. > > If they need TCP-level performance out of UDP, they can implement > TFRC. We can debate which features are needed or useful for > performance without being too complicated for a long time, but that > doesn't change the basic focus of what we're doing. > > (I think there may need to be a tweak in the receiver algorithm as > speced now to let TFRCs reach full performance, but the intention is > certainly to make sure TFRC implementations have the information they > need.) > > Bruce > > On Wed, Apr 1, 2009 at 11:11 PM, Salman Abdul Baset > wrote: >> >> Assuming TCP-over-UDP is needed, my understanding from the list discussion >> and from the meeting is that our options are: >> >> 1) Design TCP-over-UDP in TSV. RELOAD refers to it. >> 2) If that may not be possible, then >>  a) Design TCP-over-UDP as a seperate draft in P2PSIP WG. RELOAD refers to >> it. >>  b) Define TCP-over-UDP in the base document. A custom protocol that only >>    RELOAD can use. >> >> >> Now, what should be the performance requirements of TCP-over-UDP as compared >> to regular TCP? >> >> -Clearly, it should not exceed the performance of TCP. >> -It should not *only* rely on timeouts to recover losses. Otherwise, the >> performance is horrible. >> -It should not assume anything about the number of fragments. >> >> Do you think (1-3) are our only options for a TCP-over-UDP solution or did I >> miss something? Do you agree with the performance requirements of a >> TCP-over-UDP solution? >> >> If TCP-over-UDP is the solution, I prefer (1) or (2-a) as they are less >> likely to stall progress on the RELOAD base document. >> >> >> Now, the tricky question :) >> >>> 3rd question: What protocols work in scenarios with peers behind NATs >>> trying to establish direct connections. >>> >>> If you believe this is anything other than TCP when possible, but UDP >>> in an awful lot of cases, please direct your effort toward making >>> ICE-TCP work in MMUSIC, and refer to discussions in MMUSIC for >>> experiences with other solutions. >>> >>> My reading of the current charter, concepts draft, and state of the >>> art for NAT traversal makes me believe that the RELOAD must define a >>> UDP-based overlay link protocol.  I hope we can discuss solutions to >>> this problem.  But if there is agreement that the requirements are >>> different or need to be changed, let's be explicit in what question >>> we're asking and what draft(s) need(s) to be changed.  Those aren't >>> RELOAD questions. >> >> I am totally willing to believe what you are saying but I want to arrive at >> the conclusion in a more systematic manner. Specifically, I am looking for a >> paper or a draft, that will exactly list the problems with the existing >> approaches (including Characterizing paper), and conclude that these >> approaches don't work or using these approaches is much expensive than a >> TCP-over-UDP solution. However, I am not able to find such a paper, or a >> draft in the BEHAVE WG. If there was a mailing list discussion, it will be >> helpful to have it in a draft form. >> >> >> Regards, >> Salman >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip ---559023410-824023566-1238990973=:13775-- From lars.eggert@nokia.com Mon Apr 6 02:19:26 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B8D3A6BC7 for ; Mon, 6 Apr 2009 02:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 0sEUoWeRmmzk for ; Mon, 6 Apr 2009 02:19:25 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 4A23F3A69D0 for ; Mon, 6 Apr 2009 02:19:24 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n369KFvn082769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2009 12:20:16 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Bruce Lowekamp In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-73-856894096; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 12:20:15 +0300 References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Mon, 06 Apr 2009 12:20:16 +0300 (EEST) Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 09:19:26 -0000 --Apple-Mail-73-856894096 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-6, at 6:07, Bruce Lowekamp wrote: > We have the option of simpy saying "use TFRC." That will be good > enough performance, and require relatively little specification since > TSV has already put a lot of work into it. It's also a bit > complicated. A lot more complicated than is really needed for most > p2psip implementations/deployments. > > So the motivation of the other options was to provide simpler options > that are going to provide enough performance for many/most > deployments. I'd strongly urge you to use TFRC rather than rolling your own scheme. Don't underestimate the validation effort that is required to ensure that a congestion control scheme is safe to deploy. This has all been done for TFRC, and it must be done for any new scheme. Lars --Apple-Mail-73-856894096 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MDYwOTIwMTVaMCMGCSqGSIb3DQEJBDEWBBTAvbGPjgipbJso bBfBerLbiTxjFjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEATttfYT3/fk9/ZiZPJ5MOPPT34Rn/hBM9/E98ijjuR7oyIbXtqb6n s13NTpBwJqrz7Av5PEGq4gx/AxNSjTOZaLlViZcLXMU/6p5p5CuojFJsrInzhLUWBzYQiHAES0Hw EAxZV4jMPJQxjnWC1ZKbOSSqZAnH1GmOn12LdMPx9/EnQI/UmeliUf6fDYO6164few+FvVM+igPD B+8t5L/m1Lo5WVeU9uwj6rOM6z22hPgeJL5o1EVMnt+yfzfWOfh0tbexlG+J4JeTv3UkKHedw7z/ aCIyNGZBhUjm2XDwocrw7iee2t4Uu9pvP+pFAdkaXY2BfYuCCa7S3YXkDCAjgwAAAAAAAA== --Apple-Mail-73-856894096-- From br@brianrosen.net Mon Apr 6 06:18:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA203A6C78 for ; Mon, 6 Apr 2009 06:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 C6T+lQyzV4Lt for ; Mon, 6 Apr 2009 06:18:08 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E801A28C196 for ; Mon, 6 Apr 2009 06:17:14 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lqoff-0002ve-Fr; Mon, 06 Apr 2009 08:15:27 -0500 From: "Brian Rosen" To: "'Lars Eggert'" , "'Bruce Lowekamp'" References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> In-Reply-To: Date: Mon, 6 Apr 2009 09:18:18 -0400 Message-ID: <044b01c9b6ba$28dc0550$7a940ff0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2mIwvrHapO5pRSuKp45jZ/WHU5AAIMKJQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'Salman Abdul Baset' , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:18:15 -0000 Is "use TCP when it works, and TRFC when it doesn't" an answer? Arguments like "it's too complex" don't work for me when we're talking transport protocols that have to do congestion control, etc. Congestion control is complex. Brian -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Monday, April 06, 2009 5:20 AM To: Bruce Lowekamp Cc: Salman Abdul Baset; p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability Hi, On 2009-4-6, at 6:07, Bruce Lowekamp wrote: > We have the option of simpy saying "use TFRC." That will be good > enough performance, and require relatively little specification since > TSV has already put a lot of work into it. It's also a bit > complicated. A lot more complicated than is really needed for most > p2psip implementations/deployments. > > So the motivation of the other options was to provide simpler options > that are going to provide enough performance for many/most > deployments. I'd strongly urge you to use TFRC rather than rolling your own scheme. Don't underestimate the validation effort that is required to ensure that a congestion control scheme is safe to deploy. This has all been done for TFRC, and it must be done for any new scheme. Lars From bbl@lowekamp.net Mon Apr 6 10:14:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB13C28C22E for ; Mon, 6 Apr 2009 10:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ssAWr6yisL12 for ; Mon, 6 Apr 2009 10:14:25 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id B0E3F28C234 for ; Mon, 6 Apr 2009 10:14:24 -0700 (PDT) Received: by bwz17 with SMTP id 17so1970565bwz.37 for ; Mon, 06 Apr 2009 10:15:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.110.11 with SMTP id l11mr3901103fap.50.1239038128035; Mon, 06 Apr 2009 10:15:28 -0700 (PDT) In-Reply-To: <044b01c9b6ba$28dc0550$7a940ff0$@net> References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> <044b01c9b6ba$28dc0550$7a940ff0$@net> Date: Mon, 6 Apr 2009 13:15:27 -0400 Message-ID: From: Bruce Lowekamp To: Brian Rosen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:14:31 -0000 Yes, that's a valid option. Probably the right one at this point. In fact, the solution space as I last sent it out looks like: - stop and wait - simplified AIMD - TFRC - (TCP over UDP might go here if a draft existed) - TCP The argument has mostly been about the simplified AIMD. I kind of hate to lose it, but you're right, it will be a lot less controversial if we do. Actually, TFRC is a pretty flexible protocol itself, so we can probably just do something a bit more within that framework if we want to have options. stop and wait was always intended as maybe a development-type protocol, not a real deployable protocol (although it would work OK in a small office environment) Bruce On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen wrote: > Is "use TCP when it works, and TRFC when it doesn't" an answer? > Arguments like "it's too complex" don't work for me when we're talking > transport protocols that have to do congestion control, etc. =C2=A0Conges= tion > control is complex. > > Brian > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > Lars Eggert > Sent: Monday, April 06, 2009 5:20 AM > To: Bruce Lowekamp > Cc: Salman Abdul Baset; p2psip@ietf.org > Subject: Re: [P2PSIP] Solution space for fragmentation, congestion contro= l > and reliability > > Hi, > > On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >> We have the option of simpy saying "use TFRC." =C2=A0That will be good >> enough performance, and require relatively little specification since >> TSV has already put a lot of work into it. =C2=A0It's also a bit >> complicated. =C2=A0A lot more complicated than is really needed for most >> p2psip implementations/deployments. >> >> So the motivation of the other options was to provide simpler options >> that are going to provide enough performance for many/most >> deployments. > > I'd strongly urge you to use TFRC rather than rolling your own scheme. > Don't underestimate the validation effort that is required to ensure that= a > congestion control scheme is safe to deploy. This has all been done for > TFRC, and it must be done for any new scheme. > > Lars > > From saverio.mascolo@gmail.com Mon Apr 6 10:34:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5860628C137 for ; Mon, 6 Apr 2009 10:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, 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 Irb43Gs3vSdX for ; Mon, 6 Apr 2009 10:34:54 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id 39F2C3A6CAE for ; Mon, 6 Apr 2009 10:34:54 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so906982fkq.5 for ; Mon, 06 Apr 2009 10:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :received:message-id:subject:from:to:cc:content-type; bh=XPJJ7CwhoaUUQ33lQSu3hDYjsd9cpKEb3AekbGEGUc4=; b=o6hGYJqTJq/hX3+wwourWX5WlPs/F/QlzTHYF7znc2fND8W92Bw/uOkaqJh4CbNcyZ Q+MCNMLBCf7jyaBGa0V7Di6Wyj6vx3iwOJ95aAtWA6pCQvNzUub2DBuRLrQgVx4AGuWM A0eu7PFw/dkhDr1TW9P7NuaPqIBo1it71Ck70= 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=eHCQR1upfeTc7TJOuaSaqdBPYcOKyjcp5QLHDIAm7wNDyxMtVbHQ7DTGwLOA8ld/ip 6q0eISdwaxZvLD3xeHchl/1OjVopdb0Nm1MgHEOF7v3djFieaC2qjrmfmIXnwDwH2Uqi GLs6Nqm3xccSkWP5f8Tzlv7YJt5xLpo2d3qPM= MIME-Version: 1.0 In-Reply-To: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> Date: Mon, 6 Apr 2009 19:35:44 +0200 Received: by 10.223.116.195 with SMTP id n3mr3927344faq.12.1239039359418; Mon, 06 Apr 2009 10:35:59 -0700 (PDT) Message-ID: From: Saverio Mascolo To: Lars Eggert Content-Type: multipart/alternative; boundary=001636c5a7e8e182120466e6545b Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:34:55 -0000 --001636c5a7e8e182120466e6545b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi lars, On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert wrote: > Hi, > > > I'd strongly urge you to use TFRC rather than rolling your own scheme. > Don't underestimate the validation effort that is required to ensure that a > congestion control scheme is safe to deploy. This has all been done for > TFRC, and it must be done for any new scheme. > > Lars is anyone aware of applications using TFRC? s --001636c5a7e8e182120466e6545b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi lars,

On Mon, Apr 6, 2009 at 11:20 AM,= Lars Eggert <lars.eggert@nokia.com> wrote:
Hi,


=A0
I'd strongly urge you to use TFRC rather than rolling your own scheme. = Don't underestimate the validation effort that is required to ensure th= at a congestion control scheme is safe to deploy. This has all been done fo= r TFRC, and it must be done for any new scheme.

Lars

is anyone=A0 aware of applications using T= FRC?

s

--001636c5a7e8e182120466e6545b-- From hgs@cs.columbia.edu Mon Apr 6 10:50:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD5F28C250 for ; Mon, 6 Apr 2009 10:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 o9ElhBR4HDL9 for ; Mon, 6 Apr 2009 10:50:01 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 8747728C17E for ; Mon, 6 Apr 2009 10:50:01 -0700 (PDT) Received: from [10.77.11.91] (vpn-128-59-248-45.vpn.columbia.edu [128.59.248.45]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n36HohU5027992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2009 13:50:59 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Saverio Mascolo In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-34-887521011 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 13:50:42 -0400 References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:50:07 -0000 --Apple-Mail-34-887521011 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I will note that TFRC was designed for long-lived streams (e.g., media streams), which probably differs a bit from our typical application in P2PSIP, where somewhat random pairs of nodes exchange data objects of a few dozen to a few hundred packets. For example, establishing a "fair" rate is not trivial under those conditions, and has high error margins. Henning On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote: > hi lars, > > On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert > wrote: > Hi, > > > > I'd strongly urge you to use TFRC rather than rolling your own > scheme. Don't underestimate the validation effort that is required > to ensure that a congestion control scheme is safe to deploy. This > has all been done for TFRC, and it must be done for any new scheme. > > Lars > > is anyone aware of applications using TFRC? > > s > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-34-887521011 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
I will note that TFRC was = designed for long-lived streams (e.g., media streams), which probably = differs a bit from our typical application in P2PSIP, where somewhat = random pairs of nodes exchange data objects of a few dozen to a few = hundred packets. For example, establishing a "fair" rate is not trivial = under those conditions, and has high error = margins.

Henning

On Apr 6, = 2009, at 1:35 PM, Saverio Mascolo wrote:

hi = lars,

On Mon, Apr 6, 2009 at 11:20 AM, = Lars Eggert <lars.eggert@nokia.com> = wrote:
Hi,


 
I'd strongly urge = you to use TFRC rather than rolling your own scheme. Don't underestimate = the validation effort that is required to ensure that a congestion = control scheme is safe to deploy. This has all been done for TFRC, and = it must be done for any new scheme.

= Lars

is anyone  aware of applications = using TFRC?

s

= _______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-34-887521011-- From br@brianrosen.net Mon Apr 6 10:53:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885AE3A6CED for ; Mon, 6 Apr 2009 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 uFj-MOQtrhAX for ; Mon, 6 Apr 2009 10:53:00 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B02D228C190 for ; Mon, 6 Apr 2009 10:53:00 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LqsyW-0002Pm-CF; Mon, 06 Apr 2009 12:51:12 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Saverio Mascolo'" References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> In-Reply-To: Date: Mon, 6 Apr 2009 13:54:04 -0400 Message-ID: <04dd01c9b6e0$aeb33740$0c19a5c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm23+FDmpF+WGlfSBWlN0lK7ko8CQAAKlrg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:53:08 -0000 Is that a fatal flaw, or merely an expression of concern, needing some = text? Brian From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of Henning Schulzrinne Sent: Monday, April 06, 2009 1:51 PM To: Saverio Mascolo Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion = control and reliability I will note that TFRC was designed for long-lived streams (e.g., media streams), which probably differs a bit from our typical application in P2PSIP, where somewhat random pairs of nodes exchange data objects of a = few dozen to a few hundred packets. For example, establishing a "fair" rate = is not trivial under those conditions, and has high error margins. Henning On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote: hi lars, On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert = wrote: Hi, =A0=20 I'd strongly urge you to use TFRC rather than rolling your own scheme. = Don't underestimate the validation effort that is required to ensure that a congestion control scheme is safe to deploy. This has all been done for TFRC, and it must be done for any new scheme. Lars is anyone=A0 aware of applications using TFRC? s=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From sa2086@columbia.edu Mon Apr 6 11:01:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FB728C133 for ; Mon, 6 Apr 2009 11:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP7D3JXl7kY3 for ; Mon, 6 Apr 2009 11:01:46 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 7419D3A6C52 for ; Mon, 6 Apr 2009 11:01:46 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n36I2ifJ007261; Mon, 6 Apr 2009 14:02:44 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n36I2ifh010583; Mon, 6 Apr 2009 14:02:44 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n36I2hiK010580; Mon, 6 Apr 2009 14:02:44 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Mon, 6 Apr 2009 14:02:43 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> <044b01c9b6ba$28dc0550$7a940ff0$@net> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1254324197-1239040499=:8032" Content-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 18:01:47 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1254324197-1239040499=:8032 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: TFRC is a congestion control protocol. What is intended is a reliable congestion control protocol over UDP, which does not exist as a specification. Reliability cannot merely be sprinkled on top of TFRC or any congestion control protocol. -s On Mon, 6 Apr 2009, Bruce Lowekamp wrote: > Yes, that's a valid option. Probably the right one at this point. In > fact, the solution space as I last sent it out looks like: > > - stop and wait > - simplified AIMD > - TFRC > - (TCP over UDP might go here if a draft existed) > - TCP > > The argument has mostly been about the simplified AIMD. I kind of > hate to lose it, but you're right, it will be a lot less controversial > if we do. Actually, TFRC is a pretty flexible protocol itself, so we > can probably just do something a bit more within that framework if we > want to have options. > > stop and wait was always intended as maybe a development-type > protocol, not a real deployable protocol (although it would work OK in > a small office environment) > > Bruce > > > On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen wrote: >> Is "use TCP when it works, and TRFC when it doesn't" an answer? >> Arguments like "it's too complex" don't work for me when we're talking >> transport protocols that have to do congestion control, etc.  Congestion >> control is complex. >> >> Brian >> >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >> Lars Eggert >> Sent: Monday, April 06, 2009 5:20 AM >> To: Bruce Lowekamp >> Cc: Salman Abdul Baset; p2psip@ietf.org >> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control >> and reliability >> >> Hi, >> >> On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >>> We have the option of simpy saying "use TFRC."  That will be good >>> enough performance, and require relatively little specification since >>> TSV has already put a lot of work into it.  It's also a bit >>> complicated.  A lot more complicated than is really needed for most >>> p2psip implementations/deployments. >>> >>> So the motivation of the other options was to provide simpler options >>> that are going to provide enough performance for many/most >>> deployments. >> >> I'd strongly urge you to use TFRC rather than rolling your own scheme. >> Don't underestimate the validation effort that is required to ensure that a >> congestion control scheme is safe to deploy. This has all been done for >> TFRC, and it must be done for any new scheme. >> >> Lars >> >> > > ---559023410-1254324197-1239040499=:8032-- From hgs@cs.columbia.edu Mon Apr 6 13:59:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24273A6885 for ; Mon, 6 Apr 2009 13:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 JGuhFmxHjuog for ; Mon, 6 Apr 2009 13:59:38 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id E0C483A6AAA for ; Mon, 6 Apr 2009 13:59:37 -0700 (PDT) Received: from [10.77.11.91] (vpn-128-59-248-45.vpn.columbia.edu [128.59.248.45]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n36L0XhA004104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2009 17:00:34 -0400 (EDT) Message-Id: <6BBE17F8-549C-486F-A99E-9EE05B6D56BF@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <04dd01c9b6e0$aeb33740$0c19a5c0$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 17:00:25 -0400 References: <26E4EFC2-A724-46A3-9906-C04D9F6D9127@softarmor.com> <49D3DA20.70602@telecomitalia.it> <04dd01c9b6e0$aeb33740$0c19a5c0$@net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 20:59:44 -0000 It's not fatal, but it will essentially mean that TFRC will stay at the initial (RFC 3390) rate for almost all transfers. The problem is that TFRC is based on estimating loss rates, based on 8 loss intervals. If you have a loss rate of 1%, this translates, very roughly, into 800 packets or roughly 800 kB, before you can reliably estimate a better (higher) rate. Lower rates will kick in sooner, since you'll get the loss intervals more quickly. I have to admit I'm confused as to why TFRC is seen as attractive for this application. The main benefit, smoothing rates, is of no importance for this application, and TFRC is significantly more complicated than the TCP mechanism. RFC 5348 (TFRC) only specifies a mechanism, so we still would have to engineer a new transport protocol, including reliability and the bits necessary to do round- trip time estimation (a necessary ingredient for TFRC as well as more classical TCP). Thus, saying "just use TFRC" doesn't avoid the "design transport" issue - it just provides guidance on the congestion control algorithm, and probably is not even the right answer for our application. Henning On Apr 6, 2009, at 1:54 PM, Brian Rosen wrote: > Is that a fatal flaw, or merely an expression of concern, needing > some text? > > Brian > > > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of > Henning Schulzrinne > Sent: Monday, April 06, 2009 1:51 PM > To: Saverio Mascolo > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Solution space for fragmentation, congestion > control > and reliability > > I will note that TFRC was designed for long-lived streams (e.g., media > streams), which probably differs a bit from our typical application in > P2PSIP, where somewhat random pairs of nodes exchange data objects > of a few > dozen to a few hundred packets. For example, establishing a "fair" > rate is > not trivial under those conditions, and has high error margins. > > Henning > > On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote: > > > hi lars, > On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert > wrote: > Hi, > > > > I'd strongly urge you to use TFRC rather than rolling your own > scheme. Don't > underestimate the validation effort that is required to ensure that a > congestion control scheme is safe to deploy. This has all been done > for > TFRC, and it must be done for any new scheme. > > Lars > > is anyone aware of applications using TFRC? > > s > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > > From bbl@lowekamp.net Mon Apr 6 19:45:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5552F3A687E for ; Mon, 6 Apr 2009 19:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 V2bq1M4LBNRW for ; Mon, 6 Apr 2009 19:44:58 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 991453A68A0 for ; Mon, 6 Apr 2009 19:44:57 -0700 (PDT) Received: by bwz17 with SMTP id 17so2117776bwz.37 for ; Mon, 06 Apr 2009 19:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.74 with SMTP id e10mr4059721fap.35.1239072362868; Mon, 06 Apr 2009 19:46:02 -0700 (PDT) In-Reply-To: References: <49D3DA20.70602@telecomitalia.it> <044b01c9b6ba$28dc0550$7a940ff0$@net> Date: Mon, 6 Apr 2009 22:46:02 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 02:45:03 -0000 Fortunately, reliability is not important for the overlay link protocol. It's a link layer. Bruce On Mon, Apr 6, 2009 at 2:02 PM, Salman Abdul Baset wr= ote: > > TFRC is a congestion control protocol. What is intended is a reliable > congestion control protocol over UDP, which does not exist as a > specification. Reliability cannot merely be sprinkled on top of TFRC or a= ny > congestion control protocol. > > -s > > On Mon, 6 Apr 2009, Bruce Lowekamp wrote: > >> Yes, that's a valid option. =C2=A0Probably the right one at this point. = =C2=A0In >> fact, the solution space as I last sent it out looks like: >> >> - stop and wait >> - simplified AIMD >> - TFRC >> - (TCP over UDP might go here if a draft existed) >> - TCP >> >> The argument has mostly been about the simplified AIMD. =C2=A0I kind of >> hate to lose it, but you're right, it will be a lot less controversial >> if we do. =C2=A0Actually, TFRC is a pretty flexible protocol itself, so = we >> can probably just do something a bit more within that framework if we >> want to have options. >> >> stop and wait was always intended as maybe a development-type >> protocol, not a real deployable protocol (although it would work OK in >> a small office environment) >> >> Bruce >> >> >> On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen wrote: >>> >>> Is "use TCP when it works, and TRFC when it doesn't" an answer? >>> Arguments like "it's too complex" don't work for me when we're talking >>> transport protocols that have to do congestion control, etc. =C2=A0Cong= estion >>> control is complex. >>> >>> Brian >>> >>> -----Original Message----- >>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behal= f >>> Of >>> Lars Eggert >>> Sent: Monday, April 06, 2009 5:20 AM >>> To: Bruce Lowekamp >>> Cc: Salman Abdul Baset; p2psip@ietf.org >>> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion >>> control >>> and reliability >>> >>> Hi, >>> >>> On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >>>> >>>> We have the option of simpy saying "use TFRC." =C2=A0That will be good >>>> enough performance, and require relatively little specification since >>>> TSV has already put a lot of work into it. =C2=A0It's also a bit >>>> complicated. =C2=A0A lot more complicated than is really needed for mo= st >>>> p2psip implementations/deployments. >>>> >>>> So the motivation of the other options was to provide simpler options >>>> that are going to provide enough performance for many/most >>>> deployments. >>> >>> I'd strongly urge you to use TFRC rather than rolling your own scheme. >>> Don't underestimate the validation effort that is required to ensure th= at >>> a >>> congestion control scheme is safe to deploy. This has all been done for >>> TFRC, and it must be done for any new scheme. >>> >>> Lars >>> >>> >> > From bbl@lowekamp.net Mon Apr 6 20:13:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52933A6D51 for ; Mon, 6 Apr 2009 20:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Z1MTLBo3rlSz for ; Mon, 6 Apr 2009 20:13:40 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 81FDB3A6D4E for ; Mon, 6 Apr 2009 20:13:39 -0700 (PDT) Received: by fxm2 with SMTP id 2so2140567fxm.37 for ; Mon, 06 Apr 2009 20:14:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.145 with SMTP id c17mr4072786fas.16.1239074085123; Mon, 06 Apr 2009 20:14:45 -0700 (PDT) In-Reply-To: <6BBE17F8-549C-486F-A99E-9EE05B6D56BF@cs.columbia.edu> References: <49D3DA20.70602@telecomitalia.it> <04dd01c9b6e0$aeb33740$0c19a5c0$@net> <6BBE17F8-549C-486F-A99E-9EE05B6D56BF@cs.columbia.edu> Date: Mon, 6 Apr 2009 23:14:44 -0400 Message-ID: From: Bruce Lowekamp To: Henning Schulzrinne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 03:13:40 -0000 Henning is right in that TFRC is intended for streaming protocols. My understanding is that there has been some consensus at applying it to other protocols, but it is a bit of a stretch. I'm not sure I agree with Henning's analysis, though I haven't spent enough time with it to fully understand all the implications. Didn't 5348 address the issue with data-limited senders and bursty data? Here is literally what 5405 says: ------------ Applications that perform bulk transmission of data to a peer over UDP, i.e., applications that exchange more than a small number of UDP datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) [RFC5348], window-based, TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles. -------------- I'm a bit unclear what would be considered acceptable under the "window-based, TCP-like congestion control" part of that statement. I would think that AIMD window-based congestion control would be sufficient. Bruce On Mon, Apr 6, 2009 at 5:00 PM, Henning Schulzrinne w= rote: > It's not fatal, but it will essentially mean that TFRC will stay at the > initial (RFC 3390) rate for almost all transfers. The problem is that TFR= C > is based on estimating loss rates, based on 8 loss intervals. If you have= a > loss rate of 1%, this translates, very roughly, into 800 packets or rough= ly > 800 kB, before you can reliably estimate a better (higher) rate. Lower ra= tes > will kick in sooner, since you'll get the loss intervals more quickly. > > I have to admit I'm confused as to why TFRC is seen as attractive for thi= s > application. The main benefit, smoothing rates, is of no importance for t= his > application, and TFRC is significantly more complicated than the TCP > mechanism. RFC 5348 (TFRC) only specifies a mechanism, so we still would > have to engineer a new transport protocol, including reliability and the > bits necessary to do round-trip time estimation (a necessary ingredient f= or > TFRC as well as more classical TCP). > > Thus, saying "just use TFRC" doesn't avoid the "design transport" issue -= it > just provides guidance on the congestion control algorithm, and probably = is > not even the right answer for our application. > > Henning > > On Apr 6, 2009, at 1:54 PM, Brian Rosen wrote: > >> Is that a fatal flaw, or merely an expression of concern, needing some >> text? >> >> Brian >> >> >> >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf >> Of >> Henning Schulzrinne >> Sent: Monday, April 06, 2009 1:51 PM >> To: Saverio Mascolo >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion contr= ol >> and reliability >> >> I will note that TFRC was designed for long-lived streams (e.g., media >> streams), which probably differs a bit from our typical application in >> P2PSIP, where somewhat random pairs of nodes exchange data objects of a >> few >> dozen to a few hundred packets. For example, establishing a "fair" rate = is >> not trivial under those conditions, and has high error margins. >> >> Henning >> >> On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote: >> >> >> hi lars, >> On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert >> wrote: >> Hi, >> >> >> >> I'd strongly urge you to use TFRC rather than rolling your own scheme. >> Don't >> underestimate the validation effort that is required to ensure that a >> congestion control scheme is safe to deploy. This has all been done for >> TFRC, and it must be done for any new scheme. >> >> Lars >> >> is anyone =C2=A0aware of applications using TFRC? >> >> s >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From sa2086@columbia.edu Mon Apr 6 20:17:12 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049E03A6D51 for ; Mon, 6 Apr 2009 20:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHFcobj-JNp8 for ; Mon, 6 Apr 2009 20:17:04 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id CA6D428C14F for ; Mon, 6 Apr 2009 20:15:41 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n373Gj9s018829; Mon, 6 Apr 2009 23:16:45 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n373Gjed018558; Mon, 6 Apr 2009 23:16:45 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n373Giqh018555; Mon, 6 Apr 2009 23:16:44 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Mon, 6 Apr 2009 23:16:44 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <49D3DA20.70602@telecomitalia.it> <044b01c9b6ba$28dc0550$7a940ff0$@net> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1483920592-1239074204=:17362" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 03:17:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1483920592-1239074204=:17362 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Are you saying hop-by-hop reliability is not needed? A received message is useless unless all fragments are reliably received. If indeed hop-by-hop reliability is needed, then the link layer analogy is unfortunately not right. -s On Mon, 6 Apr 2009, Bruce Lowekamp wrote: > Fortunately, reliability is not important for the overlay link > protocol. It's a link layer. > > Bruce > > > On Mon, Apr 6, 2009 at 2:02 PM, Salman Abdul Baset wrote: >> >> TFRC is a congestion control protocol. What is intended is a reliable >> congestion control protocol over UDP, which does not exist as a >> specification. Reliability cannot merely be sprinkled on top of TFRC or any >> congestion control protocol. >> >> -s >> >> On Mon, 6 Apr 2009, Bruce Lowekamp wrote: >> >>> Yes, that's a valid option.  Probably the right one at this point.  In >>> fact, the solution space as I last sent it out looks like: >>> >>> - stop and wait >>> - simplified AIMD >>> - TFRC >>> - (TCP over UDP might go here if a draft existed) >>> - TCP >>> >>> The argument has mostly been about the simplified AIMD.  I kind of >>> hate to lose it, but you're right, it will be a lot less controversial >>> if we do.  Actually, TFRC is a pretty flexible protocol itself, so we >>> can probably just do something a bit more within that framework if we >>> want to have options. >>> >>> stop and wait was always intended as maybe a development-type >>> protocol, not a real deployable protocol (although it would work OK in >>> a small office environment) >>> >>> Bruce >>> >>> >>> On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen wrote: >>>> >>>> Is "use TCP when it works, and TRFC when it doesn't" an answer? >>>> Arguments like "it's too complex" don't work for me when we're talking >>>> transport protocols that have to do congestion control, etc.  Congestion >>>> control is complex. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf >>>> Of >>>> Lars Eggert >>>> Sent: Monday, April 06, 2009 5:20 AM >>>> To: Bruce Lowekamp >>>> Cc: Salman Abdul Baset; p2psip@ietf.org >>>> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion >>>> control >>>> and reliability >>>> >>>> Hi, >>>> >>>> On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >>>>> >>>>> We have the option of simpy saying "use TFRC."  That will be good >>>>> enough performance, and require relatively little specification since >>>>> TSV has already put a lot of work into it.  It's also a bit >>>>> complicated.  A lot more complicated than is really needed for most >>>>> p2psip implementations/deployments. >>>>> >>>>> So the motivation of the other options was to provide simpler options >>>>> that are going to provide enough performance for many/most >>>>> deployments. >>>> >>>> I'd strongly urge you to use TFRC rather than rolling your own scheme. >>>> Don't underestimate the validation effort that is required to ensure that >>>> a >>>> congestion control scheme is safe to deploy. This has all been done for >>>> TFRC, and it must be done for any new scheme. >>>> >>>> Lars >>>> >>>> >>> >> > > ---559023410-1483920592-1239074204=:17362-- From saverio.mascolo@gmail.com Tue Apr 7 05:02:42 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6780D3A6DC7 for ; Tue, 7 Apr 2009 05:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.104, 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 Jc6Jwy-huMFp for ; Tue, 7 Apr 2009 05:02:35 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 4A40B3A6DC3 for ; Tue, 7 Apr 2009 05:02:34 -0700 (PDT) Received: by bwz17 with SMTP id 17so2277095bwz.37 for ; Tue, 07 Apr 2009 05:03:40 -0700 (PDT) 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 :from:date:message-id:subject:to:cc:content-type; bh=LrKkLmTbM93SS0IxpOg66M8OZx9xu6meQhKDVBcg3CE=; b=iLLHQFA3MhTK06338/xae/b7PV7AurX8Qk1BlcVVG8l8XT00RkaPjE+NXSIfYxKHI0 02Lx6h0YbJrEyIU38mHRcr+WnQByfHtrUBr2XFMQeahVvfcJ7JSBWH8RfVSrZuKsks3p yzHwgNsljiuNhwckNwrZSRNAU1Dz6Xv5trPdM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=m2l2xhK7hAxVcIU1yUNypivOg/Yopy5wGMHb75XATFKZqjlhfzc6Nd4Gni/IItkWeH qFLeJBwe1WL03GYHybswBW5TDkmDdgJR4kvWBEnShUOKca1gyfoX5yFSv0IwbNGtDeUp az0qorY2jpvO/aX5amjDla5VM3nS7ZHpO9VI8= MIME-Version: 1.0 Received: by 10.223.117.1 with SMTP id o1mr37125faq.53.1239105819878; Tue, 07 Apr 2009 05:03:39 -0700 (PDT) In-Reply-To: References: <04dd01c9b6e0$aeb33740$0c19a5c0$@net> <6BBE17F8-549C-486F-A99E-9EE05B6D56BF@cs.columbia.edu> From: Saverio Mascolo Date: Tue, 7 Apr 2009 14:03:24 +0200 Message-ID: To: Bruce Lowekamp Content-Type: multipart/alternative; boundary=001636c5b6803ba5600466f5ce4b Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:02:42 -0000 --001636c5b6803ba5600466f5ce4b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi bruce, On Tue, Apr 7, 2009 at 5:14 AM, Bruce Lowekamp wrote: > Henning is right in that TFRC is intended for streaming protocols. why tcp is not good for streaming? youtube i using TCP. do you mean tfrc for real-time? saverio > My > understanding is that there has been some consensus at applying it to > other protocols, but it is a bit of a stretch. I'm not sure I agree > with Henning's analysis, though I haven't spent enough time with it to > fully understand all the implications. Didn't 5348 address the issue > with data-limited senders and bursty data? > > Here is literally what 5405 says: > > ------------ > Applications that perform bulk transmission of data to a peer over > UDP, i.e., applications that exchange more than a small number of UDP > datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) > [RFC5348], window-based, TCP-like congestion control, or otherwise > ensure that the application complies with the congestion control > principles. > -------------- > > I'm a bit unclear what would be considered acceptable under the > "window-based, TCP-like congestion control" part of that statement. I > would think that AIMD window-based congestion control would be > sufficient. > > Bruce > > > On Mon, Apr 6, 2009 at 5:00 PM, Henning Schulzrinne > wrote: > > It's not fatal, but it will essentially mean that TFRC will stay at the > > initial (RFC 3390) rate for almost all transfers. The problem is that > TFRC > > is based on estimating loss rates, based on 8 loss intervals. If you have > a > > loss rate of 1%, this translates, very roughly, into 800 packets or > roughly > > 800 kB, before you can reliably estimate a better (higher) rate. Lower > rates > > will kick in sooner, since you'll get the loss intervals more quickly. > > > > I have to admit I'm confused as to why TFRC is seen as attractive for > this > > application. The main benefit, smoothing rates, is of no importance for > this > > application, and TFRC is significantly more complicated than the TCP > > mechanism. RFC 5348 (TFRC) only specifies a mechanism, so we still would > > have to engineer a new transport protocol, including reliability and the > > bits necessary to do round-trip time estimation (a necessary ingredient > for > > TFRC as well as more classical TCP). > > > > Thus, saying "just use TFRC" doesn't avoid the "design transport" issue - > it > > just provides guidance on the congestion control algorithm, and probably > is > > not even the right answer for our application. > > > > Henning > > > > On Apr 6, 2009, at 1:54 PM, Brian Rosen wrote: > > > >> Is that a fatal flaw, or merely an expression of concern, needing some > >> text? > >> > >> Brian > >> > >> > >> > >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf > >> Of > >> Henning Schulzrinne > >> Sent: Monday, April 06, 2009 1:51 PM > >> To: Saverio Mascolo > >> Cc: p2psip@ietf.org > >> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion > control > >> and reliability > >> > >> I will note that TFRC was designed for long-lived streams (e.g., media > >> streams), which probably differs a bit from our typical application in > >> P2PSIP, where somewhat random pairs of nodes exchange data objects of a > >> few > >> dozen to a few hundred packets. For example, establishing a "fair" rate > is > >> not trivial under those conditions, and has high error margins. > >> > >> Henning > >> > >> On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote: > >> > >> > >> hi lars, > >> On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert > >> wrote: > >> Hi, > >> > >> > >> > >> I'd strongly urge you to use TFRC rather than rolling your own scheme. > >> Don't > >> underestimate the validation effort that is required to ensure that a > >> congestion control scheme is safe to deploy. This has all been done for > >> TFRC, and it must be done for any new scheme. > >> > >> Lars > >> > >> is anyone aware of applications using TFRC? > >> > >> s > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > >> > >> > >> > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --001636c5b6803ba5600466f5ce4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi bruce,


On Tue, Apr 7, 2009 at 5:14= AM, Bruce Lowekamp <bbl@lowekamp.net> wrote:
Henning is right in that TFRC is intended for streaming protocols.

why tcp is not good for streaming?=A0 youtube i using TCP.
do you mean tfrc for real-time?

saverio


=A0
=A0My
understanding is that there has been some consensus at applying it to
other protocols, but it is a bit of a stretch. =A0I'm not sure I agree<= br> with Henning's analysis, though I haven't spent enough time with it= to
fully understand all the implications. =A0Didn't 5348 address the issue=
with data-limited senders and bursty data?

Here is literally what 5405 says:

------------
=A0 Applications that perform bulk transmission of data to a peer over
=A0 UDP, i.e., applications that exchange more than a small number of UDP<= br> =A0 datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) =A0 [RFC5348], window-based, TCP-like congestion control, or otherwise
=A0 ensure that the application complies with the congestion control
=A0 principles.
--------------

I'm a bit unclear what would be considered acceptable under the
"window-based, TCP-like congestion control" part of that statemen= t. =A0I
would think that AIMD window-based congestion control would be
sufficient.

Bruce


On Mon, Apr 6, 2009 at 5:00 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
> It's not fatal, but it will essentially mean that TFRC will stay a= t the
> initial (RFC 3390) rate for almost all transfers. The problem is that = TFRC
> is based on estimating loss rates, based on 8 loss intervals. If you h= ave a
> loss rate of 1%, this translates, very roughly, into 800 packets or ro= ughly
> 800 kB, before you can reliably estimate a better (higher) rate. Lower= rates
> will kick in sooner, since you'll get the loss intervals more quic= kly.
>
> I have to admit I'm confused as to why TFRC is seen as attractive = for this
> application. The main benefit, smoothing rates, is of no importance fo= r this
> application, and TFRC is significantly more complicated than the TCP > mechanism. RFC 5348 (TFRC) only specifies a mechanism, so we still wou= ld
> have to engineer a new transport protocol, including reliability and t= he
> bits necessary to do round-trip time estimation (a necessary ingredien= t for
> TFRC as well as more classical TCP).
>
> Thus, saying "just use TFRC" doesn't avoid the "des= ign transport" issue - it
> just provides guidance on the congestion control algorithm, and probab= ly is
> not even the right answer for our application.
>
> Henning
>
> On Apr 6, 2009, at 1:54 PM, Brian Rosen wrote:
>
>> Is that a fatal flaw, or merely an expression of concern, needing = some
>> text?
>>
>> Brian
>>
>>
>>
>> From: p2psip-bounces@ie= tf.org [mailto:p2psip-bounce= s@ietf.org] On Behalf
>> Of
>> Henning Schulzrinne
>> Sent: Monday, April 06, 2009 1:51 PM
>> To: Saverio Mascolo
>> Cc: p2psip@ietf.org
>> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion= control
>> and reliability
>>
>> I will note that TFRC was designed for long-lived streams (e.g., m= edia
>> streams), which probably differs a bit from our typical applicatio= n in
>> P2PSIP, where somewhat random pairs of nodes exchange data objects= of a
>> few
>> dozen to a few hundred packets. For example, establishing a "= fair" rate is
>> not trivial under those conditions, and has high error margins. >>
>> Henning
>>
>> On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote:
>>
>>
>> hi lars,
>> On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert <lars.eggert@nokia.com>
>> wrote:
>> Hi,
>>
>>
>>
>> I'd strongly urge you to use TFRC rather than rolling your own= scheme.
>> Don't
>> underestimate the validation effort that is required to ensure tha= t a
>> congestion control scheme is safe to deploy. This has all been don= e for
>> TFRC, and it must be done for any new scheme.
>>
>> Lars
>>
>> is anyone =A0aware of applications using TFRC?
>>
>> s
>>
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2psip
>>
>>
>>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip

=A0
--001636c5b6803ba5600466f5ce4b-- From hgs@cs.columbia.edu Tue Apr 7 06:59:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6AC28C179 for ; Tue, 7 Apr 2009 06:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvUBL0aAaPsp for ; Tue, 7 Apr 2009 06:59:46 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 4DA5D28C176 for ; Tue, 7 Apr 2009 06:59:46 -0700 (PDT) Received: from [10.77.11.253] (72-255-58-163.client.stsn.net [72.255.58.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n37E0dqj025726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Apr 2009 10:00:47 -0400 (EDT) Message-Id: <334346AA-A3E9-4CC1-8BFD-499B4F7A44FB@cs.columbia.edu> From: Henning Schulzrinne To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 10:00:31 -0400 References: <49D3DA20.70602@telecomitalia.it> <04dd01c9b6e0$aeb33740$0c19a5c0$@net> <6BBE17F8-549C-486F-A99E-9EE05B6D56BF@cs.columbia.edu> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:59:47 -0000 "TCP-like" is presumably something like the Reno, Tahoe, Vegas or similar variations of AIMD implemented by TCP. I don't think you advocated this, but implementing both TFRC and AIMD (running at the same time, not alternatives as in DCCP) seems difficult and far more complicated. The issue of data-limited senders has nothing to do with the start-up issue I mentioned in my message. The inherent problem of TFRC is that it relies on estimating a loss rate, and this, by its very nature, takes a while unless loss are very high (which you obviously don't want). This isn't a problem in steady state for long-lived flows, such as a video stream, but P2PSIP does not match this model. I agree that an AIMD mechanism (of which TCP is an instance) is probably the better choice for this application. TFRC is neither simpler nor "better" than AIMD, it just fits the unreliable transport model better (again, which is not what we need here). After all, TFRC is attempting to model AIMD behavior. However, using AIMD means implementing the same thing as "TCP over UDP", with maybe the header bits re-arranged, as AIMD needs much of the TCP header information, for example. This also has nothing to do with whether TCP can be used for real-time data, which is probably a topic of interest to working groups other than P2PSIP. Salman and I, with others, have a paper on this topic in SIGMETRICS, if you happen to care about this topic. Henning On Apr 6, 2009, at 11:14 PM, Bruce Lowekamp wrote: > Henning is right in that TFRC is intended for streaming protocols. My > understanding is that there has been some consensus at applying it to > other protocols, but it is a bit of a stretch. I'm not sure I agree > with Henning's analysis, though I haven't spent enough time with it to > fully understand all the implications. Didn't 5348 address the issue > with data-limited senders and bursty data? > > Here is literally what 5405 says: > > ------------ > Applications that perform bulk transmission of data to a peer over > UDP, i.e., applications that exchange more than a small number of > UDP > datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) > [RFC5348], window-based, TCP-like congestion control, or otherwise > ensure that the application complies with the congestion control > principles. > -------------- > > I'm a bit unclear what would be considered acceptable under the > "window-based, TCP-like congestion control" part of that statement. I > would think that AIMD window-based congestion control would be > sufficient. > > Bruce > > > On Mon, Apr 6, 2009 at 5:00 PM, Henning Schulzrinne > wrote: >> It's not fatal, but it will essentially mean that TFRC will stay at >> the >> initial (RFC 3390) rate for almost all transfers. The problem is >> that TFRC >> is based on estimating loss rates, based on 8 loss intervals. If >> you have a >> loss rate of 1%, this translates, very roughly, into 800 packets or >> roughly >> 800 kB, before you can reliably estimate a better (higher) rate. >> Lower rates >> will kick in sooner, since you'll get the loss intervals more >> quickly. >> >> I have to admit I'm confused as to why TFRC is seen as attractive >> for this >> application. The main benefit, smoothing rates, is of no importance >> for this >> application, and TFRC is significantly more complicated than the TCP >> mechanism. RFC 5348 (TFRC) only specifies a mechanism, so we still >> would >> have to engineer a new transport protocol, including reliability >> and the >> bits necessary to do round-trip time estimation (a necessary >> ingredient for >> TFRC as well as more classical TCP). >> >> Thus, saying "just use TFRC" doesn't avoid the "design transport" >> issue - it >> just provides guidance on the congestion control algorithm, and >> probably is >> not even the right answer for our application. >> >> Henning >> >> On Apr 6, 2009, at 1:54 PM, Brian Rosen wrote: >> >>> Is that a fatal flaw, or merely an expression of concern, needing >>> some >>> text? >>> >>> Brian >>> >>> >>> >>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>> Behalf >>> Of >>> Henning Schulzrinne >>> Sent: Monday, April 06, 2009 1:51 PM >>> To: Saverio Mascolo >>> Cc: p2psip@ietf.org >>> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion >>> control >>> and reliability >>> >>> I will note that TFRC was designed for long-lived streams (e.g., >>> media >>> streams), which probably differs a bit from our typical >>> application in >>> P2PSIP, where somewhat random pairs of nodes exchange data objects >>> of a >>> few >>> dozen to a few hundred packets. For example, establishing a "fair" >>> rate is >>> not trivial under those conditions, and has high error margins. >>> >>> Henning >>> >>> On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote: >>> >>> >>> hi lars, >>> On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert >>> wrote: >>> Hi, >>> >>> >>> >>> I'd strongly urge you to use TFRC rather than rolling your own >>> scheme. >>> Don't >>> underestimate the validation effort that is required to ensure >>> that a >>> congestion control scheme is safe to deploy. This has all been >>> done for >>> TFRC, and it must be done for any new scheme. >>> >>> Lars >>> >>> is anyone aware of applications using TFRC? >>> >>> s >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> >>> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > From bbl@lowekamp.net Tue Apr 7 19:08:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E0028C0D9 for ; Tue, 7 Apr 2009 19:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 0rshXUNWi71j for ; Tue, 7 Apr 2009 19:08:01 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id E16D13A6E35 for ; Tue, 7 Apr 2009 19:08:00 -0700 (PDT) Received: by bwz17 with SMTP id 17so2561815bwz.37 for ; Tue, 07 Apr 2009 19:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.68 with SMTP id z4mr276117fap.72.1239156546538; Tue, 07 Apr 2009 19:09:06 -0700 (PDT) In-Reply-To: References: <044b01c9b6ba$28dc0550$7a940ff0$@net> Date: Tue, 7 Apr 2009 22:09:06 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 02:08:02 -0000 I think that if messages are typically only a few (<=3D 3) fragments, we can safely ignore this issue. If the loss rate is high enough that it matters, the network will collapse anyway. Also remember that what happens is there's a retransmission of all of the fragments, which might waste some traffic, but the receiver can still have the other fragments waiting, so they're not completely useless. OTOH, if messages are going to typically be even larger (or need to deal with higher loss rates), I would favor fixing the problem end-to-end, not through hop-by-hop reliability. I hesitated adding the minimal semi-reliability to the proposal I wrote up. It's just a lot of complexity and latency added for something that I'm not sure is a good addition to the overall stability of the network. It's important to be willing to drop traffic mid-network. That's the only way the network can shed load. The senders will back off. (Currently they back off in a per-transaction question. It's an interesting question whether they should do more.) Bruce On Mon, Apr 6, 2009 at 11:16 PM, Salman Abdul Baset wrote: > Are you saying hop-by-hop reliability is not needed? A received message i= s > useless unless all fragments are reliably received. > > If indeed hop-by-hop reliability is needed, then the link layer analogy i= s > unfortunately not right. > > -s > > On Mon, 6 Apr 2009, Bruce Lowekamp wrote: > >> Fortunately, reliability is not important for the overlay link >> protocol. =C2=A0It's a link layer. >> >> Bruce >> >> >> On Mon, Apr 6, 2009 at 2:02 PM, Salman Abdul Baset >> wrote: >>> >>> TFRC is a congestion control protocol. What is intended is a reliable >>> congestion control protocol over UDP, which does not exist as a >>> specification. Reliability cannot merely be sprinkled on top of TFRC or >>> any >>> congestion control protocol. >>> >>> -s >>> >>> On Mon, 6 Apr 2009, Bruce Lowekamp wrote: >>> >>>> Yes, that's a valid option. =C2=A0Probably the right one at this point= . =C2=A0In >>>> fact, the solution space as I last sent it out looks like: >>>> >>>> - stop and wait >>>> - simplified AIMD >>>> - TFRC >>>> - (TCP over UDP might go here if a draft existed) >>>> - TCP >>>> >>>> The argument has mostly been about the simplified AIMD. =C2=A0I kind o= f >>>> hate to lose it, but you're right, it will be a lot less controversial >>>> if we do. =C2=A0Actually, TFRC is a pretty flexible protocol itself, s= o we >>>> can probably just do something a bit more within that framework if we >>>> want to have options. >>>> >>>> stop and wait was always intended as maybe a development-type >>>> protocol, not a real deployable protocol (although it would work OK in >>>> a small office environment) >>>> >>>> Bruce >>>> >>>> >>>> On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen wrote: >>>>> >>>>> Is "use TCP when it works, and TRFC when it doesn't" an answer? >>>>> Arguments like "it's too complex" don't work for me when we're talkin= g >>>>> transport protocols that have to do congestion control, etc. >>>>> =C2=A0Congestion >>>>> control is complex. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>>> Behalf >>>>> Of >>>>> Lars Eggert >>>>> Sent: Monday, April 06, 2009 5:20 AM >>>>> To: Bruce Lowekamp >>>>> Cc: Salman Abdul Baset; p2psip@ietf.org >>>>> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion >>>>> control >>>>> and reliability >>>>> >>>>> Hi, >>>>> >>>>> On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >>>>>> >>>>>> We have the option of simpy saying "use TFRC." =C2=A0That will be go= od >>>>>> enough performance, and require relatively little specification sinc= e >>>>>> TSV has already put a lot of work into it. =C2=A0It's also a bit >>>>>> complicated. =C2=A0A lot more complicated than is really needed for = most >>>>>> p2psip implementations/deployments. >>>>>> >>>>>> So the motivation of the other options was to provide simpler option= s >>>>>> that are going to provide enough performance for many/most >>>>>> deployments. >>>>> >>>>> I'd strongly urge you to use TFRC rather than rolling your own scheme= . >>>>> Don't underestimate the validation effort that is required to ensure >>>>> that >>>>> a >>>>> congestion control scheme is safe to deploy. This has all been done f= or >>>>> TFRC, and it must be done for any new scheme. >>>>> >>>>> Lars >>>>> >>>>> >>>> >>> >> > From hgs@cs.columbia.edu Tue Apr 7 19:53:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1CC3A6829 for ; Tue, 7 Apr 2009 19:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.787 X-Spam-Level: X-Spam-Status: No, score=-4.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] 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 TuJK9whiWbS4 for ; Tue, 7 Apr 2009 19:53:08 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id B1B653A69F0 for ; Tue, 7 Apr 2009 19:53:08 -0700 (PDT) Received: from Upstairs.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n382sDbO001201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Apr 2009 22:54:13 -0400 (EDT) Message-Id: <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> From: Henning Schulzrinne To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 22:54:12 -0400 References: <044b01c9b6ba$28dc0550$7a940ff0$@net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 02:53:10 -0000 The problem is that this will collapse (say) 10 times sooner than in a non-P2P network (assuming 10 hops). Plus, getting the round-trip time estimation right is going to be that much harder the more hops there are, leading to spurious retransmission. After all, each hop is likely, on average, to transit a fair chunk of the Internet if the P2P network is global. With hop-by- hop RTT estimation, you at least have a chance to re-use the same set of "links" reasonably frequently, e.g., to finger table neighbors, so that RTT estimates are at least plausible. Each end-to-end path will be one-off, so that the RTT can only be worst-case, and that has to be significantly larger than the initial TCP estimate, given that you're traversing good spans of the Internet several (but unknown number of) times. Betting that all messages are small seems like a dangerous gamble. We lost that one before. (Not just SIP - who would have thought that DNS messages could become fairly substantial?) Dropping messages mid-stream is a great way to design a protocol that doesn't meet the reliability requirements that "competition" with client-server mechanisms requires, and makes diagnosis really hard, as you could have failures that depend on who is asking the question, and other random behavior (e.g., which replica is being asked for). P2P systems are hard enough to debug without adding more obscure failure modes. My opinion is to either to do it right or not to do it at all. Trying to cut corners now, to show how "simple" designing transport is, will just lead to regret later. We've been there, and some of us don't care to re-visit that place. In general, we're in great danger of designing a protocol that is far more complicated than needed for the simple URL-to-IP address mapping (you don't need "kinds" and customizable policies for that...), yet insufficient to handle anything more demanding. Henning On Apr 7, 2009, at 10:09 PM, Bruce Lowekamp wrote: > I think that if messages are typically only a few (<= 3) fragments, we > can safely ignore this issue. If the loss rate is high enough that it > matters, the network will collapse anyway. Also remember that what > happens is there's a retransmission of all of the fragments, which > might waste some traffic, but the receiver can still have the other > fragments waiting, so they're not completely useless. > > OTOH, if messages are going to typically be even larger (or need to > deal with higher loss rates), I would favor fixing the problem > end-to-end, not through hop-by-hop reliability. I hesitated adding > the minimal semi-reliability to the proposal I wrote up. It's just a > lot of complexity and latency added for something that I'm not sure is > a good addition to the overall stability of the network. > > It's important to be willing to drop traffic mid-network. That's the > only way the network can shed load. The senders will back off. > (Currently they back off in a per-transaction question. It's an > interesting question whether they should do more.) > > Bruce > > > On Mon, Apr 6, 2009 at 11:16 PM, Salman Abdul Baset > wrote: >> Are you saying hop-by-hop reliability is not needed? A received >> message is >> useless unless all fragments are reliably received. >> >> If indeed hop-by-hop reliability is needed, then the link layer >> analogy is >> unfortunately not right. >> >> -s >> >> On Mon, 6 Apr 2009, Bruce Lowekamp wrote: >> >>> Fortunately, reliability is not important for the overlay link >>> protocol. It's a link layer. >>> >>> Bruce >>> >>> >>> On Mon, Apr 6, 2009 at 2:02 PM, Salman Abdul Baset >> > >>> wrote: >>>> >>>> TFRC is a congestion control protocol. What is intended is a >>>> reliable >>>> congestion control protocol over UDP, which does not exist as a >>>> specification. Reliability cannot merely be sprinkled on top of >>>> TFRC or >>>> any >>>> congestion control protocol. >>>> >>>> -s >>>> >>>> On Mon, 6 Apr 2009, Bruce Lowekamp wrote: >>>> >>>>> Yes, that's a valid option. Probably the right one at this >>>>> point. In >>>>> fact, the solution space as I last sent it out looks like: >>>>> >>>>> - stop and wait >>>>> - simplified AIMD >>>>> - TFRC >>>>> - (TCP over UDP might go here if a draft existed) >>>>> - TCP >>>>> >>>>> The argument has mostly been about the simplified AIMD. I kind of >>>>> hate to lose it, but you're right, it will be a lot less >>>>> controversial >>>>> if we do. Actually, TFRC is a pretty flexible protocol itself, >>>>> so we >>>>> can probably just do something a bit more within that framework >>>>> if we >>>>> want to have options. >>>>> >>>>> stop and wait was always intended as maybe a development-type >>>>> protocol, not a real deployable protocol (although it would work >>>>> OK in >>>>> a small office environment) >>>>> >>>>> Bruce >>>>> >>>>> >>>>> On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen >>>>> wrote: >>>>>> >>>>>> Is "use TCP when it works, and TRFC when it doesn't" an answer? >>>>>> Arguments like "it's too complex" don't work for me when we're >>>>>> talking >>>>>> transport protocols that have to do congestion control, etc. >>>>>> Congestion >>>>>> control is complex. >>>>>> >>>>>> Brian >>>>>> >>>>>> -----Original Message----- >>>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>>>> Behalf >>>>>> Of >>>>>> Lars Eggert >>>>>> Sent: Monday, April 06, 2009 5:20 AM >>>>>> To: Bruce Lowekamp >>>>>> Cc: Salman Abdul Baset; p2psip@ietf.org >>>>>> Subject: Re: [P2PSIP] Solution space for fragmentation, >>>>>> congestion >>>>>> control >>>>>> and reliability >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >>>>>>> >>>>>>> We have the option of simpy saying "use TFRC." That will be >>>>>>> good >>>>>>> enough performance, and require relatively little >>>>>>> specification since >>>>>>> TSV has already put a lot of work into it. It's also a bit >>>>>>> complicated. A lot more complicated than is really needed for >>>>>>> most >>>>>>> p2psip implementations/deployments. >>>>>>> >>>>>>> So the motivation of the other options was to provide simpler >>>>>>> options >>>>>>> that are going to provide enough performance for many/most >>>>>>> deployments. >>>>>> >>>>>> I'd strongly urge you to use TFRC rather than rolling your own >>>>>> scheme. >>>>>> Don't underestimate the validation effort that is required to >>>>>> ensure >>>>>> that >>>>>> a >>>>>> congestion control scheme is safe to deploy. This has all been >>>>>> done for >>>>>> TFRC, and it must be done for any new scheme. >>>>>> >>>>>> Lars >>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Wed Apr 8 03:20:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9D53A6E5D for ; Wed, 8 Apr 2009 03:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SPEC_REPLICA_OBFU=1.812] 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 gPfdludOGKAL for ; Wed, 8 Apr 2009 03:20:32 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 68BF63A689D for ; Wed, 8 Apr 2009 03:20:31 -0700 (PDT) Received: by bwz17 with SMTP id 17so48469bwz.37 for ; Wed, 08 Apr 2009 03:21:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.107.199 with SMTP id c7mr372879fap.31.1239186097089; Wed, 08 Apr 2009 03:21:37 -0700 (PDT) In-Reply-To: <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> References: <044b01c9b6ba$28dc0550$7a940ff0$@net> <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> Date: Wed, 8 Apr 2009 06:21:37 -0400 Message-ID: From: Bruce Lowekamp To: Henning Schulzrinne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 10:20:33 -0000 One of the (if not THE) fundamental decisions that makes the Internet work is that reliability is end-to-end, not hop-by-hop. Hops are allowed to drop traffic due to congestion, and that is taken as implicit feedback that there is congestion in the network. The proposal I sent out drops traffic in two places. First, each peer maintains a limited queue for fragments and drops excess fragments (the literal analog of drops due to congestion in routers). Second, the overlay link protocol is only semi-reliable (which I debated having at all), with the assumption that on the Internet, loss is due to congestion. So we have two congestion signals to the peer, queue length and link protocol drops. Congestion needs to cause load shedding in a network (overlay or not) or else it will collapse. Arguing that we should do extra work for hop-by-hop reliability makes no sense to me. Bruce On Tue, Apr 7, 2009 at 10:54 PM, Henning Schulzrinne wrote: > The problem is that this will collapse (say) 10 times sooner than in a > non-P2P network (assuming 10 hops). > > Plus, getting the round-trip time estimation right is going to be that mu= ch > harder the more hops there are, leading to spurious retransmission. After > all, each hop is likely, on average, to transit a fair chunk of the Inter= net > if the P2P network is global. With hop-by-hop RTT estimation, you at leas= t > have a chance to re-use the same set of "links" reasonably frequently, e.= g., > to finger table neighbors, so that RTT estimates are at least plausible. > Each end-to-end path will be one-off, so that the RTT can only be > worst-case, and that has to be significantly larger than the initial TCP > estimate, given that you're traversing good spans of the Internet several > (but unknown number of) times. > > Betting that all messages are small seems like a dangerous gamble. =C2=A0= We lost > that one before. (Not just SIP - who would have thought that DNS messages > could become fairly substantial?) > > Dropping messages mid-stream is a great way to design a protocol that > doesn't meet the reliability requirements that "competition" with > client-server mechanisms requires, and makes diagnosis really hard, as yo= u > could have failures that depend on who is asking the question, and other > random behavior (e.g., which replica is being asked for). P2P systems are > hard enough to debug without adding more obscure failure modes. > > My opinion is to either to do it right or not to do it at all. Trying to = cut > corners now, to show how "simple" designing transport is, will just lead = to > regret later. We've been there, and some of us don't care to re-visit tha= t > place. > > In general, we're in great danger of designing a protocol that is far mor= e > complicated than needed for the simple URL-to-IP address mapping (you don= 't > need "kinds" and customizable policies for that...), yet insufficient to > handle anything more demanding. > > Henning > > On Apr 7, 2009, at 10:09 PM, Bruce Lowekamp wrote: > >> I think that if messages are typically only a few (<=3D 3) fragments, we >> can safely ignore this issue. =C2=A0If the loss rate is high enough that= it >> matters, the network will collapse anyway. =C2=A0Also remember that what >> happens is there's a retransmission of all of the fragments, which >> might waste some traffic, but the receiver can still have the other >> fragments waiting, so they're not completely useless. >> >> OTOH, if messages are going to typically be even larger (or need to >> deal with higher loss rates), I would favor fixing the problem >> end-to-end, not through hop-by-hop reliability. =C2=A0 I hesitated addin= g >> the minimal semi-reliability to the proposal I wrote up. =C2=A0It's just= a >> lot of complexity and latency added for something that I'm not sure is >> a good addition to the overall stability of the network. >> >> It's important to be willing to drop traffic mid-network. =C2=A0That's t= he >> only way the network can shed load. =C2=A0The senders will back off. >> (Currently they back off in a per-transaction question. =C2=A0It's an >> interesting question whether they should do more.) >> >> Bruce >> >> >> On Mon, Apr 6, 2009 at 11:16 PM, Salman =C2=A0Abdul Baset >> wrote: >>> >>> Are you saying hop-by-hop reliability is not needed? A received message >>> is >>> useless unless all fragments are reliably received. >>> >>> If indeed hop-by-hop reliability is needed, then the link layer analogy >>> is >>> unfortunately not right. >>> >>> -s >>> >>> On Mon, 6 Apr 2009, Bruce Lowekamp wrote: >>> >>>> Fortunately, reliability is not important for the overlay link >>>> protocol. =C2=A0It's a link layer. >>>> >>>> Bruce >>>> >>>> >>>> On Mon, Apr 6, 2009 at 2:02 PM, Salman Abdul Baset >>>> wrote: >>>>> >>>>> TFRC is a congestion control protocol. What is intended is a reliable >>>>> congestion control protocol over UDP, which does not exist as a >>>>> specification. Reliability cannot merely be sprinkled on top of TFRC = or >>>>> any >>>>> congestion control protocol. >>>>> >>>>> -s >>>>> >>>>> On Mon, 6 Apr 2009, Bruce Lowekamp wrote: >>>>> >>>>>> Yes, that's a valid option. =C2=A0Probably the right one at this poi= nt. =C2=A0In >>>>>> fact, the solution space as I last sent it out looks like: >>>>>> >>>>>> - stop and wait >>>>>> - simplified AIMD >>>>>> - TFRC >>>>>> - (TCP over UDP might go here if a draft existed) >>>>>> - TCP >>>>>> >>>>>> The argument has mostly been about the simplified AIMD. =C2=A0I kind= of >>>>>> hate to lose it, but you're right, it will be a lot less controversi= al >>>>>> if we do. =C2=A0Actually, TFRC is a pretty flexible protocol itself,= so we >>>>>> can probably just do something a bit more within that framework if w= e >>>>>> want to have options. >>>>>> >>>>>> stop and wait was always intended as maybe a development-type >>>>>> protocol, not a real deployable protocol (although it would work OK = in >>>>>> a small office environment) >>>>>> >>>>>> Bruce >>>>>> >>>>>> >>>>>> On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen wrot= e: >>>>>>> >>>>>>> Is "use TCP when it works, and TRFC when it doesn't" an answer? >>>>>>> Arguments like "it's too complex" don't work for me when we're >>>>>>> talking >>>>>>> transport protocols that have to do congestion control, etc. >>>>>>> =C2=A0Congestion >>>>>>> control is complex. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>>>>> Behalf >>>>>>> Of >>>>>>> Lars Eggert >>>>>>> Sent: Monday, April 06, 2009 5:20 AM >>>>>>> To: Bruce Lowekamp >>>>>>> Cc: Salman Abdul Baset; p2psip@ietf.org >>>>>>> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion >>>>>>> control >>>>>>> and reliability >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >>>>>>>> >>>>>>>> We have the option of simpy saying "use TFRC." =C2=A0That will be = good >>>>>>>> enough performance, and require relatively little specification >>>>>>>> since >>>>>>>> TSV has already put a lot of work into it. =C2=A0It's also a bit >>>>>>>> complicated. =C2=A0A lot more complicated than is really needed fo= r most >>>>>>>> p2psip implementations/deployments. >>>>>>>> >>>>>>>> So the motivation of the other options was to provide simpler >>>>>>>> options >>>>>>>> that are going to provide enough performance for many/most >>>>>>>> deployments. >>>>>>> >>>>>>> I'd strongly urge you to use TFRC rather than rolling your own >>>>>>> scheme. >>>>>>> Don't underestimate the validation effort that is required to ensur= e >>>>>>> that >>>>>>> a >>>>>>> congestion control scheme is safe to deploy. This has all been done >>>>>>> for >>>>>>> TFRC, and it must be done for any new scheme. >>>>>>> >>>>>>> Lars >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > From hgs@cs.columbia.edu Wed Apr 8 05:26:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A003A6AB3 for ; Wed, 8 Apr 2009 05:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=0.906, 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 kIHmZBLaM2Qh for ; Wed, 8 Apr 2009 05:26:24 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 987943A68C5 for ; Wed, 8 Apr 2009 05:26:24 -0700 (PDT) Received: from Upstairs.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n38CRUIc018801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2009 08:27:30 -0400 (EDT) Message-Id: <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> From: Henning Schulzrinne To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 08:27:29 -0400 References: <044b01c9b6ba$28dc0550$7a940ff0$@net> <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 12:26:25 -0000 On Apr 8, 2009, at 6:21 AM, Bruce Lowekamp wrote: > One of the (if not THE) fundamental decisions that makes the Internet > work is that reliability is end-to-end, not hop-by-hop. Hops are > allowed to drop traffic due to congestion, and that is taken as > implicit feedback that there is congestion in the network. You may want to re-read the end-to-end argument paper. You do need end- to-end reliability to ensure reliability (since nodes in the middle can do bad things to packets), but performance often dictates "hop-by- hop", particularly if the "hop" is essentially the whole Internet. Since you like to use the notion of a link layer in P2P: this is the reason why 802.11 has link-layer reliability. By your argument, 802.11 should dispense with that. > > > The proposal I sent out drops traffic in two places. First, each peer > maintains a limited queue for fragments and drops excess fragments > (the literal analog of drops due to congestion in routers). Second, > the overlay link protocol is only semi-reliable (which I debated > having at all), with the assumption that on the Internet, loss is due > to congestion. So we have two congestion signals to the peer, queue > length and link protocol drops. Unfortunately, that assumption is only somewhat true, particularly with wireless links. > > > Congestion needs to cause load shedding in a network (overlay or not) > or else it will collapse. Arguing that we should do extra work for > hop-by-hop reliability makes no sense to me. Please consult the literature; this is a topic that has received more than its share of real measurement work, albeit ten and twenty years ago, when this topic was of greater practical interest. > > > Bruce > From bbl@lowekamp.net Wed Apr 8 19:48:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D553A6781 for ; Wed, 8 Apr 2009 19:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 lkAYsCBHCLLu for ; Wed, 8 Apr 2009 19:48:49 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 857543A68CC for ; Wed, 8 Apr 2009 19:48:48 -0700 (PDT) Received: by fxm2 with SMTP id 2so393489fxm.37 for ; Wed, 08 Apr 2009 19:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.111.134 with SMTP id s6mr581404fap.60.1239245395260; Wed, 08 Apr 2009 19:49:55 -0700 (PDT) In-Reply-To: <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> References: <044b01c9b6ba$28dc0550$7a940ff0$@net> <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> Date: Wed, 8 Apr 2009 22:49:55 -0400 Message-ID: From: Bruce Lowekamp To: Henning Schulzrinne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 02:48:49 -0000 802.11 is a bad example. It needs reliability because its losses aren't well-correlated with congestion. I'm not terribly concerned about TCP having reliability when used in this context, although the stream-oriented nature of TCP is unfortunate. I don't want to go to a lot of effort adding reliability to a UDP-based protocol, because I don't think it will add much (and could hurt if done wrong). Even if the overlay link protocol does have reliability, you still need to shed load with finite-length queues (or push back) to avoid congestion collapse/infinite queues. I'm curious what literature you're thinking off that argues otherwise. Bruce On Wed, Apr 8, 2009 at 8:27 AM, Henning Schulzrinne w= rote: > > On Apr 8, 2009, at 6:21 AM, Bruce Lowekamp wrote: > >> One of the (if not THE) fundamental decisions that makes the Internet >> work is that reliability is end-to-end, not hop-by-hop. =C2=A0Hops are >> allowed to drop traffic due to congestion, and that is taken as >> implicit feedback that there is congestion in the network. > > You may want to re-read the end-to-end argument paper. You do need > end-to-end reliability to ensure reliability (since nodes in the middle c= an > do bad things to packets), but performance often dictates "hop-by-hop", > particularly if the "hop" is essentially the whole Internet. Since you li= ke > to use the notion of a link layer in P2P: this is the reason why 802.11 h= as > link-layer reliability. By your argument, 802.11 should dispense with tha= t. > > > >> >> >> The proposal I sent out drops traffic in two places. =C2=A0First, each p= eer >> maintains a limited queue for fragments and drops excess fragments >> (the literal analog of drops due to congestion in routers). =C2=A0Second= , >> the overlay link protocol is only semi-reliable (which I debated >> having at all), with the assumption that on the Internet, loss is due >> to congestion. =C2=A0So we have two congestion signals to the peer, queu= e >> length and link protocol drops. > > Unfortunately, that assumption is only somewhat true, particularly with > wireless links. > > >> >> >> Congestion needs to cause load shedding in a network (overlay or not) >> or else it will collapse. =C2=A0Arguing that we should do extra work for >> hop-by-hop reliability makes no sense to me. > > Please consult the literature; this is a topic that has received more tha= n > its share of real measurement work, albeit ten and twenty years ago, when > this topic was of greater practical interest. > >> >> >> Bruce >> > > From enrico.marocco@telecomitalia.it Thu Apr 9 03:04:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015CA3A6BDA for ; Thu, 9 Apr 2009 03:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 lLkxkQjg7s+Q for ; Thu, 9 Apr 2009 03:04:07 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id AFA713A6B61 for ; Thu, 9 Apr 2009 03:04:06 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 9 Apr 2009 12:04:57 +0200 Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 9 Apr 2009 12:04:56 +0200 Message-ID: <49DDC839.7040302@telecomitalia.it> Date: Thu, 9 Apr 2009 12:04:41 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Bruce Lowekamp References: <044b01c9b6ba$28dc0550$7a940ff0$@net> <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070400090408000306070402" Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 10:04:08 -0000 --------------ms070400090408000306070402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Bruce Lowekamp wrote: > 802.11 is a bad example. It needs reliability because its losses > aren't well-correlated with congestion. I do not expect network congestion to be the main cause of packet losses in distributed overlays either. Factors like peer failures and link instability in wireless/ad-hoc networks will probably have greater impact, no? > Even if the overlay link protocol does have reliability, you still > need to shed load with finite-length queues (or push back) to avoid > congestion collapse/infinite queues. I'm curious what literature > you're thinking off that argues otherwise. The fact that hop-by-hop reliability cannot replace end-to-end -- and I don't think that's what Henning was arguing for -- doesn't mean that the contrary is always true. It happens to be a good approximation in some scenarios, e.g. when the hops are very stable hardware routers and the links wires, but in the general case it is an oversimplistic assumption. -- Ciao, Enrico --------------ms070400090408000306070402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MDkxMDA0NDFaMCMG CSqGSIb3DQEJBDEWBBT46BPAiILDKRvAk9wzP96yo+SEFDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAKnoNSX6IMiv A6MRCI/dCt4d0usFqIp8sjSeTtPQgvONh3TlUtUtNYFKem6cSsSzE616J1OT5fpYwKVxNwat IRzn1MEwLfdMUBIaNTcUMBRxrZHgupywhPF2QrnrPmJvPhSc5DZPrYJZ30FJ9pZZXxSK57cf dTupzaufW9BiOuDmiw2SYEnxjGZPMMPSu7Bo55avFdDfNw3+/YtFkc4Mwwud35d/ay5OXJj5 dR+6+Gr/7uXOAgA32vyq/tL0sQ+eVwuH+s7xuA7FyHMXxCksZE7ASiYVZX5wve8u/Z0aUYfJ wpXf/ZOpyApXqmVBFAkYQzB21+qsWl1taDCJsd7b0twAAAAAAAA= --------------ms070400090408000306070402-- From hgs@cs.columbia.edu Thu Apr 9 05:19:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6343A6C4F for ; Thu, 9 Apr 2009 05:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 9BY6ny1Kp3yW for ; Thu, 9 Apr 2009 05:19:40 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 46C4D3A696E for ; Thu, 9 Apr 2009 05:19:40 -0700 (PDT) Received: from Upstairs.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n39CKjqF007128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Apr 2009 08:20:45 -0400 (EDT) Message-Id: <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> From: Henning Schulzrinne To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 08:20:43 -0400 References: <044b01c9b6ba$28dc0550$7a940ff0$@net> <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 12:19:41 -0000 On Apr 8, 2009, at 10:49 PM, Bruce Lowekamp wrote: > 802.11 is a bad example. It needs reliability because its losses > aren't well-correlated with congestion. I admit that I can't follow this logic. The reason for reliability in 802.11 has nothing to do with congestion. If 802.11 did not have reliability built-in, end-to-end throughput at the network layer would be horrible. The same principle applies here as well. > > > I'm not terribly concerned about TCP having reliability when used in > this context, although the stream-oriented nature of TCP is > unfortunate. I don't want to go to a lot of effort adding reliability > to a UDP-based protocol, because I don't think it will add much (and > could hurt if done wrong). Can you support your arguments with references to the literature or at least not contradict standard intro to networking course materials? > > > Even if the overlay link protocol does have reliability, you still > need to shed load with finite-length queues (or push back) to avoid > congestion collapse/infinite queues. I'm curious what literature > you're thinking off that argues otherwise. Yes, you do need (and will, by nature, have) finite buffers at intermediate hops, but they will drop P2P-layer messages very rarely, as long as they can store a full "message" worth. > > > Bruce From sa2086@columbia.edu Thu Apr 9 10:24:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48A73A6BE8 for ; Thu, 9 Apr 2009 10:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhGL-npawaix for ; Thu, 9 Apr 2009 10:24:25 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 007243A6BBD for ; Thu, 9 Apr 2009 10:24:24 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n39HPS0w021453; Thu, 9 Apr 2009 13:25:29 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n39HPSdv005925; Thu, 9 Apr 2009 13:25:28 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n39HPSr2005922; Thu, 9 Apr 2009 13:25:28 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 9 Apr 2009 13:25:28 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: p2psip@ietf.org Message-ID: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Subject: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 17:24:25 -0000 We have written a straw man proposal for doing TCP-over-UDP (ToU). ToU behavior is like TCP including its congestion control and reliability mechanisms. ToU header also mimics TCP header except port numbers, checksum, and urgent options. Comments are appreciated. http://www1.cs.columbia.edu/~salman/I-D/draft-baset-tsvwg-tcp-over-udp-00.html Salman From bbl@lowekamp.net Thu Apr 9 10:46:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D873A6A17 for ; Thu, 9 Apr 2009 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 eWYJTiokcGEm for ; Thu, 9 Apr 2009 10:46:49 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id A43F03A6A07 for ; Thu, 9 Apr 2009 10:46:48 -0700 (PDT) Received: by bwz17 with SMTP id 17so704787bwz.37 for ; Thu, 09 Apr 2009 10:47:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.68 with SMTP id z4mr541500fap.72.1239299275835; Thu, 09 Apr 2009 10:47:55 -0700 (PDT) In-Reply-To: <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> References: <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> Date: Thu, 9 Apr 2009 13:47:55 -0400 Message-ID: From: Bruce Lowekamp To: Henning Schulzrinne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 17:46:49 -0000 On Thu, Apr 9, 2009 at 8:20 AM, Henning Schulzrinne w= rote: > > On Apr 8, 2009, at 10:49 PM, Bruce Lowekamp wrote: > >> 802.11 is a bad example. =C2=A0It needs reliability because its losses >> aren't well-correlated with congestion. > > I admit that I can't follow this logic. The reason for reliability in 802= .11 > has nothing to do with congestion. If 802.11 did not have reliability > built-in, end-to-end throughput at the network layer would be horrible. T= he > same principle applies here as well. I'm not sure how we are talking past each other here. The basic principle of how TCP works is that loss=3D=3Dcongestion. 802.11 needs a reliability protocol because it doesn't have this correlation, i.e. loss can be caused by signal problems that are not related to congestion. The principle I was trying to apply a few messages ago was that if loss in the overlay link layer is caused by congestion, and end-to-end protocols react to loss by backing off, we have the same property as TCP. Your suggestion that if 802.11 needing reliability implies that an overlay link protocol only makes sense if you believe that the overlay link protocol experiences losses that are not due to congestion. I don't believe that is likely to be true, so 802.11 is a bad example. > >> >> >> I'm not terribly concerned about TCP having reliability when used in >> this context, although the stream-oriented nature of TCP is >> unfortunate. =C2=A0I don't want to go to a lot of effort adding reliabil= ity >> to a UDP-based protocol, because I don't think it will add much (and >> could hurt if done wrong). > > Can you support your arguments with references to the literature or at le= ast > not contradict standard intro to networking course materials? I have no idea what you're referring to here. But since you have claimed I am misapplying/unaware of the end-to-end argument, etc, I will quote what I think is the most relevant part of Saltzer's paper here: ----------------- Clearly, some effort at the lower levels to improve network reliability can have a significant effect on application performance. But the key idea here is that the lower levels need not provide "perfect" reliability. Thus the amount of effort to put into reliability measures within the data communication system is seen to be an engineering tradeoff based on performance, rather than a requirement for correctness. Note that performance has several aspects here. --------------------- Obviously the paper goes on to discuss more aspects of the corner cases and performance tradeoffs, but my initial suggestion that what we should build is a semi-reliable protocol is entirely in line with this, as far as I can tell. Bruce From simon.perreault@viagenie.ca Thu Apr 9 10:55:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CDE3A6B89 for ; Thu, 9 Apr 2009 10:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.105, 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 NYlf1tbfNqJ4 for ; Thu, 9 Apr 2009 10:55:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0327F3A6AD5 for ; Thu, 9 Apr 2009 10:55:15 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 9865E29E15AA; Thu, 9 Apr 2009 13:56:22 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 8FF2E29E1590; Thu, 9 Apr 2009 13:56:22 -0400 (EDT) Message-ID: <49DE36C6.8030608@viagenie.ca> Date: Thu, 09 Apr 2009 13:56:22 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Salman Abdul Baset References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 17:55:16 -0000 Salman Abdul Baset wrote, On 04/09/2009 01:25 PM: > > We have written a straw man proposal for doing TCP-over-UDP (ToU). > ToU behavior is like TCP including its congestion control and > reliability mechanisms. ToU header also mimics TCP header except port > numbers, checksum, and urgent options. > > Comments are appreciated. Keep the implementation details minimal. For example, Figure 2 is wrong for a hybrid kernel- and user-space implementation I have in mind. Just focus on the protocol. I'd remove Figure 2 and all text between the start of Section 2 until the start of 2.1. Section 5: Why not simply define a new protocol number and reuse all the current function? e.g. socket( AF_INET, SOCK_STREAM, IPPROTO_TOU ); ... Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From sa2086@columbia.edu Thu Apr 9 11:34:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521903A6BCF for ; Thu, 9 Apr 2009 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEUy4yn7iWyZ for ; Thu, 9 Apr 2009 11:34:29 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 874A43A6AA6 for ; Thu, 9 Apr 2009 11:34:29 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n39IZa3f010236; Thu, 9 Apr 2009 14:35:36 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n39IZaZM017145; Thu, 9 Apr 2009 14:35:36 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n39IZaJc017142; Thu, 9 Apr 2009 14:35:36 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 9 Apr 2009 14:35:36 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Simon Perreault In-Reply-To: <49DE36C6.8030608@viagenie.ca> Message-ID: References: <49DE36C6.8030608@viagenie.ca> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:34:30 -0000 > Keep the implementation details minimal. For example, Figure 2 is wrong for a > hybrid kernel- and user-space implementation I have in mind. Just focus on the > protocol. I'd remove Figure 2 and all text between the start of Section 2 until > the start of 2.1. Right. There may be several ways of implementing this. > Section 5: Why not simply define a new protocol number and reuse all the current > function? e.g. socket( AF_INET, SOCK_STREAM, IPPROTO_TOU ); ... Indeed, reusing all the current functions is the preferred approach. However, an intermediate solution may be needed until the current function calls don't support it. -s From simon.perreault@viagenie.ca Thu Apr 9 11:41:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5AA3A6CBB for ; Thu, 9 Apr 2009 11:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 Ept3XD263vyg for ; Thu, 9 Apr 2009 11:41:18 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 517DB3A6C34 for ; Thu, 9 Apr 2009 11:41:17 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 99E4D29E15B4; Thu, 9 Apr 2009 14:42:24 -0400 (EDT) Received: from powerbook-g4-15-de-simon-perreault.local (unknown [216.13.51.76]) by jazz.viagenie.ca (Postfix) with ESMTP id 7E3D729E1594; Thu, 9 Apr 2009 14:42:24 -0400 (EDT) Message-ID: <49DE4190.1030606@viagenie.ca> Date: Thu, 09 Apr 2009 14:42:24 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Salman Abdul Baset References: <49DE36C6.8030608@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:41:30 -0000 Salman Abdul Baset wrote: > Indeed, reusing all the current functions is the preferred approach. > However, an intermediate solution may be needed until the current > function calls don't support it. Right. However I see this as being out of scope for this draft. Applying for a protocol number, though, might be in scope. Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Thu Apr 9 11:43:38 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87BD3A6CB8 for ; Thu, 9 Apr 2009 11:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 KfNEmypPLoVz for ; Thu, 9 Apr 2009 11:43:38 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 148593A6C9A for ; Thu, 9 Apr 2009 11:43:38 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 011B229E15B7; Thu, 9 Apr 2009 14:44:45 -0400 (EDT) Received: from powerbook-g4-15-de-simon-perreault.local (unknown [216.13.51.76]) by jazz.viagenie.ca (Postfix) with ESMTP id E6D2729E1594; Thu, 9 Apr 2009 14:44:45 -0400 (EDT) Message-ID: <49DE421D.8060704@viagenie.ca> Date: Thu, 09 Apr 2009 14:44:45 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Salman Abdul Baset References: <49DE36C6.8030608@viagenie.ca> <49DE4190.1030606@viagenie.ca> In-Reply-To: <49DE4190.1030606@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:43:38 -0000 Simon Perreault wrote: > Right. However I see this as being out of scope for this draft. Applying > for a protocol number, though, might be in scope. Of course that protocol number wouldn't be used on the wire or otherwise the whole "over UDP" thing wouldn't work. ;) Hmmm... maybe there's a better way to make it fit into the BSD sockets API... Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From enrico.marocco@telecomitalia.it Thu Apr 9 15:36:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E843A6A2F for ; Thu, 9 Apr 2009 15:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 x4AUKCAdnm36 for ; Thu, 9 Apr 2009 15:36:56 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 111F83A69ED for ; Thu, 9 Apr 2009 15:36:54 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 10 Apr 2009 00:36:19 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 10 Apr 2009 00:36:18 +0200 Message-ID: <49DE7870.8090604@telecomitalia.it> Date: Fri, 10 Apr 2009 00:36:32 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Bruce Lowekamp References: <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050104050203030308070509" Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 22:36:57 -0000 --------------ms050104050203030308070509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Bruce Lowekamp wrote: > The principle I was trying to apply a few messages ago was that if > loss in the overlay link layer is caused by congestion, and end-to-end > protocols react to loss by backing off, we have the same property as > TCP. Your suggestion that if 802.11 needing reliability implies that > an overlay link protocol only makes sense if you believe that the > overlay link protocol experiences losses that are not due to > congestion. I don't believe that is likely to be true, so 802.11 is a > bad example. Uh?? In a ring based DHT with 1000 nodes, failure detection time of 1 minute, if peers fail on average every 60 minutes every query has a 1 - (1 - 1 / 60) ^ (log2(1000) / 2) =~ 8% probability to find a failed hop on its way. YMMV, but that's hardly irrelevant, especially if compared to the inherent packet loss rate of 802.11 (which, IIRC, should be less than 10%). -- Ciao, Enrico --------------ms050104050203030308070509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICEBtZixsKeF4i2Os0viEP+ncwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMyOTE2Mjg1OVoX DTEwMDMyOTE2Mjg1OVowUTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALhn5sIqd2hv7B6UBs4823vUHLamD/+tFSXZKQ4Yw5oQ 5hOdPUoJazGMDOyB9tWcqXdJxt0WqHxdgeCeAS0zV85Uf6cQcvkSe//umVkZvPuAYTKWRBJw 8rLfVuYhk9t2KraXyVfWIdoceZP0/v4eIoLyPw2/wQS3AvxujvkyL2N94S7IOmPCP6WXZmmW zNRzabSLLl50UA2jKbcYcWpKfQUFma9B1S3hAZTDiQTvXIJVmRdwYmnuwId9QTsm+7RB7oiy EC7+zeOORQk1Y6NjKinZmLb/C0tq40NIIPpBqNaZ+V6UmQ0jtYIlBQrlG6OpSPgjAS9IWsMg 7mbratVpsNkCAwEAAaM8MDowKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0 YWxpYS5pdDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADfh68XGwHIccDd0a+Fw D7LEP2QxLEqgP/gR73fsvT6y1COD7vGZY4BkYvryiU5sPkW4ulizN1ASSMJJIVMkQdzzKS+H e4dR5CpiPqz8b1LJdae8G7CUsBZ9KHYN4n6pGpdcq9YsGtfELp1W25MMppJcpKniscResCQF BWmw3EsAMIIC+DCCAmGgAwIBAgIQG1mLGwp4XiLY6zS+IQ/6dzANBgkqhkiG9w0BAQUFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDkwMzI5 MTYyODU5WhcNMTAwMzI5MTYyODU5WjBRMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMS4wLAYJKoZIhvcNAQkBFh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuGfmwip3aG/sHpQGzjzbe9QctqYP/60V JdkpDhjDmhDmE509SglrMYwM7IH21Zypd0nG3RaofF2B4J4BLTNXzlR/pxBy+RJ7/+6ZWRm8 +4BhMpZEEnDyst9W5iGT23YqtpfJV9Yh2hx5k/T+/h4igvI/Db/BBLcC/G6O+TIvY33hLsg6 Y8I/pZdmaZbM1HNptIsuXnRQDaMptxhxakp9BQWZr0HVLeEBlMOJBO9cglWZF3Biae7Ah31B Oyb7tEHuiLIQLv7N445FCTVjo2MqKdmYtv8LS2rjQ0gg+kGo1pn5XpSZDSO1giUFCuUbo6lI +CMBL0hawyDuZutq1Wmw2QIDAQABozwwOjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAN+HrxcbA chxwN3Rr4XAPssQ/ZDEsSqA/+BHvd+y9PrLUI4Pu8ZljgGRi+vKJTmw+Rbi6WLM3UBJIwkkh UyRB3PMpL4d7h1HkKmI+rPxvUsl1p7wbsJSwFn0odg3ifqkal1yr1iwa18QunVbbkwymklyk qeKxxF6wJAUFabDcSwAwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20CAQEwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBtZixsKeF4i 2Os0viEP+ncwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDkwNDA5MjIzNjMyWjAjBgkqhkiG9w0BCQQxFgQU5OAg0UXhX0lZKebZ sKuViRwzdKQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6 dzANBgkqhkiG9w0BAQEFAASCAQAoC0P8igapcc0VbOzFSZZj0y5UngthjnYVQ8zu7E8tEXNJ Ce39Egm2pKp3+0V8Nt+kbmmAm5C5b+xmlTgVLvPaHRyogwv3WlslHLPWgXD2Tim6PnlMQQo2 wO6Gb/ci6AknotX60CyQqXuChf6wWEz4qAAZ6oUpVx7Iygk63FpgAIo3i0CEhtO4Ky4rA2jL HkqKvUoldGdVhJAx62y1alUxdm9fCI/3vmhOJY4g8LnGCEAldFVYwWFEYgROz9ZhHNr/ZUkE z+wWw1AYxRUZhdYDU9wXRJFwlYlC9s7Amz641Nt2y6kqcE+8rZaBYlv9MbjwycxPAEgOdya1 yyo4qqgCAAAAAAAA --------------ms050104050203030308070509-- From bbl@lowekamp.net Thu Apr 9 16:02:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB423A69B3 for ; Thu, 9 Apr 2009 16:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 IsdhUwkvFsn2 for ; Thu, 9 Apr 2009 16:02:15 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 13D223A6C4C for ; Thu, 9 Apr 2009 16:02:14 -0700 (PDT) Received: by bwz17 with SMTP id 17so807263bwz.37 for ; Thu, 09 Apr 2009 16:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.122.15 with SMTP id j15mr952648far.10.1239318202255; Thu, 09 Apr 2009 16:03:22 -0700 (PDT) In-Reply-To: <49DE7870.8090604@telecomitalia.it> References: <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> <49DE7870.8090604@telecomitalia.it> Date: Thu, 9 Apr 2009 19:03:22 -0400 Message-ID: From: Bruce Lowekamp To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 23:02:16 -0000 Enrico, My comment was that the reason 802.11 has reliability isn't the same as the reason we may or may not need reliability in an overlay link protocol. 802.11 is irrelevant, the loss characteristics of overlays is not. But in your example, the overlay link protocol having reliability doesn't solve the problem either, if your application is real-time communication. If the failure detection time is 1 minute, 8% of your queries are going to take an average of 30 seconds to complete (assuming they succeed on the second try). So you need to rely on another mechanism to try to complete the query more quickly. Whether that is each hop replacing the failing peer in their routing table before they officially fail it and stop trying to re-establish (after 1 minute) or the querying peer trying alternative routes or replicas, you need to find an alternative route faster. Bruce On Thu, Apr 9, 2009 at 6:36 PM, Enrico Marocco wrote: > Bruce Lowekamp wrote: >> The principle I was trying to apply a few messages ago was that if >> loss in the overlay link layer is caused by congestion, and end-to-end >> protocols react to loss by backing off, we have the same property as >> TCP. =C2=A0Your suggestion that if 802.11 needing reliability implies th= at >> an overlay link protocol only makes sense if you believe that the >> overlay link protocol experiences losses that are not due to >> congestion. =C2=A0I don't believe that is likely to be true, so 802.11 i= s a >> bad example. > > Uh?? In a ring based DHT with 1000 nodes, failure detection time of 1 > minute, if peers fail on average every 60 minutes every query has a 1 - > (1 - 1 / 60) ^ (log2(1000) / 2) =3D~ 8% probability to find a failed hop > on its way. YMMV, but that's hardly irrelevant, especially if compared > to the inherent packet loss rate of 802.11 (which, IIRC, should be less > than 10%). > > -- > Ciao, > Enrico > From sam.ganesan@gmail.com Thu Apr 9 16:38:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8BF3A6B2E for ; Thu, 9 Apr 2009 16:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 egUf4dX7C+-8 for ; Thu, 9 Apr 2009 16:38:46 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id AD1473A69ED for ; Thu, 9 Apr 2009 16:38:46 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so1103224ywh.49 for ; Thu, 09 Apr 2009 16:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=XafGUBAu39iKAW/vmv9uEoBGTMpqfaLsPx6hsYnam3I=; b=h8gFyUWXN5vBjcY+YRmXI3QUzYTbPW3fiDl5EqvyTQ1l3cyWrY5iCfvs7Ie0rljNbY WeIBm7cZfeNULFM9iwB0FsDwt5CL3O7b26QD61JKCCfyvLxWROgDBg+D5914rS2WoYPG 2278ldxaT4yNaNz3brvDW4ejwwKOcO1ZkH/6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=vF4OVUyUyujSzxi2tmYBq529K8YlfSUM+ekR59ejvhSsRH7PHaSLxs4l6gxUkHoddG ooFwb1mn3ys0QTSqhpazSQVa6nhsiYVQPoEBULabXlN3m4GFWmHd2+SrLZA1Z6FjqJ1G DTY8Xq8bKk9JH/La3aB/XsRd7NP8BplXh7+YA= Received: by 10.100.167.3 with SMTP id p3mr1170600ane.141.1239320394328; Thu, 09 Apr 2009 16:39:54 -0700 (PDT) Received: from ?192.168.101.100? (68-116-201-173.dhcp.oxfr.ma.charter.com [68.116.201.173]) by mx.google.com with ESMTPS id 9sm277779yxs.25.2009.04.09.16.39.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Apr 2009 16:39:53 -0700 (PDT) Message-Id: <730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmail.com> From: Sam Ganesan To: Simon Perreault In-Reply-To: <49DE4190.1030606@viagenie.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 19:39:52 -0400 References: <49DE36C6.8030608@viagenie.ca> <49DE4190.1030606@viagenie.ca> X-Mailer: Apple Mail (2.930.3) Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 23:38:47 -0000 Somebody took Jonathan Rosenberg seriously when he said this in what was it - was it Dublin or was it Philadelphia may be even Vancouver... Some of the old hands might remember something called RDP which was sort of lightweight TCP without the burdens of full blown tcp. As I remember it, it provided acknowledgement of data delivery and tried to minimize retransmissions. There were even two versions of it... Let me look it up... yep rfc 908 and rfc 1151.... I remember thinking about it as UDP with sequencing facility and retransmission!!! Well TCP over UDP over TCP when you have to work with tunnels??? As Terry Pratchett said in the Discworld series of books... "the world stands on 8 elephants that stand on top of a giant turtle... what does the turtle stand on... it is turtles all the way down" Sorry about the tongue in cheek So is ToU also going to have slow start in it??? and all other full blown TCP'isms ??? why not just define a protocol that adds retransmit of individual udp packets and ack mechanism and sequencing rather go layer a whole stack on top of another stack... Just add the features that are needed... Since you are proposing a new protocol anyway let us keep it as minimalistic as possible Sam On Apr 9, 2009, at 2:42 PM, Simon Perreault wrote: > Salman Abdul Baset wrote: >> Indeed, reusing all the current functions is the preferred approach. >> However, an intermediate solution may be needed until the current >> function calls don't support it. > > Right. However I see this as being out of scope for this draft. > Applying > for a protocol number, though, might be in scope. > > Thanks, > Simon > -- > STUN/TURN server --> http://numb.viagenie.ca > Interplanetary news --> http://reeves.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From hgs@cs.columbia.edu Thu Apr 9 17:08:01 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C319F28C0E0 for ; Thu, 9 Apr 2009 17:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 t+1+1w3vynIs for ; Thu, 9 Apr 2009 17:08:01 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id D1A613A6D1A for ; Thu, 9 Apr 2009 17:08:00 -0700 (PDT) Received: from Upstairs.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3A093l3019075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Apr 2009 20:09:04 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Sam Ganesan In-Reply-To: <730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 20:09:03 -0400 References: <49DE36C6.8030608@viagenie.ca> <49DE4190.1030606@viagenie.ca> <730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmail.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: Salman Abdul Baset , "p2psip@ietf.org WG" Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 00:08:01 -0000 > So is ToU also going to have slow start in it??? and all other full > blown TCP'isms ??? why not just define a protocol that adds > retransmit of individual udp packets and ack mechanism and > sequencing rather go layer a whole stack on top of another stack... > Just add the features that are needed... Since you are proposing a > new protocol anyway let us keep it as minimalistic as possible Which features would you propose to remove? Unless you are content with stop-and-wait congestion control (and roughly modem data rates), you need either AIMD or rate-based control. As I mentioned earlier, rate-based control is not all that suitable for mid-sized transfers, due to the estimation delay, and isn't any simpler than AIMD. Currently, ToU has - "modern" congestion control - flow control (window-based) - reliability - extensions (so that, for example, SACK can be made to work if needed) It omits - ports - checksum - urgent mode/PSH bit I suspect we could remove RST handling, but that's a relatively minor aspect. The advantage of using TCP algorithms is that it ToU behavior is relatively easy to validate (you can run "real" TCP and ToU in parallel on the same simulator, for example, and immediately see if you screwed up) and lots and lots of implementors understand it, as it's covered in every intro networking textbook. I don't think winging our own algorithm is a good idea, given the amount of existing "prior art". As we learned from SCTP, getting the first implementations of a conceptually new protocol right is non-trivial. The goal would be to have somebody build a library, so that most application writers don't have to worry about getting RTO estimation right, dealing with window adjustments and all the other details that any non-toy transport protocol needs. Thus, generality is an advantage, as it encourages library building. We're generally not good at predicting where and how protocols will be used, and most long-term successful protocols are those that provided modular functionality, not extremely narrowly-tailored protocols. Henning From enrico.marocco@telecomitalia.it Fri Apr 10 04:34:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABE63A6932 for ; Fri, 10 Apr 2009 04:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 7UAmNrr-1N8s for ; Fri, 10 Apr 2009 04:34:59 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 8B3463A6AF5 for ; Fri, 10 Apr 2009 04:34:58 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 10 Apr 2009 13:35:47 +0200 Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 10 Apr 2009 13:35:46 +0200 Message-ID: <49DF2F05.5080303@telecomitalia.it> Date: Fri, 10 Apr 2009 13:35:33 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Bruce Lowekamp References: <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> <49DE7870.8090604@telecomitalia.it> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070508050402050104050005" Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 11:35:00 -0000 --------------ms070508050402050104050005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Bruce Lowekamp wrote: > My comment was that the reason 802.11 has reliability isn't the same > as the reason we may or may not need reliability in an overlay link > protocol. The reason why you may want to consider hop-by-hop reliability in RELOAD is performance, just as in 802.11. > But in your example, the overlay link protocol having reliability > doesn't solve the problem either, if your application is real-time > communication. If the failure detection time is 1 minute, 8% of your > queries are going to take an average of 30 seconds to complete > (assuming they succeed on the second try). So you need to rely on > another mechanism to try to complete the query more quickly. Whether > that is each hop replacing the failing peer in their routing table > before they officially fail it and stop trying to re-establish (after > 1 minute) or the querying peer trying alternative routes or replicas, > you need to find an alternative route faster. Or each hop forking a parallel route right after a few retransmissions of the same packet; that would take much longer if retransmissions were end-to-end (i.e. rather than constant, the time overhead would grow linearly with the _estimated_ path length). -- Ciao, Enrico --------------ms070508050402050104050005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MTAxMTM1MzNaMCMG CSqGSIb3DQEJBDEWBBR34HR6YN3XHL6Lb+G14VEPZM/AKjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAKq+ZgQ2gN5r bf8oJdQviSIQECgPEgNv+WhAtj4P1PWM1UMiuyb4LWC5CoZKGKjV1J8Zrq+oqjI/6YbfoUbO 9DXg5GGx7863DXThiw3c7SugGcWDVM6htrCYzbCJKFNwIyBboTBX+iXbanJcVbQjvRs0/pjS /ksHfLqOLzwCJEyeB9XmzDIsfpZQ9IBIoeokjI5L0xkq8/gDOMsETajU1xlth8RHjt06sjuC fzS4fARnZMkckh0f7ZL4Scv2SGt7d9dITcIFQC74zK8AtCrjn70qWHaQkwV00ZLc2oq/OOcN jqH8J510vJwn/Wz8LY2FoufEYg3jSfoe6Ivg/ItnSmkAAAAAAAA= --------------ms070508050402050104050005-- From fluffy@cisco.com Fri Apr 10 13:32:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56F93A69BD for ; Fri, 10 Apr 2009 13:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.624 X-Spam-Level: X-Spam-Status: No, score=-106.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 VF7fwNh1ouWE for ; Fri, 10 Apr 2009 13:32:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C25B53A68FF for ; Fri, 10 Apr 2009 13:32:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,169,1238976000"; d="scan'208";a="284083988" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Apr 2009 20:34:06 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3AKY6Pp006891; Fri, 10 Apr 2009 13:34:06 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n3AKY59b024970; Fri, 10 Apr 2009 20:34:05 GMT From: Cullen Jennings To: "Narayanan, Vidya" In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 14:34:04 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3284; t=1239395646; x=1240259646; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Access=20control=20rule=20in =20RELOAD=20to=20support=20generic=20keyword-like=20storage |Sender:=20; bh=Ok5tIunXnvDV3pwcvCC3sLS05F4fqJgwS8V9Pukx3Xs=; b=TL2fns/XiJVaujiqe0LDAnq48Kr3RsyHmNWpeWcNAUgt2vb1kuDmXMVyuT Kx0/lM1ZtQJ93pfvDr77OX0YOWSMwrYa/2P5YpEp7+QPMSZ0rdYUPhebw2XM JHqEYpBD5+jFbGBJwv/wGcBaeJbuM/kJ6S2UUVGVnTWMHlfzlZL4c=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic keyword-like storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:32:59 -0000 Vidya, I like this and think we should add it to the draft but one question. I worry about it being a bit vague of it if is a certificate with same user id or node id that is allowed to do an update. I think we need to do one of two things a) define this so the nodeid and userid are stored and a certificate that matches either the nodeid or userid is allowed ot update b) define two new rules here, one that requires the node-id to match and ones that requires the userid to match. So we would have something like NO-MATCH-CREATE-WITH-RESTRICTED-NODE-UDPATE and NO-MATCH-CREATE-WITH-RESTRICTED-USER-UDPATE I'd probably prefer approach b to aproach a but don't feel strongly either way. Thougths? Cullen, in my individual contrubotro role On Mar 22, 2009, at 8:31 PM, Narayanan, Vidya wrote: > In addition to the access control rules defined in section 6.3 of > the draft, I think there is a need for a rule, where any node is > allowed to write to a Resource ID, but, only the creator is allowed > to modify or overwrite the entry by default. This allows for > generic keyword-like storage on the overlay which will eventually be > needed to support various types of kinds and usages on the overlay > effectively. The notion here is that no authorization is needed on > the Resource ID, but access control is applied to the data > operations, once it exists. Here is suggestive text for supporting > this: > > "6.3.6. NO-MATCH-CREATE-WITH-RESTRICTED-UDPATE > > This policy allows storage of data with no constraints on choosing a > Resource ID. However, by default, only the creator of the entry is > allowed to modify or overwrite the stored data once created. The > user name and/or node id present in the certificate of the > requesting node MUST be used as the creator of the data. Upon > receiving a request to store, a node MUST verify if it already has > an entry present for the particular kind and Resource ID > corresponding to the same user name or node id that is contained in > the Store Request. If so, the received Store Request MUST be > treated as an update to the existing data and the appropriate checks > as described in section 6.4 must be applied. If no corresponding > match is found, the StoredData contained in the Store Request > message MUST be stored as a new entry in accordance with section > 6.4. This rule is useful for generic keyword-like storage on the > overlay, which is likely to be useful for several classes of > applications that may b > e defined for use with RELOAD. The access control allows ensuring > that the data created by a given node is not randomly overwritten by > any other node." > > It may be good to include the Resource Name in the StoredData > structure as well. This will allow the storing node to more easily > create an index of the resources it is storing, which can then be > used for retrieval of data. However, I think it will work even > without it - I'm looking for other thoughts on this. > > Thanks, > Vidya > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Fri Apr 10 13:45:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A653A6D0A for ; Fri, 10 Apr 2009 13:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fOa2ZrJkEqYz for ; Fri, 10 Apr 2009 13:45:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 862CF3A6B8F for ; Fri, 10 Apr 2009 13:45:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,169,1238976000"; d="scan'208";a="169959046" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Apr 2009 20:46:28 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3AKkSue031087; Fri, 10 Apr 2009 13:46:28 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3AKkRwn027019; Fri, 10 Apr 2009 20:46:27 GMT From: Cullen Jennings To: "Narayanan, Vidya" In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: <28082191-0388-4F77-9B63-E6AA717480B0@cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 14:46:27 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1971; t=1239396388; x=1240260388; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Access=20control=20lists=20f or=20RELOAD=20storage |Sender:=20; bh=tentKH0RSj2JfS0HrxKVZezK+FT7w63wy0sWVOMMsnY=; b=Vf3MvWnxKV5MwCjJs/tlusCA++O6NaElgwHBSftLipw4jOH+VvQ1SQcGjk 4TMdoUPicg3V0tA6WsFkL2eZRUit1XOmFKZ7WaN7mcKkeHCFt2SgWZLP0KmP y95RKx9mUW; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Access control lists for RELOAD storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:45:20 -0000 As a generic concept, I like this and I'm sure there will be cases =20 where this will be useful but it's not needed for the P2P SIP =20 application and it is going to open up lots of interesting topics on =20 how to created ACLs. (I for one will argue more for RBAC instead of =20 classic ACL). So as an draft that is an extensions to the base, I'd =20 certainly be keen on this and see it as useful but I would argue it =20 should not go in the base draft - it's not needed for many =20 applications and it will take some time to get done. Cullen On Mar 26, 2009, at 6:57 PM, Narayanan, Vidya wrote: > At the moment, RELOAD defines some access control rules that allows =20= > authorization of a node/user to store at a particular location. =20 > However, only that node/user may modify or overwrite the data. It =20 > does not allow a mechanism to authorize other nodes or users to =20 > modify the data. I think it is very useful to also have provisions =20= > for authorizing other node ids or user names that can modify the =20 > data. As a simple use case for this, consider multiple members of a =20= > family being able to modify the mapping for the SIP AOR of their =20 > home phone. There are plenty of other cases as well where data =20 > created by one node may be modified by other authorized nodes. > > For this purpose, I think defining an ACL that is allowed to be =20 > stored with the data might be appropriate. The creator may specify =20= > a list of node ids or user names that are authorized to modify the =20 > data. > > We can discuss further on the actual solution options, but, I=92d =20 > first like to get feedback on the topic itself to see if people =20 > agree this is worth addressing. > > Thanks, > Vidya > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Sun Apr 12 19:24:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78833A6CBA for ; Sun, 12 Apr 2009 19:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 I1IgUTMOLoc5 for ; Sun, 12 Apr 2009 19:24:31 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id ABF003A6CAD for ; Sun, 12 Apr 2009 19:24:30 -0700 (PDT) Received: by bwz17 with SMTP id 17so1849861bwz.37 for ; Sun, 12 Apr 2009 19:25:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.203 with SMTP id d11mr1621328fas.22.1239589540225; Sun, 12 Apr 2009 19:25:40 -0700 (PDT) In-Reply-To: <49DF2F05.5080303@telecomitalia.it> References: <3CB2AC0B-BB62-461D-B156-8CF3DBD024A1@cs.columbia.edu> <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> <49DE7870.8090604@telecomitalia.it> <49DF2F05.5080303@telecomitalia.it> Date: Sun, 12 Apr 2009 22:25:40 -0400 Message-ID: From: Bruce Lowekamp To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 02:24:32 -0000 On Fri, Apr 10, 2009 at 7:35 AM, Enrico Marocco wrote: > Bruce Lowekamp wrote: >> My comment was that the reason 802.11 has reliability isn't the same >> as the reason we may or may not need reliability in an overlay link >> protocol. > > The reason why you may want to consider hop-by-hop reliability in RELOAD > is performance, just as in 802.11. > Sure, everything ultimately comes down to performance. But that's reduction to the absurd. Losses in wired networks mean there is congestion and the senders should slow down. Losses in wireless networks don't necessarily mean anything. There are certainly good reasons to consider overlay link level retransmissions. (IMHO the best is that most sessions are short, so the sender backing off means little.) But the issues need to be taken beyond "802.11 has it, so we should too." >> But in your example, the overlay link protocol having reliability >> doesn't solve the problem either, if your application is real-time >> communication. =C2=A0If the failure detection time is 1 minute, 8% of yo= ur >> queries are going to take an average of 30 seconds to complete >> (assuming they succeed on the second try). =C2=A0So you need to rely on >> another mechanism to try to complete the query more quickly. =C2=A0Wheth= er >> that is each hop replacing the failing peer in their routing table >> before they officially fail it and stop trying to re-establish (after >> 1 minute) or the querying peer trying alternative routes or replicas, >> you need to find an alternative route faster. > > Or each hop forking a parallel route right after a few retransmissions > of the same packet; that would take much longer if retransmissions were > end-to-end (i.e. rather than constant, the time overhead would grow > linearly with the _estimated_ path length). We've been avoiding having actual parallel forking used in the base draft. What I think we could include is a simple approach that if A is doing link-level retrans to B and believes it has failed, A should replace B in its routing table with the next-best match and let the fragment be retransed to the new entry. Meanwhile, continue trying to re-establish with B and bring it back if it's still alive. However, this type of approach would be incompatible with any pure tcp or tcp-over-udp overlay link layer. Bruce From bbl@lowekamp.net Sun Apr 12 19:52:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23A93A6CBA for ; Sun, 12 Apr 2009 19:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 azWfv+dCZm15 for ; Sun, 12 Apr 2009 19:52:48 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 89D5D3A69F6 for ; Sun, 12 Apr 2009 19:52:47 -0700 (PDT) Received: by fxm2 with SMTP id 2so1840958fxm.37 for ; Sun, 12 Apr 2009 19:53:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.103.194 with SMTP id l2mr1603798fao.55.1239591236928; Sun, 12 Apr 2009 19:53:56 -0700 (PDT) In-Reply-To: References: <533F6973-F3BC-4102-A7B8-8032F178C41A@cs.columbia.edu> <1A043B93-38D1-4636-8108-5448702605B8@cs.columbia.edu> <49DE7870.8090604@telecomitalia.it> <49DF2F05.5080303@telecomitalia.it> Date: Sun, 12 Apr 2009 22:53:56 -0400 Message-ID: From: Bruce Lowekamp To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 02:52:48 -0000 On Sun, Apr 12, 2009 at 10:25 PM, Bruce Lowekamp wrote: > On Fri, Apr 10, 2009 at 7:35 AM, Enrico Marocco > wrote: >> Bruce Lowekamp wrote: >>> My comment was that the reason 802.11 has reliability isn't the same >>> as the reason we may or may not need reliability in an overlay link >>> protocol. >> >> The reason why you may want to consider hop-by-hop reliability in RELOAD >> is performance, just as in 802.11. >> > > Sure, everything ultimately comes down to performance. =C2=A0But that's > reduction to the absurd. =C2=A0Losses in wired networks mean there is > congestion and the senders should slow down. =C2=A0Losses in wireless > networks don't necessarily mean anything. > > There are certainly good reasons to consider overlay link level > retransmissions. =C2=A0(IMHO the best is that most sessions are short, so > the sender backing off means little.) =C2=A0But the issues need to be tak= en > beyond "802.11 has it, so we should too." > >>> But in your example, the overlay link protocol having reliability >>> doesn't solve the problem either, if your application is real-time >>> communication. =C2=A0If the failure detection time is 1 minute, 8% of y= our >>> queries are going to take an average of 30 seconds to complete >>> (assuming they succeed on the second try). =C2=A0So you need to rely on >>> another mechanism to try to complete the query more quickly. =C2=A0Whet= her >>> that is each hop replacing the failing peer in their routing table >>> before they officially fail it and stop trying to re-establish (after >>> 1 minute) or the querying peer trying alternative routes or replicas, >>> you need to find an alternative route faster. >> >> Or each hop forking a parallel route right after a few retransmissions >> of the same packet; that would take much longer if retransmissions were >> end-to-end (i.e. rather than constant, the time overhead would grow >> linearly with the _estimated_ path length). > > We've been avoiding having actual parallel forking used in the base > draft. =C2=A0What I think we could include is a simple approach that if A > is doing link-level retrans to B and believes it has failed, A should > replace B in its routing table with the next-best match and let the > fragment be retransed to the new entry. =C2=A0Meanwhile, continue trying = to > re-establish with B and bring it back if it's still alive. > > However, this type of approach would be incompatible with any pure tcp > or tcp-over-udp overlay link layer. Actually, I retract that last statement. We already have acknowledgements over tcp since its timeout is too high, so as long as that value is equal to the point where you want to fallback to the next best entry for the routing table, it's fine. Bruce From hgs@cs.columbia.edu Mon Apr 13 06:37:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8573A6CBD for ; Mon, 13 Apr 2009 06:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 oDRVTuVofYQ2 for ; Mon, 13 Apr 2009 06:37:16 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 673033A6D3D for ; Mon, 13 Apr 2009 06:37:16 -0700 (PDT) Received: from Upstairs.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3DDcOpI008559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2009 09:38:24 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Sumit Garg In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F03140773@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 09:38:22 -0400 References: <49DE36C6.8030608@viagenie.ca><49DE4190.1030606@viagenie.ca><730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmail.com> <59184B4E920E854DA8ACF8E44917D49F03140773@MAIL02.cedarpointcom.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: Salman Abdul Baset , p2psip@ietf.org Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 13:37:17 -0000 Not sure what aspect your question refers to, but let me try two angles: - SCTP does not run over UDP, so it does not address the design constraint of having a protocol that does. This design constraint triggered this whole discussion. - SCTP is significantly more complicated than TCP in its implementation and its performance is generally the same, except in circumstances involving head-of-line blocking. (If you're interested, I can point you to some papers I've been involved with that explore this aspect in much greater quantitative detail.) That said, it has long been noted that SCTP will have trouble getting traction in the consumer and enterprise Internet space unless it (also) runs over UDP, as there seem to be few NATs that know how to handle SCTP and thus it is effectively unusable by a fair fraction of the Internet user population. Also, "converting" SCTP to use UDP is likely to be relatively easy, and similar to the mechanism proposed in the TCP-over-UDP draft. Tunneling is another approach, with a different set of trade-offs. Also, the goal is to design RELOAD so that it could indeed use SCTP as one of its transports in the future if there's demand for it. Henning On Apr 13, 2009, at 9:30 AM, Sumit Garg wrote: > Advantages as compared to SCTP?? > From hardie@qualcomm.com Mon Apr 13 09:14:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5336F3A6EB7 for ; Mon, 13 Apr 2009 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HjSHtgtMf-Yp for ; Mon, 13 Apr 2009 09:14:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 56A883A6EA5 for ; Mon, 13 Apr 2009 09:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1239639354; x=1271175354; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20<49DE36C6. 8030=0D=0A=20608@viagenie.ca><49DE4190.103060 6@viagenie.ca><730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmai =0D=0A=20l.com>=09=0D=0A=20<59184B4E920E854DA8ACF8E44917D49F 03140773@MAIL02.cedarpointcom.com>=0D=0A=20|Date:=20Mon,=201 3=20Apr=202009=2009:15:46=20-0700|To:=20Henning=20Schulzr inne=20,=0D=0A=20=20=20=20=20=20=20 =20Sumit=20Garg=0D=0A=09|From: =20Ted=20Hardie=20|Subject:=20Re:=20 [P2PSIP]=20TCP-over-UDP=20proposal|CC:=20Salman=20Abdul =20Baset=20,=0D=0A=20=20=20=20=20=20 =20=20"p2psip@ietf.org"=0D=0A=09 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5583"=3B=20 a=3D"17076536"; bh=LFbArmSYMZkbG1g83lmQsv830yH23fYoJ6WC1n2SPkg=; b=dhVeIdhsjjYVimIumnN9LEEvbRwa6XhAKjT4q6jqJS5BJkMikDPy19Cj ipdSoPmlW3YAT7lDDS6Fs5Kq6GbR8etnW0ev7fX+/YOmvsHjBQK0/gk6r rpo0JvaxtuS3BL+QFUAeb3VbKmLlswbQP6wFZI8UjDzFhAHTVM9VgQvd3 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5583"; a="17076536" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2009 09:15:54 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3DGFrmO003881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Apr 2009 09:15:54 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3DGFnDT011753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Apr 2009 09:15:49 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 13 Apr 2009 09:15:48 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 13 Apr 2009 09:15:48 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <49DE36C6.8030 608@viagenie.ca><49DE4190.1030606@viagenie.ca><730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmai l.com> <59184B4E920E854DA8ACF8E44917D49F03140773@MAIL02.cedarpointcom.com> Date: Mon, 13 Apr 2009 09:15:46 -0700 To: Henning Schulzrinne , Sumit Garg From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:14:44 -0000 >At 6:38 AM -0700 4/13/09, Henning Schulzrinne wrote: >Also, "converting" SCTP to use UDP is likely to be relatively easy, >and similar to the mechanism proposed in the TCP-over-UDP draft. >Tunneling is another approach, with a different set of trade-offs. For the tunnel version, are you thinking of this work: http://www.ietf.org/proceedings/00jul/I-D/sigtran-sctptunnel-00.txt or something else? >Also, the goal is to design RELOAD so that it could indeed use SCTP as >one of its transports in the future if there's demand for it. I thought that RFC 4168 laid out some decent reasons why you might prefer SCTP to some of the other choices, but the big question seems to be: Does anyone involved have enough pull with NAT vendors to get it recognized so it can be deployed? Without that, we seem to be stuck. What amazes me is that we're busily considering NATs for v6, despite this sort of thing. Ted >Henning > >On Apr 13, 2009, at 9:30 AM, Sumit Garg wrote: > >> Advantages as compared to SCTP?? >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip From hgs@cs.columbia.edu Mon Apr 13 09:47:46 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5C83A6818 for ; Mon, 13 Apr 2009 09:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 APHxs5Na5fyG for ; Mon, 13 Apr 2009 09:47:46 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 0E1473A68B8 for ; Mon, 13 Apr 2009 09:47:45 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3DGmcgd007427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2009 12:48:38 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 12:48:39 -0400 References: <49DE36C6.8030 608@viagenie.ca><49DE4190.1030606@viagenie.ca><730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmai l.com> <59184B4E920E854DA8ACF8E44917D49F03140773@MAIL02.cedarpointcom.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:47:47 -0000 On Apr 13, 2009, at 12:15 PM, Ted Hardie wrote: >> At 6:38 AM -0700 4/13/09, Henning Schulzrinne wrote: >> Also, "converting" SCTP to use UDP is likely to be relatively easy, >> and similar to the mechanism proposed in the TCP-over-UDP draft. >> Tunneling is another approach, with a different set of trade-offs. > > For the tunnel version, are you thinking of this work: > > http://www.ietf.org/proceedings/00jul/I-D/sigtran-sctptunnel-00.txt > > or something else? Indeed, that's one easy option. Not sure what the liveness status of this draft is. Given the simplicity, I wonder why it hasn't gone anywhere since March 2000. (For what it's worth, the same document could be written for TCP as well. I'm completely agnostic as to whether the ToU proposal or tunneling is a better choice. There are some minor trade-offs in terms of port allocation and header overhead, but they are pretty trivial.) > > > >> Also, the goal is to design RELOAD so that it could indeed use SCTP >> as >> one of its transports in the future if there's demand for it. > > I thought that RFC 4168 laid out some decent reasons why you might > prefer SCTP to some of the other choices, but the big question seems > to be: > > Does anyone involved have enough pull with NAT vendors to get it > recognized so it can be deployed? > > Without that, we seem to be stuck. What amazes me is that > we're busily considering NATs for v6, despite this sort of thing. Right, but that's probably a bit beyond the pay grade of this working group to fix... > > > Ted From dean.willis@softarmor.com Mon Apr 13 15:31:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817B23A6EDA for ; Mon, 13 Apr 2009 15:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 DOQhmo3ruKZ0 for ; Mon, 13 Apr 2009 15:31:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AC3D928C182 for ; Mon, 13 Apr 2009 15:30:55 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3DMVvi0006061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2009 17:31:58 -0500 Message-Id: From: Dean Willis To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 17:31:51 -0500 References: <49DE36C6.8030 608@viagenie.ca><49DE4190.1030606@viagenie.ca><730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmai l.com> <59184B4E920E854DA8ACF8E44917D49F03140773@MAIL02.cedarpointcom.com> X-Mailer: Apple Mail (2.930.3) Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 22:31:08 -0000 On Apr 13, 2009, at 11:15 AM, Ted Hardie wrote: > Does anyone involved have enough pull with NAT vendors to get it > recognized so it can be deployed? By definition, no. The vast majority of residential/soho NATS currently in-use are effectively not upgradeable; the support contract for their firmware between the "brand" vendor and the actual manufacturer lapsed years ago, and as a consequence, their software isn't being updated. Ever again. I personally own a dozen or so devices in this category, from brands like Linksys, Netgear, Apple, D- Link, and others. The only reason anybody can consider IPv6 NAT support as an option is that we figure everybody that wants v6 is going to have to buy a new NATrouter anyhow. Of course, 1) that's a major barrier to v6 deployment in general, and 2) there's effectively only a six-month window to get new features into that generation of products before it too is frozen by aging in the installed base. -- Dean From BeckW@telekom.de Tue Apr 14 04:48:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9B93A67E6 for ; Tue, 14 Apr 2009 04:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 0o2NBlNU7AjP for ; Tue, 14 Apr 2009 04:48:06 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 9D3D53A67CC for ; Tue, 14 Apr 2009 04:48:05 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 14 Apr 2009 13:49:16 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 13:49:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Apr 2009 13:49:14 +0200 Message-ID: <4A956CE47D1066408D5C7EB34368A511043C9783@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] TCP-over-UDP proposal Thread-Index: Acm8PSUJj4VjNDsRROeWjjx/aHsG7QAtfDiA References: <49DE36C6.8030608@viagenie.ca><49DE4190.1030606@viagenie.ca><730EE623-697E-4E2A-8FF5-AB3C4C6ABCBA@gmail.com><59184B4E920E854DA8ACF8E44917D49F03140773@MAIL02.cedarpointcom.com> From: To: , X-OriginalArrivalTime: 14 Apr 2009 11:49:16.0161 (UTC) FILETIME=[09A65710:01C9BCF7] Cc: sa2086@columbia.edu Subject: Re: [P2PSIP] TCP-over-UDP proposal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 11:48:07 -0000 =20 Henning wrote > As we learned from SCTP, getting the first implementations of a =20 > conceptually new protocol right is non-trivial. The goal would be to =20 > have somebody build a library, so that most application writers don't > have to worry about getting RTO estimation right, dealing with window > adjustments and all the other details that any non-toy transport =20 > protocol needs. Thus, generality is an advantage, as it encourages =20 > library building. Having done a user space implementation of TCP some years ago, I'd say that it is easy to get it running, but hard to get a really good TCP with decent throughput. Re-transmission tends to hide your bugs. Modern TCP implementations use a number of optimizations that are not documented in RfCs.=20 As a user-space TCP needs timers, the networking code will be more complicated than ordinary socket code.=20 Many OSes started with a BSD TCP stack and ran into unexpected difficulties when they tried to replace it with a home-grown solution.=20 TCP-over-UDP is not exactly a lightweight solution.. Wolfgang From BeckW@telekom.de Wed Apr 15 01:06:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9FF23A6B46; Wed, 15 Apr 2009 01:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 WSO6-laIdbhF; Wed, 15 Apr 2009 01:06:50 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 6B9163A6A96; Wed, 15 Apr 2009 01:06:49 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 15 Apr 2009 10:08:00 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 10:08:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 10:07:59 +0200 Message-ID: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [P2PSIP] Comments on draft-baset-tsvwg-tcp-over-udp-00 Thread-Index: Acm5ODXziTlh83yyQ+eRm/Fx+6QCtwEZX4Ow References: From: To: , X-OriginalArrivalTime: 15 Apr 2009 08:08:00.0488 (UTC) FILETIME=[4B252680:01C9BDA1] Cc: tsvwg@ietf.org Subject: Re: [P2PSIP] Comments on draft-baset-tsvwg-tcp-over-udp-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 08:06:51 -0000 =20 The figure in seection 2 describes ToU as a library. This is desirable for quick adoption, but is basically an implementation detail. The socket-like API in section 5 is of limited use if you want to mix ordinary file descriptors and libraries with ToU sockets (eg gtk_input_add, or Qt's QSocketNotifier). DLL trickeries might give better results. The draft doesn't discuss any timing constraints that a library implementer would have to meet: is it enough to check timers on every tou_ call? Or do I need a background thread? What information needs to be shared among several applications using ToU, like ISN and TCBs? Is this even possible if applications on a single system use different ToU libraries? (should this draft be discussed in p2psip or tsvwg?) Wolfgang From sa2086@columbia.edu Wed Apr 15 07:43:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB59E28C242 for ; Wed, 15 Apr 2009 07:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9hSj6Jb36KY for ; Wed, 15 Apr 2009 07:43:03 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id E703728C239 for ; Wed, 15 Apr 2009 07:43:01 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3FEiCbA006240; Wed, 15 Apr 2009 10:44:13 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3FEiCD0022726; Wed, 15 Apr 2009 10:44:12 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n3FEiBFp022723; Wed, 15 Apr 2009 10:44:12 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 15 Apr 2009 10:44:11 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: BeckW@telekom.de In-Reply-To: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> Message-ID: References: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Comments on draft-baset-tsvwg-tcp-over-udp-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:43:04 -0000 On Wed, 15 Apr 2009, BeckW@telekom.de wrote: > > The figure in seection 2 describes ToU as a library. This is desirable > for quick adoption, but is basically an implementation detail. Indeed. > The socket-like API in section 5 is of limited use if you want to mix > ordinary file descriptors and libraries with ToU sockets (eg > gtk_input_add, or Qt's QSocketNotifier). DLL trickeries might give > better results. Right. The socket-like API was merely intended as a reference. > The draft doesn't discuss any timing constraints that a library > implementer would have to meet: is it enough to check timers on every > tou_ call? Or do I need a background thread? This is an implementation choice: both timers on a tou_call or a background thread will work. > What information needs to be shared among several applications using > ToU, like ISN and TCBs? Is this even possible if applications on a > single system use different ToU libraries? As long as the underlying OS does not support ToU, applications on a single system may use multiple ToU libraries. > (should this draft be discussed in p2psip or tsvwg?) Yes. We presented this straw man version on p2psip mailing list since this WG is currently the biggest customer of ToU. We are planning to update the draft with the comments gathered so far, and present it to tsvwg. -s From fluffy@cisco.com Wed Apr 15 10:04:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6203A6ACB; Wed, 15 Apr 2009 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 RsTMo0gsFoHV; Wed, 15 Apr 2009 10:04:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 668D53A6975; Wed, 15 Apr 2009 10:04:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="171993542" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2009 17:05:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3FH5CO6017518; Wed, 15 Apr 2009 10:05:12 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FH5B6A015941; Wed, 15 Apr 2009 17:05:12 GMT From: Cullen Jennings To: "" In-Reply-To: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> Impp: xmpp:cullenfluffyjennings@jabber.org References: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> Message-Id: <9E9E3463-AE80-496E-ACAE-C7B17AD9AAF4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 11:05:10 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=153; t=1239815112; x=1240679112; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Tsvwg]=20[P2PSIP]=20Comments=20on=20dr aft-baset-tsvwg-tcp-over-udp-00 |Sender:=20; bh=U3ineUpXK9wailAkeS+nA1BSt8pDOlymA+qK6nbcUPo=; b=ID4wOwe4IjAxlpnpIDvGK2fLEkKauSjoDQbxokN84ERNYhPNFHXobVf77Y R1fPp5jvbIGpprOc9DR80H2r/NSH3E1WPT4pY3m8ZiexrALaRE/P8PQRxeSc bOhafPnEGm; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sa2086@columbia.edu, p2psip@ietf.org, tsvwg@ietf.org Subject: Re: [P2PSIP] [Tsvwg] Comments on draft-baset-tsvwg-tcp-over-udp-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:04:07 -0000 On Apr 15, 2009, at 2:07 AM, wrote: > > (should this draft be discussed in p2psip or tsvwg?) > tsvwg From vidyan@qualcomm.com Thu Apr 16 10:44:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9723A6816 for ; Thu, 16 Apr 2009 10:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.071 X-Spam-Level: X-Spam-Status: No, score=-105.071 tagged_above=-999 required=5 tests=[AWL=1.528, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 6qFBDbi8TwUc for ; Thu, 16 Apr 2009 10:44:51 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2B9963A67B7 for ; Thu, 16 Apr 2009 10:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1239903964; x=1271439964; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Cullen=20Jennings=20|CC:=20"p2psip@i etf.org"=20|Date:=20Thu,=2016=20Apr=2020 09=2010:45:59=20-0700|Subject:=20RE:=20[P2PSIP]=20Access =20control=20rule=20in=20RELOAD=20to=20support=20generic =0D=0A=20keyword-like=20storage|Thread-Topic:=20[P2PSIP] =20Access=20control=20rule=20in=20RELOAD=20to=20support =20generic=0D=0A=20keyword-like=20storage|Thread-Index: =20Acm6G+lVdXOAREs4Tf2SLT4FH5N6fAEncxOw|Message-ID:=20|References:=20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5586"=3B=20a=3D"17192624"; bh=qSlHMD4QtNp3eGCHYKcFqWzMZC6ghdSO+5x/tChFwiU=; b=H2lob/sNJ8NoM55Urt7Yw1XWTnFAnVwWFsLu3AsPBXitKd1DHp0bCQLM WO9e9G3wbrac7IzGsEYrDRlDuX3kyzVEP//Ixdx31D8NQ+Jx0oFc3cgNi 8QXIsf4msJlCgyaHfzq/c2aaYnTr0jLB/8VT9BS6hT7EhcHHHXUVA5BUU 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5586"; a="17192624" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2009 10:46:04 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3GHk3wV002102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 10:46:04 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3GHk3xW030640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Apr 2009 10:46:03 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 10:46:03 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Thu, 16 Apr 2009 10:46:02 -0700 From: "Narayanan, Vidya" To: Cullen Jennings Date: Thu, 16 Apr 2009 10:45:59 -0700 Thread-Topic: [P2PSIP] Access control rule in RELOAD to support generic keyword-like storage Thread-Index: Acm6G+lVdXOAREs4Tf2SLT4FH5N6fAEncxOw Message-ID: References: In-Reply-To: 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 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic keyword-like storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:44:52 -0000 Cullen, I'm okay going with option b you mention below. I think disambiguating nod= e and user ids might be useful. And, I don't think it is unreasonable to l= imit future updates to using the same id that was used at the time of creat= ion. Cheers, Vidya=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, April 10, 2009 1:34 PM > To: Narayanan, Vidya > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic > keyword-like storage >=20 >=20 > Vidya, I like this and think we should add it to the draft but one > question. I worry about it being a bit vague of it if is a > certificate with same user id or node id that is allowed to do an > update. I think we need to do one of two things >=20 > a) define this so the nodeid and userid are stored and a certificate > that matches either the nodeid or userid is allowed ot update >=20 > b) define two new rules here, one that requires the node-id to match > and ones that requires the userid to match. So we would have something > like > NO-MATCH-CREATE-WITH-RESTRICTED-NODE-UDPATE > and > NO-MATCH-CREATE-WITH-RESTRICTED-USER-UDPATE >=20 > I'd probably prefer approach b to aproach a but don't feel strongly > either way. >=20 > Thougths? >=20 > Cullen, in my individual contrubotro role >=20 >=20 > On Mar 22, 2009, at 8:31 PM, Narayanan, Vidya wrote: >=20 > > In addition to the access control rules defined in section 6.3 of > > the draft, I think there is a need for a rule, where any node is > > allowed to write to a Resource ID, but, only the creator is allowed > > to modify or overwrite the entry by default. This allows for > > generic keyword-like storage on the overlay which will eventually be > > needed to support various types of kinds and usages on the overlay > > effectively. The notion here is that no authorization is needed on > > the Resource ID, but access control is applied to the data > > operations, once it exists. Here is suggestive text for supporting > > this: > > > > "6.3.6. NO-MATCH-CREATE-WITH-RESTRICTED-UDPATE > > > > This policy allows storage of data with no constraints on choosing a > > Resource ID. However, by default, only the creator of the entry is > > allowed to modify or overwrite the stored data once created. The > > user name and/or node id present in the certificate of the > > requesting node MUST be used as the creator of the data. Upon > > receiving a request to store, a node MUST verify if it already has > > an entry present for the particular kind and Resource ID > > corresponding to the same user name or node id that is contained in > > the Store Request. If so, the received Store Request MUST be > > treated as an update to the existing data and the appropriate checks > > as described in section 6.4 must be applied. If no corresponding > > match is found, the StoredData contained in the Store Request > > message MUST be stored as a new entry in accordance with section > > 6.4. This rule is useful for generic keyword-like storage on the > > overlay, which is likely to be useful for several classes of > > applications that may b > > e defined for use with RELOAD. The access control allows ensuring > > that the data created by a given node is not randomly overwritten by > > any other node." > > > > It may be good to include the Resource Name in the StoredData > > structure as well. This will allow the storing node to more easily > > create an index of the resources it is storing, which can then be > > used for retrieval of data. However, I think it will work even > > without it - I'm looking for other thoughts on this. > > > > Thanks, > > Vidya > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip From vidyan@qualcomm.com Thu Apr 16 17:47:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8CA3A67D2 for ; Thu, 16 Apr 2009 17:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.822 X-Spam-Level: X-Spam-Status: No, score=-104.822 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Mdf-N07G7Xfr for ; Thu, 16 Apr 2009 17:47:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0ABFF3A6831 for ; Thu, 16 Apr 2009 17:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1239929296; x=1271465296; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Cullen=20Jennings=20|CC:=20"p2psip@i etf.org"=20|Date:=20Thu,=2016=20Apr=2020 09=2017:48:09=20-0700|Subject:=20RE:=20[P2PSIP]=20Access =20control=20lists=20for=20RELOAD=20storage|Thread-Topic: =20[P2PSIP]=20Access=20control=20lists=20for=20RELOAD=20s torage|Thread-Index:=20Acm6HZkSi08NDd2BQE2r3YF1esFX3gEoNK aw|Message-ID:=20|References:=20=0D=0A=20<28082191-0388-4F77-9B63-E6AA717480B0@cisco.com >|In-Reply-To:=20<28082191-0388-4F77-9B63-E6AA717480B0@ci sco.com>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5586"=3B=20a=3D"17206030"; bh=zrlIRLH2RU83z/Fv4WpLaNeUfD1GH+UE8EVwFOnnVmI=; b=KmowAjvWF9+5Rh3z7fooaCgSi3dLsw5+AdzlGJjr5QOEUh4lVEqfIbji 6Wscm/k1/ZCnmjDstsK/Rvbaf/lvt35wUZHAzL3yPP1WomViMpavRbMHs 6ADyeM8nS4DC4DKpYrvtrAs+lomom077F+qVg05BSKAFcWelMXBuq04Oo 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5586"; a="17206030" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2009 17:48:16 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3H0mFYS014483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Apr 2009 17:48:16 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3H0mE6p012707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Apr 2009 17:48:15 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 17:48:14 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 16 Apr 2009 17:48:13 -0700 From: "Narayanan, Vidya" To: Cullen Jennings Date: Thu, 16 Apr 2009 17:48:09 -0700 Thread-Topic: [P2PSIP] Access control lists for RELOAD storage Thread-Index: Acm6HZkSi08NDd2BQE2r3YF1esFX3gEoNKaw Message-ID: References: <28082191-0388-4F77-9B63-E6AA717480B0@cisco.com> In-Reply-To: <28082191-0388-4F77-9B63-E6AA717480B0@cisco.com> 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 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Access control lists for RELOAD storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:47:04 -0000 I do think this functionality is useful even for P2P SIP applications (perh= aps not for the exact SIP usage we define first), but, I'd be okay with spe= cifying this in a separate document. However, when we do specify that, we = will be potentially going through an exercise of revisiting our authorizati= on design and that's the main reason I'd like us to spend a bit of time thi= nking about it at this stage. Whether we use RBAC or classic ACLs, when an= authorized user/node updates data that is stored previously by a different= creator, it will no longer match the h(user id) or h(node id) requirement = and that should intentionally be allowed.=20 This can be done, but, there are still a couple of non-trivial questions he= re. Is there a primary user/node that applications need to use as the resou= rce names? What happens when there is no such obvious primary user/node? = Especially in the context of RBAC, it gets more complex than that - since y= ou are assigning access to roles and mapping users/nodes to various roles, = authorization needs to happen against the role and not against the user id = specifically. And it also brings the question of who defines the roles (an= d no, it can't be the enrollment server :)) - the roles may be specific to = usages and I can't immediately see how it can universally apply to all over= lay nodes and kinds supported. =20 RBAC is arguably more useful for supporting groups, but, it is unclear to m= e that there is an advantage or even a straightforward applicability for no= rmal overlay storage authorization. =20 I'm concerned that going down a path for authorization now that might limit= definition of ACLs later might be a problem. I'm willing to keep the docu= ments separate for simplicity, but would like to have a better indication t= hat we are going down the right direction to add this capability later.=20 Cheers, Vidya > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, April 10, 2009 1:46 PM > To: Narayanan, Vidya > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Access control lists for RELOAD storage >=20 >=20 > As a generic concept, I like this and I'm sure there will be cases > where this will be useful but it's not needed for the P2P SIP > application and it is going to open up lots of interesting topics on > how to created ACLs. (I for one will argue more for RBAC instead of > classic ACL). So as an draft that is an extensions to the base, I'd > certainly be keen on this and see it as useful but I would argue it > should not go in the base draft - it's not needed for many > applications and it will take some time to get done. >=20 > Cullen >=20 > On Mar 26, 2009, at 6:57 PM, Narayanan, Vidya wrote: >=20 > > At the moment, RELOAD defines some access control rules that allows > > authorization of a node/user to store at a particular location. > > However, only that node/user may modify or overwrite the data. It > > does not allow a mechanism to authorize other nodes or users to > > modify the data. I think it is very useful to also have provisions > > for authorizing other node ids or user names that can modify the > > data. As a simple use case for this, consider multiple members of a > > family being able to modify the mapping for the SIP AOR of their > > home phone. There are plenty of other cases as well where data > > created by one node may be modified by other authorized nodes. > > > > For this purpose, I think defining an ACL that is allowed to be > > stored with the data might be appropriate. The creator may specify > > a list of node ids or user names that are authorized to modify the > > data. > > > > We can discuss further on the actual solution options, but, I'd > > first like to get feedback on the topic itself to see if people > > agree this is worth addressing. > > > > Thanks, > > Vidya > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip From gonzalo.camarillo@ericsson.com Fri Apr 17 05:44:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C141328C165 for ; Fri, 17 Apr 2009 05:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 uGdVK6f7XPAx for ; Fri, 17 Apr 2009 05:44:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E13CA28C127 for ; Fri, 17 Apr 2009 05:44:35 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31C0124B86; Fri, 17 Apr 2009 14:45:47 +0200 (CEST) X-AuditID: c1b4fb3e-ab01dbb0000024d5-f6-49e860bda13a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E5F4824B9A; Fri, 17 Apr 2009 12:58:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 12:57:58 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 12:57:58 +0200 Message-ID: <49E860B6.3040105@ericsson.com> Date: Fri, 17 Apr 2009 13:57:58 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Cullen Jennings References: <499FB831.80809@ericsson.com> <3647843D-53CE-4E07-AC84-3E0120FC136E@cisco.com> In-Reply-To: <3647843D-53CE-4E07-AC84-3E0120FC136E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2009 10:57:58.0750 (UTC) FILETIME=[5E9BEFE0:01C9BF4B] X-Brightmail-Tracker: AAAAAA== Cc: "iab@iab.org IAB" , P2PSIP Mailing List Subject: Re: [P2PSIP] Draft on P2P architectures X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 12:44:36 -0000 Hi Cullen, thanks for your comments. That is a good point. I have now added a discussion on incentives to Section 6. Thanks, Gonzalo Cullen Jennings wrote: > > This is great - thank you writing it. > > One topic that might help improve the draft is discussing incentives for > peers. Most the successful P2P systems I can think of have put a bunch > of thought into the incentives for peers to to things for other peers. > When trying to decide if p2p is a good architecture for a given > application, it's critical to think about "what are the incentives" > > Cullen > > > On Feb 21, 2009, at 24:15 , Gonzalo Camarillo wrote: > >> Folks, >> >> the IAB has just submitted the following draft: >> >> http://www.ietf.org/internet-drafts/draft-iab-p2p-archs-00.txt >> >> Comments from people involved in this WG are especially appreciated. >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > From hishigh@gmail.com Sun Apr 19 19:31:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E973A67D2 for ; Sun, 19 Apr 2009 19:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.649, 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 2AjyOlvjqFBq for ; Sun, 19 Apr 2009 19:31:13 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 8FA2C3A6B23 for ; Sun, 19 Apr 2009 19:30:31 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 31so1414405yxl.49 for ; Sun, 19 Apr 2009 19:30:57 -0700 (PDT) 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=luayLdIzgpsTeNoiZWIuhm9DAtxBwXf00wFt0r/riJQ=; b=gLpRNHqsgkiLQFJ9NL5+R4LO3Sf0lgT1t3HZiT+Pb6CCakuoaYCyprIe6RtP+AoOLO 63fig77fMjJNj2N0ZnDafkCXDCJsMM3ByPw1VQjnc92U+o38wkVQcIN4Q+upYHKoSbMK C9xp19/yNJGA5ggoWng7Gz5KDvexH4pFhQovM= 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=c2UPfBvs0a8m9zdANxUIYgtX3QfLyIXB30XLWhqJ5cqR6PLZRC6bcJ0FicytwkV3WS BKXXI/n+zPqh//iVSj82Cp4FFSlCika1gSM1arHW/pB4mlN2Pmlhr3D2p/dzYuC9pO/z PDEifH8bvomZvGcDR7IriCRRUEH28ucE0kswc= MIME-Version: 1.0 Received: by 10.150.211.4 with SMTP id j4mr6363574ybg.128.1240194582234; Sun, 19 Apr 2009 19:29:42 -0700 (PDT) In-Reply-To: <49E860B6.3040105@ericsson.com> References: <499FB831.80809@ericsson.com> <3647843D-53CE-4E07-AC84-3E0120FC136E@cisco.com> <49E860B6.3040105@ericsson.com> Date: Mon, 20 Apr 2009 10:29:42 +0800 Message-ID: <8bd755250904191929n621a8116tc9d96111f07030a4@mail.gmail.com> From: yunfei zhang To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=000e0cd4865086c5a60467f34db2 Cc: "iab@iab.org IAB" , P2PSIP Mailing List Subject: Re: [P2PSIP] Draft on P2P architectures X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 02:31:13 -0000 --000e0cd4865086c5a60467f34db2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,Gonzalo, PPSP(p2p streaming protocol) drafts http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-01.txt also provides some incentive for streaming peers.It will be great and we are happy if PPSP can provide more incentives for a good p2p architecuture. Yunfei 2009/4/17, Gonzalo Camarillo : > > Hi Cullen, > > thanks for your comments. That is a good point. I have now added a > discussion on incentives to Section 6. > > Thanks, > > Gonzalo > > Cullen Jennings wrote: > >> >> This is great - thank you writing it. >> >> One topic that might help improve the draft is discussing incentives for >> peers. Most the successful P2P systems I can think of have put a bunch of >> thought into the incentives for peers to to things for other peers. When >> trying to decide if p2p is a good architecture for a given application, it's >> critical to think about "what are the incentives" >> >> Cullen >> >> >> On Feb 21, 2009, at 24:15 , Gonzalo Camarillo wrote: >> >> Folks, >>> >>> the IAB has just submitted the following draft: >>> >>> http://www.ietf.org/internet-drafts/draft-iab-p2p-archs-00.txt >>> >>> Comments from people involved in this WG are especially appreciated. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --000e0cd4865086c5a60467f34db2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,Gonzalo,
PPSP(p2p streaming=A0protocol)=A0drafts http://www.ietf= .org/internet-drafts/draft-zhang-ppsp-problem-statement-01.txt=A0also p= rovides some incentive for streaming peers.It will be great and we are happ= y=A0if PPSP can provide more incentives for a good p2p architecuture.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yunfei
=A0
2009/4/17, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>:
Hi Cullen,

thanks for you= r comments. That is a good point. I have now added a discussion on incentiv= es to Section 6.

Thanks,

Gonzalo

Cullen Jennings wrote:

This is great - =A0thank you= writing it.

One topic that might help improve the draft is discussi= ng incentives for peers. Most the successful P2P systems I can think of hav= e put a bunch of thought into the incentives for peers to to things for oth= er peers. When trying to decide if p2p is a good architecture for a given a= pplication, it's critical to think about "what are the incentives&= quot;

Cullen <in my individual contributor role>


On Feb 21, = 2009, at 24:15 , Gonzalo Camarillo wrote:

Folks,

the IAB has just s= ubmitted the following draft:

http://www.ietf.org/internet-drafts/dr= aft-iab-p2p-archs-00.txt

Comments from people involved in this WG are especially appreciated.
Thanks,

Gonzalo

________________________________________= _______
P2PSIP mailing list
P2PSIP= @ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip



___= ____________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.= ietf.org/mailman/listinfo/p2psip

--000e0cd4865086c5a60467f34db2-- From hishigh@gmail.com Sun Apr 19 19:34:42 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C02C3A6CEB for ; Sun, 19 Apr 2009 19:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.649, 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 C6JXG9R-0ILY for ; Sun, 19 Apr 2009 19:34:42 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 000833A6B23 for ; Sun, 19 Apr 2009 19:34:41 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so2756569ywh.49 for ; Sun, 19 Apr 2009 19:35:57 -0700 (PDT) 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=luayLdIzgpsTeNoiZWIuhm9DAtxBwXf00wFt0r/riJQ=; b=gLpRNHqsgkiLQFJ9NL5+R4LO3Sf0lgT1t3HZiT+Pb6CCakuoaYCyprIe6RtP+AoOLO 63fig77fMjJNj2N0ZnDafkCXDCJsMM3ByPw1VQjnc92U+o38wkVQcIN4Q+upYHKoSbMK C9xp19/yNJGA5ggoWng7Gz5KDvexH4pFhQovM= 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=c2UPfBvs0a8m9zdANxUIYgtX3QfLyIXB30XLWhqJ5cqR6PLZRC6bcJ0FicytwkV3WS BKXXI/n+zPqh//iVSj82Cp4FFSlCika1gSM1arHW/pB4mlN2Pmlhr3D2p/dzYuC9pO/z PDEifH8bvomZvGcDR7IriCRRUEH28ucE0kswc= MIME-Version: 1.0 Received: by 10.150.211.4 with SMTP id j4mr6363574ybg.128.1240194582234; Sun, 19 Apr 2009 19:29:42 -0700 (PDT) In-Reply-To: <49E860B6.3040105@ericsson.com> References: <499FB831.80809@ericsson.com> <3647843D-53CE-4E07-AC84-3E0120FC136E@cisco.com> <49E860B6.3040105@ericsson.com> Date: Mon, 20 Apr 2009 10:29:42 +0800 Message-ID: <8bd755250904191929n621a8116tc9d96111f07030a4@mail.gmail.com> From: yunfei zhang To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=000e0cd4865086c5a60467f34db2 Cc: "iab@iab.org IAB" , P2PSIP Mailing List Subject: Re: [P2PSIP] Draft on P2P architectures X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 02:34:42 -0000 --000e0cd4865086c5a60467f34db2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,Gonzalo, PPSP(p2p streaming protocol) drafts http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-01.txt also provides some incentive for streaming peers.It will be great and we are happy if PPSP can provide more incentives for a good p2p architecuture. Yunfei 2009/4/17, Gonzalo Camarillo : > > Hi Cullen, > > thanks for your comments. That is a good point. I have now added a > discussion on incentives to Section 6. > > Thanks, > > Gonzalo > > Cullen Jennings wrote: > >> >> This is great - thank you writing it. >> >> One topic that might help improve the draft is discussing incentives for >> peers. Most the successful P2P systems I can think of have put a bunch of >> thought into the incentives for peers to to things for other peers. When >> trying to decide if p2p is a good architecture for a given application, it's >> critical to think about "what are the incentives" >> >> Cullen >> >> >> On Feb 21, 2009, at 24:15 , Gonzalo Camarillo wrote: >> >> Folks, >>> >>> the IAB has just submitted the following draft: >>> >>> http://www.ietf.org/internet-drafts/draft-iab-p2p-archs-00.txt >>> >>> Comments from people involved in this WG are especially appreciated. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --000e0cd4865086c5a60467f34db2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,Gonzalo,
PPSP(p2p streaming=A0protocol)=A0drafts http://www.ietf= .org/internet-drafts/draft-zhang-ppsp-problem-statement-01.txt=A0also p= rovides some incentive for streaming peers.It will be great and we are happ= y=A0if PPSP can provide more incentives for a good p2p architecuture.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yunfei
=A0
2009/4/17, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>:
Hi Cullen,

thanks for you= r comments. That is a good point. I have now added a discussion on incentiv= es to Section 6.

Thanks,

Gonzalo

Cullen Jennings wrote:

This is great - =A0thank you= writing it.

One topic that might help improve the draft is discussi= ng incentives for peers. Most the successful P2P systems I can think of hav= e put a bunch of thought into the incentives for peers to to things for oth= er peers. When trying to decide if p2p is a good architecture for a given a= pplication, it's critical to think about "what are the incentives&= quot;

Cullen <in my individual contributor role>


On Feb 21, = 2009, at 24:15 , Gonzalo Camarillo wrote:

Folks,

the IAB has just s= ubmitted the following draft:

http://www.ietf.org/internet-drafts/dr= aft-iab-p2p-archs-00.txt

Comments from people involved in this WG are especially appreciated.
Thanks,

Gonzalo

________________________________________= _______
P2PSIP mailing list
P2PSIP= @ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip



___= ____________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.= ietf.org/mailman/listinfo/p2psip

--000e0cd4865086c5a60467f34db2-- From fluffy@cisco.com Mon Apr 27 06:39:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE4D3A6B3A for ; Mon, 27 Apr 2009 06:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 PXG5QF1CNZIp for ; Mon, 27 Apr 2009 06:39:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 275B33A6A4E for ; Mon, 27 Apr 2009 06:39:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,254,1238976000"; d="scan'208";a="293596270" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 13:40:38 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3RDecgo030621; Mon, 27 Apr 2009 06:40:38 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3RDebfe009065; Mon, 27 Apr 2009 13:40:37 GMT From: Cullen Jennings To: Anthony D Pike In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org X-Priority: 3 (Normal) References: Message-Id: <63C68514-4465-4300-8A56-257ED64422F0@cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 07:40:36 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1007; t=1240839638; x=1241703638; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20draft-ietf-p2psip-base-02.tx t |Sender:=20; bh=Oyffm68kL5CZRqJFfIoNpYzbQ0Tc0WIkncEKrmFjrbo=; b=AVcIZdRK9kf4Ya8EkCTOxDxlcbg9FNdjDJzQkTi6qB84lHewAukC1ppN3Z xnG6xj87E78cDpAJhjaHD5Uib/PhluLR5ncJhfh0iJbHM5X86vMekSxTkavE uLMrfC7yTC; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] draft-ietf-p2psip-base-02.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:39:18 -0000 Good point - thanks - I put in a reference to 5201 that will show up =20 in the next version. On Mar 27, 2009, at 3:00 PM, Anthony D Pike wrote: > Note to the Editor of draft-ietf-p2psip-base-02.txt, > > section 5.6.1 future support for HIP > > I presume this is RFC 5201, buts thats my assumption, please could =20 > you add a reference in the refernce section in the next rev to HIP. > > Thanks Tony Pike > > This is a PRIVATE message. If you are not the intended recipient, =20 > please delete without copying and kindly advise us by e-mail of the =20= > mistake in delivery. > NOTE: Regardless of content, this e-mail shall not operate to bind =20 > CSC to any order or other contract unless pursuant to explicit =20 > written agreement or government initiative expressly permitting the =20= > use of e-mail for such purpose. =95 > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From kundansingh_99@yahoo.com Wed Apr 29 14:11:11 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8F73A68DC for ; Wed, 29 Apr 2009 14:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 BG-bQEo4kReQ for ; Wed, 29 Apr 2009 14:11:10 -0700 (PDT) Received: from web53702.mail.re2.yahoo.com (web53702.mail.re2.yahoo.com [206.190.37.23]) by core3.amsl.com (Postfix) with SMTP id 4668A28C29D for ; Wed, 29 Apr 2009 14:11:10 -0700 (PDT) Received: (qmail 95843 invoked by uid 60001); 29 Apr 2009 21:12:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241039552; bh=t5O4EF+9hh4oaQObwPXChr8kU6jto0ltXOANdff/yh4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nT7jAXleQpFLua+B6QtSjSWgd7tyXvgtPFcEqHbX91E61dMPUTcGFnhFwJsWpzC7tlAf0nXxfhQ1WMeAEnIiqcVA+pYwiXdCJoSXuilXpPhIZF8Rs9V/jSdqBs0pc5GrQMs8i64nTNR+R8Nr71ZJj7NHkfxAgStr+xjM7u33JpE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=4xyqjx6RisSnmSmupWjFX/4+LeGrji+spTLZwAp3aa/Zmck7H+IefKMZ9OvKOPfYLicSX136nQ1GJj39CftnawieJ38J7S59mUGq3e8lLyjc9ld3jo9gTKVfSwq7yAF3Ty8Zvhj8ocQ53g9m6Xo6Nla6Hd/ZbS8QDEZKWaPkOII=; Message-ID: <315318.95116.qm@web53702.mail.re2.yahoo.com> X-YMail-OSG: eaNSJ6UVM1kJlsIHaCwdb0NNe4pwb1WZ8LPP4IaedmftCsdXorKY6vwtmMIBklHZi4S1k1hHescUgZv7XBt_CvNIbs2.8f_R6xgedNZEDrsyH4VF9Cjilb3_f8hmIhRIWlREiPXG89jnOPo44iZuq5ghwtovxuGXNWyrb1EZQ.8qoNE1PkChP1Ulpq3rUxNdJtfSaN9w0g2N2wjcDa39b7RwXF18VLthQJD2hYl93dJ2zX7ANm7yJzRgx5twaCsXDVSSO6.1m0UTqPFBmMJJ1GNA.RZ2RXqE7D1mllMuKsuOZtm4deA- Received: from [216.38.144.65] by web53702.mail.re2.yahoo.com via HTTP; Wed, 29 Apr 2009 14:12:31 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 29 Apr 2009 14:12:31 -0700 (PDT) From: Kundan Singh To: p2psip@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [P2PSIP] Implementations of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: kundansingh_99@yahoo.com List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:11:11 -0000 Hello, Recently I tried to implement the current proposal of draft-ietf-p2psip-base-02.txt and have to admit that I got scared due to the complexity it has. I am curious to learn about existing open/closed source implementations of this draft if any. Also, a writeup on how to extend an existing SIP and Chord (DHT) implementation by someone who implemented this draft will be helpful to other implementors. Thanks, Kundan -- "An architect is happy with the design not when he cannot add any more, but when he cannot remove any more without losing the appeal" From glitch@me.com Thu Apr 30 18:14:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D327E3A6ADB for ; Thu, 30 Apr 2009 18:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 v2DOIlrI-ARZ for ; Thu, 30 Apr 2009 18:14:47 -0700 (PDT) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by core3.amsl.com (Postfix) with ESMTP id 2D3083A6911 for ; Thu, 30 Apr 2009 18:14:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [10.0.1.6] (ip68-5-31-14.oc.oc.cox.net [68.5.31.14]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KIX008SCY6O2P40@asmtp021.mac.com> for p2psip@ietf.org; Thu, 30 Apr 2009 18:16:01 -0700 (PDT) Message-id: From: glitch To: p2psip@ietf.org Date: Thu, 30 Apr 2009 18:16:00 -0700 X-Mailer: Apple Mail (2.930.4) Subject: [P2PSIP] draft-ietf-p2psip-base-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 01:21:40 -0000 Hi, Is there an implementation of this to test my implementation against? I have googled high and low. Thanks!