From tcpm-bounces@ietf.org Thu Dec 01 08:31:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhoXH-0006H2-LU; Thu, 01 Dec 2005 08:31:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhoXG-0006Gx-W7 for tcpm@megatron.ietf.org; Thu, 01 Dec 2005 08:31:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20113 for ; Thu, 1 Dec 2005 08:30:55 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehorg-0005Xm-7i for tcpm@ietf.org; Thu, 01 Dec 2005 08:52:53 -0500 Received: (qmail 11815 invoked from network); 1 Dec 2005 13:31:55 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 1 Dec 2005 13:31:55 -0000 Message-Id: <6.2.0.14.0.20051201035418.0323fc48@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 01 Dec 2005 04:52:13 -0800 To: Gorry Fairhurst , , Lars Eggert From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: gorry@erg.abdn.ac.uk, Ted Faber , "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 At 09:30 a.m. 12/11/2005, Gorry Fairhurst wrote: >2) I don't yet see a compelling reason why this has to be negotiated at the >TCP-layer. We are altering a transport-protocol parameter. >This needs to be made clear. The new method does not completely >relieve the need for new code - Applications still need to add (some) code >to use the new socket option. You could set up the option with a system-wide toggle, for example. >3) If I understand, the mechanism is also per-direction of data transfer - >that is there is no *necessity* for both end hosts to agree on the same >values - although there are cases where they may both wish to (e.g.) >increase the default. It's not actually "per direction". But the option is just an advisory. i.e., you need not use the same value the remote peer is advertising. The draft contains a RECOMMENDED mechanism to choose the actual user timeout. The formula means, basically, "if both the local and remote UTO options are within the allowed higher and lower limits, choose the higher of the two", >4) My biggest worry that the current mechanism allows a remote party to >alter the behaviour of a sender, without the prior consent of the host >application. This seems wrong. I suggest it is important to consider whether >this is "sane" - it needs thought. In principle, it's the transport protocol that should handle this issue. The application itself should not care about this network-specific parameter. In any case, the option will not make things any worse. You have upper and lower limits for the user timeout. And it is assumed that, within those limits, things cannot go wrong. Under the recommended scheme, receiving an UTO won't cause connections to be aborted unnecessarily, as you will always choose the larger of the two UTOs. OTOH, the upper limit is supposed to prevent you from adopting a user timeout that is too large. >On the other hand, if the application calls-down the socket API saying this >is allowed, then this is fine, and I would have no problems on this point. In the case there's no socket API call and no system-wide toggle set to "on", the upper limit could be set up so that it equals the current User Timeout, as specified in the existing RFCs. This will basically mean that even upon receipt of an UTO, you won't actually alter the user timeout for the connection. (under the RECOMMENDED scheme, at least) >1) The wording describes sending the option in either/both the SYN v. >established states. The protocol should be made clearer about this. There had been some discussion on whether sending the option in the SYN segment should be required. The consensus was, IIRC, to make it a SHOULD rather than a MUST. >If an end-host SENDS the option in a SYN packet, is it expected in the >SYN-ACK? I'd say it SHOULD be included, as above. Lars? >- One thing that I think needs thought is that in the currently defined >method the Option in a SYN indicates "I may tell you that I wish to use a >different UTO" - In fact the exact opposite is much more useful tgo the >remote party: A SYN packet that carries an option saying "MY UTO is XXXX, >you may change it". I will go back to the draft, but... the option in the SYN segment basically says "I suport UTO, my current user timeout is XXXX". >2) A separate point, relating to options is that normal TCP behaviour >REQUIRES an option to be present in the SYN to use it later. Is it REQUIRED >to send this option in the SYN packet to be allowed to later use this once >the session is established? The WG consensus was, IIRC, not to make it a requirement. >4) Too low a UTO can be VERY harmful to the network service. I believe it is >very important to establish and define a sensible minimal value. All to many >times applications developers write and test code in a LAN environment and >only later deploy in the general Internet. We should not provide another >opportunity for people to use TCP in cute ways that will break on arbitrary >Internet paths! I think the minimum UTO must be REQUIRED. Requiring a minimum UTO means we should also make the recommended mechanism for choosing the UTO a "requirement", I think. (the recommended mechanism basically means "choose the larger of the two UTOs, and apply higher and lower limits to it). I'd agree with this. Lars? >5) I really feel uneasy about the idea of responding to a UTO option with >another UTO option. This seems bad protocol design, and should at least be >damped by imposing a minimum time before the response can be sent. > >Why do this? - I change my end, I request you to change yours. Is that not >it done? Actually, IIRC this was included in the draft for further feedback, as had been raised on the mailing-list. As for my own view on this issue, I agree with yours. If I change the user timeout, I'd send an UTO. Done. >6) Are there situations in which you wish to allow the UTO to be reduced >once the session has started. Allowing reduction of the UTO below the >actual PRTT (whatever that means in practice) provides a DOS vulnerability. In principle, the UTO will reflect the length of the periods of disconnection. If these periods change (for good) during the life of a connection, then it would make sense to reduce them. However, of course you have raised a good point. But I'd assume that the lower limit for the UTO will address your case. As stated in the draft, the limits need not be fixed. So, at any point, the lower limit should be, at least, the actual PRTT. >7) Are there any interoperability issues with NATs/Middleboxes when this is >included on a SYN packet? [MEDINA] has shown that there are not. >/on a satellite/on a non-geostationary satellite/ >- All satellites orbit, but the vast majority used for telecoms take an >orbit that is goeostationary. IIRC, this had been a contribution of (NASA's) Wesley Eddy. "Satellite" need not be a communications satellite, but could also be planetary body (i.e., a node operating from the Moon experiences periods of disconnection) P.S.: Skipped a few comments, but will come back to them. BTW, Thanks so much for your detailed feedback! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Dec 01 09:04:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp39-0003N6-0o; Thu, 01 Dec 2005 09:04:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp36-0003Hc-Mm for tcpm@megatron.ietf.org; Thu, 01 Dec 2005 09:04:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23931 for ; Thu, 1 Dec 2005 09:03:48 -0500 (EST) Received: from mail.cedarpointcom.com ([67.151.79.70] helo=exchange.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpNZ-0006fb-7z for tcpm@ietf.org; Thu, 01 Dec 2005 09:25:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Dec 2005 09:04:21 -0500 Message-ID: <9CDE330E7358724EA30D93598D24DE4A01488217@exchange.cedarpointcom.com> Thread-Topic: TCP maintenance question Thread-Index: AcX2gCDpWbRudGs6TiuPqdYLXu+XDA== From: "Craig Buffinton" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Subject: [tcpm] TCP maintenance question 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="===============1822235254==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1822235254== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F680.5E0220A5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F680.5E0220A5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Please forgive me if this question is not appropriate for this forum. =20 Should TCP accept connections from source port zero?=20 =20 As best I can determine port zero is valid and there are no prohibitions on its use, although iana does list it as reserved. =20 The reason for the question is that I maintain a TCP stack that asserts that the source port in a received syn packet must be non-zero.=20 A defect in a TCP proxy device caused the inadvertent use of port zero. It seems to me that the right action is to accept the connection.=20 If port zero is invalid then should a syn with source port zero be silently ignored or reset? =20 Thanks in advance=20 Craig Buffinton ------_=_NextPart_001_01C5F680.5E0220A5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Please forgive me if this question is not appropriate = for this forum.

 

Should TCP accept connections from source port zero? =

 

As best I can determine port zero is valid and there = are no prohibitions on its use, although iana does list it as = reserved.

 

The reason for the question is that I maintain a TCP = stack that asserts that the source port in a received syn packet must be non-zero. =

A defect in a TCP proxy device caused the inadvertent = use of port zero. It seems to me that the right action is to accept the = connection.

If port zero is invalid then should a syn with source = port zero be silently ignored or reset?

 

Thanks in advance

Craig Buffinton

------_=_NextPart_001_01C5F680.5E0220A5-- --===============1822235254== 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 --===============1822235254==-- From tcpm-bounces@ietf.org Thu Dec 01 10:50:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehqh7-00064I-Hi; Thu, 01 Dec 2005 10:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehqh5-00062t-Lx for tcpm@megatron.ietf.org; Thu, 01 Dec 2005 10:49:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07317 for ; Thu, 1 Dec 2005 10:49:13 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehr1X-0002Qc-Uu for tcpm@ietf.org; Thu, 01 Dec 2005 11:11:11 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB1FkGE10165; Thu, 1 Dec 2005 07:46:16 -0800 (PST) Message-ID: <438F1AC1.70803@isi.edu> Date: Thu, 01 Dec 2005 07:46:09 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Craig Buffinton Subject: Re: [tcpm] TCP maintenance question References: <9CDE330E7358724EA30D93598D24DE4A01488217@exchange.cedarpointcom.com> In-Reply-To: <9CDE330E7358724EA30D93598D24DE4A01488217@exchange.cedarpointcom.com> X-Enigmail-Version: 0.93.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: 02ec665d00de228c50c93ed6b5e4fc1a 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="===============1908552213==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1908552213== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4EB3D6ABDDE5E1E271BDDCA5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4EB3D6ABDDE5E1E271BDDCA5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Craig Buffinton wrote: > =20 >=20 > =20 >=20 > Please forgive me if this question is not appropriate for this forum. >=20 > =20 >=20 > Should TCP accept connections from source port zero? >=20 > =20 >=20 > As best I can determine port zero is valid and there are no prohibition= s > on its use, although iana does list it as reserved. IANA reservations apply to destination ports, not source ports. > The reason for the question is that I maintain a TCP stack that asserts= > that the source port in a received syn packet must be non-zero. Given the above, in the absence of any other evidence (which I could not find in 793 or 1122), that seems like a bug. > A defect in a TCP proxy device caused the inadvertent use of port zero.= > It seems to me that the right action is to accept the connection. >=20 > If port zero is invalid then should a syn with source port zero be > silently ignored or reset? If the port turns out to be invalid, it should result in an ICMP port unreachable reply, IMO. JOe --------------enig4EB3D6ABDDE5E1E271BDDCA5 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 Mozilla - http://enigmail.mozdev.org iD8DBQFDjxrBE5f5cImnZrsRAqYuAJ0TqNCU/KRXikZYpK/CNVVWyHcOUACeNZzP +VA5xGBImLraBFwTUT5PQfw= =q7Z/ -----END PGP SIGNATURE----- --------------enig4EB3D6ABDDE5E1E271BDDCA5-- --===============1908552213== 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 --===============1908552213==-- From tcpm-bounces@ietf.org Fri Dec 02 09:14:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiBgV-0004SY-3p; Fri, 02 Dec 2005 09:14:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiBgS-0004SB-Mr for tcpm@megatron.ietf.org; Fri, 02 Dec 2005 09:14:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27664 for ; Fri, 2 Dec 2005 09:13:56 -0500 (EST) 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 1EiC17-0000Pt-3Q for tcpm@ietf.org; Fri, 02 Dec 2005 09:36:07 -0500 Received: from [139.133.207.163] (dhcp-207-163.erg.abdn.ac.uk [139.133.207.163]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id jB2EDmNE016279; Fri, 2 Dec 2005 14:13:48 GMT Message-ID: <4390569C.6050004@erg.abdn.ac.uk> Date: Fri, 02 Dec 2005 14:13:48 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <6.2.0.14.0.20051201035418.0323fc48@localhost> In-Reply-To: <6.2.0.14.0.20051201035418.0323fc48@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Cc: Lars Eggert , tcpm@ietf.org, Ted Faber , "mallman@icir.org" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@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 A few comments are in-line (but not to all points yet). Gorry Fernando Gont wrote: > At 09:30 a.m. 12/11/2005, Gorry Fairhurst wrote: > >> 2) I don't yet see a compelling reason why this has to be negotiated >> at the >> TCP-layer. > > > We are altering a transport-protocol parameter. > >> This needs to be made clear. The new method does not completely >> relieve the need for new code - Applications still need to add (some) >> code to use the new socket option. > > You could set up the option with a system-wide toggle, for example. > A proposal to make this the default behaviour for all applications on an end-host makes me feel uneasy. > >> 3) If I understand, the mechanism is also per-direction of data >> transfer - >> that is there is no *necessity* for both end hosts to agree on the same >> values - although there are cases where they may both wish to (e.g.) >> increase the default. > > > It's not actually "per direction". Are you saying that it must be configured for BOTH directions then? - This is not my understanding. > But the option is just an advisory. > i.e., you need not use the same value the remote peer is advertising. > The draft contains a RECOMMENDED mechanism to choose the actual user > timeout. The formula means, basically, "if both the local and remote UTO > options are within the allowed higher and lower limits, choose the > higher of the two", > > > >> 4) My biggest worry that the current mechanism allows a remote party to >> alter the behaviour of a sender, without the prior consent of the host >> application. This seems wrong. I suggest it is important to consider >> whether this is "sane" - it needs thought. > > > In principle, it's the transport protocol that should handle this issue. > The application itself should not care about this network-specific > parameter. > I don't agree. The application uses a transport service, this proposed change modifies that service. > In any case, the option will not make things any worse. Do you mean there are no cases where application semantics can change as a result of using this option. That's a bold statement (i.e. big is always best?). > You have upper > and lower limits for the user timeout. And it is assumed that, within > those limits, things cannot go wrong. Under the recommended scheme, > receiving an UTO won't cause connections to be aborted unnecessarily, as > you will always choose the larger of the two UTOs. OTOH, the upper limit > is supposed to prevent you from adopting a user timeout that is too large. > >> On the other hand, if the application calls-down the socket API saying >> this >> is allowed, then this is fine, and I would have no problems on this >> point. > > > In the case there's no socket API call and no system-wide toggle set to > "on", the upper limit could be set up so that it equals the current User > Timeout, as specified in the existing RFCs. This will basically mean > that even upon receipt of an UTO, you won't actually alter the user > timeout for the connection. (under the RECOMMENDED scheme, at least) > > > >> 1) The wording describes sending the option in either/both the SYN v. >> established states. The protocol should be made clearer about this. > > > There had been some discussion on whether sending the option in the SYN > segment should be required. > The consensus was, IIRC, to make it a SHOULD rather than a MUST. > > >> If an end-host SENDS the option in a SYN packet, is it expected in the >> SYN-ACK? > > > I'd say it SHOULD be included, as above. Lars? > > > >> - One thing that I think needs thought is that in the currently defined >> method the Option in a SYN indicates "I may tell you that I wish to use a >> different UTO" - In fact the exact opposite is much more useful tgo the >> remote party: A SYN packet that carries an option saying "MY UTO is XXXX, >> you may change it". > > > I will go back to the draft, but... the option in the SYN segment > basically says "I suport UTO, my current user timeout is XXXX". > > > >> 2) A separate point, relating to options is that normal TCP behaviour >> REQUIRES an option to be present in the SYN to use it later. Is it >> REQUIRED >> to send this option in the SYN packet to be allowed to later use this >> once >> the session is established? > > > The WG consensus was, IIRC, not to make it a requirement. > I am happy with this, if The WG believes that "normal" TCP stacks can handle this, without introducing problems, then I have nmo objection. > > >> 4) Too low a UTO can be VERY harmful to the network service. I believe >> it is >> very important to establish and define a sensible minimal value. All >> to many >> times applications developers write and test code in a LAN environment >> and >> only later deploy in the general Internet. We should not provide another >> opportunity for people to use TCP in cute ways that will break on >> arbitrary >> Internet paths! I think the minimum UTO must be REQUIRED. > > > Requiring a minimum UTO means we should also make the recommended > mechanism for choosing the UTO a "requirement", I think. (the > recommended mechanism basically means "choose the larger of the two > UTOs, and apply higher and lower limits to it). > I'd agree with this. Lars? > > > >> 5) I really feel uneasy about the idea of responding to a UTO option >> with >> another UTO option. This seems bad protocol design, and should at >> least be >> damped by imposing a minimum time before the response can be sent. >> >> Why do this? - I change my end, I request you to change yours. Is that >> not >> it done? > > > Actually, IIRC this was included in the draft for further feedback, as > had been raised on the mailing-list. > > As for my own view on this issue, I agree with yours. If I change the > user timeout, I'd send an UTO. Done. > > > >> 6) Are there situations in which you wish to allow the UTO to be reduced >> once the session has started. Allowing reduction of the UTO below the >> actual PRTT (whatever that means in practice) provides a DOS >> vulnerability. > > > In principle, the UTO will reflect the length of the periods of > disconnection. If these periods change (for good) during the life of a > connection, then it would make sense to reduce them. However, of course > you have raised a good point. But I'd assume that the lower limit for > the UTO will address your case. As stated in the draft, the limits need > not be fixed. So, at any point, the lower limit should be, at least, the > actual PRTT. > > > >> 7) Are there any interoperability issues with NATs/Middleboxes when >> this is >> included on a SYN packet? > > > [MEDINA] has shown that there are not. > > > >> /on a satellite/on a non-geostationary satellite/ >> - All satellites orbit, but the vast majority used for telecoms take an >> orbit that is goeostationary. > > > IIRC, this had been a contribution of (NASA's) Wesley Eddy. "Satellite" > need not be a communications satellite, but could also be planetary body > (i.e., a node operating from the Moon experiences periods of disconnection) - Yes and is also a rather bizarre illustration of the point, considering the Path RTT >> "normal Internet MSL" ;-) > > P.S.: Skipped a few comments, but will come back to them. > > BTW, Thanks so much for your detailed feedback! > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 02 16:58:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiIvj-0000YE-R8; Fri, 02 Dec 2005 16:58:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiIvi-0000Xo-Vj for tcpm@megatron.ietf.org; Fri, 02 Dec 2005 16:58:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05212 for ; Fri, 2 Dec 2005 16:58:10 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiJGT-0005Uf-Jz for tcpm@ietf.org; Fri, 02 Dec 2005 17:20:26 -0500 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 jB2LwHr11293; Fri, 2 Dec 2005 13:58:17 -0800 (PST) Message-ID: <4390C3F5.1050707@isi.edu> Date: Fri, 02 Dec 2005 14:00:21 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ron Bonica , tcpm 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: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: Subject: [tcpm] feedback on tcp-auth-02 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 Hi, Ron (et al.), As promised, here's some detailed feedback on your draft. I hope it's useful, albeit a little later than I expected... Joe - ------ First, I think there are three reasons network administrators don't use TCP/MD5, and all need to be considered: 1) key management 2) performance 3) flaws in the current protocol - not an HMAC - lack of a key ID (for key rollover/rekeying) - lack of an algorithm ID (for alternate algorithms) #2 is a bit of a red-herring; all hash algorithms are similar in performance (differing by a factor of 2-3, which is not much). #1 is a BIG issue; this doc ought to include a key management protocol. Originally, I was thinking it might leverage IKE to do key distribution, but now I believe that the fate sharing of SYN+DiffieHellman makes more sense. Otherwise it's a burden on the app to coordinate sockets with IKE. DiffieHellman (authenticated, and perhaps not [as per BTNS]) is requied; the key must be per-session. Doing the DH requires specifying that protocol - perhaps using the reserved bit to indicate DH request, DH reply, etc., and whether this is a new keying or rekeying. #3 are easier to fix, and you've taken steps along most of those lines. IMO, it's simpler to just use a key ID and do rekeying by request (use one of the flags to trigger it, and allow rekeying messages to be exchanged with null data segments). More specific comments: Sec 2, first paragraph: refer to TCP, not BGP (TCP sessions for BGP). The intent was to secure BGP sessions, but it's TCP that gets secured. Sec 2, end: I don't agree that rekeying sync is the largest deterrent to use; the largest appears to be CPU load, and that's not addressed here. As per my other post, I don't think it can be addressed; most algorithms are basically the same performance-wise. Sec 3: why not allow multiple active keys? that would allow parallelism in hardware (which might actually impact performance). Throughout: omit references to "routers". BGP sessions are host-host; the router is acting as an 1122-style host for those connections, even though the information is used to configure the router. Near end Sec 4: while I agree that the source should receive responses for bad key'd data, the recipient MIGHT (it might be useful to know you're being attacked, e.g.) End Sec 4: If the extension is not required during the SYN, you're going to need another handshake protocol to establish the diffie-hellman, and to decide at what point to allow new data through. IMO, this is just a lot of extra work; I'd just as soon assume that the DH happens during the SYN. Note - I'm assuming a DH to establish a per-session key, something this doc doesn't address, though. Page 6: reserved bits: MUST set to zero in current implementations MUST ignore on receipt in current implementations (otherwise you'll never be able to use them in the future!) Refer to the possible use of the TCP "NOP" option for alignment. Table 1: omit non-HMAC algorithms, IMO Sec 5.1: clock sync seems like an antiquated key management scheme; it would be more useful to use IKE-style management, which is not timer-based. If timer-based is required, it will be useful to give a detailed explanation as to why (i.e., why you're diverging from 'conventional' key rollover). Question about keychains - at what point do they get cleared out? If the other side reboots and loses the session keys, it can never generate a RST that is accepted. IMO, a viable solution would be to allow new SYN Diffie-Hellman exchanges, which if authenticated (with the authentication key, not the session key), would cause the current keychain to be flushed. Sec 5.4: if you have too many options, which ones take precedence? Or should the option configuration request be denied? this needs to be explained and defined. Sec 5.5: "at minimum...80 octets, as this" is sufficient. You don't need to use both "minimum" and "or less" in the same sentence ;-) I would NOT allow the use of a single key for multiple sessions; this is a TCP protocol, and everything should be per-connection. Which is why per-session keys via DH is preferred, IMO. Sec 7: I see two considerations: 1) option KIND 2) algorithm types (for use in DH negotation) which might be copied from IKE - ---- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDkMP1E5f5cImnZrsRAnsJAJ0UPi9RM9o5VQpViXpa68bH71+QOgCff5qu k79JehsOV18Rmspxjg5CYQ4= =D1SW -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 02 23:51:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiPNP-0003h7-Fe; Fri, 02 Dec 2005 23:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiPNN-0003bG-Jm for tcpm@megatron.ietf.org; Fri, 02 Dec 2005 23:51:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17903 for ; Fri, 2 Dec 2005 23:51:08 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiPi7-0002ZJ-P7 for tcpm@ietf.org; Sat, 03 Dec 2005 00:13:28 -0500 Received: (qmail 14955 invoked from network); 3 Dec 2005 04:51:55 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 3 Dec 2005 04:51:55 -0000 Message-Id: <6.2.0.14.0.20051202201002.048b5de8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 02 Dec 2005 20:37:16 -0800 To: gorry@erg.abdn.ac.uk From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <4390569C.6050004@erg.abdn.ac.uk> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Lars Eggert , tcpm@ietf.org, Ted Faber , "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 At 06:13 a.m. 02/12/2005, Gorry Fairhurst wrote: >>>This needs to be made clear. The new method does not completely >>>relieve the need for new code - Applications still need to add (some) >>>code to use the new socket option. >>You could set up the option with a system-wide toggle, for example. >A proposal to make this the default behaviour for all applications on an >end-host makes me feel uneasy. No, neither me nor the draft ever proposed that. But, thinking out loud, it might me a good idea to be able to enable the UTO option on a system-wide basis. Of course, the toggle would default to "off". Being aware of my intermitent connectivity, I could enable it on a system wide basis, to let all my connections survive the disconnections, even if the applications themselves do not enable the UTO option explicitly. >>>3) If I understand, the mechanism is also per-direction of data transfer - >>>that is there is no *necessity* for both end hosts to agree on the same >>>values - although there are cases where they may both wish to (e.g.) >>>increase the default. >> >>It's not actually "per direction". >Are you saying that it must be configured for BOTH directions then? - This >is not my understanding. Well, I'm not sure why I wrote that sentence. I'd agree on that of the mechanism being "per direction". >>>4) My biggest worry that the current mechanism allows a remote party to >>>alter the behaviour of a sender, without the prior consent of the host >>>application. This seems wrong. I suggest it is important to consider >>>whether this is "sane" - it needs thought. >> >>In principle, it's the transport protocol that should handle this issue. >>The application itself should not care about this network-specific parameter. >I don't agree. The application uses a transport service, this proposed >change modifies that service. A timeout is mechanism that may be used to provide a given type of service. But a timeout is does not provide a service by itself. An application may be asking for a data-transfer with an error rate of less than X, a jitter less than Y, a throughtput higher than Z, a delay less than M, etc. But I cannot see a case in which an application may be interested in something like "If the underlying protocol cannot transfer my data in less than X seconds, abort the connection" as a *service* provided by the layer bellow. There are many reasons for which that would simply not make sense. One of them is that even if the data themselves are transferred to the remote TCP, the remote *application* may have crashed. So you still need application-layer timeouts. This sounds to me like when people use TCP keepalives just to avoid implementing an application-layer heartbeat. The two serve completely different purposes. >>In any case, the option will not make things any worse. >Do you mean there are no cases where application semantics can change as a >result of using this option. The application should care about application-layer timeouts, not about transport-layer timeouts. Same case as above. >>>2) A separate point, relating to options is that normal TCP behaviour >>>REQUIRES an option to be present in the SYN to use it later. Is it REQUIRED >>>to send this option in the SYN packet to be allowed to later use this once >>>the session is established? >> >>The WG consensus was, IIRC, not to make it a requirement. >I am happy with this, if The WG believes that "normal" TCP stacks can >handle this, without introducing problems, then I have nmo objection. That's the results of [MEDINA], IIRC. >>>/on a satellite/on a non-geostationary satellite/ >>>- All satellites orbit, but the vast majority used for telecoms take an >>>orbit that is goeostationary. >> >>IIRC, this had been a contribution of (NASA's) Wesley Eddy. "Satellite" >>need not be a communications satellite, but could also be planetary body >>(i.e., a node operating from the Moon experiences periods of disconnection) >- Yes and is also a rather bizarre illustration of the point, considering >the Path RTT >> "normal Internet MSL" ;-) I don't get your point. :-? Kindest regards, and thanks for your feedback, again! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Dec 05 09:58:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjHnY-0000DS-MK; Mon, 05 Dec 2005 09:58:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjHnX-0000DA-Nl for tcpm@megatron.ietf.org; Mon, 05 Dec 2005 09:58:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28931 for ; Mon, 5 Dec 2005 09:57:46 -0500 (EST) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjI8r-0004bb-0j for tcpm@ietf.org; Mon, 05 Dec 2005 10:20:37 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id C9736C34D for ; Mon, 5 Dec 2005 09:58:23 -0500 (EST) 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 jB5EwLGT017748; Mon, 5 Dec 2005 09:58:21 -0500 (EST) 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 jB5EwICD003480; Mon, 5 Dec 2005 09:58:18 -0500 (EST) 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 jB5EwHLS003471; Mon, 5 Dec 2005 09:58:17 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 8C5394FD7E; Mon, 5 Dec 2005 09:53:33 -0500 (EST) Date: Mon, 5 Dec 2005 09:53:33 -0500 From: Wesley Eddy To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Message-ID: <20051205145333.GB29457@grc.nasa.gov> References: <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20051202201002.048b5de8@localhost> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: gorry@erg.abdn.ac.uk, Lars Eggert , tcpm@ietf.org, Ted Faber , "mallman@icir.org" 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="===============0592887304==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0592887304== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2005 at 08:37:16PM -0800, Fernando Gont wrote: >=20 > >>>/on a satellite/on a non-geostationary satellite/ > >>>- All satellites orbit, but the vast majority used for telecoms take an > >>>orbit that is goeostationary. > >> > >>IIRC, this had been a contribution of (NASA's) Wesley Eddy. "Satellite"= =20 > >>need not be a communications satellite, but could also be planetary bod= y=20 > >>(i.e., a node operating from the Moon experiences periods of=20 > >>disconnection) > >- Yes and is also a rather bizarre illustration of the point, considerin= g=20 > >the Path RTT >> "normal Internet MSL" ;-) >=20 > I don't get your point. :-? > I don't either. If the "normal Internet MSL" is 2 minutes, then the propagation-based RTT between the Earth and Moon of roughly 5.5 seconds is well within an MSL. I actually think that changing the text to say "geostationary" would be an odd example, since from the ground it's rather difficult to go out of touch with one of these in comparison to other orbits. The case of a polar orbit (for instance) where you can predict the amount of time when the satellite is below the horizon and the time when it'll come back up is a better example. In this case, you can use a combination of UTO (to keep the connection alive) and retransmit-now (to kick the connection), to gain a little bit of efficiency, and simplify the application by letting it use TCP in comparison to CFDP or others. -Wes =20 --=20 Wesley M. Eddy Verizon Federal Network Systems http://roland.grc.nasa.gov/~weddy --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDlFRtzBuYqbnj3IwRAou9AJ93tVsC6FPDIvVD0bVHaynzd49MoACcDs0b yYKR0roaGZJPgeUJrvlqKho= =/fmU -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- --===============0592887304== 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 --===============0592887304==-- From tcpm-bounces@ietf.org Mon Dec 05 10:13:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjI2N-0006Vh-SD; Mon, 05 Dec 2005 10:13:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjI2L-0006Vc-5F for tcpm@megatron.ietf.org; Mon, 05 Dec 2005 10:13:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01116 for ; Mon, 5 Dec 2005 10:13:03 -0500 (EST) 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 1EjINb-0005EC-NC for tcpm@ietf.org; Mon, 05 Dec 2005 10:35:55 -0500 Received: from [139.133.207.161] (dhcp-207-161.erg.abdn.ac.uk [139.133.207.161]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id jB5FCqLa029414; Mon, 5 Dec 2005 15:12:52 GMT Message-ID: <439458F0.7080509@erg.abdn.ac.uk> Date: Mon, 05 Dec 2005 15:12:48 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051205145333.GB29457@grc.nasa.gov> In-Reply-To: <20051205145333.GB29457@grc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Lars Eggert , tcpm@ietf.org, Ted Faber , Fernando Gont , "mallman@icir.org" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@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 Wesley Eddy wrote: > On Fri, Dec 02, 2005 at 08:37:16PM -0800, Fernando Gont wrote: > >>>>>/on a satellite/on a non-geostationary satellite/ >>>>>- All satellites orbit, but the vast majority used for telecoms take an >>>>>orbit that is goeostationary. >>>> >>>>IIRC, this had been a contribution of (NASA's) Wesley Eddy. "Satellite" >>>>need not be a communications satellite, but could also be planetary body >>>>(i.e., a node operating from the Moon experiences periods of >>>>disconnection) >>> >>>- Yes and is also a rather bizarre illustration of the point, considering >>>the Path RTT >> "normal Internet MSL" ;-) >> >>I don't get your point. :-? >> > > > I don't either. If the "normal Internet MSL" is 2 minutes, then the > propagation-based RTT between the Earth and Moon of roughly 5.5 seconds > is well within an MSL. > > I actually think that changing the text to say "geostationary" would be > an odd example, since from the ground it's rather difficult to go out of > touch with one of these in comparison to other orbits. The case of a > polar orbit (for instance) where you can predict the amount of time when > the satellite is below the horizon and the time when it'll come back up > is a better example. In this case, you can use a combination of UTO (to > keep the connection alive) and retransmit-now (to kick the connection), > to gain a little bit of efficiency, and simplify the application by > letting it use TCP in comparison to CFDP or others. > > -Wes > OK, so the original text was: For example, an orbiting node on a satellite might experience disconnections due to line-of-sight blocking by other planetary bodies. The disconnection periods of such a node may be easily computable from orbital mechanics. And my original point, was perhaps not clear, but we now seem to have come full circle, and so let me try again: If you think this is a good example of why UTO is useful (and I am not sure it really is such a good example), then I would have much prefered the I-D to have said something like "non-geostationary satellite" - to differentiate it from the more common form of satellite used to provide Internet services. Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Dec 08 17:38:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUPQ-0004fo-K5; Thu, 08 Dec 2005 17:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUPO-0004fB-GQ for tcpm@megatron.ietf.org; Thu, 08 Dec 2005 17:38:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01055 for ; Thu, 8 Dec 2005 17:37:45 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUPR-0008OE-KO for tcpm@ietf.org; Thu, 08 Dec 2005 17:38:43 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8MaOr08728 for ; Thu, 8 Dec 2005 14:36:24 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB8MaOhf070123 for tcpm@ietf.org; Thu, 8 Dec 2005 14:36:24 -0800 (PST) (envelope-from faber) Date: Thu, 8 Dec 2005 14:36:24 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20051208223624.GC22920@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] Minutes become final tomorrow 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="===============1182499226==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1182499226== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MnLPg7ZWsaic7Fhd" Content-Disposition: inline --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The minutes at http://www3.ietf.org/proceedings/05nov/minutes/tcpm.txt become final tomorrow. If you haven't looked, please do. --=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 --MnLPg7ZWsaic7Fhd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmLVoaUz3f+Zf+XsRAq58AKDnxyUGa/w6WU3bfEV/Qr+TDXGzYwCeMqPa HmCDUVPy6k/uqTJTd4CC3sY= =oj7W -----END PGP SIGNATURE----- --MnLPg7ZWsaic7Fhd-- --===============1182499226== 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 --===============1182499226==-- From tcpm-bounces@ietf.org Thu Dec 08 18:48:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVVD-0006tC-6L; Thu, 08 Dec 2005 18:48:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVVB-0006jt-50 for tcpm@megatron.ietf.org; Thu, 08 Dec 2005 18:48:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07605 for ; Thu, 8 Dec 2005 18:47:42 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVV9-0002Gh-Vw for tcpm@ietf.org; Thu, 08 Dec 2005 18:48:41 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8MdHr09796; Thu, 8 Dec 2005 14:39:17 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB8MdHau070161; Thu, 8 Dec 2005 14:39:17 -0800 (PST) (envelope-from faber) Date: Thu, 8 Dec 2005 14:39:17 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] ECN for SYN/ACK draft Message-ID: <20051208223917.GD22920@hut.isi.edu> References: <20051129194010.GG12561@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20051129194010.GG12561@hut.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: floyd@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="===============0003400397==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0003400397== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LKTjZJSUETSlgu2t" Content-Disposition: inline --LKTjZJSUETSlgu2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 29, 2005 at 11:40:11AM -0800, Ted Faber wrote: > Hi. >=20 > As those of you who were at tsvwg in Vancouver know, Sally Floyd has > proposed a draft adding ECN to SYN and SYN/ACK packets, which was not > allowed under the original RFC 3168 ECN spec. The draft has not yet > popped out, but there are also relatively-permanent local copies at: >=20 > http://www.icir.org/floyd/papers/draft-ietf-tsvwg-ecnsyn-00.txt > http://www.icir.org/floyd/papers/draft-kuzmanovic-ecn-syn-00.txt [snip] >=20 > If accepted, I'd like to request that we move fairly quickly to get this > reviewed and on the publication path. I think sending it up to the IESG > for Proposed Standard before Dallas would be reasonable, but you all get > the final say. If we decide not to accept it, clear reasons need to be > given. >=20 > Comments? I realize that this is December and people have end-of-year holidays and end-of-semester chores taking their time, but Mark and I need some indication that this is a useful thing for us to do or it will go back to TSVWG. Please have a look and send feedback, ASAP. It's a short draft. --=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 --LKTjZJSUETSlgu2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmLYVaUz3f+Zf+XsRAjz/AKCYIpVbbLTrIjCUzU4oynsmKVKtaACgwdKE vYIpHxp4/Qomuwg5q1D90qc= =ETng -----END PGP SIGNATURE----- --LKTjZJSUETSlgu2t-- --===============0003400397== 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 --===============0003400397==-- From tcpm-bounces@ietf.org Thu Dec 08 19:19:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVyy-0000o6-HW; Thu, 08 Dec 2005 19:19:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVym-0000mc-6J for tcpm@megatron.ietf.org; Thu, 08 Dec 2005 19:19:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11028 for ; Thu, 8 Dec 2005 19:18:11 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVyf-0003GJ-2B for tcpm@ietf.org; Thu, 08 Dec 2005 19:19:10 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8MS9r04908; Thu, 8 Dec 2005 14:28:09 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB8MS8rZ069926; Thu, 8 Dec 2005 14:28:08 -0800 (PST) (envelope-from faber) Date: Thu, 8 Dec 2005 14:28:08 -0800 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Message-ID: <20051208222808.GB22920@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20051202201002.048b5de8@localhost> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: gorry@erg.abdn.ac.uk, Lars Eggert , 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="===============1456122046==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1456122046== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2005 at 08:37:16PM -0800, Fernando Gont wrote: > At 06:13 a.m. 02/12/2005, Gorry Fairhurst wrote: > >>In any case, the option will not make things any worse. > >Do you mean there are no cases where application semantics can change as= a=20 > >result of using this option. >=20 > The application should care about application-layer timeouts, not about= =20 > transport-layer timeouts. TCP provides an interface that the application can use to set this timeout in RFC793. Breaking applications that made use of it should not be done lightly, even if there are alternative mechanisms that those applications could have used. IMHO, with my chair hat off. --=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 --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmLN4aUz3f+Zf+XsRAorgAJ9l+BIBx3NBme9hS72hWUHusmYivgCgpIhE fhqstXwcIeSOaeq1qhBXWkw= =7seS -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh-- --===============1456122046== 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 --===============1456122046==-- From tcpm-bounces@ietf.org Thu Dec 08 19:58:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkWb0-0006s5-Ik; Thu, 08 Dec 2005 19:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkWaz-0006ll-8I for tcpm@megatron.ietf.org; Thu, 08 Dec 2005 19:58:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14507 for ; Thu, 8 Dec 2005 19:57:34 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkWaj-0004NR-T6 for tcpm@ietf.org; Thu, 08 Dec 2005 19:58:32 -0500 Received: (qmail 26620 invoked from network); 9 Dec 2005 00:58:45 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 9 Dec 2005 00:58:45 -0000 Message-Id: <6.2.0.14.0.20051208164304.041ead70@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 08 Dec 2005 16:51:13 -0800 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <20051208222808.GB22920@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: gorry@erg.abdn.ac.uk, Lars Eggert , 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 At 02:28 p.m. 08/12/2005, Ted Faber wrote: > > >Do you mean there are no cases where application semantics can change > as a > > >result of using this option. > > > > The application should care about application-layer timeouts, not about > > transport-layer timeouts. > >TCP provides an interface that the application can use to set this >timeout in RFC793. Breaking applications that made use of it should not >be done lightly, even if there are alternative mechanisms that those >applications could have used. Agreed. But we agreed that the application-specified UTO would take precedence. And that, in the event a system-wide toggle existed, it would default to off. So if you were using UTO, either the application programmer or the system administrator decided to do so. (From a theoretical point of view, I'd probably argue that an application that really *breaks* because the user timeout ends up being longer than 2 minutes or whatever, then it's already broken. And, even then, we have higher and lower limits for the UTO, which one would hope will keep the UTO "within acceptable values". But well, as I pointed out above, this would not even be the case.) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 09 07:14:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekh9P-00007Y-D1; Fri, 09 Dec 2005 07:14:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekh9O-00007F-5B for tcpm@megatron.ietf.org; Fri, 09 Dec 2005 07:14:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25207 for ; Fri, 9 Dec 2005 07:13:53 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekh9O-0000jM-GJ for tcpm@ietf.org; Fri, 09 Dec 2005 07:14:59 -0500 Received: (qmail 31857 invoked from network); 9 Dec 2005 12:15:13 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 9 Dec 2005 12:15:13 -0000 Message-Id: <6.2.0.14.0.20051209040636.03241e30@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 09 Dec 2005 04:10:40 -0800 To: Ted Faber , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] Minutes become final tomorrow In-Reply-To: <20051208223624.GC22920@hut.isi.edu> References: <20051208223624.GC22920@hut.isi.edu> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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: , Content-Type: multipart/mixed; boundary="===============1214738231==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1214738231== Content-Type: multipart/alternative; boundary="=====================_202998586==.ALT" --=====================_202998586==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:36 p.m. 08/12/2005, Ted Faber wrote: >The minutes at http://www3.ietf.org/proceedings/05nov/minutes/tcpm.txt >become final tomorrow. If you haven't looked, please do. A comment on the minutes: > Touch: like the concept of this doc; but this current draft is spun > wrong; wish the doc highlighted checking checksum, window, > signature; need to be specific about not checking window when saying > discussing staleness > > Fernando: current specs don't require including full packet to > allow checking checksum and MD5 sig; *that's* the point > > Touch: then why do you think you can parse a TCP header if there > is no valid checksum? My answer to Joe's question was that it's more conservative to perform as many checks as possible on the received ICMP message (even if you were not able to check the checksum) than to simply honor the ICMP message without performing these checks. (It's not that it's the best thing you could do.... but for most ICMP messages you won't be able to check the checksum). Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org --=====================_202998586==.ALT Content-Type: text/html; charset="us-ascii" At 02:36 p.m. 08/12/2005, Ted Faber wrote:

