From tcpm-bounces@ietf.org Tue Aug 02 07:28:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzuwg-0004hY-Rz; Tue, 02 Aug 2005 07:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzuwe-0004hS-US for tcpm@megatron.ietf.org; Tue, 02 Aug 2005 07:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12259 for ; Tue, 2 Aug 2005 07:28:27 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzvT7-0002vs-8X for tcpm@ietf.org; Tue, 02 Aug 2005 08:02:02 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.4/8.13.4) with ESMTP id j72BSIuA021414 for ; Tue, 2 Aug 2005 04:28:18 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.1/Submit) id j72BSIYf021413 for tcpm@ietf.org; Tue, 2 Aug 2005 04:28:18 -0700 (PDT) (envelope-from faber) Date: Tue, 2 Aug 2005 04:28:17 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20050802112817.GA20756@pun.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [tcpm] agenda w slides at http://www.isi.edu/tcpm/agenda.html X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0020958957==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0020958957== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC71jRaUz3f+Zf+XsRAhMQAKCd1cnDRVFy1FJqS41tJoNskbTqpACgwkJ5 f13ULhGl5AVTZg/1n6SgKtM= =HCsx -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- --===============0020958957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0020958957==-- From tcpm-bounces@ietf.org Mon Aug 08 14:00:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Bv9-0002kz-AU; Mon, 08 Aug 2005 14:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Bv2-0002k4-VM for tcpm@megatron.ietf.org; Mon, 08 Aug 2005 14:00:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06204 for ; Mon, 8 Aug 2005 14:00:11 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2CSm-0007Eh-9h for tcpm@ietf.org; Mon, 08 Aug 2005 14:35:05 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j78I0AU1008952 for ; Mon, 8 Aug 2005 21:00:10 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Aug 2005 21:00:09 +0300 Received: from [172.19.11.119] ([172.19.11.119]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Aug 2005 21:00:09 +0300 Message-ID: <42F79E88.6040308@nokia.com> Date: Mon, 08 Aug 2005 13:03:52 -0500 From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.92.0.0 X-OriginalArrivalTime: 08 Aug 2005 18:00:09.0838 (UTC) FILETIME=[044638E0:01C59C43] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [tcpm] Alternative to Eifel response X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0111136969==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0111136969== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC7244C919FF27074932431A6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC7244C919FF27074932431A6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I was going through the TCPM audio archive from IETF63, and I guess there was a question (I believe from Jon) if there is an alternative to Eifel response. I have an old draft called DCLOR [1] which tries to address the problem of Spurious timeout (STO). There is a Nokia IPR disclosure [2] which I believe says that you are free to implement it as you want (I too am not a lawyer, so please direct your IPR questions to the contact person on the IPR disclosure page :-)). Coming back to technical issues, I believe that spurious timeouts are extremely rare in the absence of mobility, where eifel response is applicable. In the presence of mobility, there is a need for a broader solution than just spurious timeouts. In fact, eifel response could *potentially* be dangerous for spurious timeouts after subnet change because it simply restores the congestion window without much regard to properties of the new path. (I saw Kazunori Yamamoto slides from IETF63. The authors don't make the distinction whether the STOs were caused due to mobility or due to bit errors. They do, however, point out (slide 5) that STOs occur more often at higher speed, suggesting that mobility is the main cause of spurious timeout. This is in line with my observation from EGPRS field data.) In fact, I don't think that STO is really a TCP problem, so whether you use eifel or DCLOR or what have you, it doesn't really matter. Spurious timeout occur mainly because of poor link design, and changing TCP for that is not the most effective solution. So I would be okay if the TCP roadmap draft doesn't have a standards track solution for spurious timeouts. Thanks Yogesh [1] http://www.ietf.org/internet-drafts/draft-swami-tsvwg-tcp-dclor-05.txt [2] http://www.ietf.org/ietf/IPR/NOKIA-DCLOR.txt -- http://people.nokia.net/~yogesh --------------enigC7244C919FF27074932431A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQEVAwUBQveejYKsoYbjxS8bAQiIswf8CGLIn4JHfdUoV9q6vhTqwT6DP9xZAkyZ NkMZqjGTyHuKqk89huv28e+3zHx8jVEBKHPtvG0lfcGFW2ubW9yr1PEmPd6EYZ9w Sow8Zk6SsX2l45QH1x4uUtzoFlP5axEHOSBg7ZAV8fc6vVCBiPUD3+12ZeZ7echx C7F+UI2EUa2y888xU8HznoiptOV2QvlOof/VXldSzBIfrj1OH2wKb3wy5bUGlmJw Rdaw6oP9XlR8bctlsRpw6A+BMVoF5WUmTAzl6IsEYCiku3Y2COIQC+lpgltYJUE9 TStODfj1zIWd53ZO91rcDn3RBjBbByGS/cqp967uGDJiiuvaJPvWhw== =MYCr -----END PGP SIGNATURE----- --------------enigC7244C919FF27074932431A6-- --===============0111136969== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0111136969==-- From tcpm-bounces@ietf.org Tue Aug 09 14:59:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZJb-0004Qm-13; Tue, 09 Aug 2005 14:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZJX-0004Qb-Oj for tcpm@megatron.ietf.org; Tue, 09 Aug 2005 14:59:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29557 for ; Tue, 9 Aug 2005 14:59:01 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2ZrU-00017h-1u for tcpm@ietf.org; Tue, 09 Aug 2005 15:34:09 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.4/8.13.4) with ESMTP id j79IwrIB017968 for ; Tue, 9 Aug 2005 11:58:53 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.1/Submit) id j79IwqDQ017967 for tcpm@ietf.org; Tue, 9 Aug 2005 11:58:52 -0700 (PDT) (envelope-from faber) Date: Tue, 9 Aug 2005 11:58:52 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20050809185852.GB14613@pun.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Subject: [tcpm] IETF 63 minutes for review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2067875695==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2067875695== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f0KYrhQ4vYSV2aJu" Content-Disposition: inline --f0KYrhQ4vYSV2aJu Content-Type: multipart/mixed; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I hope everyone's back from Paris safely and happily. Attached find the minutes from the IETF 63 meeting. As always, please make sure that we've correctly attributed your statements, spelled your name correctly and captured the discussion. For these particular minutes, there are a few questions we had about what was said/meant and we've marked these with "XXX:". If you see an "XXX:" near one of your comments and can clarify please do.=20 You can send corrections here or to Mark and I personally. Thanks for looking them over and a productive meeting. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=minutes Content-Transfer-Encoding: quoted-printable TCPM Tuesday, 2 August 2005 at 1815-1945 CEST Notes by Andrew McGregor, Ted's clarifications in []. Spelling corrections (only a few) unnoted. Chair's comments - state of the world (Ted): * rohc-tcp: TCP header compression Looking for input and document reviewers rohc wants committed reviewers, so be sure to contact them if you want credit as one. * F-RTO:=20 should be published shortly * NCR:=20 approaching WG last call; new draft more understandable; technical input sought. * ICMP soft errors:=20 being revised * ICMP attacks:=20 will be discussed in Vancouver; revision in progress Lars on UTO [see slides for content] Bob Braden: UTO is exactly? There's no idle timeout in RFC 793 Lars: Unacknowledged data time out. Abolade Gbadegesin: How does this relate to SO_MAXRT? Lars: That's an API for setting this locally. (later: maxrt is apparently defined in posix as a socket option) [After the meeting, Ted: I haven't been able to find it, but under FreeBSD and Linux, I believe the the sockopts to set UTO are SO_SNDTIMEO and SO_SNDTIMEO. Linux has sysctls to set the defaults tcp_retries{1,2}. XXX: Have I run these down correctly, or is there a POSIX sockopt I've missed?] Bob: count retransmissions instead of waiting for X time to pass as per 1122 [in UTO negotiations]. Joe Touch: Conflict between description in document and consequences of actual defined semantics. Description says 'negotiate' etc, but setting is unilateral. =20 Bob: It might be in the spirit of TCP to coordinate in the apps, i.e. provide an API, and allow apps to do their own policy. Ted: Hooks to do this [coordinate in the applications] are already there [in published RFCs], we intend to allow the stack to do it itself.=20 Abolade Gbadegesin: Makes sense to allow app to specify in real time units, have TCP figure it out in RTTs. Also, app doesn't know when this timer started, so it's hard to make use of this. Tim Shepard: Sympathetic to the problem, but don't see that carrying an option to the other end is the answer. Why not allow maximum system-wide, allow apps to turn it down, and have policy on purging. AG: How does knowing the other end's timeout help me cope with events? All that matters is my own timer. Ted: Let's take these offline. Jabber summary: jishac: So I think a way of summarizing Tim's comment and resulting discussion on UTO is that there are a couple of ways of looking at this:=20 1) current is that you have (in example on all of these numbers) a server that uses 5 sec but may be able to support a day dur. for some connections. UTO gives an app a way of requesting some of those resources=20 2) Server grants a higher dur. (and thus resources) to all connections but has a smart way of purging connections. and one may argue that the purging will be required with 1 anyways=20 F-RTO field testing, Kazunori Yamamoto Presenting test results showing reduction in spurious retransmissions due to use of Eifel and F-RTO. Bob B: is this intended to be published? KY: yes, that is the intention. [See slides for papers, Ted encouraged them to post to lists] Greg Daley: asking about number of runs when measuring spurious TOs. KY: don't have that number, "a lot" =20 Markku, Helsinki U: (co-author of F-RTO draft) interesting findings, similar to our results in an emulated network, we could make delay spikes quite frequent, which makes this much easier to see. It can be the case than when window is open, the RTT is longer and that is why we see more retransmissions due to a delay spike.=20 TCP Extensions for immediate retransmission, Lars Eggert Summarizes draft looking at mechanisms for forcing probes for connections with outages longer than an RTT. [See slides] Draft does not define specific connectivity indicators (as in, triggers for this behavior). Idea is that they be local, not deep in the network.=20 Basic idea, send away if you have a connectivity indicator. Implicitly, signal with triple-duplicate ACKs Explicitly, with a new option. LMDR and Retransmit-Now play in the same space. LMDR is a proposal to prevent over-aggressive behavior when switching to a slower link (f.e.) [ XXX: Lars/Andrew - what's f.e. short= for here? ]=20 Bob B: How does this relate to DTN? D=3Ddelay or disruption=20 Lars: if delay is too long, this doesn't apply, but it might in cars or trains.=20 Bob: is it of general application, or specialized? Tim: Phil Karn's NOS had mechanism for this sort of thing, 'tcp kick', which WAS useful. But should this be 'below' TCP in some sense... HIP or shim6 might activate this. Lars: We actually tested with HIP. But the security issues do remain.=20 Greg Daley: It's about path change indication, locators have changed. Maybe want to talk to internet area about carrying this information up and down the stack, and maybe even end-to-end... but only once per endpoint, not per TCP therefore mitigating the security issues.=20 AG: draft says that this doesn't change congestion control, it at least seems to violate packet conservation... it introduces extra packets unless endpoints know that the earlier packets have certainly gone. Do CIs announce time of disruption? Must be careful not to introduce unnecessary packets.=20 Ted: should be thought about Gorry: where do link indications come from? Are we looking at remote links?=20 Lars: no, that is not my idea. Markku: this could be very useful, but might like to see broader indication than simply reconnect; maybe 'link characteristics have now changed'=20 Lars: didn't want it to be too complex Wes Eddy [via Jabber]: that's the point of LMDR, and integrating rexmit-now with LMDR [XXX: Wes, please clarify this or we'll delete. Specifically, what's=20 the point of LDMR you're trying to draw out here - I think the asynchrony of the Jabber room is confusing the issue. ] Bill S[XXX:??]: million connections likely to be lots of places, so one packet per endpoint pair may not be that much of a win Aaron Falk: (at mic) The IAB has been working on documenting some of the many efforts on bringing link change indications into the stack in draft-iab-link-indications. When these mechanisms get deployed, people will start making stack "optimizations" to do this kind of stuff. The IETF should document how to do it right, if that is possible, or why not to do it, if not. Ted: Hum if you think that looking at TCP link indication is WG material.=20 [A hum was taken indicating approval for the question, but not overwhelming support. After Joe's clarification below no additional hums were taken. Ted's position is that there is interest in the area, but by no means is the topic or the draft a WG priority at this time. The issue is not closed by any means however and more list discussion is actively solicited.] Joe Touch: Question had too many negatives. Maybe WG should indicate where it breaks. Ted: Lets pursue this on list, there is interest in the field if not the specific document (on its own) IPR issues, Eifel response, RFC 4015 Jon P: IPR situation is uncertain. There are initial indications on ancestors of the current document, but not on it itself. However, have been anecdotal reports of IPR action taking place. Scott Bradner (via jabber): the point is that the IPR holder has asked for a NDA discussion to get a license to implement 4015 so its not so theoretical as Jon suggests Christian Huitema: encumbered to the point where many in the room cannot implement Ted: Scott says cannot directly address IPR in a document, but can say RFC is moved in status based on discussion of IPR Christian: try to implement, then can change status Scott B: cannot bless IPR claim by specifically referring to it. (many 'aah's) Ted: hear 'move to experimental with a note' Gorry: [The roadmap authors and WG] discarded another item [ XXX: I belive you're referring to jumbograms -- Gorry? ] on basis that it was not widely implemented Ted: that would be another reason Markku: there is another complication, proposed standard status was accidental.=20 Scott B: Christian is correct about 2026 in theory but we actually have no running code on that part of 2026 Scott B: I think it has been implemented which is how the question of the license came up=20 Ted: Hums showed strong support for moving RFC 4015 to the experimental section of the roadmap - mostly due to IPR concerns, but please post other arguments. Hums on other two options, "move to separate section" and "no change," received basically no support. Jon: this leaves the roadmap without any standards-track recommendations for this issue, do we really want that? Joe T: Is there another solution we want in the roadmap? Ted: F-RTO is a possibility Mark Allman: Not F-RTO. F-RTO is a detection algorithm and RFC 4015 is a response algorithm. Bob B: don't hold up the roadmap for that Ted: should we hold for that? Hum was to not delay the roadmap for a new spurious RTO response algorithm and the response was strong to proceed with that issue unaddressed in the roadmap - i.e., no response algorithm in the=20 "Recommended" section. --nVMJ2NtxeReIH9PS-- --f0KYrhQ4vYSV2aJu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC+PzsaUz3f+Zf+XsRAmnKAJ9W7t9oRn7Ybc0tj/C8SNPtKKgeFACg/l/0 ZWRK52pUPmnCl99qBgS1OzI= =znmE -----END PGP SIGNATURE----- --f0KYrhQ4vYSV2aJu-- --===============2067875695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2067875695==-- From tcpm-bounces@ietf.org Tue Aug 09 15:36:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Zto-00045f-4M; Tue, 09 Aug 2005 15:36:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Ztl-00045W-Pq for tcpm@megatron.ietf.org; Tue, 09 Aug 2005 15:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03030 for ; Tue, 9 Aug 2005 15:36:27 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2aRj-0002It-GZ for tcpm@ietf.org; Tue, 09 Aug 2005 16:11:36 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id j79JaKiu060639 for ; Tue, 9 Aug 2005 12:36:21 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 280D677A69D for ; Tue, 9 Aug 2005 15:36:19 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Ohio MIME-Version: 1.0 Date: Tue, 09 Aug 2005 15:36:19 -0400 Message-Id: <20050809193619.280D677A69D@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [tcpm] roadmap and ipr, take 3 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574188656==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1574188656== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- At the IETF meeting in Paris last week we seemed to reach tentative consensus on the path forward for the placement of RFC 4015 in the TCP roadmap document (there was also a bit of a thread on the list from before the meeting that you can re-visit in the archives). The sense of the room that we got in Paris was that RFC 4015 should be moved to the experimental section of the TCP roadmap - mostly due to IPR considerations. However, decisions are not made in meetings and so we are bringing the question to the list. So, two requests ... (1) If you object to moving RFC 4015 from the 'standard enhancements' section (section 3) of the TCP roadmap to the 'experimental extensions' section (section 4) of the TCP roadmap then please yell loudly. (2) If you have other reasons that you think RFC 4015 should be in the 'experimental extensions' section of the document, please voice those, as well (even if voiced in the meeting or previously). The game plan is that we'll wait to see what rolls in from this request, we'll ask the authors to make the changes (which will be fairly straightforward, I hope) and then we'll do a quick WGLC on the new text to make sure its right before passing it back to Jon. I am attaching the relevant section of the draft meeting notes below. Thanks! Mark & Ted > IPR issues, Eifel response, RFC 4015 > > Jon P: IPR situation is uncertain. There are initial indications > on ancestors of the current document, but not on it itself. > However, have been anecdotal reports of IPR action taking place. > > Scott Bradner (via jabber): the point is that the IPR holder has > asked for a NDA discussion to get a license to implement 4015 so > its not so theoretical as Jon suggests > > Christian Huitema: encumbered to the point where many in the room > cannot implement > > Ted: Scott says cannot directly address IPR in a document, but can > say RFC is moved in status based on discussion of IPR > > Christian: try to implement, then can change status > > Scott B: cannot bless IPR claim by specifically referring to it. > > (many 'aah's) > > Ted: hear 'move to experimental with a note' > > Gorry: [The roadmap authors and WG] discarded another item [ XXX: I belive > you're referring to jumbograms -- Gorry? ] on basis that it was > not widely implemented > > Ted: that would be another reason > > Markku: there is another complication, proposed standard status > was accidental. > > Scott B: Christian is correct about 2026 in theory but we actually > have no running code on that part of 2026 > Scott B: I think it has been implemented which is how the question > of the license came up > > Ted: Hums showed strong support for moving RFC 4015 to the > experimental section of the roadmap - mostly due to IPR concerns, > but please post other arguments. Hums on other two options, > "move to separate section" and "no change," received basically no > support. > > Jon: this leaves the roadmap without any standards-track > recommendations for this issue, do we really want that? > > Joe T: Is there another solution we want in the roadmap? > Ted: F-RTO is a possibility > Mark Allman: Not F-RTO. F-RTO is a detection algorithm and RFC > 4015 is a response algorithm. > Bob B: don't hold up the roadmap for that > Ted: should we hold for that? > > Hum was to not delay the roadmap for a new spurious RTO response > algorithm and the response was strong to proceed with that issue > unaddressed in the roadmap - i.e., no response algorithm in the > "Recommended" section. --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC+QWzWyrrWs4yIs4RAnAoAJ97S88Bwe3LMxjFtVPtf99I15DX3ACglnGk bYMR5Xgmi/Ip+hMTHoR1reg= =NBXv -----END PGP SIGNATURE----- --=_bOundary-- --===============1574188656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1574188656==-- From tcpm-bounces@ietf.org Tue Aug 09 16:12:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aSv-0001Jy-VJ; Tue, 09 Aug 2005 16:12:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aSt-0001JO-O8 for tcpm@megatron.ietf.org; Tue, 09 Aug 2005 16:12:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09318 for ; Tue, 9 Aug 2005 16:12:44 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2b0p-0004rk-8M for tcpm@ietf.org; Tue, 09 Aug 2005 16:47:53 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j79K9uoJ018859; Tue, 9 Aug 2005 23:11:17 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 23:08:47 +0300 Received: from [172.19.11.119] ([172.19.11.119]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Aug 2005 23:08:47 +0300 Message-ID: <42F90E2F.2080502@nokia.com> Date: Tue, 09 Aug 2005 15:12:31 -0500 From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] roadmap and ipr, take 3 References: <20050809193619.280D677A69D@guns.icir.org> In-Reply-To: <20050809193619.280D677A69D@guns.icir.org> X-Enigmail-Version: 0.92.0.0 X-OriginalArrivalTime: 09 Aug 2005 20:08:47.0821 (UTC) FILETIME=[26F6B7D0:01C59D1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1752760040==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1752760040== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA51ED98D55F6F34B7CE6BD69" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA51ED98D55F6F34B7CE6BD69 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > (2) If you have other reasons that you think RFC 4015 should be in the > 'experimental extensions' section of the document, please voice > those, as well (even if voiced in the meeting or previously). > Because the response is not sufficient in all the different cases (i.e., when STOs occur due to mobility). I guess I already said in my last e-mail. Thanks Yogesh --------------enigA51ED98D55F6F34B7CE6BD69 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQEVAwUBQvkOM4KsoYbjxS8bAQj1SQf/RrwXrO/aS5NSKOFw51w+OLIuq+lMKGpR jRvW8J7ST9mJFkhNrY2Oz1JGGFqBqSU+loKdO4M19Tpgx8rvsFjAmt2YE0OvtT00 wnDLXssgvIegK2H23SAL8YnHMthkD9PmGQwuFz1tuplTPanISqe3bWBsiG29tU1Y XGYB8WB0wtGlRRinJn5gdQiFYNbXmiIm2uITBZGh9XhbLTwL25mJktW/5RGIDXEr ORp76MC31gMZRhfh/pHv+SluyC8IBlF/7wM7SeNIONrX4Lr0Y1Bu6Q4k0ONVS3zB JbfgpMJAVh6lY5d5Xn/D2omm/4ooF85cKF4KCfZ/T3pFGGG2BaE2sA== =Pv1Y -----END PGP SIGNATURE----- --------------enigA51ED98D55F6F34B7CE6BD69-- --===============1752760040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1752760040==-- From tcpm-bounces@ietf.org Tue Aug 09 16:45:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ayu-0001VO-EP; Tue, 09 Aug 2005 16:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ayq-0001VG-5m for tcpm@megatron.ietf.org; Tue, 09 Aug 2005 16:45:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13508 for ; Tue, 9 Aug 2005 16:45:45 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2bWn-0006er-K3 for tcpm@ietf.org; Tue, 09 Aug 2005 17:20:55 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j79Khaf12784; Tue, 9 Aug 2005 13:43:36 -0700 (PDT) Message-ID: <42F91578.3070704@isi.edu> Date: Tue, 09 Aug 2005 13:43:36 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] roadmap and ipr, take 3 References: <20050809193619.280D677A69D@guns.icir.org> In-Reply-To: <20050809193619.280D677A69D@guns.icir.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Allman wrote: > > Folks- > > At the IETF meeting in Paris last week we seemed to reach tentative > consensus on the path forward for the placement of RFC 4015 in the TCP > roadmap document (there was also a bit of a thread on the list from > before the meeting that you can re-visit in the archives). > > The sense of the room that we got in Paris was that RFC 4015 should be > moved to the experimental section of the TCP roadmap - mostly due to IPR > considerations. However, decisions are not made in meetings and so we > are bringing the question to the list. > > So, two requests ... > > (1) If you object to moving RFC 4015 from the 'standard enhancements' > section (section 3) of the TCP roadmap to the 'experimental > extensions' section (section 4) of the TCP roadmap then please yell > loudly. > > (2) If you have other reasons that you think RFC 4015 should be in the > 'experimental extensions' section of the document, please voice > those, as well (even if voiced in the meeting or previously). Dependence on experimental extensions, as noted at the meeting (though didn't appear in the minutes). > The game plan is that we'll wait to see what rolls in from this request, > we'll ask the authors to make the changes (which will be fairly > straightforward, I hope) and then we'll do a quick WGLC on the new text > to make sure its right before passing it back to Jon. > > I am attaching the relevant section of the draft meeting notes below. > > Thanks! > > Mark & Ted > > > > > > >>IPR issues, Eifel response, RFC 4015 >> >> Jon P: IPR situation is uncertain. There are initial indications >> on ancestors of the current document, but not on it itself. >> However, have been anecdotal reports of IPR action taking place. >> >> Scott Bradner (via jabber): the point is that the IPR holder has >> asked for a NDA discussion to get a license to implement 4015 so >> its not so theoretical as Jon suggests >> >> Christian Huitema: encumbered to the point where many in the room >> cannot implement >> >> Ted: Scott says cannot directly address IPR in a document, but can >> say RFC is moved in status based on discussion of IPR >> >> Christian: try to implement, then can change status >> >> Scott B: cannot bless IPR claim by specifically referring to it. >> >> (many 'aah's) >> >> Ted: hear 'move to experimental with a note' >> >> Gorry: [The roadmap authors and WG] discarded another item [ XXX: I belive >> you're referring to jumbograms -- Gorry? ] on basis that it was >> not widely implemented >> >> Ted: that would be another reason >> >> Markku: there is another complication, proposed standard status >> was accidental. >> >> Scott B: Christian is correct about 2026 in theory but we actually >> have no running code on that part of 2026 >> Scott B: I think it has been implemented which is how the question >> of the license came up >> >> Ted: Hums showed strong support for moving RFC 4015 to the >> experimental section of the roadmap - mostly due to IPR concerns, >> but please post other arguments. Hums on other two options, >> "move to separate section" and "no change," received basically no >> support. >> >> Jon: this leaves the roadmap without any standards-track >> recommendations for this issue, do we really want that? >> >> Joe T: Is there another solution we want in the roadmap? >> Ted: F-RTO is a possibility >> Mark Allman: Not F-RTO. F-RTO is a detection algorithm and RFC >> 4015 is a response algorithm. >> Bob B: don't hold up the roadmap for that >> Ted: should we hold for that? >> >> Hum was to not delay the roadmap for a new spurious RTO response >> algorithm and the response was strong to proceed with that issue >> unaddressed in the roadmap - i.e., no response algorithm in the >> "Recommended" section. > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+RV4E5f5cImnZrsRArpUAJ9m29kuHXo2+uffbwgurndIfuhbPwCfcDh/ Bit+FNKnWwaq9nNIfj2qiT8= =Db1S -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 10 10:43:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rnw-0004tA-56; Wed, 10 Aug 2005 10:43:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rns-0004lj-EM for tcpm@megatron.ietf.org; Wed, 10 Aug 2005 10:43:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03314 for ; Wed, 10 Aug 2005 10:43:34 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2sLo-0000WK-HR for tcpm@ietf.org; Wed, 10 Aug 2005 11:18:52 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id j7AEhA1Y073518; Wed, 10 Aug 2005 07:43:10 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id E8AEE77A9D9; Wed, 10 Aug 2005 10:43:08 -0400 (EDT) To: Yogesh Prem Swami From: Mark Allman Subject: Re: [tcpm] roadmap and ipr, take 3 In-Reply-To: <42F90E2F.2080502@nokia.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Given to Fly MIME-Version: 1.0 Date: Wed, 10 Aug 2005 10:43:08 -0400 Message-Id: <20050810144308.E8AEE77A9D9@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0237006287==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0237006287== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Yogesh- > Because the response is not sufficient in all the different cases > (i.e., when STOs occur due to mobility). I guess I already said in my > last e-mail. I am trying to figure out if we should be noting this in the roadmap. Your previous email to the list said: >> Coming back to technical issues, I believe that spurious timeouts are >> extremely rare in the absence of mobility, where eifel response is >> applicable. In the presence of mobility, there is a need for a >> broader solution than just spurious timeouts. In fact, eifel response >> could *potentially* be dangerous for spurious timeouts after subnet >> change because it simply restores the congestion window without much >> regard to properties of the new path. So, the claim is that spurious RTOs are nearly always caused by mobility and if that is the case then Eifel can actually be the wrong approach because it restores the previous sending rate. Do I understand that correctly? As pushback I will note that in some of the papers and discussion on Eifel and other schemes folks have talked about short disconnections (with no data loss) that are specifically allowed for in the design of packet radios as being the motivation for detecting and somehow reacting to spurious timeouts. Can someone who knows about this sort of thing comment on whether spurious timeout detection is useful outside the mobility context? Pasi? Gorry? (As the author of an RFC (3708) that detects spurious retransmissions, I'll note that my motivation in the space was to counter spurious retransmits caused by reordering and not spurious timeouts.) Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC+hJ8WyrrWs4yIs4RAgdRAJ0S7QEnhMZtJUb9T9f9xdn3kEy9RACgmLd7 PL7kePO2tVzPJT+vlfi9ZAM= =Eagh -----END PGP SIGNATURE----- --=_bOundary-- --===============0237006287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0237006287==-- From tcpm-bounces@ietf.org Wed Aug 10 10:56:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2s0D-0007oK-2h; Wed, 10 Aug 2005 10:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2s0B-0007o6-2Z for tcpm@megatron.ietf.org; Wed, 10 Aug 2005 10:56:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04143 for ; Wed, 10 Aug 2005 10:56:16 -0400 (EDT) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2sYH-0000xU-TC for tcpm@ietf.org; Wed, 10 Aug 2005 11:31:35 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id C44FAC2C6 for ; Wed, 10 Aug 2005 10:56:01 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j7AEu1GT019817; Wed, 10 Aug 2005 10:56:01 -0400 (EDT) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j7AEu025011280; Wed, 10 Aug 2005 10:56:01 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j7AEu0kL011275; Wed, 10 Aug 2005 10:56:00 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id CA1CA4FD4E; Wed, 10 Aug 2005 10:53:47 -0400 (EDT) Date: Wed, 10 Aug 2005 10:53:47 -0400 From: Wesley Eddy To: Mark Allman Subject: Re: [tcpm] roadmap and ipr, take 3 Message-ID: <20050810145347.GF27560@grc.nasa.gov> References: <42F90E2F.2080502@nokia.com> <20050810144308.E8AEE77A9D9@guns.icir.org> Mime-Version: 1.0 In-Reply-To: <20050810144308.E8AEE77A9D9@guns.icir.org> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org, Yogesh Prem Swami X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0509839419==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0509839419== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NGIwU0kFl1Z1A3An" Content-Disposition: inline --NGIwU0kFl1Z1A3An Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 10, 2005 at 10:43:08AM -0400, Mark Allman wrote: >=20 > Yogesh- >=20 > > Because the response is not sufficient in all the different cases > > (i.e., when STOs occur due to mobility). I guess I already said in my > > last e-mail. >=20 > I am trying to figure out if we should be noting this in the roadmap. > Your previous email to the list said: >=20 We might simply note that it's primarily useful when STOs are due to reordering, and either either note or leave out, that there is some question about its application to mobility-induced timeouts. -Wes --=20 Wesley M. Eddy Verizon FNS / NASA GRC http://roland.grc.nasa.gov/~weddy --NGIwU0kFl1Z1A3An Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC+hT6zBuYqbnj3IwRAlomAJ9yDAUTMuql32abYG9elxh+fKCeLwCfTZ4d 5CjVq6CjTdWclIvsa8o/VuQ= =ca8y -----END PGP SIGNATURE----- --NGIwU0kFl1Z1A3An-- --===============0509839419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0509839419==-- From tcpm-bounces@ietf.org Wed Aug 10 11:01:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2s5D-0000Uq-AO; Wed, 10 Aug 2005 11:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2s54-0000SY-U0 for tcpm@megatron.ietf.org; Wed, 10 Aug 2005 11:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04440 for ; Wed, 10 Aug 2005 11:01:20 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2sdB-000189-UN for tcpm@ietf.org; Wed, 10 Aug 2005 11:36:39 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id j7AF1IoJ073724; Wed, 10 Aug 2005 08:01:18 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1C81777A9D9; Wed, 10 Aug 2005 11:01:17 -0400 (EDT) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [tcpm] roadmap and ipr, take 3 In-Reply-To: <20050810145347.GF27560@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Given to Fly MIME-Version: 1.0 Date: Wed, 10 Aug 2005 11:01:17 -0400 Message-Id: <20050810150117.1C81777A9D9@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, Yogesh Prem Swami X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1522448676==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1522448676== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > We might simply note that it's primarily useful when STOs are due to > reordering, and either either note or leave out, that there is some > question about its application to mobility-induced timeouts. I didn't mean to claim that it is helpful for reordering. I am not sure that it really is. Reordering usually busts fast retransmit. So, I don't agree with adding the above note about RFC4015 is "primarily" about reordering. I'd still like to hear from the folks who are savvy in these wireless links. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC+ha9WyrrWs4yIs4RAoC4AJ47LlUMGaVybTrKXjJyGXe9xcFy8gCfVXkS 9l9W/b68DYVwzXiswKLdgqc= =Qby4 -----END PGP SIGNATURE----- --=_bOundary-- --===============1522448676== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1522448676==-- From tcpm-bounces@ietf.org Wed Aug 10 13:09:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2u4z-0007el-9C; Wed, 10 Aug 2005 13:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2u4w-0007ed-Oa for tcpm@megatron.ietf.org; Wed, 10 Aug 2005 13:09:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11598 for ; Wed, 10 Aug 2005 13:09:19 -0400 (EDT) Received: from fep01-0.kolumbus.fi ([193.229.0.41] helo=fep01-app.kolumbus.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2ud4-0004lZ-EJ for tcpm@ietf.org; Wed, 10 Aug 2005 13:44:40 -0400 Received: from a84-230-92-128.elisa-laajakaista.fi ([84.230.92.128]) by fep01-app.kolumbus.fi with ESMTP id <20050810170910.BDAI23558.fep01-app.kolumbus.fi@a84-230-92-128.elisa-laajakaista.fi>; Wed, 10 Aug 2005 20:09:10 +0300 Subject: Re: [tcpm] roadmap and ipr, take 3 From: Pasi Sarolahti To: Mark Allman In-Reply-To: <20050810144308.E8AEE77A9D9@guns.icir.org> References: <20050810144308.E8AEE77A9D9@guns.icir.org> Date: Wed, 10 Aug 2005 20:08:11 +0300 Message-Id: <1123693691.10553.30.camel@viivi> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org, Yogesh Prem Swami X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1795434882==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1795434882== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Jcp+VO3v3qAQzkq6RPlP" --=-Jcp+VO3v3qAQzkq6RPlP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-08-10 at 10:43 -0400, Mark Allman wrote: > Can someone who knows about this sort of thing comment on whether > spurious timeout detection is useful outside the mobility context? > Pasi? Gorry? There could be persistently reliable links along the path that might cause timeout. For example, some people are known to use PPP-over-SSH (yuck). It is true that the spurious timeout work has been motivated by the mobility world so far, but I don't think TCP can generally say anything sure about the reason of a spurious timeout, if detected. If we had an imaginary oracle RTO estimator that would have avoided a spurious timeout that occurred with standard RTO estimator, the cwnd would have remained at its earlier level. That's the reasoning I have explained myself about RFC 4015. I believe reliably declaring a mobility event would require an explicit mobility trigger of some kind. But I don't know how important this aspect is in the move-to- experimental-section discussion. Personally, I think it is a bit inconsistent that all the detection algorithms are experimental, but the response is in standards track. So I support moving RFC 4015 to experimental section of the roadmap. (And if my memory doesn't fail me, I recall that it wasn't quite clear to everyone during the WGLC what the status was going to be. Below is a flashback from tsvwg archives) ----- Message-Id: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> Date: Wed, 05 Mar 2003 12:51:52 +0100 To: tsvwg@ietf.org From: Reiner Ludwig we have updated the draft that specifies the Eifel response algorithm: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-03.= txt [...] We would greatly welcome more feedback. Otherwise, we believe that this draft is ready for WG-last-call to become=20 an experimental RFC. ----- - Pasi --=-Jcp+VO3v3qAQzkq6RPlP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBC+jR7oNa7NH1G2csRAhd5AJ9CwzRj+yyhP2XVKKFvZsvSUaDOBACeIClO lr4d8J9pSS51AnYt+ggTnto= =9HPp -----END PGP SIGNATURE----- --=-Jcp+VO3v3qAQzkq6RPlP-- --===============1795434882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1795434882==-- From tcpm-bounces@ietf.org Wed Aug 10 13:19:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uEz-0001o0-IK; Wed, 10 Aug 2005 13:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uEy-0001ni-GG for tcpm@megatron.ietf.org; Wed, 10 Aug 2005 13:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12050 for ; Wed, 10 Aug 2005 13:19:41 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2un6-00050T-Kf for tcpm@ietf.org; Wed, 10 Aug 2005 13:55:02 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7AHJWdW008776; Wed, 10 Aug 2005 20:19:33 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Aug 2005 20:19:35 +0300 Received: from [172.19.11.119] ([172.19.11.119]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Aug 2005 20:19:34 +0300 Message-ID: <42FA3803.1020101@nokia.com> Date: Wed, 10 Aug 2005 12:23:15 -0500 From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] roadmap and ipr, take 3 References: <20050810144308.E8AEE77A9D9@guns.icir.org> In-Reply-To: <20050810144308.E8AEE77A9D9@guns.icir.org> X-Enigmail-Version: 0.92.0.0 X-OriginalArrivalTime: 10 Aug 2005 17:19:34.0787 (UTC) FILETIME=[ADB26D30:01C59DCF] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1490219925==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1490219925== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7F102E98749322E1ACDC9B2E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F102E98749322E1ACDC9B2E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mark, Please see in line: ext Mark Allman wrote: > Yogesh- > > >>Because the response is not sufficient in all the different cases >>(i.e., when STOs occur due to mobility). I guess I already said in my >>last e-mail. > > > I am trying to figure out if we should be noting this in the roadmap. > Your previous email to the list said: > I'm okay either way. A short note might be good, but if it's going to delay the road map draft then it's probably not worth it. The road map draft is mature enough to move forward in my opinion. > >>>Coming back to technical issues, I believe that spurious timeouts are >>>extremely rare in the absence of mobility, where eifel response is >>>applicable. In the presence of mobility, there is a need for a >>>broader solution than just spurious timeouts. In fact, eifel response >>>could *potentially* be dangerous for spurious timeouts after subnet >>>change because it simply restores the congestion window without much >>>regard to properties of the new path. > > > So, the claim is that spurious RTOs are nearly always caused by mobility > and if that is the case then Eifel can actually be the wrong approach > because it restores the previous sending rate. Do I understand that > correctly? > This is my current understanding. Also Floyd and Gurtov have a similar observation in their wireless link modeling paper (http://www.cs.helsinki.fi/u/gurtov/papers/mtp.pdf). Thanks Yogesh --------------enig7F102E98749322E1ACDC9B2E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQEVAwUBQvo4CoKsoYbjxS8bAQiprQf+KdSUuI4E0E2Uzx9nnUNg8AVmav5PDAPr 8rmsAc4Vj4ReCgx6IjttY/+BOASten2vEclR/hdmdg0yBBaW2V/Cbekb2G/uzn1O S4ytAnSIkNExJAllGDXFLmnM+98FG5uAST4hJrJxdrDrqcbAiBnXaolvyLXEagro Xaj02hrKlrbTX7USv7JyT3O6Mq8kQ3bPC1xQG4ieomFcY/NdgEGzMUe8GXPGJmPX kW/MPygeXEgXy1RIaDP2wZQLIhsYibvQuFaxmvxX7JYm32JD1WLDyoYgqVuw1VXK J6ZF9GlMvP2dQUscmgeLU3GPLiLUSaOiu69HSWAWejwP7znRjWlNnw== =V0Hh -----END PGP SIGNATURE----- --------------enig7F102E98749322E1ACDC9B2E-- --===============1490219925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1490219925==-- From tcpm-bounces@ietf.org Wed Aug 10 13:25:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uK9-0003PD-4M; Wed, 10 Aug 2005 13:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uK7-0003N0-6X for tcpm@megatron.ietf.org; Wed, 10 Aug 2005 13:25:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12367 for ; Wed, 10 Aug 2005 13:25:00 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2usF-0005Al-IV for tcpm@ietf.org; Wed, 10 Aug 2005 14:00:20 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.4/8.13.4) with ESMTP id j7AHOqVt063713; Wed, 10 Aug 2005 10:24:52 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.1/Submit) id j7AHOqCa063712; Wed, 10 Aug 2005 10:24:52 -0700 (PDT) (envelope-from faber) Date: Wed, 10 Aug 2005 10:24:52 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] roadmap and ipr, take 3 Message-ID: <20050810172452.GA44518@pun.isi.edu> References: <20050809193619.280D677A69D@guns.icir.org> <42F91578.3070704@isi.edu> Mime-Version: 1.0 In-Reply-To: <42F91578.3070704@isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1108101461==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1108101461== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 09, 2005 at 01:43:36PM -0700, Joe Touch wrote: > Mark Allman wrote: > > (2) If you have other reasons that you think RFC 4015 should be in the > > 'experimental extensions' section of the document, please voice > > those, as well (even if voiced in the meeting or previously). >=20 > Dependence on experimental extensions, as noted at the meeting (though > didn't appear in the minutes). I don't want to lose that in the minutes. Can you please send me a short bot of text to insert in them? Thanks. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC+jhkaUz3f+Zf+XsRApT/AJ9AwKCfOuxItL2RKyAFdVfHF8HGPwCfYPr3 CbSASy6koVDhdUqkhCj7eE4= =7Mnk -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- --===============1108101461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1108101461==-- From tcpm-bounces@ietf.org Thu Aug 11 15:55:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3J93-0006Fl-8f; Thu, 11 Aug 2005 15:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3J92-0006Fg-2S for tcpm@megatron.ietf.org; Thu, 11 Aug 2005 15:55:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24315 for ; Thu, 11 Aug 2005 15:55:14 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3JhO-0007BE-Jo for tcpm@ietf.org; Thu, 11 Aug 2005 16:30:47 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id F1E9F39A; Thu, 11 Aug 2005 15:55:13 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 89A9F395; Thu, 11 Aug 2005 15:55:13 -0400 (EDT) Date: Thu, 11 Aug 2005 15:55:13 -0400 (EDT) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Joe Touch Subject: Re: [tcpm] roadmap and ipr, take 3 In-Reply-To: <42F91578.3070704@isi.edu> Message-ID: References: <20050809193619.280D677A69D@guns.icir.org> <42F91578.3070704@isi.edu> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on louie.udel.edu X-Spam-Status: No, score=-3.8 required=4.1 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >> (2) If you have other reasons that you think RFC 4015 should be in the >> 'experimental extensions' section of the document, please voice >> those, as well (even if voiced in the meeting or previously). > > Dependence on experimental extensions, [...] I, too, would like to see this reason mentioned. - jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 11 16:00:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JEZ-0007Z4-PX; Thu, 11 Aug 2005 16:00:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JEY-0007Yz-HL for tcpm@megatron.ietf.org; Thu, 11 Aug 2005 16:00:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24586 for ; Thu, 11 Aug 2005 16:00:56 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Jmv-0007Kh-4z for tcpm@ietf.org; Thu, 11 Aug 2005 16:36:30 -0400 Received: by wproxy.gmail.com with SMTP id i11so488776wra for ; Thu, 11 Aug 2005 13:00:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZWYQD8Jw8nQFLzJ1a7M1/uIyIguJspTksnvFMj2U6BnEMz1qzT0xllqt+GNiaqQkHiXGk1jrHgv9dQ791hsMhyir3W2ExACz/REu0SwDL6LDJX0cNIv9t+nginpU5SLtXFcVhWAciTCyPzF/DoKvRDVLnaPnJPXykjkclC7u8/U= Received: by 10.54.46.5 with SMTP id t5mr238861wrt; Thu, 11 Aug 2005 13:00:48 -0700 (PDT) Received: by 10.54.104.14 with HTTP; Thu, 11 Aug 2005 13:00:48 -0700 (PDT) Message-ID: <1ef225900508111300202b25fc@mail.gmail.com> Date: Thu, 11 Aug 2005 21:00:48 +0100 From: Arjuna Sathiaseelan To: tcpm@ietf.org In-Reply-To: <42fb7656.1c0da144.2e4f.ffffdd57SMTPIN_ADDED@mx.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42fb7656.1c0da144.2e4f.ffffdd57SMTPIN_ADDED@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: [tcpm] Re: tcpm Digest, Vol 16, Issue 5 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Dear Reiner, As I was going through "The Eifel Algorithm Making TCP Robust Against Spurious Retransmissions" paper - a question arose - so would like to clarify with you. >From the paper: "On receipt of the first ACK after the timeout, the sender must interpret this ACK as acknowledging the retransmission, and must assume that all other outstanding segments have also been lost" You say that a spurious retransmission timeout, could cause go-back-n retransmissions..i.e the ACKs the sender receives are mistaken to be those of the retransmitted packets rather than the original packets and the sender which is already in slow start could end up retransmitting those packets again. Am I right? Now the question - if the receiver receives all the original packets - wouldnt it send a cumulative ACK acknowledging all the packets and thus the sender would know all the packets have been received at the receiver. So the sender need not retransmit all those packets again. So why the sender "must" assume that the outstanding packets have been lost? Is it because of the assumption that the receiver may have reneged? I am not able to comprehend this. Please let me know. Thanks. Regards, Arjuna _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 17 21:30:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ZEQ-0008Q0-Vn; Wed, 17 Aug 2005 21:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ZEP-0008Pn-BU for tcpm@megatron.ietf.org; Wed, 17 Aug 2005 21:30:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17968 for ; Wed, 17 Aug 2005 21:30:07 -0400 (EDT) From: kazunori@nim.yrp.nttdocomo.co.jp Received: from mail0.yrp.nttdocomo.co.jp ([202.245.184.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Zo1-0005dx-UB for tcpm@ietf.org; Wed, 17 Aug 2005 22:07:00 -0400 Received: from nim.yrp.nttdocomo.co.jp (nim.yrp.nttdocomo.co.jp [172.21.88.12]) by mail0.yrp.nttdocomo.co.jp (8.12.11/8.12.11) with SMTP id j7I1Tcn3022357 for ; Thu, 18 Aug 2005 10:29:43 +0900 Received: (qmail 3783 invoked from network); 18 Aug 2005 10:29:33 +0900 Received: from unknown (HELO kazunori) (172.21.234.173) by nim.yrp.nttdocomo.co.jp with SMTP; 18 Aug 2005 10:29:33 +0900 To: Date: Thu, 18 Aug 2005 10:31:43 +0900 Message-ID: <007b01c5a394$973b2450$adea15ac@mig.yrp.nttdocomo.co.jp> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae Cc: Subject: [tcpm] Papers concerning field test results of F-RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1492447595==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1492447595== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C5A3E0.0722CC50" This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C5A3E0.0722CC50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, Our papers concerning the presentation, "Field test results of F-RTO", in Paris meeting are available on the web site. We would appreciate it if we have your comments on them. "Field Test Results of F-RTO," presentation slides in the 63rd IETF meeting, Aug. 2005. http://www.docomolabsresearchers-usa.com/~tkawahara/frto_test_results_63 ietf_tcpm.ppt K. Yamamoto, H. Suzuki, N. Ishikawa, A. Hokamura, K. Sekiguchi, and Y. Suwa, "Effects of F-RTO and Eifel Response Algorithms for W-CDMA and HSDPA Networks," Wireless Personal Multimedia Communications(WPMC)'05, Sept. 2005. http://www.docomolabsresearchers-usa.com/~tkawahara/wpmc2005_yamamoto.pd f A. Hokamura, K. Sekiguchi, Y. Suwa, K. Yamamoto, H. Suzuki, and N. Ishikawa, "Performance Evaluation of F-RTO and Eifel Response Algorithms over W-CDMA Packet Network," Wireless Personal Multimedia Communications(WPMC)'05, Sept. 2005. http://www.docomolabsresearchers-usa.com/~tkawahara/wpmc2005_hokamura.pd f Best regards, Kazunori Yamamoto ----- Kazunori Yamamoto NTT DoCoMo, Inc. ------=_NextPart_000_007C_01C5A3E0.0722CC50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello, =

 

Our papers concerning the presentation, “Field test results of F-RTO”, = in Paris meeting =

are available on the web site. We = would appreciate it if we have your comments on = them.

 

"Field Test Results of F-RTO," presentation slides in the 63rd IETF meeting, = Aug. 2005.

http://www.docomolabsresearchers-usa.com/~tkawahara= /frto_test_results_63ietf_tcpm.ppt

&n= bsp;

 K. Yamamoto, H. Suzuki, N. Ishikawa, A. Hokamura, K. Sekiguchi, and Y. Suwa,
 "Effects of F-RTO and Eifel = Response Algorithms for W-CDMA and HSDPA Networks,"
 Wireless Personal Multimedia Communications(WPMC)'05, Sept. = 2005.

http://www.docomolabsresearchers-usa.com/~tkawahara/wpmc2005_ya= mamoto.pdf

 

A. Hokamura, K. Sekiguchi, Y. Suwa, K. Yamamoto, H. Suzuki, and N. Ishikawa,
"Performance Evaluation of F-RTO and Eifel Response Algorithms over W-CDMA Packet = Network," 

Wireless = Personal Multimedia Communications(WPMC)'05, Sept. = 2005.

http://www.docomolabsresearchers-usa.com/~tkawahara/wpmc2005_ho= kamura.pdf

