From ipoverib-bounces@ietf.org Mon Aug 9 14:33:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24543 for ; Mon, 9 Aug 2004 14:33:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEeB-0001z0-QK; Mon, 09 Aug 2004 14:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEGg-0001eV-5w for ipoverib@megatron.ietf.org; Mon, 09 Aug 2004 13:49:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18445 for ; Mon, 9 Aug 2004 13:49:04 -0400 (EDT) Received: from [64.223.135.10] (helo=Simonelli.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BuEL2-0001bf-HE for ipoverib@ietf.org; Mon, 09 Aug 2004 13:53:37 -0400 Date: Mon, 09 Aug 2004 13:49:03 -0500 To: "Ipoverib" From: "Bill" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ozgieunhpomopvilbtcy" X-Spam-Score: 0.9 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [Ipoverib] (no subject) X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org ----------ozgieunhpomopvilbtcy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price

----------ozgieunhpomopvilbtcy Content-Type: application/octet-stream; name="newprice.zip" Content-Disposition: attachment; filename="newprice.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------ozgieunhpomopvilbtcy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib ----------ozgieunhpomopvilbtcy-- From ipoverib-bounces@ietf.org Mon Aug 9 17:59:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23552 for ; Mon, 9 Aug 2004 17:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHpO-0002TI-H6; Mon, 09 Aug 2004 17:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHet-0007oZ-2b for ipoverib@megatron.ietf.org; Mon, 09 Aug 2004 17:26:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20059 for ; Mon, 9 Aug 2004 17:26:16 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuHjE-0002M5-2W for ipoverib@ietf.org; Mon, 09 Aug 2004 17:30:52 -0400 Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i79LQD53003261 for ; Mon, 9 Aug 2004 15:26:13 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I2700A017AF7C@bur-mail1.east.sun.com> (original mail from Daniel.Cassiday@Sun.COM) for ipoverib@ietf.org; Mon, 09 Aug 2004 17:26:12 -0400 (EDT) Received: from sun.com (dhcp-ubur03-183-236.East.Sun.COM [129.148.183.236]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I2700EFT7JOZZ@bur-mail1.east.sun.com> for ipoverib@ietf.org; Mon, 09 Aug 2004 17:26:12 -0400 (EDT) Date: Mon, 09 Aug 2004 17:28:42 -0400 From: Daniel Cassiday To: ipoverib@ietf.org Message-id: <4117EC8A.6070509@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT Subject: [Ipoverib] Update on status of eui-64 in IB X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel.Cassiday@Sun.COM List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org Content-Transfer-Encoding: 7BIT A while back it was pointed out that the IB specification was unclear on how to set the universal/local bit in the EUI-64. This was causing a problem in the ipoverib wg on how to generate an interface identifier from this EUI-64. The IBTA has looked into this and planning is to modify the IB spec to clarify that the universal/local bit should be cleared when defining the EUI-64. The spec with this modification is currently under internal review. Pending approval (which is expected) the clarification will be included in the upcoming 1.2 release of the spec. This means that the IBA will conform to the IEEE definition of universal/local bit, and that for ipoverib, interface identifiers should be generated from the EUI-64 as per RFC 2373 (i.e. the universal/local bit should be inverted). (Note, at one point the IBTA Link WG considered using a special value in the OUI field (i.e. this is where the vendor id appears) to indicate local scope but this was discarded in favor of the simplier fix defined above.) _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Fri Aug 13 16:00:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13075 for ; Fri, 13 Aug 2004 16:00:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvhfX-0001j9-L4; Fri, 13 Aug 2004 15:24:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvhYr-0000Wk-Ca; Fri, 13 Aug 2004 15:17:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08198; Fri, 13 Aug 2004 15:17:55 -0400 (EDT) Message-Id: <200408131917.PAA08198@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 13 Aug 2004 15:17:55 -0400 Cc: ipoverib@ietf.org Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-over-infiniband-07.txt X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : Transmission of IP over InfiniBand Author(s) : V. Kashyap, H.K. Jerry Chu Filename : draft-ietf-ipoib-ip-over-infiniband-07.txt Pages : 20 Date : 2004-8-13 This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link layer address to be used when resolving the IP addresses in 'IP over InfiniBand (IPoIB)' subnets. The document also describes the mapping from IP multicast addresse to InfiniBand multicast addresses. Additionally this document defines the setup and configuration of IPoIB links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipoib-ip-over-infiniband-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-13153157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ip-over-infiniband-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-13153157.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib --NextPart-- From ipoverib-bounces@ietf.org Fri Aug 13 20:01:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26802 for ; Fri, 13 Aug 2004 20:01:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvlxq-0002TN-3J; Fri, 13 Aug 2004 20:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvlvV-0001zg-Sg for ipoverib@megatron.ietf.org; Fri, 13 Aug 2004 19:57:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26526 for ; Fri, 13 Aug 2004 19:57:36 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvm0l-00021W-Jf for ipoverib@ietf.org; Fri, 13 Aug 2004 20:03:04 -0400 Received: from mobilebill (c-24-6-192-177.client.comcast.net[24.6.192.177]) by comcast.net (sccrmhc12) with SMTP id <2004081323570501200pnt2ke>; Fri, 13 Aug 2004 23:57:05 +0000 From: "bill" To: Date: Fri, 13 Aug 2004 16:56:31 -0700 Message-ID: <000001c48191$2d3d4e50$1e02a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Ipoverib] Connected mode draft and retransmit implosion X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org Content-Transfer-Encoding: 7bit Vivek, So I have been concerned about the Connected mode draft and I run into a simple problem here... Imagine I have a TCP socket running over a 64K RC MTU link. I transmit the IP packet (all 64K of it) Infiniband breaks the packet up into a bunch of 2K Infiniband MTU packets (all 32 of them) - lets say I loose the second packet. No problem IB will retransmit the packet over the link and it gets to the other side... The problem that I want to see - is what happens if the TCP retransmit timer goes off - causing the whole TCP segment to be retransmitted. Is there anyway that IPoIB-RC can handle this. I am assuming the first pass is "There are no IB link errors". The second pass will be "IB Link timers are orders of magnitude faster than TCP timers" (order millisecond rather than order second) The third (And I hope correct) answer will be "We have done the analysis and we can show that there is such a low probability of 1 happening, that 2 will cover all but some rediculously small ammount that the retransmission problem doesn't happen" Any input ? Am I worried over nothing (because of 1 and 2) Bill _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Fri Aug 13 20:56:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29152 for ; Fri, 13 Aug 2004 20:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvmpG-0002DZ-6P; Fri, 13 Aug 2004 20:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvmfj-0000c2-2K for ipoverib@megatron.ietf.org; Fri, 13 Aug 2004 20:45:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28584 for ; Fri, 13 Aug 2004 20:45:21 -0400 (EDT) Received: from gw0.infiniconsys.com ([65.219.193.226] helo=mail.infiniconsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvmkx-0002cP-BE for ipoverib@ietf.org; Fri, 13 Aug 2004 20:50:50 -0400 Received: from ftillier ([192.168.90.101]) by mail.infiniconsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 20:44:38 -0400 From: "Fab Tillier" To: "'bill'" , Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion Date: Fri, 13 Aug 2004 17:41:39 -0700 Message-ID: <000001c48197$76fb6c10$655aa8c0@infiniconsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <000001c48191$2d3d4e50$1e02a8c0@mobilebill> Importance: Normal X-OriginalArrivalTime: 14 Aug 2004 00:44:38.0829 (UTC) FILETIME=[E1025DD0:01C48197] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org Content-Transfer-Encoding: 7bit > From: bill [mailto:bill@strahm.net] > Sent: Friday, August 13, 2004 4:57 PM > > Vivek, > > So I have been concerned about the Connected mode draft and I run into a > simple problem here... > > Imagine I have a TCP socket running over a 64K RC MTU link. > > I transmit the IP packet (all 64K of it) > > Infiniband breaks the packet up into a bunch of 2K Infiniband MTU > packets (all 32 of them) - lets say I loose the second packet. > > No problem IB will retransmit the packet over the link and it gets to > the other side... > > The problem that I want to see - is what happens if the TCP retransmit > timer goes off - causing the whole TCP segment to be retransmitted. Wouldn't you end up with the same packet getting sent twice? If so, why is this problematic (aside from the inefficiency)? - Fab _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Fri Aug 13 21:02:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29443 for ; Fri, 13 Aug 2004 21:02:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvmut-0003S5-EZ; Fri, 13 Aug 2004 21:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvmuC-0003GP-CC for ipoverib@megatron.ietf.org; Fri, 13 Aug 2004 21:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29369 for ; Fri, 13 Aug 2004 21:00:18 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvmzS-0002rc-Hn for ipoverib@ietf.org; Fri, 13 Aug 2004 21:05:47 -0400 Received: from mobilebill (c-24-6-192-177.client.comcast.net[24.6.192.177]) by comcast.net (sccrmhc11) with SMTP id <20040814005947011004o478e>; Sat, 14 Aug 2004 00:59:47 +0000 From: "bill" To: "'Fab Tillier'" , Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion Date: Fri, 13 Aug 2004 17:59:17 -0700 Message-ID: <000901c48199$f04b42a0$1e02a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <000001c48197$76fb6c10$655aa8c0@infiniconsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org Content-Transfer-Encoding: 7bit Yes, that is exactly the problem... Both layers retransmitting at the same time And possibly not recovering for quite a while Bill > -----Original Message----- > From: ipoverib-bounces@ietf.org > [mailto:ipoverib-bounces@ietf.org] On Behalf Of Fab Tillier > Sent: Friday, August 13, 2004 5:42 PM > To: 'bill'; ipoverib@ietf.org > Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion > > > > From: bill [mailto:bill@strahm.net] > > Sent: Friday, August 13, 2004 4:57 PM > > > > Vivek, > > > > So I have been concerned about the Connected mode draft and > I run into > > a simple problem here... > > > > Imagine I have a TCP socket running over a 64K RC MTU link. > > > > I transmit the IP packet (all 64K of it) > > > > Infiniband breaks the packet up into a bunch of 2K Infiniband MTU > > packets (all 32 of them) - lets say I loose the second packet. > > > > No problem IB will retransmit the packet over the link and > it gets to > > the other side... > > > > The problem that I want to see - is what happens if the TCP > retransmit > > timer goes off - causing the whole TCP segment to be retransmitted. > > Wouldn't you end up with the same packet getting sent twice? > If so, why is this problematic (aside from the inefficiency)? > > - Fab > > > > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Fri Aug 13 21:22:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00262 for ; Fri, 13 Aug 2004 21:22:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvn9W-0005al-HG; Fri, 13 Aug 2004 21:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvn52-0004w0-HW for ipoverib@megatron.ietf.org; Fri, 13 Aug 2004 21:11:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29932 for ; Fri, 13 Aug 2004 21:11:30 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvnAI-00032D-Oe for ipoverib@ietf.org; Fri, 13 Aug 2004 21:17:00 -0400 Received: from phys-hanwk-1 ([129.149.2.111]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7E1AxJ6001672 for ; Fri, 13 Aug 2004 18:10:59 -0700 (PDT) Received: from conversion-daemon.hanwk-mail1.sfbay.sun.com by hanwk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I2E00001W7ZN6@hanwk-mail1.sfbay.sun.com> (original mail from Ajoy.Siddabathuni@Sun.COM) for ipoverib@ietf.org; Fri, 13 Aug 2004 18:10:59 -0700 (PDT) Received: from endeavour (endeavour.SFBay.Sun.COM [129.149.192.63]) by hanwk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I2E00AQHWMBG8@hanwk-mail1.sfbay.sun.com>; Fri, 13 Aug 2004 18:10:59 -0700 (PDT) Date: Fri, 13 Aug 2004 18:04:42 -0700 (PDT) From: Ajoy Siddabathuni Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion In-reply-to: <000901c48199$f04b42a0$1e02a8c0@mobilebill> X-Sender: ajoy@endeavour To: bill Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ipoverib@ietf.org, "'Fab Tillier'" X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org Isnt tcp timers in the order of msec and ib timers in the order of usecs? I think its just a problem of tuning the stack for the application in question. ~Ajoy On Fri, 13 Aug 2004, bill wrote: > Yes, that is exactly the problem... Both layers retransmitting at the > same time > > And possibly not recovering for quite a while > Bill > > > -----Original Message----- > > From: ipoverib-bounces@ietf.org > > [mailto:ipoverib-bounces@ietf.org] On Behalf Of Fab Tillier > > Sent: Friday, August 13, 2004 5:42 PM > > To: 'bill'; ipoverib@ietf.org > > Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion > > > > > > > From: bill [mailto:bill@strahm.net] > > > Sent: Friday, August 13, 2004 4:57 PM > > > > > > Vivek, > > > > > > So I have been concerned about the Connected mode draft and > > I run into > > > a simple problem here... > > > > > > Imagine I have a TCP socket running over a 64K RC MTU link. > > > > > > I transmit the IP packet (all 64K of it) > > > > > > Infiniband breaks the packet up into a bunch of 2K Infiniband MTU > > > packets (all 32 of them) - lets say I loose the second packet. > > > > > > No problem IB will retransmit the packet over the link and > > it gets to > > > the other side... > > > > > > The problem that I want to see - is what happens if the TCP > > retransmit > > > timer goes off - causing the whole TCP segment to be retransmitted. > > > > Wouldn't you end up with the same packet getting sent twice? > > If so, why is this problematic (aside from the inefficiency)? > > > > - Fab > > > > > > > > _______________________________________________ > > IPoverIB mailing list > > IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib > > > > > > _______________________________________________ > IPoverIB mailing list > IPoverIB@ietf.org > https://www1.ietf.org/mailman/listinfo/ipoverib > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Fri Aug 13 21:37:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00748 for ; Fri, 13 Aug 2004 21:37:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvnR2-0008OZ-GS; Fri, 13 Aug 2004 21:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvnM7-0007CJ-9N for ipoverib@megatron.ietf.org; Fri, 13 Aug 2004 21:29:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00471 for ; Fri, 13 Aug 2004 21:29:09 -0400 (EDT) Received: from gw0.infiniconsys.com ([65.219.193.226] helo=mail.infiniconsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvnRN-0003Ep-VQ for ipoverib@ietf.org; Fri, 13 Aug 2004 21:34:39 -0400 Received: from ftillier ([192.168.90.101]) by mail.infiniconsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 21:28:39 -0400 From: "Fab Tillier" To: "'bill'" , Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion Date: Fri, 13 Aug 2004 18:25:41 -0700 Message-ID: <000101c4819d$9d2ce430$655aa8c0@infiniconsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <000901c48199$f04b42a0$1e02a8c0@mobilebill> Importance: Normal X-OriginalArrivalTime: 14 Aug 2004 01:28:39.0677 (UTC) FILETIME=[0713CAD0:01C4819E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > From: bill [mailto:bill@strahm.net] > Sent: Friday, August 13, 2004 5:59 PM >=20 > Yes, that is exactly the problem... Both layers retransmitting at the > same time While both layers issue retransmits at the same time, the packets on the wire maintain their order. The first packet sent will be delivered = first, with the second queued up behind. The data will not get interleaved. = There is no way for the retransmitted packet to get delivered first. >=20 > And possibly not recovering for quite a while IB recovery is pretty much binary - if an RC QP exceeds its retry limit, = it will transition to the error state. At that point, all processing of = the send queue stops and the consumer gets an error completion and an async error notification for that QP. I still don't see the harm in TCP retransmitting while IB is also retransmitting aside from inefficiencies. - Fab _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Fri Aug 20 17:42:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16027 for ; Fri, 20 Aug 2004 17:42:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByGcV-0007K0-EZ; Fri, 20 Aug 2004 17:08:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByGFD-0007Z1-9C for ipoverib@megatron.ietf.org; Fri, 20 Aug 2004 16:44:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12974 for ; Fri, 20 Aug 2004 16:44:07 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByGLo-0008QD-1e for ipoverib@ietf.org; Fri, 20 Aug 2004 16:51:06 -0400 Received: from mobilebill (c-24-20-39-234.client.comcast.net[24.20.39.234]) by comcast.net (rwcrmhc11) with SMTP id <20040820204336013005kth4e>; Fri, 20 Aug 2004 20:43:36 +0000 From: "bill" To: Date: Fri, 20 Aug 2004 13:43:12 -0700 Message-ID: <000101c486f6$504eb9f0$6601a8c0@mobilebill> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01C486BB.A3EFE1F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Ipoverib] Meeting Minutes X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C486BB.A3EFE1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cheng got me the meeting minutes last week. I am posting them now. Any questions comments please get comments to me by next Friday. I will be sending them off with the presentations to the agenda folks. I will see if I can put the presentations up on my web log at sun. If I can do that - I will post the link Bill ------=_NextPart_000_0002_01C486BB.A3EFE1F0 Content-Type: text/plain; name="IPoIB Meeting Minutes.txt" Content-Disposition: attachment; filename="IPoIB Meeting Minutes.txt" Content-Transfer-Encoding: 7bit MIB Stataus: Not updated There is an Open IB group, to implement IB on 2.6 Linux. Bill presents Hal's slides. January 2004 there was a IBTA Plugfest to test interopbility. August will be another plugfest. Organized by IBTA and OpenIB is participating that. January/Feb 2005 again. Need to resolve NDA issue with IBTA and IETF. Margeret will work with Bill on that. check openib.org for update. Issues: ARP size is too small for IB. Rebuild kernel to make room for it. Simply enlarge that will that break IO control, may cause problem with user program? IB uses MC to implement Broadcast. What does "JOIN" MC mean? Does Join mean create? IBTA doesn't have a position on that. Should we tighten this saying purposely left-out? Also QKey generation need to be resolved. Need to look at spec to find QKey conflict. How to define IPOIB interface RUNNING? When? before or after join the BC/MC? SM Restart losing multicast subscription. IBTA will stress that SM should maintain the info. Performance: Max UD is max 4K but currently 2K. Vivek: status of the drafts. 3 drafts are being published. Architecture. DHCP has been through lastcall, to send note to DHCP group to review it. transmission over ip, has been through last call. GID format (bit reversed?)has some problem, need to fixed in IB spec. Vivek: IPoIB Connected Mode. IPOIB modes. advantage: Large MTU for better throughput. Topic, How to do address resolution in multicast? rely on UD QPKey to solve multicast problem. Suggested use UD QPN to create a service ID. MTU negotiation between min,desired, accepted MTUs. on going discussion: multiple connections allowed or not? one comment: should this be a configuration parameter? Vivek - Chang - IB Subnet manager MIB status Goal is to enable out-of-band configuration of IB Subnet Manager and IB fabrics and monitoring of IB fabrics. Multicast - suggestion that Multicast table be Read-Write with minimum access of Read. Then it could start out as read only and later if Writes could be allowed without having to introduce a new object. Chang points out that the object might not be the ideal object form for doing that anyway. Issue left open for discussion. Trace record - suggested that the author also look at the DisMan draft. Notification - why not just use a normal notification macro instead of encapsulating? Wouldn't it be more useful for network managers to use notifications that it can understand. Answer, encapsulation uses the Infiniband notifications. In the current notification, some identifying information such as node number are in the format. This seems sufficient. ------=_NextPart_000_0002_01C486BB.A3EFE1F0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib ------=_NextPart_000_0002_01C486BB.A3EFE1F0-- From ipoverib-bounces@ietf.org Fri Aug 20 20:04:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24112 for ; Fri, 20 Aug 2004 20:04:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByIva-0000yz-IS; Fri, 20 Aug 2004 19:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByIMl-0000pp-5q for ipoverib@megatron.ietf.org; Fri, 20 Aug 2004 19:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20864 for ; Fri, 20 Aug 2004 19:00:02 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByITM-0002Sf-WA for ipoverib@ietf.org; Fri, 20 Aug 2004 19:07:03 -0400 Received: from mobilebill (c-24-20-39-234.client.comcast.net[24.20.39.234]) by comcast.net (sccrmhc11) with SMTP id <2004082022593201100cag0me>; Fri, 20 Aug 2004 22:59:32 +0000 From: "bill" To: Date: Fri, 20 Aug 2004 15:58:38 -0700 Message-ID: <000001c48709$40d0d5e0$6601a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Ipoverib] Hal's presentation posted on my weblog X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org Content-Transfer-Encoding: 7bit As soon as I get the other three presentations readied, I will get them posted as well. Please visit my weblog at - http://blogs.sun.com/roller/page/BillS/20040820#first_attempt_to_post_ie tf Bill _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Tue Aug 24 13:33:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26432 for ; Tue, 24 Aug 2004 13:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzesA-0006gX-Kd; Tue, 24 Aug 2004 13:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzeXn-0001FW-LC for ipoverib@megatron.ietf.org; Tue, 24 Aug 2004 12:53:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21967 for ; Tue, 24 Aug 2004 12:53:03 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzeYH-0004P4-2a for ipoverib@ietf.org; Tue, 24 Aug 2004 12:53:41 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id B969EBE15 for ; Tue, 24 Aug 2004 09:53:04 -0700 (PDT) Received: from MK73191c.cup.hp.com (mk731916.cup.hp.com [15.8.80.134]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id JAA11265 for ; Tue, 24 Aug 2004 09:52:17 -0700 (PDT) Message-Id: <6.1.2.0.2.20040823073840.01fafd58@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 23 Aug 2004 07:43:32 -0700 To: From: Michael Krause Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion In-Reply-To: <000101c4819d$9d2ce430$655aa8c0@infiniconsys.com> References: <000901c48199$f04b42a0$1e02a8c0@mobilebill> <000101c4819d$9d2ce430$655aa8c0@infiniconsys.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1059301661==" Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org --===============1059301661== Content-Type: multipart/alternative; boundary="=====================_874417==.ALT" --=====================_874417==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:25 PM 8/13/2004, Fab Tillier wrote: > > From: bill [mailto:bill@strahm.net] > > Sent: Friday, August 13, 2004 5:59 PM > > > > Yes, that is exactly the problem... Both layers retransmitting at the > > same time > >While both layers issue retransmits at the same time, the packets on the >wire maintain their order. The first packet sent will be delivered first, >with the second queued up behind. The data will not get interleaved. There >is no way for the retransmitted packet to get delivered first. > > > > > And possibly not recovering for quite a while > >IB recovery is pretty much binary - if an RC QP exceeds its retry limit, it >will transition to the error state. At that point, all processing of the >send queue stops and the consumer gets an error completion and an async >error notification for that QP. > >I still don't see the harm in TCP retransmitting while IB is also >retransmitting aside from inefficiencies. Given this is a RC QP, the WR are processed in order and must complete in order to make forward progress. As such, the consumer which is posting WR can post new or duplicate packets and the underlying QP will not see these until it completes the current WR. As such, IB retransmission and consumer retransmission algorithms are orthogonal to one another in all respects sans perhaps doing a poor job configuring the associated IB retransmission timers as well as the arbitration policies within the fabric such that the consumer falls into its retransmission algorithm too often. Mike --=====================_874417==.ALT Content-Type: text/html; charset="us-ascii" At 06:25 PM 8/13/2004, Fab Tillier wrote:

> From: bill [mailto:bill@strahm.net]
> Sent: Friday, August 13, 2004 5:59 PM
>
> Yes, that is exactly the problem... Both layers retransmitting at the
> same time

While both layers issue retransmits at the same time, the packets on the
wire maintain their order. The first packet sent will be delivered first,
with the second queued up behind. The data will not get interleaved. There
is no way for the retransmitted packet to get delivered first.

>
> And possibly not recovering for quite a while

IB recovery is pretty much binary - if an RC QP exceeds its retry limit, it
will transition to the error state. At that point, all processing of the
send queue stops and the consumer gets an error completion and an async
error notification for that QP.

I still don't see the harm in TCP retransmitting while IB is also
retransmitting aside from inefficiencies.

Given this is a RC QP, the WR are processed in order and must complete in order to make forward progress. As such, the consumer which is posting WR can post new or duplicate packets and the underlying QP will not see these until it completes the current WR. As such, IB retransmission and consumer retransmission algorithms are orthogonal to one another in all respects sans perhaps doing a poor job configuring the associated IB retransmission timers as well as the arbitration policies within the fabric such that the consumer falls into its retransmission algorithm too often.

Mike --=====================_874417==.ALT-- --===============1059301661== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib --===============1059301661==-- From ipoverib-bounces@ietf.org Wed Aug 25 04:18:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23186 for ; Wed, 25 Aug 2004 04:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzsau-0000Ky-Jy; Wed, 25 Aug 2004 03:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzsIK-0006Ea-2W for ipoverib@megatron.ietf.org; Wed, 25 Aug 2004 03:34:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20584 for ; Wed, 25 Aug 2004 03:33:51 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzsIk-0003dO-Db for ipoverib@ietf.org; Wed, 25 Aug 2004 03:34:35 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7P7Uhdn551266; Wed, 25 Aug 2004 03:30:43 -0400 Received: from sig-9-49-135-195.mts.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7P7Ucxt038780; Wed, 25 Aug 2004 01:30:42 -0600 Date: Wed, 25 Aug 2004 00:30:21 -0700 (PDT) From: Vivek Kashyap X-X-Sender: kashyapv@localhost.localdomain To: Michael Krause Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion In-Reply-To: <6.1.2.0.2.20040823073840.01fafd58@esmail.cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ipoverib@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org On Mon, 23 Aug 2004, Michael Krause wrote: > At 06:25 PM 8/13/2004, Fab Tillier wrote: > > > From: bill [mailto:bill@strahm.net] > > > Sent: Friday, August 13, 2004 5:59 PM > > > > > > Yes, that is exactly the problem... Both layers retransmitting at the > > > same time > > > >While both layers issue retransmits at the same time, the packets on the > >wire maintain their order. The first packet sent will be delivered first, > >with the second queued up behind. The data will not get interleaved. There > >is no way for the retransmitted packet to get delivered first. > > > > > > > > And possibly not recovering for quite a while > > > >IB recovery is pretty much binary - if an RC QP exceeds its retry limit, it > >will transition to the error state. At that point, all processing of the > >send queue stops and the consumer gets an error completion and an async > >error notification for that QP. > > > >I still don't see the harm in TCP retransmitting while IB is also > >retransmitting aside from inefficiencies. > > Given this is a RC QP, the WR are processed in order and must complete in > order to make forward progress. As such, the consumer which is posting WR > can post new or duplicate packets and the underlying QP will not see these > until it completes the current WR. As such, IB retransmission and consumer > retransmission algorithms are orthogonal to one another in all respects > sans perhaps doing a poor job configuring the associated IB retransmission > timers as well as the arbitration policies within the fabric such that the > consumer falls into its retransmission algorithm too often. > > Mike Yes, TCP will not see out of order packets since the underlying layer delivers in order, reliable data. Also, TCP timers are likely to be much longer than the RC timers. Therefore, it is quite likely that RC will retransmit multiple times and recover by the time TCP timers expire. As an aside, IPoIB over connected mode is not limited to RC, it includes UC too. Also, it is IP (which implies UDP, SCTP etc.) over RC or UC. Vivek _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-bounces@ietf.org Wed Aug 25 15:02:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09720 for ; Wed, 25 Aug 2004 15:02:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C02p0-0007Wc-Sx; Wed, 25 Aug 2004 14:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C02bI-0004u5-GE for ipoverib@megatron.ietf.org; Wed, 25 Aug 2004 14:34:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07774 for ; Wed, 25 Aug 2004 14:34:23 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C02c2-0007X2-Gp for ipoverib@ietf.org; Wed, 25 Aug 2004 14:35:13 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id E5F225471; Wed, 25 Aug 2004 11:34:19 -0700 (PDT) Received: from MK73191c.cup.hp.com ([15.244.200.153]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id LAA12287; Wed, 25 Aug 2004 11:32:50 -0700 (PDT) Message-Id: <6.1.2.0.2.20040825113131.07233608@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 25 Aug 2004 11:33:03 -0700 To: Vivek Kashyap From: Michael Krause Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion In-Reply-To: References: <6.1.2.0.2.20040823073840.01fafd58@esmail.cup.hp.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: ipoverib@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1189038026==" Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org --===============1189038026== Content-Type: multipart/alternative; boundary="=====================_12628949==.ALT" --=====================_12628949==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:30 AM 8/25/2004, Vivek Kashyap wrote: >On Mon, 23 Aug 2004, Michael Krause wrote: > > > At 06:25 PM 8/13/2004, Fab Tillier wrote: > > > > From: bill [mailto:bill@strahm.net] > > > > Sent: Friday, August 13, 2004 5:59 PM > > > > > > > > Yes, that is exactly the problem... Both layers retransmitting at the > > > > same time > > > > > >While both layers issue retransmits at the same time, the packets on the > > >wire maintain their order. The first packet sent will be delivered first, > > >with the second queued up behind. The data will not get > interleaved. There > > >is no way for the retransmitted packet to get delivered first. > > > > > > > > > > > And possibly not recovering for quite a while > > > > > >IB recovery is pretty much binary - if an RC QP exceeds its retry > limit, it > > >will transition to the error state. At that point, all processing of the > > >send queue stops and the consumer gets an error completion and an async > > >error notification for that QP. > > > > > >I still don't see the harm in TCP retransmitting while IB is also > > >retransmitting aside from inefficiencies. > > > > Given this is a RC QP, the WR are processed in order and must complete in > > order to make forward progress. As such, the consumer which is posting WR > > can post new or duplicate packets and the underlying QP will not see these > > until it completes the current WR. As such, IB retransmission and > consumer > > retransmission algorithms are orthogonal to one another in all respects > > sans perhaps doing a poor job configuring the associated IB retransmission > > timers as well as the arbitration policies within the fabric such that the > > consumer falls into its retransmission algorithm too often. > > > > Mike > >Yes, TCP will not see out of order packets since the underlying layer delivers >in order, reliable data. Also, TCP timers are likely to be much longer than >the RC timers. Therefore, it is quite likely that RC will retransmit multiple >times and recover by the time TCP timers expire. > >As an aside, IPoIB over connected mode is not limited to RC, it includes UC >too. Also, it is IP (which implies UDP, SCTP etc.) over RC or UC. Hence why I did not state a particular consumer type only that it is posting to a connected QP. Whether RC or UC, the processing order remains the same. The only difference is the lack of IB ACK as well as Send Credit management for UC but for this discussion, they are essentially the same from the consumer's perspective. Mike --=====================_12628949==.ALT Content-Type: text/html; charset="us-ascii" At 12:30 AM 8/25/2004, Vivek Kashyap wrote:

On Mon, 23 Aug 2004, Michael Krause wrote:

> At 06:25 PM 8/13/2004, Fab Tillier wrote:
> > > From: bill [mailto:bill@strahm.net]
> > > Sent: Friday, August 13, 2004 5:59 PM
> > >
> > > Yes, that is exactly the problem... Both layers retransmitting at the
> > > same time
> >
> >While both layers issue retransmits at the same time, the packets on the
> >wire maintain their order. The first packet sent will be delivered first,
> >with the second queued up behind. The data will not get interleaved. There
> >is no way for the retransmitted packet to get delivered first.
> >
> > >
> > > And possibly not recovering for quite a while
> >
> >IB recovery is pretty much binary - if an RC QP exceeds its retry limit, it
> >will transition to the error state. At that point, all processing of the
> >send queue stops and the consumer gets an error completion and an async
> >error notification for that QP.
> >
> >I still don't see the harm in TCP retransmitting while IB is also
> >retransmitting aside from inefficiencies.
>
> Given this is a RC QP, the WR are processed in order and must complete in
> order to make forward progress. As such, the consumer which is posting WR
> can post new or duplicate packets and the underlying QP will not see these
> until it completes the current WR. As such, IB retransmission and consumer
> retransmission algorithms are orthogonal to one another in all respects
> sans perhaps doing a poor job configuring the associated IB retransmission
> timers as well as the arbitration policies within the fabric such that the
> consumer falls into its retransmission algorithm too often.
>
> Mike

Yes, TCP will not see out of order packets since the underlying layer delivers
in order, reliable data. Also, TCP timers are likely to be much longer than
the RC timers. Therefore, it is quite likely that RC will retransmit multiple
times and recover by the time TCP timers expire.

As an aside, IPoIB over connected mode is not limited to RC, it includes UC
too. Also, it is IP (which implies UDP, SCTP etc.) over RC or UC.

Hence why I did not state a particular consumer type only that it is posting to a connected QP. Whether RC or UC, the processing order remains the same. The only difference is the lack of IB ACK as well as Send Credit management for UC but for this discussion, they are essentially the same from the consumer's perspective.

Mike --=====================_12628949==.ALT-- --===============1189038026== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib --===============1189038026==-- From ipoverib-bounces@ietf.org Wed Aug 25 18:35:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03291 for ; Wed, 25 Aug 2004 18:35:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C05wJ-0001DD-Di; Wed, 25 Aug 2004 18:08:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C04my-0003YI-DX; Wed, 25 Aug 2004 16:54:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19643; Wed, 25 Aug 2004 16:54:19 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C04nW-0002CP-Mh; Wed, 25 Aug 2004 16:55:11 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7PKrgDD565558; Wed, 25 Aug 2004 16:53:42 -0400 Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7PKrfEM414428; Wed, 25 Aug 2004 14:53:42 -0600 Subject: RE: [Ipoverib] Connected mode draft and retransmit implosion To: Michael Krause X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Wed, 25 Aug 2004 13:53:39 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/25/2004 14:53:42 MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: ipoverib@ietf.org, ipoverib-bounces@ietf.org, kashyapv@us.ibm.com X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over InfiniBand WG Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0736161115==" Sender: ipoverib-bounces@ietf.org Errors-To: ipoverib-bounces@ietf.org --===============0736161115== Content-type: multipart/alternative; Boundary="0__=08BBE468DFE1AC188f9e8a93df938690918c08BBE468DFE1AC18" Content-Disposition: inline --0__=08BBE468DFE1AC188f9e8a93df938690918c08BBE468DFE1AC18 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable At 12:30 AM 8/25/2004, Vivek Kashyap wrote: On Mon, 23 Aug 2004, Michael Krause wrote: > At 06:25 PM 8/13/2004, Fab Tillier wrote: > > > From: bill [mailto:bill@strahm.net] > > > Sent: Friday, August 13, 2004 5:59 PM > > > > > > Yes, that is exactly the problem... Both layers retransmitt= ing at the > > > same time > > > >While both layers issue retransmits at the same time, the pack= ets on the > >wire maintain their order. The first packet sent will be delivered first, > >with the second queued up behind. The data will not get interleaved. There > >is no way for the retransmitted packet to get delivered first.= > > > > > > > > And possibly not recovering for quite a while > > > >IB recovery is pretty much binary - if an RC QP exceeds its re= try limit, it > >will transition to the error state. At that point, all proces= sing of the > >send queue stops and the consumer gets an error completion and= an async > >error notification for that QP. > > > >I still don't see the harm in TCP retransmitting while IB is a= lso > >retransmitting aside from inefficiencies. > > Given this is a RC QP, the WR are processed in order and must complete in > order to make forward progress. As such, the consumer which is= posting WR > can post new or duplicate packets and the underlying QP will no= t see these > until it completes the current WR. As such, IB retransmission = and consumer > retransmission algorithms are orthogonal to one another in all respects > sans perhaps doing a poor job configuring the associated IB retransmission > timers as well as the arbitration policies within the fabric su= ch that the > consumer falls into its retransmission algorithm too often. > > Mike Yes, TCP will not see out of order packets since the underlying l= ayer delivers in order, reliable data. Also, TCP timers are likely to be much longer than the RC timers. Therefore, it is quite likely that RC will retrans= mit multiple times and recover by the time TCP timers expire. As an aside, IPoIB over connected mode is not limited to RC, it includes UC too. Also, it is IP (which implies UDP, SCTP etc.) over RC or UC.= Hence why I did not state a particular consumer type only that it is posting to a connected QP. Whether RC or UC, the processing order rema= ins the same. The only difference is the lack of IB ACK as well as Send Cr= edit management for UC but for this discussion, they are essentially the sam= e from the consumer's perspective. Mike_ True... RC/UC are largely indistinuishable in ipoib context. Vivek ______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib = --0__=08BBE468DFE1AC188f9e8a93df938690918c08BBE468DFE1AC18 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

At 12:30 AM 8/25/2004, Viv= ek Kashyap wrote:

On Mon, 23 Aug 2004, Mich= ael Krause wrote:

> At 06:25 PM 8/13/2004, Fab Tillier wrote:
> > > From: bill [

mailto:bil= l@strahm.net

]<= br> > > > Sent: Friday, August 13, 2004 5:59 PM
> > >
> > > Yes, that is exactly the problem... Both layers retransm= itting at the
> > > same time
> >
> >While both layers issue retransmits at the same time, the pack= ets on the
> >wire maintain their order. The first packet sent will be deli= vered first,
> >with the second queued up behind. The data will not get inter= leaved. There
> >is no way for the retransmitted packet to get delivered first.=
> >
> > >
> > > And possibly not recovering for quite a while
> >
> >IB recovery is pretty much binary - if an RC QP exceeds its re= try limit, it
> >will transition to the error state. At that point, all proces= sing of the
> >send queue stops and the consumer gets an error completion and= an async
> >error notification for that QP.
> >
> >I still don't see the harm in TCP retransmitting while IB is a= lso
> >retransmitting aside from inefficiencies.
>
> Given this is a RC QP, the WR are processed in order and must comp= lete in
> order to make forward progress. As such, the consumer which is po= sting WR
> can post new or duplicate packets and the underlying QP will not s= ee these

> until it completes the c= urrent WR. As such, IB retransmission and consumer
> retransmission algorithms are orthogonal to one another in all res= pects
> sans perhaps doing a poor job configuring the associated IB retran= smission
> timers as well as the arbitration policies within the fabric such = that the
> consumer falls into its retransmission algorithm too often.
>
> Mike

Yes, TCP will not see out of order packets since the underlying layer d= elivers
in order, reliable data. Also, TCP timers are likely to be much longer = than
the RC timers. Therefore, it is quite likely that RC will retransmit mu= ltiple
times and recover by the time TCP timers expire.

As an aside, IPoIB over connected mode is not limited to RC, it include= s UC
too. Also, it is IP (which implies UDP, SCTP etc.) over RC or UC.

Hence why I did not state a particular consumer type only that it is po= sting to a connected QP. Whether RC or UC, the processing order remain= s the same. The only difference is the lack of IB ACK as well as Send = Credit management for UC but for this discussion, they are essentially = the same from the consumer's perspective.

Mike_

<VK>
True... RC/UC are largely indistinuishable in ipoib context.
Vivek
<VK>

____________________________________________= __
IPoverIB mailing list
IPoverIB@ietf.org
https://www1.ietf.org/mailman/listinfo/ipoverib<= /a>
= --0__=08BBE468DFE1AC188f9e8a93df938690918c08BBE468DFE1AC18-- --===============0736161115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib --===============0736161115==--