The minutes at http://www3.ietf.org/proceedings/05nov/minutes/tcpm.txt
become final tomorrow.  If you haven't looked, please do.

A comment on the minutes:


  Touch: like the
concept of this doc; but this current draft is spun
  wrong; wish the doc highlighted checking checksum, window,
  signature; need to be specific about not checking window when
saying
  discussing staleness

    Fernando: current specs don't require including full
packet to
    allow checking checksum and MD5 sig; *that's* the
point

    Touch: then why do you think you can parse a TCP
header if there
    is no valid checksum?

My answer to Joe's question was that it's more conservative to perform as many checks as possible on the received ICMP message (even if you were not able to check the checksum) than to simply honor the ICMP message without performing these checks. (It's not that it's the best thing you could do.... but for most ICMP messages you won't be able to check the checksum).

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org




--=====================_202998586==.ALT-- --===============1214738231== 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 --===============1214738231==-- From tcpm-bounces@ietf.org Fri Dec 09 13:16:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekmnd-0005FJ-CH; Fri, 09 Dec 2005 13:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekmnc-0005CC-0W for tcpm@megatron.ietf.org; Fri, 09 Dec 2005 13:16:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10063 for ; Fri, 9 Dec 2005 13:15:49 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekmnh-0005Wt-Bg for tcpm@ietf.org; Fri, 09 Dec 2005 13:16:58 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9IFv005660; Fri, 9 Dec 2005 10:15:57 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB9IFvV9005347; Fri, 9 Dec 2005 10:15:57 -0800 (PST) (envelope-from faber) Date: Fri, 9 Dec 2005 10:15:57 -0800 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] Minutes become final tomorrow Message-ID: <20051209181557.GB1177@hut.isi.edu> References: <20051208223624.GC22920@hut.isi.edu> <6.2.0.14.0.20051209040636.03241e30@localhost> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20051209040636.03241e30@localhost> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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="===============0669348268==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0669348268== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 09, 2005 at 04:10:40AM -0800, Fernando Gont wrote: > At 02:36 p.m. 08/12/2005, Ted Faber wrote: >=20 > >The minutes at http://www3.ietf.org/proceedings/05nov/minutes/tcpm.txt > >become final tomorrow. If you haven't looked, please do. >=20 > A comment on the minutes: >=20 >=20 > > Touch: like the concept of this doc; but this current draft is spun > > wrong; wish the doc highlighted checking checksum, window, > > signature; need to be specific about not checking window when saying > > discussing staleness > > > > Fernando: current specs don't require including full packet to > > allow checking checksum and MD5 sig; *that's* the point > > > > Touch: then why do you think you can parse a TCP header if there > > is no valid checksum? >=20 > My answer to Joe's question was that it's more conservative to perform as= =20 > many checks as possible on the received ICMP message (even if you were no= t=20 > able to check the checksum) than to simply honor the ICMP message without= =20 > performing these checks. (It's not that it's the best thing you could=20 > do.... but for most ICMP messages you won't be able to check the checksum= ). Changed. Hopefully that will get in under the deadline. --=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 --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmcndaUz3f+Zf+XsRAiC0AJ9FZfdOsVql6fSeFWLLbWZSQvK/nwCeOj6r CQH4R+xBvqg5vRmkVsCnvos= =/Yzi -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- --===============0669348268== 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 --===============0669348268==-- From tcpm-bounces@ietf.org Fri Dec 09 13:26:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmxM-0000tq-I9; Fri, 09 Dec 2005 13:26:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmxK-0000pO-Fj for tcpm@megatron.ietf.org; Fri, 09 Dec 2005 13:26:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11100 for ; Fri, 9 Dec 2005 13:25:59 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkmxX-0005sG-78 for tcpm@ietf.org; Fri, 09 Dec 2005 13:27:08 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB9IPW008914; Fri, 9 Dec 2005 10:25:32 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB9IPV5x005429; Fri, 9 Dec 2005 10:25:31 -0800 (PST) (envelope-from faber) Date: Fri, 9 Dec 2005 10:25:31 -0800 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Message-ID: <20051209182531.GC1177@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20051208164304.041ead70@localhost> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: gorry@erg.abdn.ac.uk, Lars Eggert , 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="===============0178733785==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0178733785== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 08, 2005 at 04:51:13PM -0800, Fernando Gont wrote: > At 02:28 p.m. 08/12/2005, Ted Faber wrote: >=20 > >> >Do you mean there are no cases where application semantics can change= =20 > >as a > >> >result of using this option. > >> > >> The application should care about application-layer timeouts, not about > >> transport-layer timeouts. > > > >TCP provides an interface that the application can use to set this > >timeout in RFC793. Breaking applications that made use of it should not > >be done lightly, even if there are alternative mechanisms that those > >applications could have used. >=20 > Agreed. >=20 > But we agreed that the application-specified UTO would take precedence. A= nd=20 > that, in the event a system-wide toggle existed, it would default to off. >=20 > So if you were using UTO, either the application programmer or the system= =20 > administrator decided to do so. I think you mean that if you're using UTO negotiation it's because of an active decision, which is IMHO, correct. >=20 > (From a theoretical point of view, I'd probably argue that an application= =20 > that really *breaks* because the user timeout ends up being longer than 2= =20 > minutes or whatever, then it's already broken. And, even then, we have=20 > higher and lower limits for the UTO, which one would hope will keep the U= TO=20 > "within acceptable values". But well, as I pointed out above, this would= =20 > not even be the case.) If you're arguing that implementation of the user timeout is more likely to be flaky than more core features of the protocol, I agree. Relying on the urgent pointer has similar practical issues. So does relying on the UNIX sleep or usleep timers. The mechanism described in 793 and 1122 is a perfectly reasonable definition of a timeout system that an application could use to take action if data's not delivered in a timely fashion. In a system where those mechanisms are implemented to spec, I don't see why using them would break an application. And that seems to be what you're saying. --=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 --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmcwbaUz3f+Zf+XsRAq4uAKD2UohRKjnTHMQ7CGjhJQKPUU4bfgCg6R+u aLm2YVt5Zay3EsEqzrYlmfY= =hwSs -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- --===============0178733785== 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 --===============0178733785==-- From tcpm-bounces@ietf.org Mon Dec 12 07:59:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElnHO-0007Co-O5; Mon, 12 Dec 2005 07:59:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElnHL-00078i-9Z for tcpm@megatron.ietf.org; Mon, 12 Dec 2005 07:59:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18120 for ; Mon, 12 Dec 2005 07:58:42 -0500 (EST) 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 1ElnI2-0002qN-JU for tcpm@ietf.org; Mon, 12 Dec 2005 08:00:28 -0500 Received: from [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id jBCCwe8i021563; Mon, 12 Dec 2005 12:58:40 GMT Message-ID: <439D7400.20902@erg.abdn.ac.uk> Date: Mon, 12 Dec 2005 12:58:40 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> In-Reply-To: <20051209182531.GC1177@hut.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Lars Eggert , tcpm@ietf.org, Fernando Gont , "mallman@icir.org" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@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 Ted Faber wrote: > On Thu, Dec 08, 2005 at 04:51:13PM -0800, Fernando Gont wrote: > >>At 02:28 p.m. 08/12/2005, Ted Faber wrote: >> >> >>>>>Do you mean there are no cases where application semantics can change >>> >>>as a >>> >>>>>result of using this option. >>>> >>>>The application should care about application-layer timeouts, not about >>>>transport-layer timeouts. >>> >>>TCP provides an interface that the application can use to set this >>>timeout in RFC793. Breaking applications that made use of it should not >>>be done lightly, even if there are alternative mechanisms that those >>>applications could have used. >> >>Agreed. >> >>But we agreed that the application-specified UTO would take precedence. And >>that, in the event a system-wide toggle existed, it would default to off. >> >>So if you were using UTO, either the application programmer or the system >>administrator decided to do so. > > > I think you mean that if you're using UTO negotiation it's because of an > active decision, which is IMHO, correct. > > >>(From a theoretical point of view, I'd probably argue that an application >>that really *breaks* because the user timeout ends up being longer than 2 >>minutes or whatever, then it's already broken. And, even then, we have >>higher and lower limits for the UTO, which one would hope will keep the UTO >>"within acceptable values". But well, as I pointed out above, this would >>not even be the case.) > > > If you're arguing that implementation of the user timeout is more likely > to be flaky than more core features of the protocol, I agree. Relying > on the urgent pointer has similar practical issues. So does relying on > the UNIX sleep or usleep timers. > > The mechanism described in 793 and 1122 is a perfectly reasonable > definition of a timeout system that an application could use to take > action if data's not delivered in a timely fashion. In a system where > those mechanisms are implemented to spec, I don't see why using them > would break an application. And that seems to be what you're saying. > I agree - my concern was application of a SMALLER value (from the remote end) than currently defined by standard mechanism - and the impact this could have on an unsuspecting application. Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Dec 12 18:57:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElxXt-0003YA-0h; Mon, 12 Dec 2005 18:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElxXr-0003Xs-AM for tcpm@megatron.ietf.org; Mon, 12 Dec 2005 18:57:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16514 for ; Mon, 12 Dec 2005 18:56:31 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElxYj-0003mb-3r for tcpm@ietf.org; Mon, 12 Dec 2005 18:58:22 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBCNu4005102; Mon, 12 Dec 2005 15:56:21 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jBCNu3fA011464; Mon, 12 Dec 2005 15:56:03 -0800 (PST) (envelope-from faber) Date: Mon, 12 Dec 2005 15:56:03 -0800 From: Ted Faber To: Gorry Fairhurst Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Message-ID: <20051212235603.GB1156@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> Mime-Version: 1.0 In-Reply-To: <439D7400.20902@erg.abdn.ac.uk> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Lars Eggert , tcpm@ietf.org, Fernando Gont , "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="===============1793237671==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1793237671== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 12, 2005 at 12:58:40PM +0000, Gorry Fairhurst wrote: > Ted Faber wrote: > >The mechanism described in 793 and 1122 is a perfectly reasonable > >definition of a timeout system that an application could use to take > >action if data's not delivered in a timely fashion. In a system where > >those mechanisms are implemented to spec, I don't see why using them > >would break an application. And that seems to be what you're saying. > > >=20 > I agree - my concern was application of a SMALLER value (from the remote= =20 > end) than currently defined by standard mechanism - and the impact this= =20 > could have on an unsuspecting application. Hmmmmm. On the one hand, I'd say that if an application cares, it should set the value explicitly. On the other hand, an application that didn't set a value for UTO becasue any reasonable value was fine would probably be unhappy if a 5ms UTO had been negotiated for it. :-) If I recall correctly, they do have a min/max kind of set up that encourages systems not to push their defaults down. I can see a good argument that UTO negotiation should *never* reduce the default min UTO of a system to avoid violating POLA. Is this restriction what you're arguing for, Gorry? (If so, Lars/Fernando, do you have objections/counter-arguments?) --=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 --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDng4TaUz3f+Zf+XsRAnYhAKDDBaSEu0WpBoGBM12dbSXj0ic2TQCeOVwD 7Nz5xRe+k4BfVYOO9o+gDPc= =j73U -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- --===============1793237671== 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 --===============1793237671==-- From tcpm-bounces@ietf.org Tue Dec 13 04:56:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6tw-0002eg-Cc; Tue, 13 Dec 2005 04:56:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6tu-0002eJ-Mi for tcpm@megatron.ietf.org; Tue, 13 Dec 2005 04:56:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28557 for ; Tue, 13 Dec 2005 04:55:53 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em6us-0000qi-II for tcpm@ietf.org; Tue, 13 Dec 2005 04:57:51 -0500 Received: (qmail 2371 invoked from network); 13 Dec 2005 09:57:01 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 13 Dec 2005 09:57:01 -0000 Message-Id: <6.2.0.14.0.20051209201513.05519d10@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 13 Dec 2005 01:24:32 -0800 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <20051209182531.GC1177@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: gorry@erg.abdn.ac.uk, Lars Eggert , 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 At 10:25 a.m. 09/12/2005, Ted Faber wrote: > > But we agreed that the application-specified UTO would take precedence. > And > > that, in the event a system-wide toggle existed, it would default to off. > > > > So if you were using UTO, either the application programmer or the system > > administrator decided to do so. > >I think you mean that if you're using UTO negotiation it's because of an >active decision, which is IMHO, correct. Exactly.It never "kicks in by default". >The mechanism described in 793 and 1122 is a perfectly reasonable >definition of a timeout system that an application could use to take >action if data's not delivered in a timely fashion. The point is that if you;re really concerned about data being delivered, you should be implementing an application layer timeout mechanism. If there's no TCP timeout, it does not mean that the data were delivered. >In a system where >those mechanisms are implemented to spec, I don't see why using them >would break an application. Say I really need to know that the remote app got these data I have just sent. So I rely on TCP's timeout. Now the remote app crashed, but the remote app didn't. The application design is broken. I'd be assuming taht the remote app got the data, when it didn't. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Dec 13 04:56:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6tw-0002fA-Pd; Tue, 13 Dec 2005 04:56:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6tv-0002eV-F2 for tcpm@megatron.ietf.org; Tue, 13 Dec 2005 04:56:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28562 for ; Tue, 13 Dec 2005 04:55:54 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em6us-0000qy-0w for tcpm@ietf.org; Tue, 13 Dec 2005 04:57:51 -0500 Received: (qmail 10094 invoked from network); 13 Dec 2005 09:57:12 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 13 Dec 2005 09:57:12 -0000 Message-Id: <6.2.0.14.0.20051213012717.048f1608@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 13 Dec 2005 01:27:48 -0800 To: gorry@erg.abdn.ac.uk, Ted Faber From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <439D7400.20902@erg.abdn.ac.uk> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Lars Eggert , 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 At 04:58 a.m. 12/12/2005, Gorry Fairhurst wrote: >I agree - my concern was application of a SMALLER value (from the remote >end) than currently defined by standard mechanism - and the impact this >could have on an unsuspecting application. I understand. And for that reason it's that the lower limit for the UTO should be set correctly. Of the top of my head, I realize that maybe the current draft does not mention which value should be the minimum we should use for the lower limit, though. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Dec 13 04:56:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6ty-0002fb-6T; Tue, 13 Dec 2005 04:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6tw-0002em-FO for tcpm@megatron.ietf.org; Tue, 13 Dec 2005 04:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28565 for ; Tue, 13 Dec 2005 04:55:55 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em6ut-0000rO-Ue for tcpm@ietf.org; Tue, 13 Dec 2005 04:57:52 -0500 Received: (qmail 21956 invoked from network); 13 Dec 2005 09:57:18 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 13 Dec 2005 09:57:18 -0000 Message-Id: <6.2.0.14.0.20051213012758.048ed298@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 13 Dec 2005 01:34:32 -0800 To: Ted Faber , Gorry Fairhurst From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <20051212235603.GB1156@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Lars Eggert , 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 At 03:56 p.m. 12/12/2005, Ted Faber wrote: >If I recall correctly, they do have a min/max kind of set up that >encourages systems not to push their defaults down. I can see a good >argument that UTO negotiation should *never* reduce the default min UTO >of a system to avoid violating POLA. Is this restriction what you're >arguing for, Gorry? (If so, Lars/Fernando, do you have >objections/counter-arguments?) Of the top of my head, I don't recall we proposed any value for the lower limit. Anyway, that's what we had in mind when including the equation for choosing the UTO: "As long as it is within acceptable limits, choose the larger of the two". The idea is that if you don't set the UTO explicitly, then your local UTO should be set to the default UTO (which may even be larger than the minimum allowed UTO, i.e., the lower limit). This means that, your user timeout will be, at least, the default. And, at most, that of the upper limit. If you do set the UTO explicitly (i.e., you know what you're doing), then the user timeout will be, at least, that of the lower limit, and, at most, that of the upper limit. (I realize that this is probably not explained in the draft, though). Does it make sense? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 14 09:18:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXSc-0000SE-9U; Wed, 14 Dec 2005 09:18:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXSW-0000R3-Sn for tcpm@megatron.ietf.org; Wed, 14 Dec 2005 09:18:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00413 for ; Wed, 14 Dec 2005 09:17:13 -0500 (EST) 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 1EmXTY-00009P-Ma for tcpm@ietf.org; Wed, 14 Dec 2005 09:19:26 -0500 Received: from [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id jBEEHSBX024411; Wed, 14 Dec 2005 14:17:28 GMT Message-ID: <43A02978.4020809@erg.abdn.ac.uk> Date: Wed, 14 Dec 2005 14:17:28 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> In-Reply-To: <6.2.0.14.0.20051213012758.048ed298@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Lars Eggert , Gorry Fairhurst , tcpm@ietf.org, Ted Faber , "mallman@icir.org" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@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 So, a summary of my take and responding to some of this (which I hope we now have right). I'd be happy with new text saying something along the lines of: * MIN RTO is system-defined (with a warning that small requires caution;-) ). * The RECOMMENDED value for MIN RTO is follow RFCxxx. * UTO negotiation SHOULD be OFF by default. * UTO negotiation MAY be via a system config. * RECOMMEND negotiation is enabled via an API call from the application. * Upper and lower bounds may be set, but MUST NOT go below system MIN RTO * MUST use MIN RTO, if UTO negotiation is not enabled. ? Gorry Fernando Gont wrote: > At 03:56 p.m. 12/12/2005, Ted Faber wrote: > >> If I recall correctly, they do have a min/max kind of set up that >> encourages systems not to push their defaults down. I can see a good >> argument that UTO negotiation should *never* reduce the default min UTO >> of a system to avoid violating POLA. Is this restriction what you're >> arguing for, Gorry? (If so, Lars/Fernando, do you have >> objections/counter-arguments?) > > > Of the top of my head, I don't recall we proposed any value for the > lower limit. > > Anyway, that's what we had in mind when including the equation for > choosing the UTO: "As long as it is within acceptable limits, choose the > larger of the two". > > The idea is that if you don't set the UTO explicitly, then your local > UTO should be set to the default UTO (which may even be larger than the > minimum allowed UTO, i.e., the lower limit). This means that, your user > timeout will be, at least, the default. And, at most, that of the upper > limit. > > If you do set the UTO explicitly (i.e., you know what you're doing), > then the user timeout will be, at least, that of the lower limit, and, > at most, that of the upper limit. > > (I realize that this is probably not explained in the draft, though). > > Does it make sense? > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 14 12:21:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaJv-0008Ek-5u; Wed, 14 Dec 2005 12:21:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaJp-0008Db-Bz for tcpm@megatron.ietf.org; Wed, 14 Dec 2005 12:21:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26468 for ; Wed, 14 Dec 2005 12:20:27 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmaKu-0008JQ-DL for tcpm@ietf.org; Wed, 14 Dec 2005 12:22:42 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBEHKhe08745; Wed, 14 Dec 2005 09:20:43 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jBEHKhJg022441; Wed, 14 Dec 2005 09:20:43 -0800 (PST) (envelope-from faber) Date: Wed, 14 Dec 2005 09:20:43 -0800 From: Ted Faber To: Gorry Fairhurst Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Message-ID: <20051214172043.GD20929@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> Mime-Version: 1.0 In-Reply-To: <43A02978.4020809@erg.abdn.ac.uk> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Lars Eggert , tcpm@ietf.org, Fernando Gont , "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="===============1541257715==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1541257715== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 14, 2005 at 02:17:28PM +0000, Gorry Fairhurst wrote: >=20 >=20 > So, a summary of my take and responding to some of this (which I hope we= =20 > now have right). I'd be happy with new text saying something along the=20 > lines of: >=20 > * MIN RTO is system-defined (with a warning that small requires=20 > caution;-) ). > * The RECOMMENDED value for MIN RTO is follow RFCxxx. >=20 > * UTO negotiation SHOULD be OFF by default. > * UTO negotiation MAY be via a system config. > * RECOMMEND negotiation is enabled via an API call from the application. > * Upper and lower bounds may be set, but MUST NOT go below system MIN RTO > * MUST use MIN RTO, if UTO negotiation is not enabled. That's a nice, succinct description of constraints on UTO. They sound reasonable to me, and I'd love to hear from others. --=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 --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDoFRraUz3f+Zf+XsRAnKvAKCQbQXnY8DN5tC+IB+s358/mZ6xIACghZh8 TmAUxSLifK5PNBWmf6jLVFA= =2S5e -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF-- --===============1541257715== 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 --===============1541257715==-- From tcpm-bounces@ietf.org Wed Dec 14 12:21:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaKD-0008Hi-NQ; Wed, 14 Dec 2005 12:21:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaKC-0008GM-EA for tcpm@megatron.ietf.org; Wed, 14 Dec 2005 12:21:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26497 for ; Wed, 14 Dec 2005 12:20:53 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmaLM-0008Kr-F4 for tcpm@ietf.org; Wed, 14 Dec 2005 12:23:08 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBEHJre08450; Wed, 14 Dec 2005 09:19:53 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jBEHJqAu022417; Wed, 14 Dec 2005 09:19:52 -0800 (PST) (envelope-from faber) Date: Wed, 14 Dec 2005 09:19:52 -0800 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Message-ID: <20051214171952.GC20929@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <6.2.0.14.0.20051209201513.05519d10@localhost> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20051209201513.05519d10@localhost> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: gorry@erg.abdn.ac.uk, Lars Eggert , 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="===============1796110658==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1796110658== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 13, 2005 at 01:24:32AM -0800, Fernando Gont wrote: > At 10:25 a.m. 09/12/2005, Ted Faber wrote: > >The mechanism described in 793 and 1122 is a perfectly reasonable > >definition of a timeout system that an application could use to take > >action if data's not delivered in a timely fashion. >=20 > The point is that if you;re really concerned about data being delivered,= =20 > you should be implementing an application layer timeout mechanism. > If there's no TCP timeout, it does not mean that the data were delivered. I understand the difference between a transport ack and acknowledgements from higher layers. Some applications (correctly!) use transport state to synchronize application state. Consider a file transfer appliaction that opens a TCP connection for each file. The connection is closed when the file is saved to disk. A transmitter knows the file has been delivered correctly if and only if the receiver closes its connection correctly. The receiver knows the whole file has been transmitted when the sender closes its side of the connection (a receiver never closes its connection before a sender does). Voila, application synchronization using TCP signalling.=20 Such an application may well want to use TCP's existing UTO mechanism as a timeout. --=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 --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDoFQ4aUz3f+Zf+XsRAmWIAJ9mzFMd+EfM09l6e+oVf4SHjCrj7ACgpJpz PvX0SdxRYD9gqSkXFuzaqjo= =0hTQ -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- --===============1796110658== 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 --===============1796110658==-- From tcpm-bounces@ietf.org Wed Dec 14 14:30:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcKp-0007td-LP; Wed, 14 Dec 2005 14:30:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcKo-0007sr-3f for tcpm@megatron.ietf.org; Wed, 14 Dec 2005 14:30:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14090 for ; Wed, 14 Dec 2005 14:29:42 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmcM2-0005Gj-RX for tcpm@ietf.org; Wed, 14 Dec 2005 14:32:00 -0500 Received: from lars.local (p54AD2ADB.dip0.t-ipconnect.de [84.173.42.219]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A3A211BAC9E; Wed, 14 Dec 2005 20:30:30 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id E204D58615D; Wed, 14 Dec 2005 20:30:26 +0100 (CET) In-Reply-To: <20051214172043.GD20929@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <20051214172043.GD20929@hut.isi.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Lars Eggert Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Date: Wed, 14 Dec 2005 20:30:24 +0100 To: Ted Faber X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Gorry Fairhurst , tcpm@ietf.org, Fernando Gont , "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="===============1668687770==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1668687770== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-43--484880894; protocol="application/pkcs7-signature" --Apple-Mail-43--484880894 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Dec 14, 2005, at 18:20, Ted Faber wrote: > On Wed, Dec 14, 2005 at 02:17:28PM +0000, Gorry Fairhurst wrote: >> >> So, a summary of my take and responding to some of this (which I >> hope we >> now have right). I'd be happy with new text saying something along >> the >> lines of: >> >> * MIN RTO is system-defined (with a warning that small requires >> caution;-) ). >> * The RECOMMENDED value for MIN RTO is follow RFCxxx. >> >> * UTO negotiation SHOULD be OFF by default. >> * UTO negotiation MAY be via a system config. >> * RECOMMEND negotiation is enabled via an API call from the >> application. >> * Upper and lower bounds may be set, but MUST NOT go below system >> MIN RTO >> * MUST use MIN RTO, if UTO negotiation is not enabled. > > That's a nice, succinct description of constraints on UTO. They sound > reasonable to me, and I'd love to hear from others. I think all of this is reasonable to put in. Some of the things we already say or try to say, but maybe the language isn't clear enough. (Sorry for not responding earlier to this threat, I'm swamped with year-end project stuff.) Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-43--484880894 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUxMjE0MTkzMDI1WjAjBgkqhkiG9w0BCQQxFgQURX6Zz+da+Hu9WLhOBwFM jLhNYgUwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAJKbPCqnygWXZTthSgZPRUjeKjqL6gTWQjDClTKfRFNppHaZ8UazaT1itrEFim53ajUhP/1I KF44oo5WnhVelSjveCWZTmIm757lFnmrS9vUwKL3riuJZPxXZ7NKNt1+kqN2h8iQ5q9XJ5O183u/ gNXM6VsjxRTLSuo0kUnArtdzUG1rE04AhDDKZw0Dq2CauJlHMGuxGx8av3GxBYF2zRKEsfZ9/7o5 32HBa0HkGpyEaMXOSundbrOHj/GtF8qEPbUKNntqChdYi9trix/ZsHV4Ca9eCZIG6KCVQmznmM/9 KOZp82XfJKOQbLeE83mR46DgSmJQmlT7/MvS9VPnTg8AAAAAAAA= --Apple-Mail-43--484880894-- --===============1668687770== 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 --===============1668687770==-- From tcpm-bounces@ietf.org Fri Dec 16 14:02:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnKq8-0002C5-N6; Fri, 16 Dec 2005 14:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnKq4-0002A5-VP for tcpm@megatron.ietf.org; Fri, 16 Dec 2005 14:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01146 for ; Fri, 16 Dec 2005 14:00:49 -0500 (EST) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnKg4-0002Iw-Fd for tcpm@ietf.org; Fri, 16 Dec 2005 13:51:38 -0500 Received: (qmail 28746 invoked from network); 16 Dec 2005 18:49:52 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 16 Dec 2005 18:49:52 -0000 Message-Id: <6.2.0.14.0.20051216101920.04459230@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 16 Dec 2005 10:32:00 -0800 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <20051214171952.GC20929@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <6.2.0.14.0.20051209201513.05519d10@localhost> <20051214171952.GC20929@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: gorry@erg.abdn.ac.uk, Lars Eggert , 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 At 09:19 a.m. 14/12/2005, Ted Faber wrote: > > The point is that if you;re really concerned about data being delivered, > > you should be implementing an application layer timeout mechanism. > > If there's no TCP timeout, it does not mean that the data were delivered. > >I understand the difference between a transport ack and acknowledgements >from higher layers. Some applications (correctly!) use transport state >to synchronize application state. Well, I'm not sure to what extent this is "correct". For example, if BGP connections were "decoupled" from the underlying TCP connection, then we'd not care about reset attacks against TCP, for example. (Or, well, at least we'd not be so "scared") >Consider a file transfer appliaction that opens a TCP connection for >each file. The connection is closed when the file is saved to disk. A >transmitter knows the file has been delivered correctly if and only if >the receiver closes its connection correctly. The receiver knows the >whole file has been transmitted when the sender closes its side of the >connection (a receiver never closes its connection before a sender >does). Voila, application synchronization using TCP signalling. This assumes that the underlying transport protocol allows each direction of the connection to be closed independently of the other. I'd not put such a requirement on the underlying transport protocol if I were to design an application layer protocol. >Such an application may well want to use TCP's existing UTO mechanism as >a timeout. The timeout may help in some scenarios, but still does not solve the usual requirement of the application layer. If the point of using the TCP timeout is just to avoid waiting forever, okay. But, in the more general case of an application wanting to know what the result of the last command sent was, you will still need the application-layer thing. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 16 16:27:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnN6v-0004ZF-0w; Fri, 16 Dec 2005 16:27:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnN6r-0004X8-Af for tcpm@megatron.ietf.org; Fri, 16 Dec 2005 16:27:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20703 for ; Fri, 16 Dec 2005 16:26:24 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnN8W-00014m-47 for tcpm@ietf.org; Fri, 16 Dec 2005 16:29:09 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBGLQYe02092; Fri, 16 Dec 2005 13:26:34 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jBGLQJ3c074429; Fri, 16 Dec 2005 13:26:19 -0800 (PST) (envelope-from faber) Date: Fri, 16 Dec 2005 13:26:19 -0800 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 Message-ID: <20051216212619.GB66551@hut.isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <6.2.0.14.0.20051209201513.05519d10@localhost> <20051214171952.GC20929@hut.isi.edu> <6.2.0.14.0.20051216101920.04459230@localhost> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20051216101920.04459230@localhost> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: gorry@erg.abdn.ac.uk, Lars Eggert , 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="===============1185978879==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1185978879== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+" Content-Disposition: inline --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 16, 2005 at 10:32:00AM -0800, Fernando Gont wrote: > At 09:19 a.m. 14/12/2005, Ted Faber wrote: >=20 > >> The point is that if you;re really concerned about data being delivere= d, > >> you should be implementing an application layer timeout mechanism. > >> If there's no TCP timeout, it does not mean that the data were deliver= ed. > > > >I understand the difference between a transport ack and acknowledgements > >from higher layers. Some applications (correctly!) use transport state > >to synchronize application state. >=20 > Well, I'm not sure to what extent this is "correct". Correct is hard to dispute. If TCP behaves properly and the application behaves as I specified, both ends know if the transfer succeeds or fails; that's correct. I think you mean that you find it distasteful. :-) I can't argue with that. >=20 > For example, if BGP connections were "decoupled" from the underlying TCP= =20 > connection, then we'd not care about reset attacks against TCP, for=20 > example. (Or, well, at least we'd not be so "scared") I understand that you can incorrectly use code an application using TCP. That doesn't mean you can't code an application that uses it correctly. > >Consider a file transfer appliaction that opens a TCP connection for > >each file. The connection is closed when the file is saved to disk. A > >transmitter knows the file has been delivered correctly if and only if > >the receiver closes its connection correctly. The receiver knows the > >whole file has been transmitted when the sender closes its side of the > >connection (a receiver never closes its connection before a sender > >does). Voila, application synchronization using TCP signalling. >=20 > This assumes that the underlying transport protocol allows each direction= =20 > of the connection to be closed independently of the other. That's why I identified the transport as TCP, which has this property. The inclusion of that property is intentional. Depending on non-existant properties is certainly a bad design. :-) > I'd not put such a requirement on the underlying transport protocol if I= =20 > were to design an application layer protocol. There are good reasons for an engineer not to design an app the way I suggested. I don't think it's particularly clean myself, but I do think it's correct and I do think it's done. And it has the benefit of not having to redesign TCP's state synchronization machinery at the application. >=20 >=20 > >Such an application may well want to use TCP's existing UTO mechanism as > >a timeout. >=20 > The timeout may help in some scenarios, but still does not solve the usua= l=20 > requirement of the application layer. >=20 > If the point of using the TCP timeout is just to avoid waiting forever,= =20 > okay. But, in the more general case of an application wanting to know wha= t=20 > the result of the last command sent was, you will still need the=20 > application-layer thing. Again, I'm not arguing that all applications must be designed the way I layed out. There are certainly applications that can't be. You said that the app must be broken w/o additional application layer processing, which I took to mean that breaking applications w/o that processing by changing UTO semantics was acceptable to you. I presented a single instance of an application that used TCP signalling to signal application level state as a counter example. I just want those sorts of applications taken into account when we discuss UTO changes. That's my whole point. --=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 --jho1yZJdad60DJr+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDozD7aUz3f+Zf+XsRAhQUAJ0W0zd4tbHha0qrtatw8xpUtVde5ACg4wuZ mg2x3Ab+6RPQhnBz4cdVUEc= =jyLm -----END PGP SIGNATURE----- --jho1yZJdad60DJr+-- --===============1185978879== 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 --===============1185978879==--