&n= bsp;

Best = regards,

 

Kazunori = Yamamoto

 

-----

Kazunori Yamamoto

NTT DoCoMo, Inc.

------=_NextPart_000_007C_01C5A3E0.0722CC50-- --===============1492447595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1492447595==-- From tcpm-bounces@ietf.org Thu Aug 18 16:10:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qiu-0004AJ-9K; Thu, 18 Aug 2005 16:10:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qiq-00046X-Mn for tcpm@megatron.ietf.org; Thu, 18 Aug 2005 16:10:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01188 for ; Thu, 18 Aug 2005 16:10:42 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5rIc-0005OW-UO for tcpm@ietf.org; Thu, 18 Aug 2005 16:47:45 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j7IKABRt003709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Aug 2005 21:10:11 +0100 (BST) Message-ID: <4304EB22.3040702@erg.abdn.ac.uk> Date: Thu, 18 Aug 2005 21:10:10 +0100 From: gorry fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] roadmap and ipr, take 3 References: <20050810144308.E8AEE77A9D9@guns.icir.org> In-Reply-To: <20050810144308.E8AEE77A9D9@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-5.899, required 5, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60) X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Yogesh Prem Swami X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gf@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > As pushback I will note that in some of the papers and discussion on > Eifel and other schemes folks have talked about short disconnections > (with no data loss) that are specifically allowed for in the design of > packet radios as being the motivation for detecting and somehow reacting > to spurious timeouts. > > Can someone who knows about this sort of thing comment on whether > spurious timeout detection is useful outside the mobility context? > Pasi? Gorry? > I believe there are "wireless" i.e. radio environments in which delay from the under-lying infrastructure can vary, (L2 re-routing, bandwidth-on-demand, contention-access to L2, ARQ mechanisms, etc). > (As the author of an RFC (3708) that detects spurious retransmissions, > I'll note that my motivation in the space was to counter spurious > retransmits caused by reordering and not spurious timeouts.) > > Thanks! > > allman > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm I would like to see Eifel in the roadmap, but I questioned the position on the basis of lack of deployment experience in current mainstream TCP stacks - without this experience, it seems "experimental" in an IETF sense. I noted the similarity of this to the case for Jumbogram support. Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 19 16:37:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Dcf-0000pN-Vk; Fri, 19 Aug 2005 16:37:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Dcd-0000om-96 for tcpm@megatron.ietf.org; Fri, 19 Aug 2005 16:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04096 for ; Fri, 19 Aug 2005 16:37:48 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6ECc-0007kV-RY for tcpm@ietf.org; Fri, 19 Aug 2005 17:15:04 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.4/8.13.4) with ESMTP id j7JKbblX019847; Fri, 19 Aug 2005 13:37:37 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.1/Submit) id j7JKbapV019846; Fri, 19 Aug 2005 13:37:36 -0700 (PDT) (envelope-from faber) Date: Fri, 19 Aug 2005 13:37:36 -0700 From: Ted Faber To: kazunori@nim.yrp.nttdocomo.co.jp Subject: Re: [tcpm] Papers concerning field test results of F-RTO Message-ID: <20050819203736.GG15372@pun.isi.edu> References: <007b01c5a394$973b2450$adea15ac@mig.yrp.nttdocomo.co.jp> Mime-Version: 1.0 In-Reply-To: <007b01c5a394$973b2450$adea15ac@mig.yrp.nttdocomo.co.jp> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298382406==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1298382406== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fCcDWlUEdh43YKr8" Content-Disposition: inline --fCcDWlUEdh43YKr8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2005 at 10:31:43AM +0900, kazunori@nim.yrp.nttdocomo.co.jp = wrote: > Hello,=20 > =20 > Our papers concerning the presentation, "Field test results of F-RTO", > in Paris meeting are available on the web site. We would appreciate it > if we have your comments on them. Thanks for the pointers. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --fCcDWlUEdh43YKr8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDBkMQaUz3f+Zf+XsRAj59AKDa86+j6260U927rq68opmK2nf/mgCbBMx3 Yvhg2dZ25Tgex3P0LXQQ7yY= =z+L9 -----END PGP SIGNATURE----- --fCcDWlUEdh43YKr8-- --===============1298382406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1298382406==-- From tcpm-bounces@ietf.org Fri Aug 26 07:05:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8c1Y-0004Uv-7u; Fri, 26 Aug 2005 07:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8c1W-0004Sb-Ho for tcpm@megatron.ietf.org; Fri, 26 Aug 2005 07:05:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10974 for ; Fri, 26 Aug 2005 07:05:23 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8c2E-0001aw-Bc for tcpm@ietf.org; Fri, 26 Aug 2005 07:06:11 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8813A1115; Fri, 26 Aug 2005 13:05:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 13:05:06 +0200 Received: from esealnt744.al.sw.ericsson.se ([153.88.251.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 13:05:06 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Aug 2005 13:05:06 +0200 Message-ID: From: "Reiner Ludwig (AC/EDD)" To: "'tcpm@ietf.org'" , "'sob@harvard.edu'" Subject: Re: [tcpm] ipr and the tcp roadmap Date: Fri, 26 Aug 2005 13:04:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Aug 2005 11:05:06.0655 (UTC) FILETIME=[04418EF0:01C5AA2E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Sorry for this late reply, but I was out of e-mail coverage for some time. I just want to add a few more facts for this group to consider, and will also add my personal view. More facts: ----------- * Ericsson has played by the IETF rules (RFC2026) right from the start: when I first presented Eifel at the IETF, I also declared that Ericsson might have IPR related to Eifel. Going even beyond RFC2026, Ericsson has even submitted http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL ensuring that the research community would have no problem experimenting with the Eifel algorithm. * Ericsson will continue to comply with RFC2026; in particular to Sec. 10.3.2. (C): Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The Working Group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the IETF Executive Director in this effort. The results of this procedure shall not affect advancement of a specification along the standards track, except that the IESG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the IETF Executive Director, and made available. The IESG may also direct that a summary of the results be included in any RFC published containing the specification. * Ericsson has in 2000 already submitted such a "written assurance": http://www.ietf.org/ietf/IPR/ERICSSON-General which is also cited in http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL * It is an industry standard that licensing negotiations including the disclosure of licensing terms are only conducted under a non-disclosure agreement (NDA). I.e., without signing an NDA company A does not even get to see the licensing terms that company B would put on to the table. * One company that approached Ericsson to obtain a license for the Eifel algorithm was not willing to sign the required NDA. My very own personal view (not necessarily Ericsson's view): ------------------------------------------------------------ * The members of TSVWG, and the IESG knew for a long time that Ericsson had declared that Ericsson might have IPR related to Eifel. Still, both the TSVWG and the IESG approved RFC4015 as Proposed Standard. Thus, I don't understand on what basis the TCPM WG would not list RFC4015 under the "standard mechanisms" section of the TCP roadmap document. To me that would seem like the TCPM WG could overrule decisions that have already been made by the TSVWG and the IESG. At this point, RFC4015 is a standards track specification, and the way I understand how the IETF works only the IESG can change that status. Please, correct me if I'm wrong. * I would not be suprised if the mentioned company that is not willing to sign the NDA required to enter into licensing negotiations with Ericsson is the same company that seems to leave the impression within the IETF that Ericsson was not acting reasonable in its licensing business. * I want to make this very explicit: Ericsson is a fair player that will stick to its assurance: http://www.ietf.org/ietf/IPR/ERICSSON-General. And I'm sure that in the near future there will be companies that will be able to attest that. ///Reiner Mark Allman wrote: > > Folks- > > We tried to start some discussion about IPR-ed RFCs within the TCP > roadmap document some time back, but were not what one might call > "clear" on the subject. So, this is a second try. To make sure this > note is correct on the IPR issues Scott Bradner has reviewed it. > > To step back for a moment and remind folks... When Jon Peterson was > doing his AD review of the TCP roadmap after it passed WGLC he sent us a > query as to whether the WG had discussed the inclusion and/or placement > of the Eifel response algorithm (RFC 4015) with regards to the IPR claim > filed about this document. The answer to Jon's question is that the WG > did not consider the question and so process-wise we need to back-track > and think about whether or how this statement impacts the roadmap. > > The facts: > > * RFC 4015 has been published as a proposed standard. > > * According to IETF policy, Ericsson has filed an IPR statement on RFC > 4015 (& RFC 3522). The statement is at: > > http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL > > Loosely speaking the statement grants open source operating systems > the ability to use Eifel without paying royalties, but non-open > source implementations are not covered. > > * We (Scott) know of at least one case in which Ericsson has, in fact, > has requested royalties in exchange for a license to use the > technology in RFC 4015. > > * Currently, the TCP roadmap (draft-ietf-tcpm-tcp-roadmap-04.txt) > lists the Eifel response algorithm (RFC 4015) in section 3 on > "standard enhancements". The first sentence in that section says... > > "This section describes recommended TCP modifications that > improve performance and security." > > The question on the table is then with the above context how (if at all) > should RFC 4015 be handled in the roadmap document? The space of > possible ways to handle Eifel in the roadmap is something like this ... > > (1) We can remove mention from the roadmap all together. > > (2) We can leave the roadmap exactly how it is. That is, the WG can > decide that the IPR issues do not merit the changing of the > classification of the technology at all. > > (3) We can move the RFC 4015 item (including all text) from the > "standard mechanisms" section of the document to some other existing > place in the document - for instance the "experimental extensions" > section. (This would require a bit of change to the header of the > "experimental extensions" section in that it would need to indicate > inclusiveness for things that we need more licensing experience with > (for instance).) > > (4) We could create a new section of the document that explicitly has no > recommendation attached to the items listed within. > > RFC 4015 naturally falls within the "standard mechanisms" if you just > look at its current status (PS) and the placement of other changes with > the same status. So, any movement of RFC 4015 from that location will > have to be explained in the document. This is another area of general > confusion as far as IPR goes --- at least to some of us. Our > discussions with Scott indicate: > > * While we can discuss the IPR in all its gory detail, its > implications, etc. on the mailing list the document cannot comment > on the IPR itself. The IETF does not make IPR judgments -- even if > individual members might use such judgments as part of their input > to the process. Therefore, the document cannot say that we think > the IPR claim is bogus and wouldn't stand up, or that we think the > license is fair, or it's not, etc. > > * To justify the placement of Eifel somewhere besides where it would > naturally fall we can comment on the WG's decision making process > within the document. That is, we can say that we have placed RFC > 4015 in section X following a WG discussion about the IPR claimed on > the technology outlined within 4015. > > We need to hear thoughts on which path folks think we should be taking > with regards to the inclusion and the placement of RFC 4015 within the > roadmap such that we can clear up this process issue and get the > document back in the hands of the IESG. > > Thanks in advance! > > Mark & Ted > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 26 07:58:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8crD-0004Vk-G9; Fri, 26 Aug 2005 07:58:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8crB-0004T7-G7 for tcpm@megatron.ietf.org; Fri, 26 Aug 2005 07:58:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13331 for ; Fri, 26 Aug 2005 07:58:47 -0400 (EDT) Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8crt-0003Ip-HM for tcpm@ietf.org; Fri, 26 Aug 2005 07:59:33 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1E8cqu-00050I-00; Fri, 26 Aug 2005 07:58:32 -0400 From: Tim Shepard To: "Reiner Ludwig (AC/EDD)" Subject: Re: [tcpm] ipr and the tcp roadmap In-reply-to: Your message of Fri, 26 Aug 2005 13:04:58 +0200. Date: Fri, 26 Aug 2005 07:58:32 -0400 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "'tcpm@ietf.org'" , "'sob@harvard.edu'" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > * It is an industry standard that licensing negotiations including the > disclosure of licensing terms are only conducted under a non-disclosure > agreement (NDA). I.e., without signing an NDA company A does not even > get to see the licensing terms that company B would put on to the table. I have never heard of anything like that. Even if it is "industry standard", it is the first time I've heard anyone allege that one has to sign an NDA to learn what the "reasonable, non-discriminatory terms" are. It would seem that the NDA is to ensure that no one can ever discover (and disclose) that the terms are in fact *not* non-discriminatory. If in fact the terms are non-discriminatory, then there can be no reason to require an NDA to divulge what the terms are. I cannot think of any other reason. The patent and the lack of a general license available to everyone makes the value of deploying this technology less than the cost of the hassle. So it would be appropriate for the IETF to move this off of the standards track, because of the patent. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 26 09:22:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e9w-0005kV-8q; Fri, 26 Aug 2005 09:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e9u-0005kQ-Bg for tcpm@megatron.ietf.org; Fri, 26 Aug 2005 09:22:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18868 for ; Fri, 26 Aug 2005 09:22:12 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8eAd-0006Jt-KM for tcpm@ietf.org; Fri, 26 Aug 2005 09:23:00 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id j7QDM75O042382; Fri, 26 Aug 2005 06:22:07 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 266ED77AA1D; Fri, 26 Aug 2005 09:22:06 -0400 (EDT) To: "Reiner Ludwig (AC/EDD)" From: Mark Allman Subject: Re: [tcpm] ipr and the tcp roadmap In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Street Fighting Man MIME-Version: 1.0 Date: Fri, 26 Aug 2005 09:22:06 -0400 Message-Id: <20050826132206.266ED77AA1D@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: "'tcpm@ietf.org'" , "'sob@harvard.edu'" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0636583082==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0636583082== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Thanks for the note Reiner! > * The members of TSVWG, and the IESG knew for a long time that Ericsson > had declared that Ericsson might have IPR related to Eifel. Still, > both the TSVWG and the IESG approved RFC4015 as Proposed > Standard. Thus, I don't understand on what basis the TCPM WG would not > list RFC4015 under the "standard mechanisms" section of the TCP > roadmap document. To me that would seem like the TCPM WG could > overrule decisions that have already been made by the TSVWG and the > IESG. At this point, RFC4015 is a standards track specification, and > the way I understand how the IETF works only the IESG can change that > status. Please, correct me if I'm wrong. Let's try to be more clear. No matter if or where or how RFC 4015 is cited in the roadmap (even when the roadmap becomes an RFC itself), RFC 4015's status will not be changed from Proposed Standard. RFC 4015's status could be changed from Proposed Standard by other means. But, the roadmap document is an informational, non-normative, document and the document makes zero mention of changing RFC 4015's status. In other words, even if the roadmap document were to list RFC 4015 in the "experimental extensions" section of the document for whatever reason (e.g., because the WG/IETF does not want to "strongly encourage" RFC 4015's use or because of concerns about RFC 4015 depending on experimental RFCs or whatever else) that does not mean that a TCP implementation that supports RFC 4015 is any more or less standards compliant than if the roadmap were to list RFC 4015 in the "standard mechanisms" section. Folks- from the recent meeting in Paris and the comments on the list it would seem as if consensus is that RFC 4015 should be moved to the "experimental extensions" section of the roadmap. If you disagree, please speak up soon because we'd really like to get this issue closed and get the document moving again. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDDxd+WyrrWs4yIs4RAra/AKCNuS7JiKpOB8k909GAkgsmVUhDTwCfarzh ZoQ6rrbuvW+irKiixw16lgY= =AeEo -----END PGP SIGNATURE----- --=_bOundary-- --===============0636583082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0636583082==-- From tcpm-bounces@ietf.org Fri Aug 26 09:42:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8eTD-0002x0-VU; Fri, 26 Aug 2005 09:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8eTB-0002wf-P5 for tcpm@megatron.ietf.org; Fri, 26 Aug 2005 09:42:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19954 for ; Fri, 26 Aug 2005 09:42:06 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8eTr-0006xV-BD for tcpm@ietf.org; Fri, 26 Aug 2005 09:42:53 -0400 Received: from [70.194.60.177] (177.sub-70-194-60.myvzw.com [70.194.60.177]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7QDejh07032; Fri, 26 Aug 2005 06:40:46 -0700 (PDT) Message-ID: <430F1BD5.70502@isi.edu> Date: Fri, 26 Aug 2005 06:40:37 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Reiner Ludwig (AC/EDD)" Subject: Re: [tcpm] ipr and the tcp roadmap References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "'tcpm@ietf.org'" , "'sob@harvard.edu'" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1948456767==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1948456767== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig16637390C0466235BBDD49BF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16637390C0466235BBDD49BF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reiner Ludwig (AC/EDD) wrote: ... > My very own personal view (not necessarily Ericsson's view): > ------------------------------------------------------------ > > * The members of TSVWG, and the IESG knew for a long time that Ericsson > had declared that Ericsson might have IPR related to Eifel. Still, both > the TSVWG and the IESG approved RFC4015 as Proposed Standard. Thus, I > don't understand on what basis the TCPM WG would not list RFC4015 under > the "standard mechanisms" section of the TCP roadmap document. To me > that would seem like the TCPM WG could overrule decisions that have > already been made by the TSVWG and the IESG. At this point, RFC4015 is a > standards track specification, and the way I understand how the IETF > works only the IESG can change that status. Please, correct me if I'm wrong. The sections of the document reflect, IMO, more of the actual status of the document than IETF standards-track, e.g., some experimental extensions are informational. In that same spirit, some standards-track docs are experimental as well, in the sense that although PS, they may appear not to be gaining momentum to go to DS. Joe --------------enig16637390C0466235BBDD49BF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDDxvVE5f5cImnZrsRAibUAKCPbCQT2qhzM/eHL4ykS2XSMdEW6ACg75Ky cb2CjmFUEOCY+G2uaCUHIyY= =zL4G -----END PGP SIGNATURE----- --------------enig16637390C0466235BBDD49BF-- --===============1948456767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1948456767==-- From tcpm-bounces@ietf.org Fri Aug 26 11:22:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8g2J-0005On-Fw; Fri, 26 Aug 2005 11:22:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8g2I-0005Oi-MF for tcpm@megatron.ietf.org; Fri, 26 Aug 2005 11:22:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26429 for ; Fri, 26 Aug 2005 11:22:28 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8g32-0001tK-6k for tcpm@ietf.org; Fri, 26 Aug 2005 11:23:17 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.4/8.13.4) with ESMTP id j7QFM6oD091360; Fri, 26 Aug 2005 08:22:06 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.1/Submit) id j7QFM5wY091359; Fri, 26 Aug 2005 08:22:05 -0700 (PDT) (envelope-from faber) Date: Fri, 26 Aug 2005 08:22:05 -0700 From: Ted Faber To: Tim Shepard Subject: Re: [tcpm] ipr and the tcp roadmap Message-ID: <20050826152205.GA91249@pun.isi.edu> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "'tcpm@ietf.org'" , "Reiner Ludwig \(AC/EDD\)" , "'sob@harvard.edu'" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0161672064==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0161672064== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 26, 2005 at 07:58:32AM -0400, Tim Shepard wrote: > The patent and the lack of a general license available to everyone > makes the value of deploying this technology less than the cost of the > hassle. So it would be appropriate for the IETF to move this off of > the standards track, because of the patent. While that's a defensible opinion, it's not the issue on the table. That issue is where the roadmap places Eifel in its structure. That structure is related to the IETF standards structure, but not isomorphic to it. I'm not sure how one might move an published IETF standard off the standards track, but that's not what tcpm is trying to do right now. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDDzOdaUz3f+Zf+XsRAsPcAJ4/XxghGEShxLhbJeIlRyzkTOKgUACeMBOv d3p0rdSDyZ61W6mkM9O9tus= =L6kf -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- --===============0161672064== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0161672064==-- From tcpm-bounces@ietf.org Fri Aug 26 13:29:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8i1T-0000yS-DN; Fri, 26 Aug 2005 13:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8i1R-0000yN-Uz for tcpm@megatron.ietf.org; Fri, 26 Aug 2005 13:29:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03011 for ; Fri, 26 Aug 2005 13:29:42 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8i2C-0006Dc-Dr for tcpm@ietf.org; Fri, 26 Aug 2005 13:30:33 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id j7QHTSFU044617; Fri, 26 Aug 2005 10:29:28 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id EA16D77AA1D; Fri, 26 Aug 2005 13:29:26 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Street Fighting Man MIME-Version: 1.0 Date: Fri, 26 Aug 2005 13:29:26 -0400 Message-Id: <20050826172926.EA16D77AA1D@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Ethan Blanton , Josh Blanton Subject: [tcpm] a different scheme for reacting to spurious RTOs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0120414037==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0120414037== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- In Paris it was noted that Eifel was the only way to react to detected spurious timeouts during the meeting (that is, the only way specified in IETF documents). Some of us thought about this after the meeting and wondered if we could come up with a reasonable alternative. We have a small idea and a correspondingly small draft (surely a virtue!). Our feeling is that the idea and the principles behind it are solid. Our intent is not to say this scheme is better than the Eifel response -- just that this is a reasonable alternative that someone could use if they wanted to. We'd very much appreciate comments on the draft, which is: Mark Allman, Ethan Blanton, Josh Blanton. Using Spurious Retransmissions to Adapt the Retransmission Timeout. August 2005. Internet-Draft draft-allman-rto-backoff-00.txt (work in progress). http://www.icir.org/mallman/papers/draft-allman-rto-backoff-00.txt (And, also in the i-d archive at this point.) Thanks in advance! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDD1F2WyrrWs4yIs4RAq7wAJ9fUOmD3dgiiUajVlyzr3EJU/Vi2wCdHplb CotkSOP+dlX80OAjM4XOMP4= =TP7m -----END PGP SIGNATURE----- --=_bOundary-- --===============0120414037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0120414037==-- From tcpm-bounces@ietf.org Sat Aug 27 02:47:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8uT0-0003zY-2X; Sat, 27 Aug 2005 02:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8uSv-0003zQ-OV for tcpm@megatron.ietf.org; Sat, 27 Aug 2005 02:47:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29193 for ; Sat, 27 Aug 2005 02:46:56 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8uTn-0006Zw-5n for tcpm@ietf.org; Sat, 27 Aug 2005 02:47:52 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5AFEBCC1; Sat, 27 Aug 2005 08:46:38 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 Aug 2005 08:46:37 +0200 Received: from eed.ericsson.se ([164.48.133.33]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 Aug 2005 08:46:37 +0200 Received: from [164.48.123.177] (rac177pc.edd.ericsson.se [164.48.123.177]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id IAA07678; Sat, 27 Aug 2005 08:46:34 +0200 (MET DST) Message-ID: <43100B55.5080605@ericsson.com> Date: Sat, 27 Aug 2005 08:42:29 +0200 From: Reiner Ludwig User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] ipr and the tcp roadmap References: <20050826132206.266ED77AA1D@guns.icir.org> In-Reply-To: <20050826132206.266ED77AA1D@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2005 06:46:37.0165 (UTC) FILETIME=[124AF1D0:01C5AAD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'sob@harvard.edu'" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Mark, all of what you wrote in your e-mail below is fine with me. With my previous mail to this list I just wanted to point out clearly that 'company_A requests royalties for a technology' is not equivalent with 'company_A is "bad"'. I know, nobody said that Ericsson was "bad", but certain statements made in e-mails or on corridors at IETF meetings can be easily misunderstood. This IPR/licensing stuff is every day business in the industry. And as long as this is carried out under reasonable and fair terms there is nothing wrong with that. The industry (not only in IT) is quite different from the collaborative research community. Companies that don't protect their development investments with IPR can get bitten. I'm sure that most companies that develop technology of some sort would agree to that. I have met a number of people, in particular from the academic side of the research community, that are not really aware of that, or even have the simplistic attitude "IPR = Evil". And from my personal experience I must say that one has a good chance to meet such people within the IETF. Concerning the roadmap document I would like to make the following proposal. Rename the section "standard mechanisms" to "recommended mechanisms". Maybe add that the word 'recommended' has nothing to do with how it's defined in RFC2119. Then I would be fine with putting RFC4015 into the "experimental extensions" section if there is text that explains why RFC4015 (being a standards track spec.) is not placed into the "recommended mechanisms" section. ///Reiner Mark Allman wrote: > Thanks for the note Reiner! > > >>* The members of TSVWG, and the IESG knew for a long time that Ericsson >>had declared that Ericsson might have IPR related to Eifel. Still, >>both the TSVWG and the IESG approved RFC4015 as Proposed >>Standard. Thus, I don't understand on what basis the TCPM WG would not >>list RFC4015 under the "standard mechanisms" section of the TCP >>roadmap document. To me that would seem like the TCPM WG could >>overrule decisions that have already been made by the TSVWG and the >>IESG. At this point, RFC4015 is a standards track specification, and >>the way I understand how the IETF works only the IESG can change that >>status. Please, correct me if I'm wrong. > > > Let's try to be more clear. No matter if or where or how RFC 4015 is > cited in the roadmap (even when the roadmap becomes an RFC itself), RFC > 4015's status will not be changed from Proposed Standard. RFC 4015's > status could be changed from Proposed Standard by other means. But, the > roadmap document is an informational, non-normative, document and the > document makes zero mention of changing RFC 4015's status. > > In other words, even if the roadmap document were to list RFC 4015 in > the "experimental extensions" section of the document for whatever > reason (e.g., because the WG/IETF does not want to "strongly encourage" > RFC 4015's use or because of concerns about RFC 4015 depending on > experimental RFCs or whatever else) that does not mean that a TCP > implementation that supports RFC 4015 is any more or less standards > compliant than if the roadmap were to list RFC 4015 in the "standard > mechanisms" section. > > Folks- from the recent meeting in Paris and the comments on the list it > would seem as if consensus is that RFC 4015 should be moved to the > "experimental extensions" section of the roadmap. If you disagree, > please speak up soon because we'd really like to get this issue closed > and get the document moving again. > > allman > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 29 03:12:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dp8-0006Qz-Ao; Mon, 29 Aug 2005 03:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dp7-0006Qp-4c for tcpm@megatron.ietf.org; Mon, 29 Aug 2005 03:12:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20869 for ; Mon, 29 Aug 2005 03:12:51 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9dqN-0005Jm-Jn for tcpm@ietf.org; Mon, 29 Aug 2005 03:14:13 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F06C1B81 for ; Mon, 29 Aug 2005 09:12:49 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 09:12:48 +0200 Received: from eed.ericsson.se ([164.48.133.33]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 09:12:48 +0200 Received: from [164.48.135.162] (dhcp5-162.eed.ericsson.se [164.48.135.162]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id JAA04113; Mon, 29 Aug 2005 09:12:47 +0200 (MET DST) Message-ID: <4312B56F.4000504@ericsson.com> Date: Mon, 29 Aug 2005 09:12:47 +0200 From: Reiner Ludwig User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig Subject: Re: [tcpm] ipr and the tcp roadmap References: <43100B55.5080605@ericsson.com> In-Reply-To: <43100B55.5080605@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2005 07:12:48.0095 (UTC) FILETIME=[0F7756F0:01C5AC69] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org ... and adding on second thought ... Reiner Ludwig wrote: > Concerning the roadmap document I would like to make the following > proposal. Rename the section "standard mechanisms" to "recommended > mechanisms". Maybe add that the word 'recommended' has nothing to do > with how it's defined in RFC2119. > > Then I would be fine with putting RFC4015 into the "experimental > extensions" section if there is text that explains why RFC4015 (being a > standards track spec.) is not placed into the "recommended mechanisms" > section. Maybe we could also change the section heading "experimental extensions" to simply "extensions". I think the current section headings are too easily associated with RFC status. And, the RFC status 'experimental' has this negative touch of being a technology/specification that the IETF is not really convinced of. ///Reiner _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 29 14:33:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oRP-0004Gf-5R; Mon, 29 Aug 2005 14:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oRM-0004GK-SP for tcpm@megatron.ietf.org; Mon, 29 Aug 2005 14:33:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26491 for ; Mon, 29 Aug 2005 14:33:03 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9oSi-0000YY-Hi for tcpm@ietf.org; Mon, 29 Aug 2005 14:34:31 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.4/8.13.4) with ESMTP id j7TIWo8d056958 for ; Mon, 29 Aug 2005 11:32:50 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.1/Submit) id j7TIWkuu056955 for tcpm@ietf.org; Mon, 29 Aug 2005 11:32:46 -0700 (PDT) (envelope-from faber) Date: Mon, 29 Aug 2005 11:32:46 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20050829183246.GH1075@pun.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Subject: [tcpm] Minutes - last chance to disapprove X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0193940521==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0193940521== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fmvA4kSBHQVZhkR6" Content-Disposition: inline --fmvA4kSBHQVZhkR6 Content-Type: multipart/mixed; boundary="0OWHXb1mYLuhj1Ox" Content-Disposition: inline --0OWHXb1mYLuhj1Ox Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Minutes are due this Friday. I've attached a version that includes the last set of updates I've received from people. If you feel that your contribution or that of someone else has been misrepresented or ignored, or if you'd like some point of discussion clarified, now is the time to speak up. Feel free to speak up on or off list. Thanks. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --0OWHXb1mYLuhj1Ox Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=minutes Content-Transfer-Encoding: quoted-printable TCPM Tuesday, 2 August 2005 at 1815-1945 CEST Notes by Andrew McGregor, Ted's clarifications in []. Spelling corrections (only a few) unnoted. Chair's comments - state of the world (Ted): * rohc-tcp: TCP header compression Looking for input and document reviewers rohc wants committed reviewers, so be sure to contact them if you want credit as one. * F-RTO:=20 should be published shortly * NCR:=20 approaching WG last call; new draft more understandable; technical input sought. * ICMP soft errors:=20 being revised * ICMP attacks:=20 will be discussed in Vancouver; revision in progress * TCP antispoof revision in progress; perhaps WGLC before Vancouver Lars on UTO [see slides for content] Bob Braden: UTO is exactly? There's no idle timeout in RFC 793 Lars: Unacknowledged data time out. Abolade Gbadegesin: How does this relate to SO_MAXRT? Lars: That's an API for setting this locally. (later: maxrt is apparently defined in posix as a socket option) [After the meeting, Ted: I haven't been able to find it, but under FreeBSD and Linux, I believe the the sockopts to set UTO are SO_SNDTIMEO and SO_SNDTIMEO. Linux has sysctls to set the defaults tcp_retries{1,2}. XXX: Have I run these down correctly, or is there a POSIX sockopt I've missed?] Bob: count retransmissions instead of waiting for X time to pass as per 1122 [in UTO negotiations]. Joe Touch: Conflict between description in document and consequences of actual defined semantics. Description says 'negotiate' etc, but setting is unilateral. =20 Bob: It might be in the spirit of TCP to coordinate in the apps, i.e. provide an API, and allow apps to do their own policy. Ted: Hooks to do this [coordinate in the applications] are already there [in published RFCs], we intend to allow the stack to do it itself.=20 Abolade Gbadegesin: Makes sense to allow app to specify in real time units, have TCP figure it out in RTTs. Also, app doesn't know when this timer started, so it's hard to make use of this. Tim Shepard: Sympathetic to the problem, but don't see that carrying an option to the other end is the answer. Why not allow maximum system-wide, allow apps to turn it down, and have policy on purging. AG: How does knowing the other end's timeout help me cope with events? All that matters is my own timer. Ted: Let's take these offline. Jabber summary: jishac: So I think a way of summarizing Tim's comment and resulting discussion on UTO is that there are a couple of ways of looking at this:=20 1) current is that you have (in example on all of these numbers) a server that uses 5 sec but may be able to support a day dur. for some connections. UTO gives an app a way of requesting some of those resources=20 2) Server grants a higher dur. (and thus resources) to all connections but has a smart way of purging connections. and one may argue that the purging will be required with 1 anyways=20 F-RTO field testing, Kazunori Yamamoto Presenting test results showing reduction in spurious retransmissions due to use of Eifel and F-RTO. Bob B: is this intended to be published? KY: yes, that is the intention. [See slides for papers, Ted encouraged them to post to lists] Greg Daley: asking about number of runs when measuring spurious TOs. KY: don't have that number, "a lot" =20 Markku, Helsinki U: (co-author of F-RTO draft) interesting findings, similar to our results in an emulated network, we could make delay spikes quite frequent, which makes this much easier to see. It can be the case than when window is open, the RTT is longer and that is why we see more retransmissions due to a delay spike.=20 TCP Extensions for immediate retransmission, Lars Eggert Summarizes draft looking at mechanisms for forcing probes for connections with outages longer than an RTT. [See slides] Draft does not define specific connectivity indicators (as in, triggers for this behavior). Idea is that they be local, not deep in the network.=20 Basic idea, send away if you have a connectivity indicator. Implicitly, signal with triple-duplicate ACKs Explicitly, with a new option. LMDR and Retransmit-Now play in the same space. LMDR is a proposal to prevent over-aggressive behavior when switching to a slower link (f.e.) [ XXX: Lars/Andrew - what's f.e. short= for here? ]=20 Bob B: How does this relate to DTN? D=3Ddelay or disruption=20 Lars: if delay is too long, this doesn't apply, but it might in cars or trains.=20 Bob: is it of general application, or specialized? Tim: Phil Karn's NOS had mechanism for this sort of thing, 'tcp kick', which WAS useful. But should this be 'below' TCP in some sense... HIP or shim6 might activate this. Lars: We actually tested with HIP. But the security issues do remain.=20 Greg Daley: It's about path change indication, locators have changed. Maybe want to talk to internet area about carrying this information up and down the stack, and maybe even end-to-end... but only once per endpoint, not per TCP therefore mitigating the security issues.=20 AG: draft says that this doesn't change congestion control, it at least seems to violate packet conservation... it introduces extra packets unless endpoints know that the earlier packets have certainly gone. Do CIs announce time of disruption? Must be careful not to introduce unnecessary packets.=20 Ted: should be thought about Gorry: where do link indications come from? Are we looking at remote links?=20 Lars: no, that is not my idea. Markku: this could be very useful, but might like to see broader indication than simply reconnect; maybe 'link characteristics have now changed'=20 Lars: didn't want it to be too complex Wes Eddy [via Jabber]: that's the point of LMDR, and integrating rexmit-now with LMDR. [ Wes says: The LMDR signalling specifically indicates that the physical = path has changed to some extent (at least at the "final hop"), i.e. it is a "l= ink characteristics have now changed" notification, as the speaker at the mic= was suggesting would be useful.] Bill S[XXX:??]: million connections likely to be lots of places, so one packet per endpoint pair may not be that much of a win Aaron Falk: (at mic) The IAB has been working on documenting some of the many efforts on bringing link change indications into the stack in draft-iab-link-indications. When these mechanisms get deployed, people will start making stack "optimizations" to do this kind of stuff. The IETF should document how to do it right, if that is possible, or why not to do it, if not. Ted: Hum if you think that looking at TCP link indication is WG material.=20 [A hum was taken indicating approval for the question, but not overwhelming support. After Joe's clarification below no additional hums were taken. Ted's position is that there is interest in the area, but by no means is the topic or the draft a WG priority at this time. The issue is not closed by any means however and more list discussion is actively solicited.] Joe Touch: Question had too many negatives. Maybe WG should indicate where it breaks. Ted: Lets pursue this on list, there is interest in the field if not the specific document (on its own) IPR issues, Eifel response, RFC 4015 Jon P: IPR situation is uncertain. There are initial indications on ancestors of the current document, but not on it itself. However, have been anecdotal reports of IPR action taking place. Scott Bradner (via jabber): the point is that the IPR holder has asked for a NDA discussion to get a license to implement 4015 so its not so theoretical as Jon suggests Christian Huitema: encumbered to the point where many in the room cannot implement Ted: Scott says cannot directly address IPR in a document, but can say RFC is moved in status based on discussion of IPR Christian: try to implement, then can change status Scott B: cannot bless IPR claim by specifically referring to it. (many 'aah's) Ted: hear 'move to experimental with a note' Gorry: [The roadmap authors and WG] discarded another item [ XXX: I belive you're referring to jumbograms -- Gorry? ] on basis that it was not widely implemented Ted: that would be another reason Markku: there is another complication, proposed standard status was accidental.=20 Scott B: Christian is correct about 2026 in theory but we actually have no running code on that part of 2026 Scott B: I think it has been implemented which is how the question of the license came up=20 Ted: Hums showed strong support for moving RFC 4015 to the experimental section of the roadmap - mostly due to IPR concerns, but please post other arguments. Hums on other two options, "move to separate section" and "no change," received basically no support. Joe T: note the other reason for moving 4015 to experimental section, i.e., dependence on experimental RFCs, and asked to include that in the comment in the roadmap Jon: this leaves the roadmap without any standards-track recommendations for this issue, do we really want that? Joe T: Is there another solution we want in the roadmap? Ted: F-RTO is a possibility Mark Allman: Not F-RTO. F-RTO is a detection algorithm and RFC 4015 is a response algorithm. Bob B: don't hold up the roadmap for that Ted: should we hold for that? Hum was to not delay the roadmap for a new spurious RTO response algorithm and the response was strong to proceed with that issue unaddressed in the roadmap - i.e., no response algorithm in the=20 "Recommended" section. --0OWHXb1mYLuhj1Ox-- --fmvA4kSBHQVZhkR6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDE1TOaUz3f+Zf+XsRAprIAKCuxsrCybVvUA1czL/G3AfRWdRMVgCg/mLg v5q9Tx/OfHbe2Us6VI0Sm08= =+Zlm -----END PGP SIGNATURE----- --fmvA4kSBHQVZhkR6-- --===============0193940521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0193940521==-- From tcpm-bounces@ietf.org Mon Aug 29 18:35:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sDV-000688-QO; Mon, 29 Aug 2005 18:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sDU-00067p-2U for tcpm@megatron.ietf.org; Mon, 29 Aug 2005 18:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16345 for ; Mon, 29 Aug 2005 18:34:57 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9sEh-0000zJ-24 for tcpm@ietf.org; Mon, 29 Aug 2005 18:36:16 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.4/8.13.4) with ESMTP id j7TMYb6H021824 for ; Mon, 29 Aug 2005 15:34:37 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.1/Submit) id j7TMYW75021811 for tcpm@ietf.org; Mon, 29 Aug 2005 15:34:32 -0700 (PDT) (envelope-from faber) Date: Mon, 29 Aug 2005 15:34:32 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] Minutes - last chance to disapprove Message-ID: <20050829223432.GC65852@pun.isi.edu> References: <20050829183246.GH1075@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: <20050829183246.GH1075@pun.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064369725==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2064369725== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BI5RvnYi6R4T2M87" Content-Disposition: inline --BI5RvnYi6R4T2M87 Content-Type: multipart/mixed; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Several people have jumped in with revisions. Current state is attached. Requests for additions to me or the list. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=minutes Content-Transfer-Encoding: quoted-printable TCPM Tuesday, 2 August 2005 at 1815-1945 CEST Notes by Andrew McGregor, Ted's clarifications in []. Spelling corrections (only a few) unnoted. Chair's comments - state of the world (Ted): * rohc-tcp: TCP header compression Looking for input and document reviewers rohc wants committed reviewers, so be sure to contact them if you want credit as one. * F-RTO:=20 should be published shortly * NCR:=20 approaching WG last call; new draft more understandable; technical input sought. * ICMP soft errors:=20 being revised * ICMP attacks:=20 will be discussed in Vancouver; revision in progress * TCP antispoof revision in progress; perhaps WGLC before Vancouver Lars on UTO [see slides for content] Bob Braden: UTO is exactly? There's no idle timeout in RFC 793 Lars: Unacknowledged data time out. Abolade Gbadegesin: How does this relate to SO_MAXRT? Lars: That's an API for setting this locally. (later: maxrt is apparently defined in posix as a socket option) [After the meeting, Ted: I haven't been able to find it, but under FreeBSD and Linux, I believe the the sockopts to set UTO are SO_SNDTIMEO and SO_SNDTIMEO. Linux has sysctls to set the defaults tcp_retries{1,2}. XXX: Have I run these down correctly, or is there a POSIX sockopt I've missed?] Bob: count retransmissions instead of waiting for X time to pass as per 1122 [in UTO negotiations]. Joe Touch: Conflict between description in document and consequences of actual defined semantics. Description says 'negotiate' etc, but setting is unilateral. =20 Bob: It might be in the spirit of TCP to coordinate in the apps, i.e. provide an API, and allow apps to do their own policy. Ted: Hooks to do this [coordinate in the applications] are already there [in published RFCs], we intend to allow the stack to do it itself.=20 Abolade Gbadegesin: Makes sense to allow app to specify in real time units, have TCP figure it out in RTTs. Also, app doesn't know when this timer started, so it's hard to make use of this. Tim Shepard: Sympathetic to the problem, but don't see that carrying an option to the other end is the answer. Why not allow maximum system-wide, allow apps to turn it down, and have policy on purging. AG: How does knowing the other end's timeout help me cope with events? All that matters is my own timer. Knowing the other end's timeout is of no use if I don't know that the other end has begun trying to send something to me. Typically, the only way to know the other end has begun trying to send something is if there's an upper layer protocol which gives me that information. But if I'm relying on an upper layer protocol to tell me when I should be expecting something from the other end, I may as well rely on that upper layer protocol to tell me the timeout as well. And in that case, I don't need UTO in the TCP layer. Ted: Let's take these offline. Jabber summary: jishac: So I think a way of summarizing Tim's comment and resulting discussion on UTO is that there are a couple of ways of looking at this:=20 1) current is that you have (in example on all of these numbers) a server that uses 5 sec but may be able to support a day dur. for some connections. UTO gives an app a way of requesting some of those resources=20 2) Server grants a higher dur. (and thus resources) to all connections but has a smart way of purging connections. and one may argue that the purging will be required with 1 anyways=20 F-RTO field testing, Kazunori Yamamoto Presenting test results showing reduction in spurious retransmissions due to use of Eifel and F-RTO. Bob B: is this intended to be published? KY: yes, that is the intention. [See slides for papers, Ted encouraged them to post to lists] Greg Daley: asking about number of runs when measuring spurious TOs. KY: don't have that number, "a lot" =20 Markku, Helsinki U: (co-author of F-RTO draft) interesting findings, similar to our results in an emulated network, we could make delay spikes quite frequent, which makes this much easier to see. It can be the case than when window is open, the RTT is longer and that is why we see more retransmissions due to a delay spike.=20 TCP Extensions for immediate retransmission, Lars Eggert Summarizes draft looking at mechanisms for forcing probes for connections with outages longer than an RTT. [See slides] Draft does not define specific connectivity indicators (as in, triggers for this behavior). Idea is that they be local, not deep in the network.=20 Basic idea, send away if you have a connectivity indicator. Implicitly, signal with triple-duplicate ACKs Explicitly, with a new option. LMDR and Retransmit-Now play in the same space. LMDR is a proposal to prevent over-aggressive behavior when switching to a slower link (f.e.) [ XXX: Lars/Andrew - what's f.e. short= for here? ]=20 Bob B: How does this relate to DTN? D=3Ddelay or disruption=20 Lars: if delay is too long, this doesn't apply, but it might in cars or trains.=20 Bob: is it of general application, or specialized? Tim: Phil Karn's NOS had mechanism for this sort of thing, 'tcp kick', which WAS useful. But should this be 'below' TCP in some sense... HIP or shim6 might activate this. Lars: We actually tested with HIP. But the security issues do remain.=20 Greg Daley: It's about path change indication, locators have changed. Maybe want to talk to internet area about carrying this information up and down the stack, and maybe even end-to-end... but only once per endpoint, not per TCP therefore mitigating the security issues.=20 AG: draft says that this doesn't change congestion control, it at least seems to violate packet conservation... it introduces extra packets unless endpoints know that the earlier packets have certainly gone. Do CIs announce time of disruption? Must be careful not to introduce unnecessary packets.=20 Ted: should be thought about Gorry: where do link indications come from? Are we looking at remote links?=20 Lars: no, that is not my idea. Markku: this could be very useful, but might like to see broader indication than simply reconnect; maybe 'link characteristics have now changed'=20 Lars: didn't want it to be too complex Wes Eddy [via Jabber]: that's the point of LMDR, and integrating rexmit-now with LMDR. [ Wes says: The LMDR signalling specifically indicates that the physical = path has changed to some extent (at least at the "final hop"), i.e. it is a "l= ink characteristics have now changed" notification, as the speaker at the mic= was suggesting would be useful.] Bill S[XXX:??]: million connections likely to be lots of places, so one packet per endpoint pair may not be that much of a win Aaron Falk: (at mic) The IAB has been working on documenting some of the many efforts on bringing link change indications into the stack in draft-iab-link-indications. When these mechanisms get deployed, people will start making stack "optimizations" to do this kind of stuff. The IETF should document how to do it right, if that is possible, or why not to do it, if not. Ted: Hum if you think that looking at TCP link indication is WG material.=20 [A hum was taken indicating approval for the question, but not overwhelming support. After Joe's clarification below no additional hums were taken. Ted's position is that there is interest in the area, but by no means is the topic or the draft a WG priority at this time. The issue is not closed by any means however and more list discussion is actively solicited.] Joe Touch: Question had too many negatives. Maybe WG should indicate where it breaks. Ted: Lets pursue this on list, there is interest in the field if not the specific document (on its own) IPR issues, Eifel response, RFC 4015 Jon P: IPR situation is uncertain. There are initial indications on ancestors of the current document, but not on it itself. However, have been anecdotal reports of IPR action taking place. Scott Bradner (via jabber): the point is that the IPR holder has asked for a NDA discussion to get a license to implement 4015 so its not so theoretical as Jon suggests Christian Huitema: encumbered to the point where many in the room cannot implement Ted: Scott says cannot directly address IPR in a document, but can say RFC is moved in status based on discussion of IPR Christian: try to implement, then can change status Scott B: cannot bless IPR claim by specifically referring to it. (many 'aah's) Ted: hear 'move to experimental with a note' Gorry: The roadmap authors and WG moved another standards-track document (jumbograms, RFC2675) to the "extensions" section, on the basis that it w= as not yet widely implemented. Could a similar case be made for Eifel? Ted: that would be another reason Markku: there is another complication, proposed standard status was accidental.=20 Scott B: Christian is correct about 2026 in theory but we actually have no running code on that part of 2026 Scott B: I think it has been implemented which is how the question of the license came up=20 Ted: Hums showed strong support for moving RFC 4015 to the experimental section of the roadmap - mostly due to IPR concerns, but please post other arguments. Hums on other two options, "move to separate section" and "no change," received basically no support. Joe T: note the other reason for moving 4015 to experimental section, i.e., dependence on experimental RFCs, and asked to include that in the comment in the roadmap Jon: this leaves the roadmap without any standards-track recommendations for this issue, do we really want that? Joe T: Is there another solution we want in the roadmap? Ted: F-RTO is a possibility Mark Allman: Not F-RTO. F-RTO is a detection algorithm and RFC 4015 is a response algorithm. Bob B: don't hold up the roadmap for that Ted: should we hold for that? Hum was to not delay the roadmap for a new spurious RTO response algorithm and the response was strong to proceed with that issue unaddressed in the roadmap - i.e., no response algorithm in the=20 "Recommended" section. --Clx92ZfkiYIKRjnr-- --BI5RvnYi6R4T2M87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDE414aUz3f+Zf+XsRAujzAKD1KYhyR/rP6wFt0PhzoD5C+nC81QCeLdUy En9GjU64tomoZB+32xVyk7M= =wyR3 -----END PGP SIGNATURE----- --BI5RvnYi6R4T2M87-- --===============2064369725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2064369725==-- From tcpm-bounces@ietf.org Tue Aug 30 14:43:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB5K-0001VD-Kl; Tue, 30 Aug 2005 14:43:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB5I-0001V5-3f for tcpm@megatron.ietf.org; Tue, 30 Aug 2005 14:43:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29939 for ; Tue, 30 Aug 2005 14:43:46 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAB6r-0001Sg-Uf for tcpm@ietf.org; Tue, 30 Aug 2005 14:45:27 -0400 Received: from [192.168.1.45] (pool-141-158-231-93.phil.east.verizon.net [141.158.231.93]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7UIgtk23594; Tue, 30 Aug 2005 11:42:55 -0700 (PDT) Message-ID: <4314A8A8.50009@isi.edu> Date: Tue, 30 Aug 2005 11:42:48 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig Subject: Re: [tcpm] ipr and the tcp roadmap References: <43100B55.5080605@ericsson.com> <4312B56F.4000504@ericsson.com> In-Reply-To: <4312B56F.4000504@ericsson.com> X-Enigmail-Version: 0.92.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "'tcpm@ietf.org'" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1408379737==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1408379737== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig272565ACB91ACEDC2137B4AB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig272565ACB91ACEDC2137B4AB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > ... and adding on second thought ... > > Reiner Ludwig wrote: > >> Concerning the roadmap document I would like to make the following >> proposal. Rename the section "standard mechanisms" to "recommended >> mechanisms". Maybe add that the word 'recommended' has nothing to do >> with how it's defined in RFC2119. >> >> Then I would be fine with putting RFC4015 into the "experimental >> extensions" section if there is text that explains why RFC4015 (being >> a standards track spec.) is not placed into the "recommended >> mechanisms" section. > > Maybe we could also change the section heading "experimental extensions" > to simply "extensions". I think the current section headings are too > easily associated with RFC status. And, the RFC status 'experimental' > has this negative touch of being a technology/specification that the > IETF is not really convinced of. The document has sections labelled 'standard', 'experimental', and 'historic', none of which necessarily corresponds to RFC status. Although we might continue to wordsmith the document ad infinitum to ensure that _everyone_ is clear on that point, IMO the doc is sufficient as-is - esp given the explanation in the intro. Joe --------------enig272565ACB91ACEDC2137B4AB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFKioE5f5cImnZrsRAgn6AJ4omgsQaZnTZlU7DzB3DBBn/K/+HQCgx7LS fK1mxXQhXSRY5L5dnK3bRP8= =9qIK -----END PGP SIGNATURE----- --------------enig272565ACB91ACEDC2137B4AB-- --===============1408379737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1408379737==--