From nobody Mon Dec 1 06:37:15 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C726E1A1BCC for ; Mon, 1 Dec 2014 06:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFn4RMhNaaGD for ; Mon, 1 Dec 2014 06:37:10 -0800 (PST) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B314A1A0173 for ; Mon, 1 Dec 2014 06:37:09 -0800 (PST) X-Spam-Processed: mail.kau.se, Mon, 01 Dec 2014 15:36:50 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.155.45 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <547C7D0C.8060500@kau.se> Date: Mon, 01 Dec 2014 15:37:00 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> <544ED2B8.4020208@kau.se> <655C07320163294895BBADA28372AF5D1669053B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <545F5B71.5090906@kau.se> <655C07320163294895BBADA28372AF5D16699B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16699B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7DIl7tYXx4ahbCSo2w0HOcNmdxs Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 14:37:14 -0000 Hi Michael, Sorry for my delayed response. Comments inline. On 2014-11-10 16:59, Scharf, Michael (Michael) wrote: > Hi Anna, > > Some follow-up comments. I omit the parts for which there seems to be agreement on the need for a document update. > >>> * Section 4: I also wonder if the text should define "previously >> unsent segments". The term "previously unsent data" is very well-known >> in the RFC series. A quick search revealed that "previously unsent >> segments" is usually only used to refer to situations when segments >> with this property have indeed been transmitted. Is my understanding >> correct that draft-ietf-tcpm-rtorestart-04 uses this term differently? >> I think it here refers to data that will be sent *in future*. In that >> case, I wonder if it is really clear how the sender can determine the >> number of "previously unsent segments". For instance, that number may >> depend on the segmentation strategy of the sender, in particular for >> applications that use many small write() calls. In this case a TCP >> stack may e.g. decide to send partial segments. I am not sure if the >> actual number of segments created from the "unsent data" is really >> known in advance always. Or do I miss something? >> >> You are correct that "previously unsent segments" refers to data that >> will be sent in the future. This is the same meaning as in RFC 3517 and >> RFC 4653. A definition of this term could be added to Section 2, but I >> am not sure if it is needed? To better understand the possible conflict >> in terminology, could you point to some of RFCs that use the term to >> refer to already transmitted segments? Intuitively that seems a bit >> strange to me. > I didn't say that there is a conflict in terminology. I might be wrong, but to me draft-ietf-tcpm-rtorestart-04 defines the term "previously unsent segments" as a *new* TCP state variable. Ok, I understood your first mail as two separate issues: 1) that the term "previously unsent segment" had a different meaning from other RFCs, 2) it was not clear how to calculate the number of previously unsent segments. So my pointer to RFC 3517 and RFC 4653 was with respect to issue 1 above. But if I understand correctly now, your question is mainly about the second issue of how one can estimate the number of previously unsent segments. We can add "previously unsent segments" to the terminology section as a variable, with the discussion on how to estimate the number of previously unsent segments then still contained in section 5.3. Is this what you are looking for? > The value of that variable may be obvious for certain architectures of a TCP stack, in particular if segmentation into packets occurs on socket write() calls, i.e., before data is actually sent to network. As far as I recall, this is how the Linux stack works internally. But I'd like to avoid that an RFC describes an algorithm that can only be implemented for certain architecture of a TCP stack. > > RFC 3517 and RFC 4653 either refer to the "amount of previously unsent data" (which doesn't need to be further defined IMHO), or the "transmission of previously unsent segments" (which is not what draft-ietf-tcpm-rtorestart-04 refers to). For instance, here is the exact wording of the closest matches I could find in RFC 3517 and RFC 4563: > > RFC 3517 Section 5 Processing and Acting Upon SACK Information > > "(2) If no sequence number 'S2' per rule (1) exists but there > exists available unsent data and the receiver's advertised > window allows, the sequence range of one segment of up to SMSS > octets of previously unsent data starting with sequence number > HighData+1 MUST be returned." > > => "previously unsent data", NOT segments > > RFC 3517 Section 5 Algorithm Details > > "Note: The first and second > duplicate ACKs can also be used to trigger the transmission of > previously unsent segments using the Limited Transmit algorithm > [RFC3042]." > > => "transmission of previously unsent segments", NOT the number of segments queued > > RFC 4653 Section 2 NCR Description > > "The first Extended Limited Transmit variant, Careful Limited > Transmit, calls for the transmission of one previously unsent > segment, in response to duplicate acknowledgments, for every two > segments that are known to have left the network." > > => "transmission of previously unsent segments", NOT the number of segments queued > > RFC 4653 Section 3.2 Terminating Extended Limited Transmit and Preventing Bursts > > "(T.3) A TCP is now permitted to transmit previously unsent data as > allowed by cwnd, FlightSize, application data availability, and > the receiver's advertised window." > > => "previously unsent data", NOT segments > > RFC 4653 Section 3.3. Extended Limited Transmit > > "(E.2) If the comparison in equation (1), below, holds and there are > SMSS bytes of previously unsent data available for > transmission, then the sender MUST transmit one segment of SMSS > bytes." > > => "previously unsent data", NOT segments > > Unless there is a definition of "number of previously unsent segments", I think this variable has to be defined and it has to be explained how it is calculated. > >> As discussed in section 5.3, the number of unsent segments can be >> estimated from the amount of unsent data and the SMSS. Note that we are >> only talking about data that is already available in the send queue, >> and >> later write calls can of course create additional segments. I guess a >> TCP stack that has one SMSS of data in its send queue is free to send >> this as multiple segments if it wants to, but I assume that would not >> be >> the normal behavior. As the estimate is not very critical it is not >> really a problem if this happens occasionally. > If Nagle's algorithm is disabled, sending out multiple segments would be the normal behavior in this case. Why would turning off Nagle's algorithm make the sender split up data ALREADY AVAILABLE in the send queue into multiple small-sized segments when it gets a chance to send? Note that the sender is blocked by the cwnd when the ACK arrives. While technically allowed I guess, I do not think this would be normal. > > I could imagine that disabling Nagle's algorithm could be pretty common among thin stream applications. This is why the draft should IMHO discuss if disabling Nagle's algorithm affects the method. I do not think it affects it. We can of course say this. Do you think this would be good/needed? (There are of course a lot of things available in TCP/SCTP that does not affect RTO restart.) > >> The addition of "previously unsent segments" is there to capture a >> corner case (see issue raised by Alex in >> http://www.ietf.org/mail-archive/web/tcpm/current/msg08780.html), so it >> will only be occasionally used. If we then get an incorrect estimate, >> say a sender with one SMSS of data would instead send this as two SMSS, >> and the algorithm triggers "incorrectly", this would be equivalent to >> using a RTOR threshold of rrthresh + 1 so nothing critical happens. (In >> some cases rrthresh + 1 may even be better.) > If a wrong parameter for the estimate is possible but not critical, this should be explained in the document. Ok, we can mention this in section 5.3. > > In general, the cited email from Alex stated: > > "* Sec 3: IMO the algo/doc is too much Linux driven. I would like to see a > segment-based *and* byte-based version of the algo, like RFC 5827." > > I fully agree to this statement and I think it has not been completely addressed in -04 so far. > >>> * Section 9: I wonder if an attacker could try to send certain ACK >> patterns to increase the risk of timeouts e.g. at a Web Server, >> leveraging the smaller RTO value. If successful, the RTOs could >> significantly reduce application performance. Probably, such an >> attacker could cause much more harm by other means, i.e., this may not >> be a significant security risk. But the current security analysis is >> very short. >> >> The section is very short, but this is because we do not really see any >> new security issues. >> >> If I understand your example above correctly, the receiver is trying >> to somehow reduce performance for its own application by manipulating >> the ACK pattern. But if you are trying to mess up things for your own >> application you can deliver incorrect data, throw away any data >> received >> or do whatever you want so I do not think trying to possibly slow down >> the sender is the thing to worry about in this attack scenario. If >> someone finds a relevant security issue it should of course be >> documented, but I do not think it makes sense to put in something like >> the above just to make the section longer. > I was thinking e.g. about an off-path attacker that tries to inject ACKs into the TCP connection to trigger RTOs to harm application performance. I am not arguing that this is really a relevant attack scenario, but it seems not impossible to try that. If you inject early ACKs you may be able to affect the RTO calculation and thereby increase the risk of spurious retransmissions, but this applies to RFC 6298 as well so there is nothing RTO restart specific about the attack. You do not increase the risk of a spurious RTO with RTO restart by sending an early ACK as this will be adjusted for in the RTO restart calculation, the timer always trigger one RTO after the transmission no matter when the ACK arrives. What should probably be clarified in this section is that the security considerations in RFC 6298 still applies also with RTO restart, but that no additional security problems are known. Unless someone detects some specific problems of course. We will clarify this. Cheers, Anna > > Michael > > > > From nobody Mon Dec 1 07:31:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4A71A1EED for ; Mon, 1 Dec 2014 07:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea5CBZkJ2uqo for ; Mon, 1 Dec 2014 07:31:29 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE7C1A1EF0 for ; Mon, 1 Dec 2014 07:31:15 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 320FAE667C6AA; Mon, 1 Dec 2014 15:31:09 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sB1FUpXf018216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 16:31:10 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 16:30:52 +0100 From: "Scharf, Michael (Michael)" To: Anna Brunstrom , "tcpm@ietf.org" Thread-Topic: [tcpm] draft-ietf-tcpm-rtorestart-04 Thread-Index: AQHP9vVqrXJrvR/Ze0yRRPU/kEN2LZxYL7CAgAHTccCAIOa4AIAAFzWQ Date: Mon, 1 Dec 2014 15:30:51 +0000 Message-ID: <655C07320163294895BBADA28372AF5D166AC52C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> <544ED2B8.4020208@kau.se> <655C07320163294895BBADA28372AF5D1669053B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <545F5B71.5090906@kau.se> <655C07320163294895BBADA28372AF5D16699B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> <547C7D0C.8060500@kau.se> In-Reply-To: <547C7D0C.8060500@kau.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/DmDnQ6Qt5Y892g9xx7LwIEt-RuU Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 15:31:36 -0000 Hi Anna, > > Some follow-up comments. I omit the parts for which there seems to be > agreement on the need for a document update. > > > >>> * Section 4: I also wonder if the text should define "previously > >> unsent segments". The term "previously unsent data" is very well- > known > >> in the RFC series. A quick search revealed that "previously unsent > >> segments" is usually only used to refer to situations when segments > >> with this property have indeed been transmitted. Is my understanding > >> correct that draft-ietf-tcpm-rtorestart-04 uses this term > differently? > >> I think it here refers to data that will be sent *in future*. In > that > >> case, I wonder if it is really clear how the sender can determine > the > >> number of "previously unsent segments". For instance, that number > may > >> depend on the segmentation strategy of the sender, in particular for > >> applications that use many small write() calls. In this case a TCP > >> stack may e.g. decide to send partial segments. I am not sure if the > >> actual number of segments created from the "unsent data" is really > >> known in advance always. Or do I miss something? > >> > >> You are correct that "previously unsent segments" refers to data > that > >> will be sent in the future. This is the same meaning as in RFC 3517 > and > >> RFC 4653. A definition of this term could be added to Section 2, but > I > >> am not sure if it is needed? To better understand the possible > conflict > >> in terminology, could you point to some of RFCs that use the term to > >> refer to already transmitted segments? Intuitively that seems a bit > >> strange to me. > > I didn't say that there is a conflict in terminology. I might be > wrong, but to me draft-ietf-tcpm-rtorestart-04 defines the term > "previously unsent segments" as a *new* TCP state variable. >=20 > Ok, I understood your first mail as two separate issues: 1) that the > term "previously unsent segment" had a different meaning from other > RFCs, 2) it was not clear how to calculate the number of previously > unsent segments. So my pointer to RFC 3517 and RFC 4653 was with > respect > to issue 1 above. But if I understand correctly now, your question is > mainly about the second issue of how one can estimate the number of > previously unsent segments. >=20 > We can add "previously unsent segments" to the terminology section as a > variable, with the discussion on how to estimate the number of > previously unsent segments then still contained in section 5.3. Is this > what you are looking for? Yes, I look for an exact definition of this parameter given that it is used= in the algorithm. I think the document should clearly define the variable = "previously unsent segments" and discuss how a TCP stack can determine this= variable. That definition should cover both a TCP stack that stores unsent= data internally in a segment-based buffer as well as a TCP stack that uses= a byte-based send buffer.=20 =20 > > The value of that variable may be obvious for certain architectures > of a TCP stack, in particular if segmentation into packets occurs on > socket write() calls, i.e., before data is actually sent to network. As > far as I recall, this is how the Linux stack works internally. But I'd > like to avoid that an RFC describes an algorithm that can only be > implemented for certain architecture of a TCP stack. > > > > RFC 3517 and RFC 4653 either refer to the "amount of previously > unsent data" (which doesn't need to be further defined IMHO), or the > "transmission of previously unsent segments" (which is not what draft- > ietf-tcpm-rtorestart-04 refers to). For instance, here is the exact > wording of the closest matches I could find in RFC 3517 and RFC 4563: > > > > RFC 3517 Section 5 Processing and Acting Upon SACK Information > > > > "(2) If no sequence number 'S2' per rule (1) exists but there > > exists available unsent data and the receiver's advertised > > window allows, the sequence range of one segment of up to > SMSS > > octets of previously unsent data starting with sequence > number > > HighData+1 MUST be returned." > > > > =3D> "previously unsent data", NOT segments > > > > RFC 3517 Section 5 Algorithm Details > > > > "Note: The first and second > > duplicate ACKs can also be used to trigger the transmission of > > previously unsent segments using the Limited Transmit algorithm > > [RFC3042]." > > > > =3D> "transmission of previously unsent segments", NOT the number > of segments queued > > > > RFC 4653 Section 2 NCR Description > > > > "The first Extended Limited Transmit variant, Careful Limited > > Transmit, calls for the transmission of one previously unsent > > segment, in response to duplicate acknowledgments, for every two > > segments that are known to have left the network." > > > > =3D> "transmission of previously unsent segments", NOT the number > of segments queued > > > > RFC 4653 Section 3.2 Terminating Extended Limited Transmit and > Preventing Bursts > > > > "(T.3) A TCP is now permitted to transmit previously unsent data > as > > allowed by cwnd, FlightSize, application data availability, > and > > the receiver's advertised window." > > > > =3D> "previously unsent data", NOT segments > > > > RFC 4653 Section 3.3. Extended Limited Transmit > > > > "(E.2) If the comparison in equation (1), below, holds and there > are > > SMSS bytes of previously unsent data available for > > transmission, then the sender MUST transmit one segment of > SMSS > > bytes." > > > > =3D> "previously unsent data", NOT segments > > > > Unless there is a definition of "number of previously unsent > segments", I think this variable has to be defined and it has to be > explained how it is calculated. > > > >> As discussed in section 5.3, the number of unsent segments can be > >> estimated from the amount of unsent data and the SMSS. Note that we > are > >> only talking about data that is already available in the send queue, > >> and > >> later write calls can of course create additional segments. I guess > a > >> TCP stack that has one SMSS of data in its send queue is free to > send > >> this as multiple segments if it wants to, but I assume that would > not > >> be > >> the normal behavior. As the estimate is not very critical it is not > >> really a problem if this happens occasionally. > > If Nagle's algorithm is disabled, sending out multiple segments would > be the normal behavior in this case. >=20 > Why would turning off Nagle's algorithm make the sender split up data > ALREADY AVAILABLE in the send queue into multiple small-sized segments > when it gets a chance to send? Note that the sender is blocked by the > cwnd when the ACK arrives. While technically allowed I guess, I do not > think this would be normal. As far as I can tell, you refer by a "send queue" to a byte-based stack, ri= ght? Example: Let us assume an application that triggerd three socket write() ca= lls of 100B after having disabled Nagle, but CWND currently does not allow = sending a new packet. write(100B) write(100B) write(100B) How many unsent segments does the TCP stack than have? For a byte-based stack, the most likely answer seems to be one segment of 3= 00B, given that the data has to be queued. But for a segment-based stack, it depends whether the stack internally crea= tes a segment immediately after each write() call. In this case, the stack = could create *three* segments of 100B and schedule all of them for transmis= sion. Alternatively, the stack could detect during/after the second and thi= rd write() call that there is queued data less than the MSS and merge the s= egments into one segment, resulting again in one segment of 300B. The latte= r operation could imply memory copies in the data structure that stores the= segment, and this may be more expensive than scheduling three segments. Be= cause of this effort, I could imagine some TCP stacks would have three segm= ents of unsent data in this example, in particular if Nagle is disabled. I have not checked recently what TCP stacks in reality do in that case, i.e= ., my example may not be realistic. But there are both segment- and byte-ba= sed TCP stacks in the wild, and the document should explain whether the par= ameter "number of previously unsent segments" depends on the stack-internal= segmentation strategy, or not. > > I could imagine that disabling Nagle's algorithm could be pretty > common among thin stream applications. This is why the draft should > IMHO discuss if disabling Nagle's algorithm affects the method. >=20 > I do not think it affects it. We can of course say this. Do you think > this would be good/needed? (There are of course a lot of things > available in TCP/SCTP that does not affect RTO restart.) Unless I miss something, disabling Nagle algorithm does affect the algorith= m depending on the segmentation strategy used by the stack. See the example= above. But my key question is about dependency on the segmentation strategy. Nagle= is just one aspect of this. > >> The addition of "previously unsent segments" is there to capture a > >> corner case (see issue raised by Alex in > >> http://www.ietf.org/mail-archive/web/tcpm/current/msg08780.html), so > it > >> will only be occasionally used. If we then get an incorrect > estimate, > >> say a sender with one SMSS of data would instead send this as two > SMSS, > >> and the algorithm triggers "incorrectly", this would be equivalent > to > >> using a RTOR threshold of rrthresh + 1 so nothing critical happens. > (In > >> some cases rrthresh + 1 may even be better.) > > If a wrong parameter for the estimate is possible but not critical, > this should be explained in the document. >=20 > Ok, we can mention this in section 5.3. OK > > In general, the cited email from Alex stated: > > > > "* Sec 3: IMO the algo/doc is too much Linux driven. I would like to > see a > > segment-based *and* byte-based version of the algo, like RFC > 5827." > > > > I fully agree to this statement and I think it has not been > completely addressed in -04 so far. > > > >>> * Section 9: I wonder if an attacker could try to send certain ACK > >> patterns to increase the risk of timeouts e.g. at a Web Server, > >> leveraging the smaller RTO value. If successful, the RTOs could > >> significantly reduce application performance. Probably, such an > >> attacker could cause much more harm by other means, i.e., this may > not > >> be a significant security risk. But the current security analysis is > >> very short. > >> > >> The section is very short, but this is because we do not really see > any > >> new security issues. > >> > >> If I understand your example above correctly, the receiver is > trying > >> to somehow reduce performance for its own application by > manipulating > >> the ACK pattern. But if you are trying to mess up things for your > own > >> application you can deliver incorrect data, throw away any data > >> received > >> or do whatever you want so I do not think trying to possibly slow > down > >> the sender is the thing to worry about in this attack scenario. If > >> someone finds a relevant security issue it should of course be > >> documented, but I do not think it makes sense to put in something > like > >> the above just to make the section longer. > > I was thinking e.g. about an off-path attacker that tries to inject > ACKs into the TCP connection to trigger RTOs to harm application > performance. I am not arguing that this is really a relevant attack > scenario, but it seems not impossible to try that. >=20 > If you inject early ACKs you may be able to affect the RTO calculation > and thereby increase the risk of spurious retransmissions, but this > applies to RFC 6298 as well so there is nothing RTO restart specific > about the attack. You do not increase the risk of a spurious RTO with > RTO restart by sending an early ACK as this will be adjusted for in the > RTO restart calculation, the timer always trigger one RTO after the > transmission no matter when the ACK arrives. >=20 > What should probably be clarified in this section is that the security > considerations in RFC 6298 still applies also with RTO restart, but > that > no additional security problems are known. Unless someone detects some > specific problems of course. We will clarify this. Thanks Michael From nobody Wed Dec 3 00:40:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80341A01D5; Wed, 3 Dec 2014 00:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy9iU4BRlFdL; Wed, 3 Dec 2014 00:40:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 801771A0092; Wed, 3 Dec 2014 00:40:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203084051.22265.30521.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 00:40:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/R8_VnZV140SvLhfgT6tdB0rcDY4 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-undeployed-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 08:40:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status Authors : Alexander Zimmermann Wesley M. Eddy Lars Eggert Filename : draft-ietf-tcpm-undeployed-01.txt Pages : 7 Date : 2014-12-03 Abstract: This document reclassifies several TCP extensions and TCP-related documents that have either been superseded, never seen widespread use, or are no longer recommended for use to Historic status. The affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, and RFC 6013. Additionally, it reclassifies RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and RFC 1071 to Informational status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-undeployed-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-undeployed-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 3 02:39:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D57A1A1A3E; Wed, 3 Dec 2014 02:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PavHAe01uFez; Wed, 3 Dec 2014 02:39:39 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E57B1A1A2D; Wed, 3 Dec 2014 02:39:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,507,1413270000"; d="scan'208";a="216019994" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx12-out.netapp.com with ESMTP; 03 Dec 2014 02:39:39 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 3 Dec 2014 02:39:37 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Wed, 3 Dec 2014 02:39:37 -0800 From: "Scheffenegger, Richard" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-undeployed-01.txt Thread-Index: AQHQDtTtnatKu9YgrES4EzG0jEEeGZx9rMyw Date: Wed, 3 Dec 2014 10:39:37 +0000 Message-ID: References: <20141203084051.22265.30521.idtracker@ietfa.amsl.com> In-Reply-To: <20141203084051.22265.30521.idtracker@ietfa.amsl.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wuFXDLv6XUq-plD-imMNxfHobGo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-undeployed-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 10:39:41 -0000 I have read (and privately commented on -00) -01, and like the updated text= . Thanks Alex! Richard -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Mittwoch, 03. Dezember 2014 09:41 To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-undeployed-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Moving Outdated TCP Extensions and TCP-related Do= cuments to Historic and Informational Status Authors : Alexander Zimmermann Wesley M. Eddy Lars Eggert Filename : draft-ietf-tcpm-undeployed-01.txt Pages : 7 Date : 2014-12-03 Abstract: This document reclassifies several TCP extensions and TCP-related documents that have either been superseded, never seen widespread use, or are no longer recommended for use to Historic status. The affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, and RFC 6013. Additionally, it reclassifies RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and RFC 1071 to Informational status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-undeployed-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-undeployed-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Dec 5 01:01:09 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0D71ACE0E for ; Fri, 5 Dec 2014 01:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.12 X-Spam-Level: *** X-Spam-Status: No, score=3.12 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW5EJM08lTsh for ; Fri, 5 Dec 2014 01:01:05 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10F41A0075 for ; Fri, 5 Dec 2014 01:01:05 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3E5C02780A7 for ; Fri, 5 Dec 2014 18:01:03 +0900 (JST) Received: by mail-lb0-f182.google.com with SMTP id f15so199762lbj.41 for ; Fri, 05 Dec 2014 01:01:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.120.167 with SMTP id ld7mr1732873lab.77.1417770060601; Fri, 05 Dec 2014 01:01:00 -0800 (PST) Received: by 10.114.200.113 with HTTP; Fri, 5 Dec 2014 01:01:00 -0800 (PST) Date: Fri, 5 Dec 2014 01:01:00 -0800 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e012290f2d5e0ea05097450a8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/sYBLxCG_xiJ9DD2wpiB7rt-ktUg Subject: [tcpm] Q about window scale factor limitation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 09:01:08 -0000 --089e012290f2d5e0ea05097450a8 Content-Type: text/plain; charset=UTF-8 Hi folks, I start wondering why window scaling factor is limited to 14. I guess this question might have come up before(e.g. https://www.ietf.org/mail-archive/web/tcpm/current/msg05787.html) But, I'm still wondering it might be worth discussing a bit more. Please point out if I miss something. We know the window scale factor is limited to 14 as described in RFC7323. TCP determines if a data segment is "old" or "new" by testing whether its sequence number is within 2^31 bytes of the left edge of the window, and if it is not, discarding the data as "old". To insure that new data is never mistakenly considered old and vice versa, the left edge of the sender's window has to be at most 2^31 away from the right edge of the receiver's window. The same is true of the sender's right edge and receiver's left edge. Since the right and left edges of either the sender's or receiver's window differ by the window size, and since the sender and receiver windows can be out of phase by at most the window size, the above constraints imply that two times the maximum window size must be less than 2^31, or max window < 2^30 However, I'm not very sure TCP determines if a data segment is old or new. In my understanding, TCP checks if a segment is inside of the window or not. It doesn't care if a segment is too old or too new as long as it's outside of the window. In order to discuss this more, I would like to think about the following example. Let's say, sender and receiver windows are completely out of sync. The sender's left edge is S and the right edge is S+W. (W is window size) The receiver's left edge is S+W+1 and the right edge is S + 2W +1. Now the segment S arrives at the receiver. In case of W >= 2^31, we can easily see it will be problematic. However, I would like to think about the case where W = 2^31 - X. Because if we allow window scale factor = 15, max window size will be 2^31 - 2^15. In this case, when the receiver checks the left edge, it considers S is in the left side of the left edge as W+1 < 2^31. It means S is outside of the window. When the receiver checks the right edge, it considers S is in the right side of the right edge as S - 2X +1 < S. this also means S is outside of the window. Here, as the RFC points out, the right edge check cannot detect S is old packet, however, this doesn't affect the result. If we think in this way, I'm thinking that scale factor=15 might be possible. Please let me know if I misunderstand something. Regards, -- Yoshi --089e012290f2d5e0ea05097450a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I start wondering why window scalin= g factor is limited to 14.
I guess this question might have come up= before(e.g.=C2=A0https://www.ietf.org/mail-archive/web/tcpm/current/msg0= 5787.html)
But, I'm still wondering it might be worth dis= cussing a bit more.
Please point out if I miss something.

We know the window scale factor is limited to 14 as descr= ibed in RFC7323.

   TCP determines =
if a data segment is "old" or "new" by testing whether
   its sequence number is within 2^31 bytes of the left edge of the
   window, and if it is not, discarding the data as "old".  To in=
sure
   that new data is never mistakenly considered old and vice versa, the
   left edge of the sender's window has to be at most 2^31 away from th=
e
   right edge of the receiver's window.  The same is true of the
   sender's right edge and receiver's left edge.  Since the right a=
nd
   left edges of either the sender's or receiver's window differ by=
 the
   window size, and since the sender and receiver windows can be out of
   phase by at most the window size, the above constraints imply that
   two times the maximum window size must be less than 2^31, or

                             max window < 2^30

<=
/pre>
However, I'm not very sure TCP determi=
nes if a data segment is old or new.=C2=A0
In my understa=
nding, TCP checks if a segment is inside of the window or not. It doesn'=
;t care if a segment is too old or too new as long as it's outside of t=
he window.=C2=A0

In order to discu=
ss this more, I would like to think about the following example.
Let's say, sender and receiver windows are completely out of sy=
nc.=C2=A0
The sender's left edge is S and the right e=
dge is S+W. (W is window size)
The receiver's left ed=
ge is S+W+1 and the right edge is S + 2W +1.
Now the segm=
ent S arrives at the receiver.

In =
case of W >=3D 2^31, we can easily see it will be problematic.
However, I would like to think about the case where W =3D 2^31 - X=
. Because if we allow window scale factor =3D 15, max window size will be 2=
^31 - 2^15.

In this case, when the= receiver checks the left edge, it considers S is in the left side of the l= eft edge as W+1 < 2^31. It means S is outside of the window.=C2=A0
=
When the receiver checks the right edge, it considers S is in = the right side of the right edge as S - 2X +1 < S. this also means S is = outside of the window.=C2=A0
Here, as the RFC points out,= the right edge check cannot detect S is old packet, however, this doesn= 9;t affect the result.
=C2=A0
If we thi= nk in this way, I'm thinking that scale factor=3D15 might be possible.<= /div>
Please let me know if I misunderstand something. =C2=A0

Regards,
--
=
Yoshi
--089e012290f2d5e0ea05097450a8-- From nobody Sun Dec 7 15:13:25 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F131A1B03 for ; Sun, 7 Dec 2014 15:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE_XV6iHRX77 for ; Sun, 7 Dec 2014 15:13:19 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490371A06E9 for ; Sun, 7 Dec 2014 15:13:18 -0800 (PST) X-Spam-Processed: mail.kau.se, Mon, 08 Dec 2014 00:13:08 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 213.113.180.22 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <5484DF05.5060800@kau.se> Date: Mon, 08 Dec 2014 00:13:09 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> <544ED2B8.4020208@kau.se> <655C07320163294895BBADA28372AF5D1669053B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <545F5B71.5090906@kau.se> <655C07320163294895BBADA28372AF5D16699B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> <547C7D0C.8060500@kau.se> <655C07320163294895BBADA28372AF5D166AC52C@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D166AC52C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/cFaXO2rIBNfTMkzTekl3QJTcEvw Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 23:13:23 -0000 Hi Michael, On 2014-12-01 16:30, Scharf, Michael (Michael) wrote: > Hi Anna, > >>> Some follow-up comments. I omit the parts for which there seems to be >> agreement on the need for a document update. >>>>> * Section 4: I also wonder if the text should define "previously >>>> unsent segments". The term "previously unsent data" is very well- >> known >>>> in the RFC series. A quick search revealed that "previously unsent >>>> segments" is usually only used to refer to situations when segments >>>> with this property have indeed been transmitted. Is my understanding >>>> correct that draft-ietf-tcpm-rtorestart-04 uses this term >> differently? >>>> I think it here refers to data that will be sent *in future*. In >> that >>>> case, I wonder if it is really clear how the sender can determine >> the >>>> number of "previously unsent segments". For instance, that number >> may >>>> depend on the segmentation strategy of the sender, in particular for >>>> applications that use many small write() calls. In this case a TCP >>>> stack may e.g. decide to send partial segments. I am not sure if the >>>> actual number of segments created from the "unsent data" is really >>>> known in advance always. Or do I miss something? >>>> >>>> You are correct that "previously unsent segments" refers to data >> that >>>> will be sent in the future. This is the same meaning as in RFC 3517 >> and >>>> RFC 4653. A definition of this term could be added to Section 2, but >> I >>>> am not sure if it is needed? To better understand the possible >> conflict >>>> in terminology, could you point to some of RFCs that use the term to >>>> refer to already transmitted segments? Intuitively that seems a bit >>>> strange to me. >>> I didn't say that there is a conflict in terminology. I might be >> wrong, but to me draft-ietf-tcpm-rtorestart-04 defines the term >> "previously unsent segments" as a *new* TCP state variable. >> >> Ok, I understood your first mail as two separate issues: 1) that the >> term "previously unsent segment" had a different meaning from other >> RFCs, 2) it was not clear how to calculate the number of previously >> unsent segments. So my pointer to RFC 3517 and RFC 4653 was with >> respect >> to issue 1 above. But if I understand correctly now, your question is >> mainly about the second issue of how one can estimate the number of >> previously unsent segments. >> >> We can add "previously unsent segments" to the terminology section as a >> variable, with the discussion on how to estimate the number of >> previously unsent segments then still contained in section 5.3. Is this >> what you are looking for? > Yes, I look for an exact definition of this parameter given that it is used in the algorithm. I think the document should clearly define the variable "previously unsent segments" and discuss how a TCP stack can determine this variable. That definition should cover both a TCP stack that stores unsent data internally in a segment-based buffer as well as a TCP stack that uses a byte-based send buffer. Ok. > >>> The value of that variable may be obvious for certain architectures >> of a TCP stack, in particular if segmentation into packets occurs on >> socket write() calls, i.e., before data is actually sent to network. As >> far as I recall, this is how the Linux stack works internally. But I'd >> like to avoid that an RFC describes an algorithm that can only be >> implemented for certain architecture of a TCP stack. >>> RFC 3517 and RFC 4653 either refer to the "amount of previously >> unsent data" (which doesn't need to be further defined IMHO), or the >> "transmission of previously unsent segments" (which is not what draft- >> ietf-tcpm-rtorestart-04 refers to). For instance, here is the exact >> wording of the closest matches I could find in RFC 3517 and RFC 4563: >>> RFC 3517 Section 5 Processing and Acting Upon SACK Information >>> >>> "(2) If no sequence number 'S2' per rule (1) exists but there >>> exists available unsent data and the receiver's advertised >>> window allows, the sequence range of one segment of up to >> SMSS >>> octets of previously unsent data starting with sequence >> number >>> HighData+1 MUST be returned." >>> >>> => "previously unsent data", NOT segments >>> >>> RFC 3517 Section 5 Algorithm Details >>> >>> "Note: The first and second >>> duplicate ACKs can also be used to trigger the transmission of >>> previously unsent segments using the Limited Transmit algorithm >>> [RFC3042]." >>> >>> => "transmission of previously unsent segments", NOT the number >> of segments queued >>> RFC 4653 Section 2 NCR Description >>> >>> "The first Extended Limited Transmit variant, Careful Limited >>> Transmit, calls for the transmission of one previously unsent >>> segment, in response to duplicate acknowledgments, for every two >>> segments that are known to have left the network." >>> >>> => "transmission of previously unsent segments", NOT the number >> of segments queued >>> RFC 4653 Section 3.2 Terminating Extended Limited Transmit and >> Preventing Bursts >>> "(T.3) A TCP is now permitted to transmit previously unsent data >> as >>> allowed by cwnd, FlightSize, application data availability, >> and >>> the receiver's advertised window." >>> >>> => "previously unsent data", NOT segments >>> >>> RFC 4653 Section 3.3. Extended Limited Transmit >>> >>> "(E.2) If the comparison in equation (1), below, holds and there >> are >>> SMSS bytes of previously unsent data available for >>> transmission, then the sender MUST transmit one segment of >> SMSS >>> bytes." >>> >>> => "previously unsent data", NOT segments >>> >>> Unless there is a definition of "number of previously unsent >> segments", I think this variable has to be defined and it has to be >> explained how it is calculated. >>>> As discussed in section 5.3, the number of unsent segments can be >>>> estimated from the amount of unsent data and the SMSS. Note that we >> are >>>> only talking about data that is already available in the send queue, >>>> and >>>> later write calls can of course create additional segments. I guess >> a >>>> TCP stack that has one SMSS of data in its send queue is free to >> send >>>> this as multiple segments if it wants to, but I assume that would >> not >>>> be >>>> the normal behavior. As the estimate is not very critical it is not >>>> really a problem if this happens occasionally. >>> If Nagle's algorithm is disabled, sending out multiple segments would >> be the normal behavior in this case. >> >> Why would turning off Nagle's algorithm make the sender split up data >> ALREADY AVAILABLE in the send queue into multiple small-sized segments >> when it gets a chance to send? Note that the sender is blocked by the >> cwnd when the ACK arrives. While technically allowed I guess, I do not >> think this would be normal. > As far as I can tell, you refer by a "send queue" to a byte-based stack, right? I was not really making a distinction. > > Example: Let us assume an application that triggerd three socket write() calls of 100B after having disabled Nagle, but CWND currently does not allow sending a new packet. > write(100B) > write(100B) > write(100B) > > How many unsent segments does the TCP stack than have? I would think that one segment of 300B is the normal case for both types of stacks, but it is true that the implementation can do what it wants. > > For a byte-based stack, the most likely answer seems to be one segment of 300B, given that the data has to be queued. > > But for a segment-based stack, it depends whether the stack internally creates a segment immediately after each write() call. In this case, the stack could create *three* segments of 100B and schedule all of them for transmission. Alternatively, the stack could detect during/after the second and third write() call that there is queued data less than the MSS and merge the segments into one segment, resulting again in one segment of 300B. The latter operation could imply memory copies in the data structure that stores the segment, and this may be more expensive than scheduling three segments. Because of this effort, I could imagine some TCP stacks would have three segments of unsent data in this example, in particular if Nagle is disabled. > > I have not checked recently what TCP stacks in reality do in that case, i.e., my example may not be realistic. But there are both segment- and byte-based TCP stacks in the wild, and the document should explain whether the parameter "number of previously unsent segments" depends on the stack-internal segmentation strategy, or not. Ok, we will try to address this in the next version. BR, Anna > >>> I could imagine that disabling Nagle's algorithm could be pretty >> common among thin stream applications. This is why the draft should >> IMHO discuss if disabling Nagle's algorithm affects the method. >> >> I do not think it affects it. We can of course say this. Do you think >> this would be good/needed? (There are of course a lot of things >> available in TCP/SCTP that does not affect RTO restart.) > Unless I miss something, disabling Nagle algorithm does affect the algorithm depending on the segmentation strategy used by the stack. See the example above. > > But my key question is about dependency on the segmentation strategy. Nagle is just one aspect of this. > >>>> The addition of "previously unsent segments" is there to capture a >>>> corner case (see issue raised by Alex in >>>> http://www.ietf.org/mail-archive/web/tcpm/current/msg08780.html), so >> it >>>> will only be occasionally used. If we then get an incorrect >> estimate, >>>> say a sender with one SMSS of data would instead send this as two >> SMSS, >>>> and the algorithm triggers "incorrectly", this would be equivalent >> to >>>> using a RTOR threshold of rrthresh + 1 so nothing critical happens. >> (In >>>> some cases rrthresh + 1 may even be better.) >>> If a wrong parameter for the estimate is possible but not critical, >> this should be explained in the document. >> >> Ok, we can mention this in section 5.3. > OK > >>> In general, the cited email from Alex stated: >>> >>> "* Sec 3: IMO the algo/doc is too much Linux driven. I would like to >> see a >>> segment-based *and* byte-based version of the algo, like RFC >> 5827." >>> I fully agree to this statement and I think it has not been >> completely addressed in -04 so far. >>>>> * Section 9: I wonder if an attacker could try to send certain ACK >>>> patterns to increase the risk of timeouts e.g. at a Web Server, >>>> leveraging the smaller RTO value. If successful, the RTOs could >>>> significantly reduce application performance. Probably, such an >>>> attacker could cause much more harm by other means, i.e., this may >> not >>>> be a significant security risk. But the current security analysis is >>>> very short. >>>> >>>> The section is very short, but this is because we do not really see >> any >>>> new security issues. >>>> >>>> If I understand your example above correctly, the receiver is >> trying >>>> to somehow reduce performance for its own application by >> manipulating >>>> the ACK pattern. But if you are trying to mess up things for your >> own >>>> application you can deliver incorrect data, throw away any data >>>> received >>>> or do whatever you want so I do not think trying to possibly slow >> down >>>> the sender is the thing to worry about in this attack scenario. If >>>> someone finds a relevant security issue it should of course be >>>> documented, but I do not think it makes sense to put in something >> like >>>> the above just to make the section longer. >>> I was thinking e.g. about an off-path attacker that tries to inject >> ACKs into the TCP connection to trigger RTOs to harm application >> performance. I am not arguing that this is really a relevant attack >> scenario, but it seems not impossible to try that. >> >> If you inject early ACKs you may be able to affect the RTO calculation >> and thereby increase the risk of spurious retransmissions, but this >> applies to RFC 6298 as well so there is nothing RTO restart specific >> about the attack. You do not increase the risk of a spurious RTO with >> RTO restart by sending an early ACK as this will be adjusted for in the >> RTO restart calculation, the timer always trigger one RTO after the >> transmission no matter when the ACK arrives. >> >> What should probably be clarified in this section is that the security >> considerations in RFC 6298 still applies also with RTO restart, but >> that >> no additional security problems are known. Unless someone detects some >> specific problems of course. We will clarify this. > Thanks > > Michael > From nobody Thu Dec 18 16:43:29 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422381ACCDE; Thu, 18 Dec 2014 16:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_uXmrMkhJ4A; Thu, 18 Dec 2014 16:43:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8D61ACCDA; Thu, 18 Dec 2014 16:43:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5CD03181CD6; Thu, 18 Dec 2014 16:42:57 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141219004257.5CD03181CD6@rfc-editor.org> Date: Thu, 18 Dec 2014 16:42:57 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TsacgA79xoWUVeHseHgY-wlSb4Q Cc: drafts-update-ref@iana.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 7413 on TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 00:43:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7413 Title: TCP Fast Open Author: Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Status: Experimental Stream: IETF Date: December 2014 Mailbox: ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com Pages: 26 Characters: 59945 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-fastopen-10.txt URL: https://www.rfc-editor.org/rfc/rfc7413.txt This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC