Hi,

Thanks for the ques= tion.

In the draft -- https://tools.ietf.org/html/draft-ietf-= tcpm-rack-01 -- we try to address that in section 7.5:

7.5.=C2=A0 Interaction with congestion control

=C2=A0 =C2=A0RACK intentionally decouples loss detection from congest= ion control.

=C2=A0 =C2=A0RACK only detects losses; it does not m= odify the congestion control

=C2=A0 =C2=A0algorithm [RFC5681][RFC= 6937].

Thus, in any scenario like the one you des= cribe, where RACK (with or without a TLP probe) marks one or more packets a= s lost, the sender should use its normal congestion control response to pac= ket loss. So if the sender is using Reno or CUBIC, it should leave congesti= on avoidance and enter fast recovery, and cut cwnd and ssthresh as it would= with any other loss detection algorithm.

Does that help= clear up this question?

If there is a particular = section that was unclear on this point or seemed to imply otherwise, please= let us know so we can revise it. :-)

Thanks!

neal

On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun <marcelo@it.= uc3m.es> wrote:

Hi,

After reading draft-ietf-tcpm-rack-01, I have a question about the impact o= f the impact of the use of RACK and TLP in congestion control.

If this issue has been discussed earlier, I apologize and please point me t= o the right thread in the archive.

So, consider the following situation. A TCP sender using RACK and TLP as de= fined in the draft has at a given moment a large number on packets in fligh= t. Suppose that all packets are lost. I understand the reaction of the send= er in this case is that it will fire a Tail Loss Probe after the PTO expire= s i.e. 2RTT later.

Suppose that the probe makes it and an ack for that probe is returned. Sinc= e the probe is a new packet or a retransmission of the latest packet, RACK = at the sender is likely to mark all previous packets as lost and retransmit= them. All this is done while staying in congestion avoidance phase, afaiu.=

This seems a significant departure from current congestion control mechanis= ms, i think. I mean, this is not the case of a spurious isolated drop. All = packets in flight were lost, which can be a pretty large number of packets.= Staying in congestion avoidance after a single packet made it through seem= s more optimistic than the current situation, i would say.

Am i missing something?

Regards, marcelo

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a114152c2d423a80549387850-- From nobody Thu Feb 23 12:43:46 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFDE129AB8 for ; Thu, 23 Feb 2017 12:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 V9HLP7n2YnCa for ; Thu, 23 Feb 2017 12:43:42 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DA912A2C9 for ; Thu, 23 Feb 2017 12:43:19 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id v186so182937562wmd.0 for ; Thu, 23 Feb 2017 12:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=vv4OP5nrh4FHZeZs5J6BfFYuGF6TBEL5cfACwlM50JM=; b=wWtJqkZ4xQQzP4rJwsjtEW7pGT99MV2BQ2N12F2wFxFH+bmTcpfdClIL2T9qL6IO7p VnLw+BClaDZ1htrYCqcPO0haeezWKhmiuAVbeueY/3NLYsirvOPn46jkfXBlvsa4B94V qR04X+FpTDyeZhOq5Ds1YmPoV8EJClr1ww7HxYQztxfWB+S8cuDiLeJDjycM10Erl5dN IH+EdFPFV7siAwB3KHJvsWsZ+gUeLeVcPjBA+pt4vrymWV0niLLDweLHY4e5IuxZ/dVO YPY2fxAJ+LjKQ1X0NpdwuOXUqbacEIJWYzBsxIV90awOvjm3DKeDgeMOuNRwcz1xhGH7 JCyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=vv4OP5nrh4FHZeZs5J6BfFYuGF6TBEL5cfACwlM50JM=; b=kw8koINHzHTLXr5p5BNoZVPQc82vMvfPUCrq2tnI5b0HhM1cbJhul8RtLJ44DUXPx3 QbLZRMah1uXN2kzxfkx0MgDzhGc7cR7EsyS4GB2XceKlv0OZKQvuRI1ddGQDlxfky0ht y2Kb3gUNivz4wxcYo3cO6mRlrCf7KStdq9MWpyofNOxSSDzAQ1yNJF8CvUnDzSbb8OfP Dz8jJJrgFMGDB67ryg6Sg/+iea3qgp0ZIYCQbk5QCMGdaJgOLWLkWYqRLRdYfyANczZI 1NAx16M+p7uapM7pjNBfdkjOeAvbUf2Tx819uKPq4k6JHY6Zpm+PHOSnXzGxK2KsaQXC HJng== X-Gm-Message-State: AMke39m43J1LIdkoF+dACdjNKhs2CK2+w94TWIN0T3Elv/7emPw82ShH/+eb0rUf++8LTxwS X-Received: by 10.28.236.79 with SMTP id k76mr6625188wmh.79.1487882597924; Thu, 23 Feb 2017 12:43:17 -0800 (PST) Received: from Macintosh-6.local (20.163.16.95.dynamic.jazztel.es. [95.16.163.20]) by smtp.gmail.com with ESMTPSA id y1sm7806463wme.15.2017.02.23.12.43.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 12:43:17 -0800 (PST) To: Neal Cardwell References: From: marcelo bagnulo braun Message-ID: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es> Date: Thu, 23 Feb 2017 21:43:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 23 Feb 2017 20:43:45 -0000 Hi, Let me try to rephrase/expand. As I understand it, the response to congestion depends on the intensity of the congestion signal. If a few packets are lost, the CWND is reduced to half. This is why afaiu, the response to 3 (or more) duplicated ACKs is to reduce CWND by half (or some other number in cubic) However, if all the packets in flight are lost, there are no duplicated acks, and the loss is detected through the RTO. In this case, the congestion signal is more intense and the CWND is reduced to 1 MSS. In the example i included below, all the packets in flight are lost, but TLP+RACK manages to recover without using the RTO. So, i guess my question is: in this case, what happens to the CWND? is it reduced to half or is it set to 1 MSS? Regards, marcelo El 23/02/17 a las 21:29, Neal Cardwell escribió: > Hi, > > Thanks for the question. > > In the draft -- https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 -- > we try to address that in section 7.5: > > 7.5. Interaction with congestion control > > RACK intentionally decouples loss detection from congestion control. > RACK only detects losses; it does not modify the congestion control > algorithm [RFC5681][RFC6937]. > > Thus, in any scenario like the one you describe, where RACK (with or > without a TLP probe) marks one or more packets as lost, the sender > should use its normal congestion control response to packet loss. So > if the sender is using Reno or CUBIC, it should leave congestion > avoidance and enter fast recovery, and cut cwnd and ssthresh as it > would with any other loss detection algorithm. > > Does that help clear up this question? > > If there is a particular section that was unclear on this point or > seemed to imply otherwise, please let us know so we can revise it. :-) > > Thanks! > neal > > > On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun > > wrote: > > Hi, > > After reading draft-ietf-tcpm-rack-01, I have a question about the > impact of the impact of the use of RACK and TLP in congestion control. > > If this issue has been discussed earlier, I apologize and please > point me to the right thread in the archive. > > So, consider the following situation. A TCP sender using RACK and > TLP as defined in the draft has at a given moment a large number > on packets in flight. Suppose that all packets are lost. I > understand the reaction of the sender in this case is that it will > fire a Tail Loss Probe after the PTO expires i.e. 2RTT later. > > Suppose that the probe makes it and an ack for that probe is > returned. Since the probe is a new packet or a retransmission of > the latest packet, RACK at the sender is likely to mark all > previous packets as lost and retransmit them. All this is done > while staying in congestion avoidance phase, afaiu. > > This seems a significant departure from current congestion control > mechanisms, i think. I mean, this is not the case of a spurious > isolated drop. All packets in flight were lost, which can be a > pretty large number of packets. Staying in congestion avoidance > after a single packet made it through seems more optimistic than > the current situation, i would say. > > Am i missing something? > > Regards, marcelo > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > From nobody Thu Feb 23 14:00:11 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15795129B3D for ; Thu, 23 Feb 2017 14:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Z96QmIa9xkHp for ; Thu, 23 Feb 2017 14:00:06 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686681296D5 for ; Thu, 23 Feb 2017 14:00:06 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id s205so2321481oif.3 for ; Thu, 23 Feb 2017 14:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sTdDuw8YkzeAaAs6WT8rdmDhUvSKKDqAtp4Qli8jjBM=; b=d8T98QPQhLSClt/SN9kYSD6/dTk5+9B9ixYks2nG8eZxC+VxkKiaXc4jbSANIlY2SA eiu2PuuZoLzJGQFzXxzegXZH/JbKezGBN6aLWm2ALCcK1938ETmUi1S3Sn2XABKUVSay VIZHIRVU/kQGR/8hQbetc5xb72womY3Vw5nbJ6WM//7RR66eRM5Xmpw1fDaSoYgDBC2N pGqXJZbO71ZphOFxh3N/hXvBah6PZUB8e8i1VLXj6p8jEDLe2uhF4hLiE3f7l+S/59wn DeR1HyQI4nK8Ur35kuIZLI6gBzX5XiO9F3FRmykQy7E1ZiAfPKOuxpV5aHZVsSPNdBet lrRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sTdDuw8YkzeAaAs6WT8rdmDhUvSKKDqAtp4Qli8jjBM=; b=ax9wysP3KS0c2MvglgrzrTT86KAzcmL0ZSq0zODKZ/RagoRywxFRGH7NvgnhnI0ROr cf9l58Wg15EBDQnMecJef3KCVV4qr5L+FtGH2ygAZoGIsQjsQM5/38ucfeK6b3FZWS3k tmc6yknBhkZKkMWgLdvKBHVrl5nMqNgpgGmaPhuSaSsw7oxR++o6JuzJ2+ZKi9amVsdE icFhMaoXyvZAmS8LkCYiIg2+HRjYQUWown/Wfl9teQ0KNJH+hMSTE/3d41Nhyr0Ekwh4 1JrdVplfUOuWzSx6VpJxKvOm2mIcT+OFXjUwaw3etB4BkShDCYiKkcYScY43ZI3vosd2 cirQ== X-Gm-Message-State: AMke39n98KPHHTWodc9la6rk7QCpPlr7pAFpnbk0ZIYIs+SAZQEhPXNnkn16GkNY28tDTC/W+MzMg2ivbktAGqFP X-Received: by 10.202.236.18 with SMTP id k18mr19278720oih.83.1487887205576; Thu, 23 Feb 2017 14:00:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.71.216 with HTTP; Thu, 23 Feb 2017 13:59:35 -0800 (PST) In-Reply-To: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es> References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es> From: Neal Cardwell Date: Thu, 23 Feb 2017 16:59:35 -0500 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a11c17dc65af130054939bc20 Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 23 Feb 2017 22:00:09 -0000 --001a11c17dc65af130054939bc20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun wrote: > Hi, > > Let me try to rephrase/expand. > > As I understand it, the response to congestion depends on the intensity o= f > the congestion signal. > If a few packets are lost, the CWND is reduced to half. This is why afaiu= , > the response to 3 (or more) duplicated ACKs is to reduce CWND by half (or > some other number in cubic) > > However, if all the packets in flight are lost, there are no duplicated > acks, and the loss is detected through the RTO. In this case, the > congestion signal is more intense and the CWND is reduced to 1 MSS. > > In the example i included below, all the packets in flight are lost, but > TLP+RACK manages to recover without using the RTO. > So, i guess my question is: in this case, what happens to the CWND? is it > reduced to half or is it set to 1 MSS? > At a high level, that is a decision for congestion control, and RACK is a loss detection aglorithm, and tries to stay orthogonal to congestion control. But on a practical level, a TCP sender ideally should be using the state of the art recovery algorithm, PRR -- https://tools.ietf.org/html/rfc6937 -- for fast recovery. If it does that then in the situation you sketch it will slow-start up from a cwnd of 1, allowing 1 packet in flight, up to the ssthresh set by the congestion control algorithm. This is basically the response that the sender would have had to an RTO as well. So from a practical standpoint it doesn't matter much that with RACK the sender enters recovery instead of RTO - either way the sender should be slow-starting up from a cwnd of 1 up to ssthresh. neal > Regards, marcelo > > > El 23/02/17 a las 21:29, Neal Cardwell escribi=C3=B3: > >> Hi, >> >> Thanks for the question. >> >> In the draft -- https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 -- >> we try to address that in section 7.5: >> >> 7.5. Interaction with congestion control >> >> RACK intentionally decouples loss detection from congestion control. >> RACK only detects losses; it does not modify the congestion control >> algorithm [RFC5681][RFC6937]. >> >> Thus, in any scenario like the one you describe, where RACK (with or >> without a TLP probe) marks one or more packets as lost, the sender shoul= d >> use its normal congestion control response to packet loss. So if the sen= der >> is using Reno or CUBIC, it should leave congestion avoidance and enter f= ast >> recovery, and cut cwnd and ssthresh as it would with any other loss >> detection algorithm. >> >> Does that help clear up this question? >> >> If there is a particular section that was unclear on this point or seeme= d >> to imply otherwise, please let us know so we can revise it. :-) >> >> Thanks! >> neal >> >> >> On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun < >> marcelo@it.uc3m.es > wrote: >> >> Hi, >> >> After reading draft-ietf-tcpm-rack-01, I have a question about the >> impact of the impact of the use of RACK and TLP in congestion contro= l. >> >> If this issue has been discussed earlier, I apologize and please >> point me to the right thread in the archive. >> >> So, consider the following situation. A TCP sender using RACK and >> TLP as defined in the draft has at a given moment a large number >> on packets in flight. Suppose that all packets are lost. I >> understand the reaction of the sender in this case is that it will >> fire a Tail Loss Probe after the PTO expires i.e. 2RTT later. >> >> Suppose that the probe makes it and an ack for that probe is >> returned. Since the probe is a new packet or a retransmission of >> the latest packet, RACK at the sender is likely to mark all >> previous packets as lost and retransmit them. All this is done >> while staying in congestion avoidance phase, afaiu. >> >> This seems a significant departure from current congestion control >> mechanisms, i think. I mean, this is not the case of a spurious >> isolated drop. All packets in flight were lost, which can be a >> pretty large number of packets. Staying in congestion avoidance >> after a single packet made it through seems more optimistic than >> the current situation, i would say. >> >> Am i missing something? >> >> Regards, marcelo >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> >> > --001a11c17dc65af130054939bc20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun <marcelo@it.uc= 3m.es> wrote:

Hi,

Let me try to rephrase/expand.

As I understand it, the response to congestion depends on the intensity of = the congestion signal.
If a few packets are lost, the CWND is reduced to half. This is why afaiu, = the response to 3 (or more) duplicated ACKs is to reduce CWND by half (or s= ome other number in cubic)

However, if all the packets in flight are lost, there are no duplicated ack= s, and the loss is detected through the RTO. In this case, the congestion s= ignal is more intense and the CWND is reduced to 1 MSS.

In the example i included below, all the packets in flight are lost, but TL= P+RACK manages to recover without using the RTO.
So, i guess my question is: in this case, what happens to the CWND? is it r= educed to half or is it set to 1 MSS?

A= t a high level, that is a decision for congestion control, and RACK is a lo= ss detection aglorithm, and tries to stay orthogonal to congestion control.=

But on a practical level, a TCP sender ideally sh= ould be using the state of the art recovery algorithm, PRR =C2=A0-- https://tools.ietf.org/html/rfc693= 7 -- for fast recovery. If it does that then in the situation you sketc= h it will slow-start up from a cwnd of 1, allowing 1 packet in flight, up t= o the ssthresh set by the congestion control algorithm. This is basically t= he response that the sender would have had to an RTO as well. So from a pra= ctical standpoint it doesn't matter much that with RACK the sender ente= rs recovery instead of RTO - either way the sender should be slow-starting = up from a cwnd of 1 up to ssthresh.

neal

=C2=A0

Regards, marcelo

El 23/02/17 a las 21:29, Neal Cardwell escribi=C3=B3:

Hi,

Thanks for the question.

In the draft -- https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 -- we try to address that in section 7.5:

7.5.=C2=A0 Interaction with congestion control

=C2=A0 =C2=A0RACK intentionally decouples loss detection from congestion co= ntrol.
=C2=A0 =C2=A0RACK only detects losses; it does not modify the congestion co= ntrol
=C2=A0 =C2=A0algorithm [RFC5681][RFC6937].

Thus, in any scenario like the one you describe, where RACK (with or withou= t a TLP probe) marks one or more packets as lost, the sender should use its= normal congestion control response to packet loss. So if the sender is usi= ng Reno or CUBIC, it should leave congestion avoidance and enter fast recov= ery, and cut cwnd and ssthresh as it would with any other loss detection al= gorithm.

Does that help clear up this question?

If there is a particular section that was unclear on this point or seemed t= o imply otherwise, please let us know so we can revise it. :-)

Thanks!
neal

On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun <marcelo@it.uc3m.es <mailto:<= a href=3D"mailto:marcelo@it.uc3m.es" target=3D"_blank">marcelo@it.uc3m.es>> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 After reading draft-ietf-tcpm-rack-01, I have a question abou= t the
=C2=A0 =C2=A0 impact of the impact of the use of RACK and TLP in congestion= control.

=C2=A0 =C2=A0 If this issue has been discussed earlier, I apologize and ple= ase
=C2=A0 =C2=A0 point me to the right thread in the archive.

=C2=A0 =C2=A0 So, consider the following situation. A TCP sender using RACK= and
=C2=A0 =C2=A0 TLP as defined in the draft has at a given moment a large num= ber
=C2=A0 =C2=A0 on packets in flight. Suppose that all packets are lost. I =C2=A0 =C2=A0 understand the reaction of the sender in this case is that it= will
=C2=A0 =C2=A0 fire a Tail Loss Probe after the PTO expires i.e. 2RTT later.=

=C2=A0 =C2=A0 Suppose that the probe makes it and an ack for that probe is<= br> =C2=A0 =C2=A0 returned. Since the probe is a new packet or a retransmission= of
=C2=A0 =C2=A0 the latest packet, RACK at the sender is likely to mark all =C2=A0 =C2=A0 previous packets as lost and retransmit them. All this is don= e
=C2=A0 =C2=A0 while staying in congestion avoidance phase, afaiu.

=C2=A0 =C2=A0 This seems a significant departure from current congestion co= ntrol
=C2=A0 =C2=A0 mechanisms, i think. I mean, this is not the case of a spurio= us
=C2=A0 =C2=A0 isolated drop. All packets in flight were lost, which can be = a
=C2=A0 =C2=A0 pretty large number of packets. Staying in congestion avoidan= ce
=C2=A0 =C2=A0 after a single packet made it through seems more optimistic t= han
=C2=A0 =C2=A0 the current situation, i would say.

=C2=A0 =C2=A0 Am i missing something?

=C2=A0 =C2=A0 Regards, marcelo

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 tcpm mailing list
=C2=A0 =C2=A0 tcpm@ietf.= org <mailto:tcpm@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/t= cpm
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/tcpm>

--001a11c17dc65af130054939bc20-- From nobody Thu Feb 23 14:15:23 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C73129B8C for ; Thu, 23 Feb 2017 14:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 DWsRUeYQnvV6 for ; Thu, 23 Feb 2017 14:15:18 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE99129B86 for ; Thu, 23 Feb 2017 14:15:15 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id 203so1852336ith.0 for ; Thu, 23 Feb 2017 14:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HBI6fyFMysiQe4+3uol6dRFpmkoRG5P32Dy0wDmGw/U=; b=QiX7vUdJKJDXCflxdRKcCQlsdfemO0YSHoXaD6yK8I2TvbPwjToa1uTYUGziBe0mOb uNxiOswOl42IT/0FxLUAyDbeA/a6gLblvhJToC9DI1aU60bY+2dk/VAXJAVq8MjXsBj/ C+C2zGiEr284lV4kfAuWJSXtrQzZHwP6H43JFZRKu0XXE2tTZkrEsz67gx0li8mSeMbT HTeTxjt91ZC/m2nSS/5q3HkDHGc69+MA7dQDQDIhJQfFXIQYTUzTQRvh4NXZNz5a3R1t 1l1D1ILS0i2W78TC5PMCWsBGuKWfxUW1yDO4lHwmtAcbbmuD2gpcZ9FnPIapVIk1yL8f PZVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HBI6fyFMysiQe4+3uol6dRFpmkoRG5P32Dy0wDmGw/U=; b=pf/FuHgAxtRUh8LoopmikDUhQLMs61+Qcr6uKP8M4HBChVjJ/X3cxl7WI81LVF86iO sYWRtgMCK0MorfQViN7ctpDb96POnvPKCadft7zftzBAI1eAJ33KGDfbk56/UgyCKPx4 BqecPWlAoYMRFDz0KUk/N2xYTbV9gQ1tQCzRfy0epVPV0YfSB2fsKP40DlG4Q7W8I0ls 6jqONC6gGlU4GPx4CxmmxWClsofhDS8rOZSQ3EnrPblZYGjDS91M4y64tfM4BLxcGiav tTEJpkBiIQXxCakAlc+tkq1kDtkZqiaYdI4GUuIsSzZIqvh2lGIT0NqKmkunLm6P/W0D Ra5g== X-Gm-Message-State: AMke39kNHHbx2S7iN+xALPc6bdAUWWMG/+xCnxjMzn/+7wmgOwrputK3RBbb/9+lcZceaHhnUO8AXUOxKaeRmHx9 X-Received: by 10.107.172.7 with SMTP id v7mr34360743ioe.49.1487888114762; Thu, 23 Feb 2017 14:15:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Thu, 23 Feb 2017 14:14:34 -0800 (PST) In-Reply-To: References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es> From: Yuchung Cheng Date: Thu, 23 Feb 2017 14:14:34 -0800 Message-ID: To: Neal Cardwell Content-Type: multipart/alternative; boundary=94eb2c05a3808c487c054939f234 Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 23 Feb 2017 22:15:22 -0000 --94eb2c05a3808c487c054939f234 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell wrote= : > > > On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun > wrote: > >> Hi, >> >> Let me try to rephrase/expand. >> >> As I understand it, the response to congestion depends on the intensity >> of the congestion signal. >> If a few packets are lost, the CWND is reduced to half. This is why >> afaiu, the response to 3 (or more) duplicated ACKs is to reduce CWND by >> half (or some other number in cubic) >> >> However, if all the packets in flight are lost, there are no duplicated >> acks, and the loss is detected through the RTO. In this case, the >> congestion signal is more intense and the CWND is reduced to 1 MSS. >> >> In the example i included below, all the packets in flight are lost, but >> TLP+RACK manages to recover without using the RTO. >> So, i guess my question is: in this case, what happens to the CWND? is i= t >> reduced to half or is it set to 1 MSS? >> > A more direct answer is that CWND is reduced to half. We can put more details in the draft on the impact of C.C.. The original rationale behind halving cwnd post Fast Recovery is that ACK clock is still going so the congestion is not severe enough to warrant a complete cwnd reset (=3D1). So if TLP+RACK was able to recover the loss within 2-3 RTTs, = we should react similar to the 3 dupack thresh based recovery. HTH > At a high level, that is a decision for congestion control, and RACK is a > loss detection aglorithm, and tries to stay orthogonal to congestion > control. > > But on a practical level, a TCP sender ideally should be using the state > of the art recovery algorithm, PRR -- https://tools.ietf.org/html/rfc693= 7 > -- for fast recovery. If it does that then in the situation you sketch it > will slow-start up from a cwnd of 1, allowing 1 packet in flight, up to t= he > ssthresh set by the congestion control algorithm. This is basically the > response that the sender would have had to an RTO as well. So from a > practical standpoint it doesn't matter much that with RACK the sender > enters recovery instead of RTO - either way the sender should be > slow-starting up from a cwnd of 1 up to ssthresh. > > neal > > > > >> Regards, marcelo >> >> >> El 23/02/17 a las 21:29, Neal Cardwell escribi=C3=B3: >> >>> Hi, >>> >>> Thanks for the question. >>> >>> In the draft -- https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 -- >>> we try to address that in section 7.5: >>> >>> 7.5. Interaction with congestion control >>> >>> RACK intentionally decouples loss detection from congestion control. >>> RACK only detects losses; it does not modify the congestion control >>> algorithm [RFC5681][RFC6937]. >>> >>> Thus, in any scenario like the one you describe, where RACK (with or >>> without a TLP probe) marks one or more packets as lost, the sender shou= ld >>> use its normal congestion control response to packet loss. So if the se= nder >>> is using Reno or CUBIC, it should leave congestion avoidance and enter = fast >>> recovery, and cut cwnd and ssthresh as it would with any other loss >>> detection algorithm. >>> >>> Does that help clear up this question? >>> >>> If there is a particular section that was unclear on this point or >>> seemed to imply otherwise, please let us know so we can revise it. :-) >>> >>> Thanks! >>> neal >>> >>> >>> On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun < >>> marcelo@it.uc3m.es > wrote: >>> >>> Hi, >>> >>> After reading draft-ietf-tcpm-rack-01, I have a question about the >>> impact of the impact of the use of RACK and TLP in congestion >>> control. >>> >>> If this issue has been discussed earlier, I apologize and please >>> point me to the right thread in the archive. >>> >>> So, consider the following situation. A TCP sender using RACK and >>> TLP as defined in the draft has at a given moment a large number >>> on packets in flight. Suppose that all packets are lost. I >>> understand the reaction of the sender in this case is that it will >>> fire a Tail Loss Probe after the PTO expires i.e. 2RTT later. >>> >>> Suppose that the probe makes it and an ack for that probe is >>> returned. Since the probe is a new packet or a retransmission of >>> the latest packet, RACK at the sender is likely to mark all >>> previous packets as lost and retransmit them. All this is done >>> while staying in congestion avoidance phase, afaiu. >>> >>> This seems a significant departure from current congestion control >>> mechanisms, i think. I mean, this is not the case of a spurious >>> isolated drop. All packets in flight were lost, which can be a >>> pretty large number of packets. Staying in congestion avoidance >>> after a single packet made it through seems more optimistic than >>> the current situation, i would say. >>> >>> Am i missing something? >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >>> >> > --94eb2c05a3808c487c054939f234 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell <ncardwell@google.co= m> wrote:

=

On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun <marcelo@it.= uc3m.es> wrote:
Hi,

Let me try to rephrase/expand.

As I understand it, the response to congestion depends on the intensity of = the congestion signal.
If a few packets are lost, the CWND is reduced to half. This is why afaiu, = the response to 3 (or more) duplicated ACKs is to reduce CWND by half (or s= ome other number in cubic)

However, if all the packets in flight are lost, there are no duplicated ack= s, and the loss is detected through the RTO. In this case, the congestion s= ignal is more intense and the CWND is reduced to 1 MSS.

In the example i included below, all the packets in flight are lost, but TL= P+RACK manages to recover without using the RTO.
So, i guess my question is: in this case, what happens to the CWND? is it r= educed to half or is it set to 1 MSS?

A more direct answer is that CWND is reduced to half.=

We can put more details in the draft on the impac= t of C.C.. The original rationale behind halving cwnd post Fast Recovery is= that ACK clock is still going so the congestion is not severe enough to wa= rrant a complete cwnd reset (=3D1). So if TLP+RACK was able to recover the = loss within 2-3 RTTs, we should react similar to the 3 dupack thresh based = recovery. HTH

At a high level, that is a decision for co= ngestion control, and RACK is a loss detection aglorithm, and tries to stay= orthogonal to congestion control.

But on a practi= cal level, a TCP sender ideally should be using the state of the art recove= ry algorithm, PRR =C2=A0-- https://tools.ietf.org/html/rfc6937 -- for fast = recovery. If it does that then in the situation you sketch it will slow-sta= rt up from a cwnd of 1, allowing 1 packet in flight, up to the ssthresh set= by the congestion control algorithm. This is basically the response that t= he sender would have had to an RTO as well. So from a practical standpoint = it doesn't matter much that with RACK the sender enters recovery instea= d of RTO - either way the sender should be slow-starting up from a cwnd of = 1 up to ssthresh.
=
neal

=C2=A0
Regards, marcelo

El 23/02/17 a las 21:29, Neal Cardwell escribi=C3=B3:

Hi,

Thanks for the question.

In the draft -- https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 -- we try to address that in section 7.5:

7.5.=C2=A0 Interaction with congestion control

=C2=A0 =C2=A0RACK intentionally decouples loss detection from congestion co= ntrol.
=C2=A0 =C2=A0RACK only detects losses; it does not modify the congestion co= ntrol
=C2=A0 =C2=A0algorithm [RFC5681][RFC6937].

Thus, in any scenario like the one you describe, where RACK (with or withou= t a TLP probe) marks one or more packets as lost, the sender should use its= normal congestion control response to packet loss. So if the sender is usi= ng Reno or CUBIC, it should leave congestion avoidance and enter fast recov= ery, and cut cwnd and ssthresh as it would with any other loss detection al= gorithm.

Does that help clear up this question?

If there is a particular section that was unclear on this point or seemed t= o imply otherwise, please let us know so we can revise it. :-)

Thanks!
neal

On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun <marcelo@it.uc3m.es <mailto:<= a href=3D"mailto:marcelo@it.uc3m.es" target=3D"_blank">marcelo@it.uc3m.es>> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 After reading draft-ietf-tcpm-rack-01, I have a question abou= t the
=C2=A0 =C2=A0 impact of the impact of the use of RACK and TLP in congestion= control.

=C2=A0 =C2=A0 If this issue has been discussed earlier, I apologize and ple= ase
=C2=A0 =C2=A0 point me to the right thread in the archive.

=C2=A0 =C2=A0 So, consider the following situation. A TCP sender using RACK= and
=C2=A0 =C2=A0 TLP as defined in the draft has at a given moment a large num= ber
=C2=A0 =C2=A0 on packets in flight. Suppose that all packets are lost. I =C2=A0 =C2=A0 understand the reaction of the sender in this case is that it= will
=C2=A0 =C2=A0 fire a Tail Loss Probe after the PTO expires i.e. 2RTT later.=

=C2=A0 =C2=A0 Suppose that the probe makes it and an ack for that probe is<= br> =C2=A0 =C2=A0 returned. Since the probe is a new packet or a retransmission= of
=C2=A0 =C2=A0 the latest packet, RACK at the sender is likely to mark all =C2=A0 =C2=A0 previous packets as lost and retransmit them. All this is don= e
=C2=A0 =C2=A0 while staying in congestion avoidance phase, afaiu.

=C2=A0 =C2=A0 This seems a significant departure from current congestion co= ntrol
=C2=A0 =C2=A0 mechanisms, i think. I mean, this is not the case of a spurio= us
=C2=A0 =C2=A0 isolated drop. All packets in flight were lost, which can be = a
=C2=A0 =C2=A0 pretty large number of packets. Staying in congestion avoidan= ce
=C2=A0 =C2=A0 after a single packet made it through seems more optimistic t= han
=C2=A0 =C2=A0 the current situation, i would say.

=C2=A0 =C2=A0 Am i missing something?

=C2=A0 =C2=A0 Regards, marcelo

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 tcpm mailing list
=C2=A0 =C2=A0 tcpm@ietf.= org <mailto:tcpm@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/t= cpm
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/tcpm>

--94eb2c05a3808c487c054939f234-- From nobody Mon Feb 27 03:23:31 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5869129DBF for ; Mon, 27 Feb 2017 03:23:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 V4spGAFt2mU6 for ; Mon, 27 Feb 2017 03:23:26 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8980E129DBE for ; Mon, 27 Feb 2017 03:23:25 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id u48so230594wrc.0 for ; Mon, 27 Feb 2017 03:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=7E+vM9JTMGElzz/2rII6h+A2Wkbriwp/03UXQmg3XAE=; b=PlB0eZpi4IUUasVt04/oZ6Yxy8d4/FeJcMnUidLMn5kQ6tJqw68pSfmqk4DK28uAN5 Trl0RbSCpIsoGp8BJn2kJ4bPfai81dJujTxGCYZOC9VsYO0QJbPF7Ifcqoi5sYzeBGQb Ut+DZPSzmjDaf81w5+xdQQvn7f7PVDQvy2F8Mi0ufRWiE9PK2Ww8HuYIyCY3d7W89nXv bfNm7PjtlyXjhk0s7vYo+EwyDkBQB3ncc5fzm8pD3Lj+r69pPeXJ4zrKGqTEYEgHrgGH TyAEIKfRTpWlL2lY4a9ogkmu6l/g7u2+p0Olgqo+aSU2Ov/c/tR79wOOgfNfZXj9317D NJCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7E+vM9JTMGElzz/2rII6h+A2Wkbriwp/03UXQmg3XAE=; b=P0jHwS2iI2r0Cq8HpdIIZW0iS7qEb9UU/h1KSYCJRsAQRHq958Q/kH7wxxOhHisUwP cQkt8geFQBMTFyM+Ex496RKAI6elFxTfn5Jpbl3xMh6LkdLbPMJhjWAxYMHcVgchYB6p 9fHSAIvxnbVkEG2ZC29fJRseS9g4Afoykk16WiE6ri7EsaLpZYDpdBaXJBaTOqk5tQ6r /yTbONgdQOX5/RMYtMnCoe4vhOqfeEGr7/f1HGaDS4PpVeVBEJayn392rqIDGAAP/gDJ dzJQe5sJcyDxew4tuboFTXaT468utkz5cmeaEFTjO6tsVFFETpbfyqt9JxfDBdu7tg+/ byAw== X-Gm-Message-State: AMke39kaIkuKpXpepMe6BjGqPCLlYQCq2cUbIG3i3tzdhlYiDFFRcAk27FJVof0Hzz4oAcgZ X-Received: by 10.223.164.216 with SMTP id h24mr138918wrb.128.1488194603857; Mon, 27 Feb 2017 03:23:23 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:aca8:a71f:2043:f6ca]) by smtp.gmail.com with ESMTPSA id w17sm21937511wra.28.2017.02.27.03.23.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 03:23:23 -0800 (PST) To: Yuchung Cheng , Neal Cardwell References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es> From: marcelo bagnulo braun Message-ID: Date: Mon, 27 Feb 2017 12:23:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 11:23:31 -0000 Thanks for the replies, both from Neal and Yuchung, but i am (more) confused now. From Neal's reply, i understand that in the situation i described the cwnd fall to 1 MSS and from Yuchung's reply it seems it falls to half its value. What am i missing? El 23/02/17 a las 23:14, Yuchung Cheng escribió: > > > On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell > wrote: > > > > On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun > > wrote: > > Hi, > > Let me try to rephrase/expand. > > As I understand it, the response to congestion depends on the > intensity of the congestion signal. > If a few packets are lost, the CWND is reduced to half. This > is why afaiu, the response to 3 (or more) duplicated ACKs is > to reduce CWND by half (or some other number in cubic) > > However, if all the packets in flight are lost, there are no > duplicated acks, and the loss is detected through the RTO. In > this case, the congestion signal is more intense and the CWND > is reduced to 1 MSS. > > In the example i included below, all the packets in flight are > lost, but TLP+RACK manages to recover without using the RTO. > So, i guess my question is: in this case, what happens to the > CWND? is it reduced to half or is it set to 1 MSS? > > A more direct answer is that CWND is reduced to half. > > We can put more details in the draft on the impact of C.C.. The > original rationale behind halving cwnd post Fast Recovery is that ACK > clock is still going so the congestion is not severe enough to warrant > a complete cwnd reset (=1). So if TLP+RACK was able to recover the > loss within 2-3 RTTs, we should react similar to the 3 dupack thresh > based recovery. HTH > > > > At a high level, that is a decision for congestion control, and > RACK is a loss detection aglorithm, and tries to stay orthogonal > to congestion control. > > But on a practical level, a TCP sender ideally should be using the > state of the art recovery algorithm, PRR -- > https://tools.ietf.org/html/rfc6937 > -- for fast recovery. If it > does that then in the situation you sketch it will slow-start up > from a cwnd of 1, allowing 1 packet in flight, up to the ssthresh > set by the congestion control algorithm. This is basically the > response that the sender would have had to an RTO as well. So from > a practical standpoint it doesn't matter much that with RACK the > sender enters recovery instead of RTO - either way the sender > should be slow-starting up from a cwnd of 1 up to ssthresh. > > neal > > > Regards, marcelo > > > El 23/02/17 a las 21:29, Neal Cardwell escribió: > > Hi, > > Thanks for the question. > > In the draft -- > https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 > -- > we try to address that in section 7.5: > > 7.5. Interaction with congestion control > > RACK intentionally decouples loss detection from > congestion control. > RACK only detects losses; it does not modify the > congestion control > algorithm [RFC5681][RFC6937]. > > Thus, in any scenario like the one you describe, where > RACK (with or without a TLP probe) marks one or more > packets as lost, the sender should use its normal > congestion control response to packet loss. So if the > sender is using Reno or CUBIC, it should leave congestion > avoidance and enter fast recovery, and cut cwnd and > ssthresh as it would with any other loss detection algorithm. > > Does that help clear up this question? > > If there is a particular section that was unclear on this > point or seemed to imply otherwise, please let us know so > we can revise it. :-) > > Thanks! > neal > > > On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun > > >> > wrote: > > Hi, > > After reading draft-ietf-tcpm-rack-01, I have a > question about the > impact of the impact of the use of RACK and TLP in > congestion control. > > If this issue has been discussed earlier, I apologize > and please > point me to the right thread in the archive. > > So, consider the following situation. A TCP sender > using RACK and > TLP as defined in the draft has at a given moment a > large number > on packets in flight. Suppose that all packets are lost. I > understand the reaction of the sender in this case is > that it will > fire a Tail Loss Probe after the PTO expires i.e. 2RTT > later. > > Suppose that the probe makes it and an ack for that > probe is > returned. Since the probe is a new packet or a > retransmission of > the latest packet, RACK at the sender is likely to > mark all > previous packets as lost and retransmit them. All this > is done > while staying in congestion avoidance phase, afaiu. > > This seems a significant departure from current > congestion control > mechanisms, i think. I mean, this is not the case of a > spurious > isolated drop. All packets in flight were lost, which > can be a > pretty large number of packets. Staying in congestion > avoidance > after a single packet made it through seems more > optimistic than > the current situation, i would say. > > Am i missing something? > > Regards, marcelo > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > From nobody Mon Feb 27 04:58:16 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BD9129F4D for ; Mon, 27 Feb 2017 04:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 WgGLyyK0Bh9Q for ; Mon, 27 Feb 2017 04:58:13 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEF3129893 for ; Mon, 27 Feb 2017 04:58:11 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id 62so38092718oih.2 for ; Mon, 27 Feb 2017 04:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wrSGNNd/m/PophRgfdD43AMWOL1hmVUb+rrgRd7IUZg=; b=OFMsS90QSZM9Fsb4tIom5vltVNm6PWta0mLPvBwT2Cc18b5ymggRKmTl/HLcw/wNIg 7Uqi0go401Wf4paP8pQnSiMpyGsnNJBsLrI5MKD9v68lmrljaOZCDvsWyQ52zw7Jb77X 72z48g9ZXy71uVCn80anvcrUzUBhqPbU4VrvJqGJj0uGSrvtRm5USoO4JI0OyvojyUx1 H1wKmxuczLSQWZqJDgnpLGRPeIRbbmbR6uSohFisgJ+g6DEozMn23y+nfepEnAOJWYm2 Vgo0I3ARqpxcgI9WaGgl1k7nsID0Oyl70AHAMf9ct4vhmhFdxbWQI74L9s5DR8CTzaMX wiqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wrSGNNd/m/PophRgfdD43AMWOL1hmVUb+rrgRd7IUZg=; b=RirKZwUsQ6b8kUrlVgR+kQd8LsDnAPjq0VPyrqUYJMv8/vHKEjBJouqwHi0IoBIp3r uKwkH2CGJLpFFDzpQsoi91cGblgOavdamTRxHcQ8DyJLPjZTvL2lJ5PB9FZ9ByLD4oZu HUqABxROb31O5IfG0/HaKYOyeiuEJM3nxXs8Y4i5/qeMdV+D1dHxvCJpt2jyoykfFVJV 7hLDsbcKiHZa8VIRUvOZvLkEqTmt2m6Tz05ecKutlu3kIv95LnrMiW00PeLXqizZQ3Nm u0nue7kJBtXs2d46VoS7/wsedQpv751zExVyXiVDa/oqe6tOBsSnGHhdLxA0nmqFrzI3 +2/w== X-Gm-Message-State: AMke39mzLdOXbdMe5Zn3DEmh7dINBoAn9LYaNnOcIG5IrXGI7YXMT0WyrN0CP19qP5t6Hk7+jraEPNYauoKKpv/6 X-Received: by 10.202.182.11 with SMTP id g11mr8935165oif.110.1488200290517; Mon, 27 Feb 2017 04:58:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.71.216 with HTTP; Mon, 27 Feb 2017 04:57:40 -0800 (PST) In-Reply-To: References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es>

From: Neal Cardwell Date: Mon, 27 Feb 2017 07:57:40 -0500 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a113caa44ac0f0f054982a118 Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 12:58:15 -0000 --001a113caa44ac0f0f054982a118 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2017 at 6:23 AM, marcelo bagnulo braun wrote: > Thanks for the replies, both from Neal and Yuchung, but i am (more) > confused now. > > From Neal's reply, i understand that in the situation i described the cwn= d > fall to 1 MSS and from Yuchung's reply it seems it falls to half its valu= e. > What am i missing? > In the situation you sketch, both are true, but at different time scales. :-) Short-term: upon the first ACK, which causes the sender to enter fast recovery, the sender will set the cwnd to 1. Long-term: over the course of fast recovery, the sender will gradually increase (slow-start) the cwnd upward; at the end of recovery cwnd will equal the ssthresh set by the congestion control algorithm, which will be half of the cwnd before entering recovery. (This is all assuming the sender is using PRR and IETF standard congestion control, aka Reno.) Hope that clarifies things a bit, neal > El 23/02/17 a las 23:14, Yuchung Cheng escribi=C3=B3: > >> >> >> On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell > > wrote: >> >> >> >> On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun >> > wrote: >> >> Hi, >> >> Let me try to rephrase/expand. >> >> As I understand it, the response to congestion depends on the >> intensity of the congestion signal. >> If a few packets are lost, the CWND is reduced to half. This >> is why afaiu, the response to 3 (or more) duplicated ACKs is >> to reduce CWND by half (or some other number in cubic) >> >> However, if all the packets in flight are lost, there are no >> duplicated acks, and the loss is detected through the RTO. In >> this case, the congestion signal is more intense and the CWND >> is reduced to 1 MSS. >> >> In the example i included below, all the packets in flight are >> lost, but TLP+RACK manages to recover without using the RTO. >> So, i guess my question is: in this case, what happens to the >> CWND? is it reduced to half or is it set to 1 MSS? >> >> A more direct answer is that CWND is reduced to half. >> >> We can put more details in the draft on the impact of C.C.. The original >> rationale behind halving cwnd post Fast Recovery is that ACK clock is st= ill >> going so the congestion is not severe enough to warrant a complete cwnd >> reset (=3D1). So if TLP+RACK was able to recover the loss within 2-3 RTT= s, we >> should react similar to the 3 dupack thresh based recovery. HTH >> >> >> >> At a high level, that is a decision for congestion control, and >> RACK is a loss detection aglorithm, and tries to stay orthogonal >> to congestion control. >> >> But on a practical level, a TCP sender ideally should be using the >> state of the art recovery algorithm, PRR -- >> https://tools.ietf.org/html/rfc6937 >> -- for fast recovery. If it >> does that then in the situation you sketch it will slow-start up >> from a cwnd of 1, allowing 1 packet in flight, up to the ssthresh >> set by the congestion control algorithm. This is basically the >> response that the sender would have had to an RTO as well. So from >> a practical standpoint it doesn't matter much that with RACK the >> sender enters recovery instead of RTO - either way the sender >> should be slow-starting up from a cwnd of 1 up to ssthresh. >> >> neal >> >> >> Regards, marcelo >> >> >> El 23/02/17 a las 21:29, Neal Cardwell escribi=C3=B3: >> >> Hi, >> >> Thanks for the question. >> >> In the draft -- >> https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 >> -- >> we try to address that in section 7.5: >> >> 7.5. Interaction with congestion control >> >> RACK intentionally decouples loss detection from >> congestion control. >> RACK only detects losses; it does not modify the >> congestion control >> algorithm [RFC5681][RFC6937]. >> >> Thus, in any scenario like the one you describe, where >> RACK (with or without a TLP probe) marks one or more >> packets as lost, the sender should use its normal >> congestion control response to packet loss. So if the >> sender is using Reno or CUBIC, it should leave congestion >> avoidance and enter fast recovery, and cut cwnd and >> ssthresh as it would with any other loss detection algorithm= . >> >> Does that help clear up this question? >> >> If there is a particular section that was unclear on this >> point or seemed to imply otherwise, please let us know so >> we can revise it. :-) >> >> Thanks! >> neal >> >> >> On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun >> >> >> >> >> wrote: >> >> Hi, >> >> After reading draft-ietf-tcpm-rack-01, I have a >> question about the >> impact of the impact of the use of RACK and TLP in >> congestion control. >> >> If this issue has been discussed earlier, I apologize >> and please >> point me to the right thread in the archive. >> >> So, consider the following situation. A TCP sender >> using RACK and >> TLP as defined in the draft has at a given moment a >> large number >> on packets in flight. Suppose that all packets are lost.= I >> understand the reaction of the sender in this case is >> that it will >> fire a Tail Loss Probe after the PTO expires i.e. 2RTT >> later. >> >> Suppose that the probe makes it and an ack for that >> probe is >> returned. Since the probe is a new packet or a >> retransmission of >> the latest packet, RACK at the sender is likely to >> mark all >> previous packets as lost and retransmit them. All this >> is done >> while staying in congestion avoidance phase, afaiu. >> >> This seems a significant departure from current >> congestion control >> mechanisms, i think. I mean, this is not the case of a >> spurious >> isolated drop. All packets in flight were lost, which >> can be a >> pretty large number of packets. Staying in congestion >> avoidance >> after a single packet made it through seems more >> optimistic than >> the current situation, i would say. >> >> Am i missing something? >> >> Regards, marcelo >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tcpm >> >> > > >> >> >> >> >> >> > --001a113caa44ac0f0f054982a118 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On M= on, Feb 27, 2017 at 6:23 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

Th= anks for the replies, both from Neal and Yuchung, but i am (more) confused = now.

>From Neal's reply, i understand that in the situation i described the c= wnd fall to 1 MSS and from Yuchung's reply it seems it falls to half it= s value. What am i missing?

In the situation you sketch,=C2=A0both are true, but at different time scales. :-= )

Short-term: upo= n the first ACK, which causes the sender to enter fast recovery, the sender= will set the cwnd to 1.

Long-term: over the = course of fast recovery, the sender will gradually increase (slow-start) th= e cwnd upward; at the end of recovery cwnd will equal the ssthresh set by t= he congestion control algorithm, which will be half of the cwnd before ente= ring recovery.

(This is all assuming the sender is using PRR and=C2=A0IETF standard congestion control, aka Reno.)

= Hope that clarifies things a bit,

neal

<= div>=C2=A0

El 23/02/17 a las 23:14, Yuchung Cheng escribi=C3=B3:

On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell <ncardwell@google.com <mailto:ncardwell@google.com>> wrote:

=C2=A0 =C2=A0 On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun
=C2=A0 =C2=A0 <m= arcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Let me try to rephrase/expand.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As I understand it, the response to congestion = depends on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 intensity of the congestion signal.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a few packets are lost, the CWND is reduced = to half. This
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is why afaiu, the response to 3 (or more) dupli= cated ACKs is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to reduce CWND by half (or some other number in= cubic)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, if all the packets in flight are lost,= there are no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 duplicated acks, and the loss is detected throu= gh the RTO. In
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this case, the congestion signal is more intens= e and the CWND
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is reduced to 1 MSS.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In the example i included below, all the packet= s in flight are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lost, but TLP+RACK manages to recover without u= sing the RTO.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, i guess my question is: in this case, what = happens to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CWND? is it reduced to half or is it set to 1 M= SS?

A more direct answer is that CWND is reduced to half.

We can put more details in the draft on the impact of C.C.. The original ra= tionale behind halving cwnd post Fast Recovery is that ACK clock is still g= oing so the congestion is not severe enough to warrant a complete cwnd rese= t (=3D1). So if TLP+RACK was able to recover the loss within 2-3 RTTs, we s= hould react similar to the 3 dupack thresh based recovery. HTH

=C2=A0 =C2=A0 At a high level, that is a decision for congestion control, a= nd
=C2=A0 =C2=A0 RACK is a loss detection aglorithm, and tries to stay orthogo= nal
=C2=A0 =C2=A0 to congestion control.

=C2=A0 =C2=A0 But on a practical level, a TCP sender ideally should be usin= g the
=C2=A0 =C2=A0 state of the art recovery algorithm, PRR=C2=A0 --
=C2=A0 =C2=A0 https://tools.ietf.org/html/rfc6937
=C2=A0 =C2=A0 <https://tools.ietf.org/html/rfc6937>= ; -- for fast recovery. If it
=C2=A0 =C2=A0 does that then in the situation you sketch it will slow-start= up
=C2=A0 =C2=A0 from a cwnd of 1, allowing 1 packet in flight, up to the ssth= resh
=C2=A0 =C2=A0 set by the congestion control algorithm. This is basically th= e
=C2=A0 =C2=A0 response that the sender would have had to an RTO as well. So= from
=C2=A0 =C2=A0 a practical standpoint it doesn't matter much that with R= ACK the
=C2=A0 =C2=A0 sender enters recovery instead of RTO - either way the sender=
=C2=A0 =C2=A0 should be slow-starting up from a cwnd of 1 up to ssthresh.
=C2=A0 =C2=A0 neal

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, marcelo

=C2=A0 =C2=A0 =C2=A0 =C2=A0 El 23/02/17 a las 21:29, Neal Cardwell escribi= =C3=B3:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks for the question.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the draft --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /tools.ietf.org/html/draft-ietf-tcpm-rack-01
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://tools.ietf.org/html/draft-ietf-tcpm-rack-01> --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we try to address that in section= 7.5:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7.5.=C2=A0 Interaction with conge= stion control

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RACK intentionally d= ecouples loss detection from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RACK only detects lo= sses; it does not modify the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm [RFC5681][= RFC6937].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thus, in any scenario like the on= e you describe, where
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RACK (with or without a TLP probe= ) marks one or more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 packets as lost, the sender shoul= d use its normal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control response to pa= cket loss. So if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sender is using Reno or CUBIC, it= should leave congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 avoidance and enter fast recovery= , and cut cwnd and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ssthresh as it would with any oth= er loss detection algorithm.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Does that help clear up this ques= tion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If there is a particular section = that was unclear on this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point or seemed to imply otherwis= e, please let us know so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we can revise it. :-)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 neal

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Feb 23, 2017 at 2:30 AM, = marcelo bagnulo braun
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>= >>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 After reading draft= -ietf-tcpm-rack-01, I have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 question about the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 impact of the impac= t of the use of RACK and TLP in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If this issue has b= een discussed earlier, I apologize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and please
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point me to the rig= ht thread in the archive.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, consider the fo= llowing situation. A TCP sender
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 using RACK and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLP as defined in t= he draft has at a given moment a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 large number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on packets in fligh= t. Suppose that all packets are lost. I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 understand the reac= tion of the sender in this case is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that it will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fire a Tail Loss Pr= obe after the PTO expires i.e. 2RTT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 later.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Suppose that the pr= obe makes it and an ack for that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 probe is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 returned. Since the= probe is a new packet or a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retransmission of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the latest packet, = RACK at the sender is likely to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mark all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 previous packets as= lost and retransmit them. All this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while staying in co= ngestion avoidance phase, afaiu.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This seems a signif= icant departure from current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms, i think= . I mean, this is not the case of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spurious
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 isolated drop. All = packets in flight were lost, which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 can be a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pretty large number= of packets. Staying in congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 avoidance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 after a single pack= et made it through seems more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 optimistic than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the current situati= on, i would say.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Am i missing someth= ing?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, marcelo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm@ietf.org <mailto:tcpm@ietf.org> <mailto:tcpm@ietf.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tcpm@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mailman/listinfo/tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.= ietf.org/mailman/listinfo/tcpm>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.= ietf.org/mailman/listinfo/tcpm>>

--001a113caa44ac0f0f054982a118-- From nobody Mon Feb 27 08:52:58 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057B912997D for ; Mon, 27 Feb 2017 08:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 UvOX_dozyRFU for ; Mon, 27 Feb 2017 08:52:54 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96515129976 for ; Mon, 27 Feb 2017 08:52:54 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 72so41116593uaf.3 for ; Mon, 27 Feb 2017 08:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RK3MT9SafY+FU3xNdTQ61CSyB4yIuTw8NR67x7N3RSg=; b=edBEH3vtyHKiWyq2D55R6vASmiZr7ye9alo1HF6jiidfZT4XfyL2Gd8Ec448FjIgps RvjGOQ5Dg636aG10SuKdFbcUnu3LC4oGQUL2gl5/5VsWoSXC5iPe0dChVHTyUgs46YLO +1wt++YtXc5MSTrkyZkNubJcdVID350ro4YF7g3fdRnqOKp9DMIjdEH49igumjuNj6gs /EA8q7SYtY0I0mzqU6i7PF/Mvy5gYRak/JrNbK0UvSnayX2jP5oefSVBIuKsw29roA8U 5D8mhVOgn6AqLr9RbDdEp6FuOC7uR64kOs+fQOzK7xPgmGnk8Y5T0oxkFy0PClC7G+0Z KlXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RK3MT9SafY+FU3xNdTQ61CSyB4yIuTw8NR67x7N3RSg=; b=JSbjfKKjAp6Yp8oe6OOqNMTxlXVntEnjnJOfV9rCdWUYvNwS+WSgmSRHkZPrHC2Q9Q VQcE4CvGKhI6+54CvAEQrA9vwq0+44f22QSNdMjvPGz5kepB328H46gvkPMgSqoE50/r CWPIvMgffau0LIKMrxdX8IMbKbDth9bIL9rM90ocZAmEZrdizhNvvowZdGodIk9swaWZ 5GcLLiwkuofWAZp+l1XY5gCiO0PNUVhsPqpFFhY69ERrfm7LJIAGBlevIkptXw8WsQMp /0Y+1tQYCXMk1mwCLK9WT0LKhv+BGWNad3xdSdDiewv4yvX/xE6F+NJW70Mm2+4lbCxH ej1g== X-Gm-Message-State: AMke39kK+Pn8lwExtzU98nGQIyFlgfzZ2OVelhpenzNZ9/bAlw/QlU2qgoecl+F0bapQB18UJpfoNmK+cJhoeEts X-Received: by 10.159.48.22 with SMTP id h22mr6663902uab.13.1488214373206; Mon, 27 Feb 2017 08:52:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Mon, 27 Feb 2017 08:52:52 -0800 (PST) In-Reply-To: References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es>

From: Jana Iyengar Date: Mon, 27 Feb 2017 08:52:52 -0800 Message-ID: To: Neal Cardwell Content-Type: multipart/alternative; boundary=f403045e3664114dfe054985e931 Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 16:52:57 -0000 --f403045e3664114dfe054985e931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable An additional bit of info that might help: in PRR ( https://tools.ietf.org/html/rfc6937), sndcnt is used to gate how much a sender can send in response to an ack (see computation of "limit" in the algorithm.) On Mon, Feb 27, 2017 at 4:57 AM, Neal Cardwell wrote= : > On Mon, Feb 27, 2017 at 6:23 AM, marcelo bagnulo braun > wrote: > >> Thanks for the replies, both from Neal and Yuchung, but i am (more) >> confused now. >> >> >From Neal's reply, i understand that in the situation i described the >> cwnd fall to 1 MSS and from Yuchung's reply it seems it falls to half it= s >> value. What am i missing? >> > > In the situation you sketch, both are true, but at different time scales. > :-) > > Short-term: upon the first ACK, which causes the sender to enter fast > recovery, the sender will set the cwnd to 1. > > Long-term: over the course of fast recovery, the sender will gradually > increase (slow-start) the cwnd upward; at the end of recovery cwnd will > equal the ssthresh set by the congestion control algorithm, which will be > half of the cwnd before entering recovery. > > (This is all assuming the sender is using PRR and IETF standard > congestion control, aka Reno.) > > Hope that clarifies things a bit, > neal > > > >> El 23/02/17 a las 23:14, Yuchung Cheng escribi=C3=B3: >> >>> >>> >>> On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell >> > wrote: >>> >>> >>> >>> On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun >>> > wrote: >>> >>> Hi, >>> >>> Let me try to rephrase/expand. >>> >>> As I understand it, the response to congestion depends on the >>> intensity of the congestion signal. >>> If a few packets are lost, the CWND is reduced to half. This >>> is why afaiu, the response to 3 (or more) duplicated ACKs is >>> to reduce CWND by half (or some other number in cubic) >>> >>> However, if all the packets in flight are lost, there are no >>> duplicated acks, and the loss is detected through the RTO. In >>> this case, the congestion signal is more intense and the CWND >>> is reduced to 1 MSS. >>> >>> In the example i included below, all the packets in flight are >>> lost, but TLP+RACK manages to recover without using the RTO. >>> So, i guess my question is: in this case, what happens to the >>> CWND? is it reduced to half or is it set to 1 MSS? >>> >>> A more direct answer is that CWND is reduced to half. >>> >>> We can put more details in the draft on the impact of C.C.. The origina= l >>> rationale behind halving cwnd post Fast Recovery is that ACK clock is s= till >>> going so the congestion is not severe enough to warrant a complete cwnd >>> reset (=3D1). So if TLP+RACK was able to recover the loss within 2-3 RT= Ts, we >>> should react similar to the 3 dupack thresh based recovery. HTH >>> >>> >>> >>> At a high level, that is a decision for congestion control, and >>> RACK is a loss detection aglorithm, and tries to stay orthogonal >>> to congestion control. >>> >>> But on a practical level, a TCP sender ideally should be using the >>> state of the art recovery algorithm, PRR -- >>> https://tools.ietf.org/html/rfc6937 >>> -- for fast recovery. If it >>> does that then in the situation you sketch it will slow-start up >>> from a cwnd of 1, allowing 1 packet in flight, up to the ssthresh >>> set by the congestion control algorithm. This is basically the >>> response that the sender would have had to an RTO as well. So from >>> a practical standpoint it doesn't matter much that with RACK the >>> sender enters recovery instead of RTO - either way the sender >>> should be slow-starting up from a cwnd of 1 up to ssthresh. >>> >>> neal >>> >>> >>> Regards, marcelo >>> >>> >>> El 23/02/17 a las 21:29, Neal Cardwell escribi=C3=B3: >>> >>> Hi, >>> >>> Thanks for the question. >>> >>> In the draft -- >>> https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 >>> -- >>> we try to address that in section 7.5: >>> >>> 7.5. Interaction with congestion control >>> >>> RACK intentionally decouples loss detection from >>> congestion control. >>> RACK only detects losses; it does not modify the >>> congestion control >>> algorithm [RFC5681][RFC6937]. >>> >>> Thus, in any scenario like the one you describe, where >>> RACK (with or without a TLP probe) marks one or more >>> packets as lost, the sender should use its normal >>> congestion control response to packet loss. So if the >>> sender is using Reno or CUBIC, it should leave congestion >>> avoidance and enter fast recovery, and cut cwnd and >>> ssthresh as it would with any other loss detection algorith= m. >>> >>> Does that help clear up this question? >>> >>> If there is a particular section that was unclear on this >>> point or seemed to imply otherwise, please let us know so >>> we can revise it. :-) >>> >>> Thanks! >>> neal >>> >>> >>> On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun >>> >>> >> >>> >>> wrote: >>> >>> Hi, >>> >>> After reading draft-ietf-tcpm-rack-01, I have a >>> question about the >>> impact of the impact of the use of RACK and TLP in >>> congestion control. >>> >>> If this issue has been discussed earlier, I apologize >>> and please >>> point me to the right thread in the archive. >>> >>> So, consider the following situation. A TCP sender >>> using RACK and >>> TLP as defined in the draft has at a given moment a >>> large number >>> on packets in flight. Suppose that all packets are lost= . >>> I >>> understand the reaction of the sender in this case is >>> that it will >>> fire a Tail Loss Probe after the PTO expires i.e. 2RTT >>> later. >>> >>> Suppose that the probe makes it and an ack for that >>> probe is >>> returned. Since the probe is a new packet or a >>> retransmission of >>> the latest packet, RACK at the sender is likely to >>> mark all >>> previous packets as lost and retransmit them. All this >>> is done >>> while staying in congestion avoidance phase, afaiu. >>> >>> This seems a significant departure from current >>> congestion control >>> mechanisms, i think. I mean, this is not the case of a >>> spurious >>> isolated drop. All packets in flight were lost, which >>> can be a >>> pretty large number of packets. Staying in congestion >>> avoidance >>> after a single packet made it through seems more >>> optimistic than >>> the current situation, i would say. >>> >>> Am i missing something? >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >> > >>> >>> >>> >>> >>> >>> >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --f403045e3664114dfe054985e931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

An additional bit of info that might help: in PRR (https://tools.ietf.org/html/rfc693= 7), sndcnt is used to gate how much a sender can send in response to an= ack (see computation of "limit" in the algorithm.)

On Mon, Feb 27, 2017 at 4= :57 AM, Neal Cardwell <ncardwell@google.com> wrote:

On Mon, Feb 27, 2017 at 6:23 AM, = marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
Thanks for the replies, both fr= om Neal and Yuchung, but i am (more) confused now.

>From Neal's reply, i understand that in the situation i described t= he cwnd fall to 1 MSS and from Yuchung's reply it seems it falls to hal= f its value. What am i missing?

= In the situation you sketch,=C2=A0both are true, but at different time= scales. :-)

Shor= t-term: upon the first ACK, which causes the sender to enter fast recovery,= the sender will set the cwnd to 1.

Long-term= : over the course of fast recovery, the sender will gradually increase (slo= w-start) the cwnd upward; at the end of recovery cwnd will equal the ssthre= sh set by the congestion control algorithm, which will be half of the cwnd = before entering recovery.

(This is all assuming the sender is using PRR an= d=C2=A0IETF standard congestion control, a= ka Reno.)

Hope that clarifies things a bi= t,

neal

=C2=A0

El 23/02/17 a las 23:14, Yuchung Cheng escribi=C3=B3:

On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell <ncardwell@google.com <mailto:ncardwell@google.com>> wrote:

=C2=A0 =C2=A0 On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun
=C2=A0 =C2=A0 <m= arcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Let me try to rephrase/expand.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As I understand it, the response to congestion = depends on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 intensity of the congestion signal.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a few packets are lost, the CWND is reduced = to half. This
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is why afaiu, the response to 3 (or more) dupli= cated ACKs is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to reduce CWND by half (or some other number in= cubic)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, if all the packets in flight are lost,= there are no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 duplicated acks, and the loss is detected throu= gh the RTO. In
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this case, the congestion signal is more intens= e and the CWND
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is reduced to 1 MSS.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In the example i included below, all the packet= s in flight are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lost, but TLP+RACK manages to recover without u= sing the RTO.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, i guess my question is: in this case, what = happens to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CWND? is it reduced to half or is it set to 1 M= SS?

A more direct answer is that CWND is reduced to half.

We can put more details in the draft on the impact of C.C.. The original ra= tionale behind halving cwnd post Fast Recovery is that ACK clock is still g= oing so the congestion is not severe enough to warrant a complete cwnd rese= t (=3D1). So if TLP+RACK was able to recover the loss within 2-3 RTTs, we s= hould react similar to the 3 dupack thresh based recovery. HTH

=C2=A0 =C2=A0 At a high level, that is a decision for congestion control, a= nd
=C2=A0 =C2=A0 RACK is a loss detection aglorithm, and tries to stay orthogo= nal
=C2=A0 =C2=A0 to congestion control.

=C2=A0 =C2=A0 But on a practical level, a TCP sender ideally should be usin= g the
=C2=A0 =C2=A0 state of the art recovery algorithm, PRR=C2=A0 --
=C2=A0 =C2=A0 https://tools.ietf.org/html/rfc6937
=C2=A0 =C2=A0 <https://tools.ietf.org/html/rfc6937>= ; -- for fast recovery. If it
=C2=A0 =C2=A0 does that then in the situation you sketch it will slow-start= up
=C2=A0 =C2=A0 from a cwnd of 1, allowing 1 packet in flight, up to the ssth= resh
=C2=A0 =C2=A0 set by the congestion control algorithm. This is basically th= e
=C2=A0 =C2=A0 response that the sender would have had to an RTO as well. So= from
=C2=A0 =C2=A0 a practical standpoint it doesn't matter much that with R= ACK the
=C2=A0 =C2=A0 sender enters recovery instead of RTO - either way the sender=
=C2=A0 =C2=A0 should be slow-starting up from a cwnd of 1 up to ssthresh.
=C2=A0 =C2=A0 neal

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, marcelo

=C2=A0 =C2=A0 =C2=A0 =C2=A0 El 23/02/17 a las 21:29, Neal Cardwell escribi= =C3=B3:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks for the question.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the draft --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /tools.ietf.org/html/draft-ietf-tcpm-rack-01
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://tools.ietf.org/html/draft-ietf-tcpm-rack-01> --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we try to address that in section= 7.5:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7.5.=C2=A0 Interaction with conge= stion control

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RACK intentionally d= ecouples loss detection from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RACK only detects lo= sses; it does not modify the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm [RFC5681][= RFC6937].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thus, in any scenario like the on= e you describe, where
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RACK (with or without a TLP probe= ) marks one or more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 packets as lost, the sender shoul= d use its normal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control response to pa= cket loss. So if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sender is using Reno or CUBIC, it= should leave congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 avoidance and enter fast recovery= , and cut cwnd and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ssthresh as it would with any oth= er loss detection algorithm.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Does that help clear up this ques= tion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If there is a particular section = that was unclear on this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point or seemed to imply otherwis= e, please let us know so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we can revise it. :-)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 neal

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Feb 23, 2017 at 2:30 AM, = marcelo bagnulo braun
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>= >>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 After reading draft= -ietf-tcpm-rack-01, I have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 question about the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 impact of the impac= t of the use of RACK and TLP in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If this issue has b= een discussed earlier, I apologize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and please
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point me to the rig= ht thread in the archive.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, consider the fo= llowing situation. A TCP sender
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 using RACK and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLP as defined in t= he draft has at a given moment a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 large number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on packets in fligh= t. Suppose that all packets are lost. I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 understand the reac= tion of the sender in this case is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that it will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fire a Tail Loss Pr= obe after the PTO expires i.e. 2RTT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 later.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Suppose that the pr= obe makes it and an ack for that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 probe is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 returned. Since the= probe is a new packet or a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retransmission of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the latest packet, = RACK at the sender is likely to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mark all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 previous packets as= lost and retransmit them. All this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while staying in co= ngestion avoidance phase, afaiu.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This seems a signif= icant departure from current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms, i think= . I mean, this is not the case of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spurious
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 isolated drop. All = packets in flight were lost, which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 can be a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pretty large number= of packets. Staying in congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 avoidance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 after a single pack= et made it through seems more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 optimistic than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the current situati= on, i would say.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Am i missing someth= ing?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, marcelo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm@ietf.org <mailto:tcpm@ietf.org> <mailto:tcpm@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tcpm@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mailman/listinfo/tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.= ietf.org/mailman/listinfo/tcpm>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.= ietf.org/mailman/listinfo/tcpm>>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--f403045e3664114dfe054985e931-- From nobody Mon Feb 27 09:38:19 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D0D129994; Mon, 27 Feb 2017 09:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 ALYEAatVaaRz; Mon, 27 Feb 2017 09:38:16 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30097.outbound.protection.outlook.com [40.107.3.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785D01298AA; Mon, 27 Feb 2017 09:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R1UWpc/XWiydRRNMNTrDpL/iW1siqoQtTPQP0VrZaNQ=; b=R2YocNqYqBWD45msiG5gTElmaZqur4/RLCFK/+rD4E294yBhCE1dsUK1+xNHY2qoidkYPaToBPQ3YtyU5kU40f88qiGn4ccsGhA9tHd03v/73diTvGS5gxUqtcVWmbsua+wDyxeQHZhAxOvkwlUrxQSWWng2jB5lbYBnnst3ius= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Mon, 27 Feb 2017 17:38:14 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.0947.010; Mon, 27 Feb 2017 17:38:14 +0000 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org" Thread-Topic: Agenda requests for IETF 98 Thread-Index: AdKRIDfgISnmKYyVTa20McjceVEv2g== Date: Mon, 27 Feb 2017 17:38:14 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [135.245.240.250] x-ms-office365-filtering-correlation-id: 47ae5e5b-6ae7-479d-6c40-08d45f376847 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM5PR0701MB2547; x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 7:4Br+8Jog6BnDEjCk+Q9V+W6mbhEaLQHDqJNOuuxlhEOQIZQmffa/ksas0rEoe2NlY1SWymmFnlzgTlBHEqTXqYpv5FD4Aaxew1DUNojjM6N3G9iAq+MRt3hgqEimpdGtbPv52Wdw90fGQG3JycDcY1/HuihYQj4PvCrigEH18K8WbTVQ4Hi4+2NQO6fgK38iEcimQRegVexCyyz0l2xTiyAsfIBdJ/CcJbSHm2nI3X8Eik5NINJ9olvoXnvnpMKnfuCBGTYFAXuAf9S1gCGzn8BGrj28FSxaDrwPEoRRkBXSVAdToZ7PiTjI7Q6SFv2C03XRArMVrQ0GWjgGJJHUOg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2547; x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(189002)(53754006)(199003)(110136004)(81156014)(81166006)(38730400002)(66066001)(3660700001)(6436002)(8676002)(3280700002)(68736007)(1730700003)(9686003)(8936002)(86362001)(53936002)(5660300001)(3846002)(102836003)(6116002)(6506006)(2501003)(92566002)(106356001)(77096006)(2900100001)(99286003)(7696004)(33656002)(105586002)(122556002)(558084003)(74316002)(50986999)(2351001)(5640700003)(55016002)(54356999)(7736002)(4326007)(305945005)(2906002)(6916009)(189998001)(25786008)(450100001)(97736004)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2017 17:38:14.2052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Cc: "tcpm-chairs@ietf.org" Subject: [tcpm] Agenda requests for IETF 98 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 17:38:18 -0000 Hi all, For the Chicago meeting, tentatively (!) TCPM got the 2.5h slot on Wednesda= y morning. If you want to present something in the TCPM meeting, please let the chairs= know until Sunday March 12: * Draft name / title * Presenter * Total time (including Q&A) Thanks! Michael From nobody Mon Feb 27 10:06:12 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6C12A2A6 for ; Mon, 27 Feb 2017 10:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 1ni9I9T9BeSg for ; Mon, 27 Feb 2017 10:05:57 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F4612A299 for ; Mon, 27 Feb 2017 10:05:46 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id y135so73324096itc.1 for ; Mon, 27 Feb 2017 10:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fO3oMjn8Sr1p1bN4WiMBKN7F4800PKyugecMmMFlx5w=; b=F16MHZM1JwnP6l7IwZ98nCmjGFT3jGX2WhpifOnrzGiCN6Xye5NefOYJOnUWuEI7fd RfJQTyAVCzgkwU+vaC0MKQudYW1bzo5c+r47JRx9ucwYkG7Aj7x4ik1KB13ZduoABeHH U6Gfy9R4HBwpPjKw8dUvjkfE+UxJxtQc96xdecTeT4bEydMqupAdmZDnXfjiOtSn+ZB+ YISltitmNf9w0040l0lSAy1nB/s2LPO1733tgajK0U2w6/aITvzL0rd7VvGQ5j0MkqhE xdC4v8GILYHwWykKLqY6U4ISsWhEeODQPcOJRcukYyINe0ulu6Ph5Y1FsDIA5g8sO2lV 6c4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fO3oMjn8Sr1p1bN4WiMBKN7F4800PKyugecMmMFlx5w=; b=iLoKphvnYIqEiDmzOz1yRziJviyOhEurPT8kpI8sCEuSgPiXpgzJbkY5kPC9Or20O2 S9EAAt23IjVVn3gBqNyShLG5tTzIKWbiSYwr+AgyvROv5n4nkNxCLqGBFLIPw1OLeo03 UMWY0Oa+c7kayzvmaLqARyzwQJRaE7nmb74nB4yUdpOLuVzeDRpJ21KKyjYHR7dlG+ww RjT1y+y13WTSgPanplvgh4mMqlcZni5ldM54usDZkJ+aSMLESTd/jkFevjG1n792gcNd RZv/TBa4xD3l9TRe/w5gpC1bRNDhVFI5Hs0cOmEP7lIWOdsFLqLfFnBoVHyHkYbXzmgT eX4Q== X-Gm-Message-State: AMke39kG+DReRBPUD3Fp3qT0ilhzVNP5cdxNv3g0VXG8BMK/PQGh50B8q3EpEo1Dja9VPfLntqaK+vBh9hRgc27o X-Received: by 10.36.67.210 with SMTP id s201mr15905835itb.28.1488218745830; Mon, 27 Feb 2017 10:05:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Mon, 27 Feb 2017 10:05:05 -0800 (PST) In-Reply-To: References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es>

From: Yuchung Cheng Date: Mon, 27 Feb 2017 10:05:05 -0800 Message-ID: To: Neal Cardwell Content-Type: multipart/alternative; boundary=001a113fac78b1e7dd054986edab Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 18:06:02 -0000 --001a113fac78b1e7dd054986edab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2017 at 4:57 AM, Neal Cardwell wrote= : > On Mon, Feb 27, 2017 at 6:23 AM, marcelo bagnulo braun > wrote: > >> Thanks for the replies, both from Neal and Yuchung, but i am (more) >> confused now. >> >> From Neal's reply, i understand that in the situation i described the >> cwnd fall to 1 MSS and from Yuchung's reply it seems it falls to half it= s >> value. What am i missing? >> > > In the situation you sketch, both are true, but at different time scales. > :-) > > Short-term: upon the first ACK, which causes the sender to enter fast > recovery, the sender will set the cwnd to 1. > > Long-term: over the course of fast recovery, the sender will gradually > increase (slow-start) the cwnd upward; at the end of recovery cwnd will > equal the ssthresh set by the congestion control algorithm, which will be > half of the cwnd before entering recovery. > > (This is all assuming the sender is using PRR and IETF standard > congestion control, aka Reno.) > > Hope that clarifies things a bit, > neal > ack. thanks for the clarification and sorry about the confusion. > > > >> El 23/02/17 a las 23:14, Yuchung Cheng escribi=C3=B3: >> >>> >>> >>> On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell >> > wrote: >>> >>> >>> >>> On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun >>> > wrote: >>> >>> Hi, >>> >>> Let me try to rephrase/expand. >>> >>> As I understand it, the response to congestion depends on the >>> intensity of the congestion signal. >>> If a few packets are lost, the CWND is reduced to half. This >>> is why afaiu, the response to 3 (or more) duplicated ACKs is >>> to reduce CWND by half (or some other number in cubic) >>> >>> However, if all the packets in flight are lost, there are no >>> duplicated acks, and the loss is detected through the RTO. In >>> this case, the congestion signal is more intense and the CWND >>> is reduced to 1 MSS. >>> >>> In the example i included below, all the packets in flight are >>> lost, but TLP+RACK manages to recover without using the RTO. >>> So, i guess my question is: in this case, what happens to the >>> CWND? is it reduced to half or is it set to 1 MSS? >>> >>> A more direct answer is that CWND is reduced to half. >>> >>> We can put more details in the draft on the impact of C.C.. The origina= l >>> rationale behind halving cwnd post Fast Recovery is that ACK clock is s= till >>> going so the congestion is not severe enough to warrant a complete cwnd >>> reset (=3D1). So if TLP+RACK was able to recover the loss within 2-3 RT= Ts, we >>> should react similar to the 3 dupack thresh based recovery. HTH >>> >>> >>> >>> At a high level, that is a decision for congestion control, and >>> RACK is a loss detection aglorithm, and tries to stay orthogonal >>> to congestion control. >>> >>> But on a practical level, a TCP sender ideally should be using the >>> state of the art recovery algorithm, PRR -- >>> https://tools.ietf.org/html/rfc6937 >>> -- for fast recovery. If it >>> does that then in the situation you sketch it will slow-start up >>> from a cwnd of 1, allowing 1 packet in flight, up to the ssthresh >>> set by the congestion control algorithm. This is basically the >>> response that the sender would have had to an RTO as well. So from >>> a practical standpoint it doesn't matter much that with RACK the >>> sender enters recovery instead of RTO - either way the sender >>> should be slow-starting up from a cwnd of 1 up to ssthresh. >>> >>> neal >>> >>> >>> Regards, marcelo >>> >>> >>> El 23/02/17 a las 21:29, Neal Cardwell escribi=C3=B3: >>> >>> Hi, >>> >>> Thanks for the question. >>> >>> In the draft -- >>> https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 >>> -- >>> we try to address that in section 7.5: >>> >>> 7.5. Interaction with congestion control >>> >>> RACK intentionally decouples loss detection from >>> congestion control. >>> RACK only detects losses; it does not modify the >>> congestion control >>> algorithm [RFC5681][RFC6937]. >>> >>> Thus, in any scenario like the one you describe, where >>> RACK (with or without a TLP probe) marks one or more >>> packets as lost, the sender should use its normal >>> congestion control response to packet loss. So if the >>> sender is using Reno or CUBIC, it should leave congestion >>> avoidance and enter fast recovery, and cut cwnd and >>> ssthresh as it would with any other loss detection algorith= m. >>> >>> Does that help clear up this question? >>> >>> If there is a particular section that was unclear on this >>> point or seemed to imply otherwise, please let us know so >>> we can revise it. :-) >>> >>> Thanks! >>> neal >>> >>> >>> On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun >>> >>> >> >>> >>> wrote: >>> >>> Hi, >>> >>> After reading draft-ietf-tcpm-rack-01, I have a >>> question about the >>> impact of the impact of the use of RACK and TLP in >>> congestion control. >>> >>> If this issue has been discussed earlier, I apologize >>> and please >>> point me to the right thread in the archive. >>> >>> So, consider the following situation. A TCP sender >>> using RACK and >>> TLP as defined in the draft has at a given moment a >>> large number >>> on packets in flight. Suppose that all packets are lost= . >>> I >>> understand the reaction of the sender in this case is >>> that it will >>> fire a Tail Loss Probe after the PTO expires i.e. 2RTT >>> later. >>> >>> Suppose that the probe makes it and an ack for that >>> probe is >>> returned. Since the probe is a new packet or a >>> retransmission of >>> the latest packet, RACK at the sender is likely to >>> mark all >>> previous packets as lost and retransmit them. All this >>> is done >>> while staying in congestion avoidance phase, afaiu. >>> >>> This seems a significant departure from current >>> congestion control >>> mechanisms, i think. I mean, this is not the case of a >>> spurious >>> isolated drop. All packets in flight were lost, which >>> can be a >>> pretty large number of packets. Staying in congestion >>> avoidance >>> after a single packet made it through seems more >>> optimistic than >>> the current situation, i would say. >>> >>> Am i missing something? >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >> > >>> >>> >>> >>> >>> >>> >> > --001a113fac78b1e7dd054986edab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 27, 2017 at 4:57 AM, Neal Cardwell <ncardwell@google.co= m> wrote:

=
On M= on, Feb 27, 2017 at 6:23 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
Th= anks for the replies, both from Neal and Yuchung, but i am (more) confused = now.

>From Neal's reply, i understand that in the situation i described the c= wnd fall to 1 MSS and from Yuchung's reply it seems it falls to half it= s value. What am i missing?

In the situation you sketch,=C2=A0both are true, but at different time sca= les. :-)

Short-te= rm: upon the first ACK, which causes the sender to enter fast recovery, the= sender will set the cwnd to 1.

Long-term: ov= er the course of fast recovery, the sender will gradually increase (slow-st= art) the cwnd upward; at the end of recovery cwnd will equal the ssthresh s= et by the congestion control algorithm, which will be half of the cwnd befo= re entering recovery.

(This is all assuming the sender is using PRR and=C2= =A0IETF standard congestion control, aka R= eno.)

Hope that clarifies things a bit,
neal

ack. thanks for the clarification and sorry abou= t the confusion.=C2=A0

=C2=A0
El 23/02/17 a las 23:14, Yuchung Cheng escribi=C3=B3:

On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell <ncardwell@google.com <mailto:ncardwell@google.com>> wrote:

=C2=A0 =C2=A0 On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun
=C2=A0 =C2=A0 <m= arcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Let me try to rephrase/expand.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As I understand it, the response to congestion = depends on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 intensity of the congestion signal.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a few packets are lost, the CWND is reduced = to half. This
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is why afaiu, the response to 3 (or more) dupli= cated ACKs is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to reduce CWND by half (or some other number in= cubic)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, if all the packets in flight are lost,= there are no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 duplicated acks, and the loss is detected throu= gh the RTO. In
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this case, the congestion signal is more intens= e and the CWND
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is reduced to 1 MSS.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In the example i included below, all the packet= s in flight are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lost, but TLP+RACK manages to recover without u= sing the RTO.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, i guess my question is: in this case, what = happens to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CWND? is it reduced to half or is it set to 1 M= SS?

A more direct answer is that CWND is reduced to half.

We can put more details in the draft on the impact of C.C.. The original ra= tionale behind halving cwnd post Fast Recovery is that ACK clock is still g= oing so the congestion is not severe enough to warrant a complete cwnd rese= t (=3D1). So if TLP+RACK was able to recover the loss within 2-3 RTTs, we s= hould react similar to the 3 dupack thresh based recovery. HTH

=C2=A0 =C2=A0 At a high level, that is a decision for congestion control, a= nd
=C2=A0 =C2=A0 RACK is a loss detection aglorithm, and tries to stay orthogo= nal
=C2=A0 =C2=A0 to congestion control.

=C2=A0 =C2=A0 But on a practical level, a TCP sender ideally should be usin= g the
=C2=A0 =C2=A0 state of the art recovery algorithm, PRR=C2=A0 --
=C2=A0 =C2=A0 https://tools.ietf.org/html/rfc6937
=C2=A0 =C2=A0 <https://tools.ietf.org/html/rfc6937>= ; -- for fast recovery. If it
=C2=A0 =C2=A0 does that then in the situation you sketch it will slow-start= up
=C2=A0 =C2=A0 from a cwnd of 1, allowing 1 packet in flight, up to the ssth= resh
=C2=A0 =C2=A0 set by the congestion control algorithm. This is basically th= e
=C2=A0 =C2=A0 response that the sender would have had to an RTO as well. So= from
=C2=A0 =C2=A0 a practical standpoint it doesn't matter much that with R= ACK the
=C2=A0 =C2=A0 sender enters recovery instead of RTO - either way the sender=
=C2=A0 =C2=A0 should be slow-starting up from a cwnd of 1 up to ssthresh.
=C2=A0 =C2=A0 neal

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, marcelo

=C2=A0 =C2=A0 =C2=A0 =C2=A0 El 23/02/17 a las 21:29, Neal Cardwell escribi= =C3=B3:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks for the question.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the draft --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /tools.ietf.org/html/draft-ietf-tcpm-rack-01
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://tools.ietf.org/html/draft-ietf-tcpm-rack-01> --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we try to address that in section= 7.5:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7.5.=C2=A0 Interaction with conge= stion control

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RACK intentionally d= ecouples loss detection from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RACK only detects lo= sses; it does not modify the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm [RFC5681][= RFC6937].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thus, in any scenario like the on= e you describe, where
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RACK (with or without a TLP probe= ) marks one or more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 packets as lost, the sender shoul= d use its normal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control response to pa= cket loss. So if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sender is using Reno or CUBIC, it= should leave congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 avoidance and enter fast recovery= , and cut cwnd and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ssthresh as it would with any oth= er loss detection algorithm.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Does that help clear up this ques= tion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If there is a particular section = that was unclear on this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point or seemed to imply otherwis= e, please let us know so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we can revise it. :-)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 neal

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Feb 23, 2017 at 2:30 AM, = marcelo bagnulo braun
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>= >>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 After reading draft= -ietf-tcpm-rack-01, I have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 question about the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 impact of the impac= t of the use of RACK and TLP in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If this issue has b= een discussed earlier, I apologize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and please
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point me to the rig= ht thread in the archive.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, consider the fo= llowing situation. A TCP sender
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 using RACK and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLP as defined in t= he draft has at a given moment a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 large number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on packets in fligh= t. Suppose that all packets are lost. I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 understand the reac= tion of the sender in this case is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that it will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fire a Tail Loss Pr= obe after the PTO expires i.e. 2RTT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 later.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Suppose that the pr= obe makes it and an ack for that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 probe is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 returned. Since the= probe is a new packet or a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retransmission of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the latest packet, = RACK at the sender is likely to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mark all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 previous packets as= lost and retransmit them. All this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while staying in co= ngestion avoidance phase, afaiu.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This seems a signif= icant departure from current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms, i think= . I mean, this is not the case of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spurious
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 isolated drop. All = packets in flight were lost, which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 can be a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pretty large number= of packets. Staying in congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 avoidance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 after a single pack= et made it through seems more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 optimistic than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the current situati= on, i would say.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Am i missing someth= ing?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, marcelo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm@ietf.org <mailto:tcpm@ietf.org> <mailto:tcpm@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tcpm@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mailman/listinfo/tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.= ietf.org/mailman/listinfo/tcpm>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.= ietf.org/mailman/listinfo/tcpm>>

--001a113fac78b1e7dd054986edab-- From nobody Mon Feb 27 10:18:58 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BFE12999E for ; Mon, 27 Feb 2017 10:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 vI--PhuzTzj3 for ; Mon, 27 Feb 2017 10:18:55 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD18912999D for ; Mon, 27 Feb 2017 10:18:55 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id y135so73588857itc.1 for ; Mon, 27 Feb 2017 10:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=943r/OFr69W+1FGH1tLPlJeoBhB8oEpcu1IRX7vyA6k=; b=nhaTa8rSGTZtR1QGg0VX8DzciWYGd1ljX8dV7VIOkRo6TXkFu29FAIiI/DUzR9Vdne tEG1OvWLqtPXMkUA3YJTX2u4yYTJsr2j/smuLma/6UiBk9UCPBZ2yLtUk2oTX9gom5ox suQpIp6iaoPa59JulpUTJLU662cflW9a0P968yuf5m1RximdLEhY4s9AolKT2p2RcyzD Q5Qfyg76rE1cRviAKy4pS7+SfsmMUMMASZmPWlpNOq8jaEa8GF/5X9WdnSYJGyaEazZ+ R9UH6VV+H1oQOM6paK797dn7DnvQjKYWBi+etYYJ2IzXNxFXlsQBVQnw+O1mhsj6P8ig b/pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=943r/OFr69W+1FGH1tLPlJeoBhB8oEpcu1IRX7vyA6k=; b=dS0z0pxK72dn2YibEQtqyVSKCGG/SLgLqti0nt5ZkfTBleaY7ybg41lDpeAAxEG80+ D1tWPl2MvdpBkLqPSFxC+M6rw5nEVp42VdXBJAx6eg826uPHsFCElBOUq/n8hOiTxKtE wJ0c2ZQYWPwOSm63vZBnjad+aHixYj+VElOqDz62H1w9LiF7jRf05Pc65HatsHBUVr+J WK6YE0VfNFR/oZL7uy7j47HUvTega2SP8UdKSPts63dMBafi03Fckq4ZsVuzRRCIHOIa 71duEp3zRvIHfQFInOQQQqzS0EfaWICNsRdiCPDRDpqt5+EXXQiPLfxMrJicWbGj2+fO jOfQ== X-Gm-Message-State: AMke39n0dJdrYpMmknfyGUGcUNvdCFf9Y7Za2T7h+XH+a0TjDktUOI8V/2iey4dIfMXbyeBMYvHBmO/dWusmzs+1 X-Received: by 10.36.44.4 with SMTP id i4mr14963003iti.105.1488219534950; Mon, 27 Feb 2017 10:18:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Mon, 27 Feb 2017 10:18:14 -0800 (PST) In-Reply-To: References: From: Yuchung Cheng Date: Mon, 27 Feb 2017 10:18:14 -0800 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a11440eb4bb08940549871c76 Archived-At: Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Subject: Re: [tcpm] Agenda requests for IETF 98 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 18:18:57 -0000 --001a11440eb4bb08940549871c76 Content-Type: text/plain; charset=UTF-8 * Draft-ietf-tcpm-rack * Yuchung Cheng * 20m I will present updates on the draft as well as experimentation results that've been requested in previous meetings. On Mon, Feb 27, 2017 at 9:38 AM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Hi all, > > For the Chicago meeting, tentatively (!) TCPM got the 2.5h slot on > Wednesday morning. > > If you want to present something in the TCPM meeting, please let the > chairs know until Sunday March 12: > > * Draft name / title > * Presenter > * Total time (including Q&A) > > Thanks! > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11440eb4bb08940549871c76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

* Draft-ietf-tcpm-rack

* Yuchung Cheng

* 20m=

I will present updates on the draft as well as ex= perimentation results that've been requested in previous meetings.

On Mon, Fe= b 27, 2017 at 9:38 AM, Scharf, Michael (Nokia - DE) <<= a href=3D"mailto:michael.scharf@nokia.com" target=3D"_blank">michael.scharf= @nokia.com> wrote:

Hi all,<= br>
For the Chicago meeting, tentatively (!) TCPM got the 2.5h slot on Wednesda= y morning.

If you want to present something in the TCPM meeting, please let the chairs= know until Sunday March 12:

* Draft name / title
* Presenter
* Total time (including Q&A)

Thanks!

Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a11440eb4bb08940549871c76-- From nobody Mon Feb 27 23:46:08 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75D1294E0 for ; Mon, 27 Feb 2017 23:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 UAF5FXsW3Px0 for ; Mon, 27 Feb 2017 23:46:02 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F241294DD for ; Mon, 27 Feb 2017 23:46:01 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v186so78519668wmd.0 for ; Mon, 27 Feb 2017 23:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=WcZoRAxy86Fhs9JN/amAC6w/xHCSZafucg2YU0xqYUQ=; b=iTpz5o/4s9kXnUkul2dP3mNCX5VWkvvI9I1F8bkB9+nXTWCvCo8o+ubDVX3jxX/dvi SxTRoqArFpPNzPVFf9Px0nv+SRRO4VBkDyTXkI5/JYcTQcRQWpio6ed5hWGCpw4jI+Vv 6vt4cEfwfRKvXGkQ0Xzpc2lyM7JqFpAmfJrV5KigI28OVa6VUgAkxssX7xVZ28bbMom0 jvAsO3s2mAPtbp9jLP8L4PsWXmmHruatnLt1j8dkewS6gQueUfmU/2Atxp6JQ8BNHTcr OzACx37czHyy7aOhpUGR/9ZE3tt6p/3D7GYSn2dVF8JajoKjvkW5ra7Wm2qJcYE/HHC1 HtNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WcZoRAxy86Fhs9JN/amAC6w/xHCSZafucg2YU0xqYUQ=; b=JFEpecg5gmnhWeZqtG57UsHu5RvpPKz3fitvEHeRYpAVbqTdvS++UwEiTd8e/Yi56P 2OGyshvCiHDA02Uek1nPoAJglad/cODW6xwfw0FNsMK9PXInGApfLovv5JZ3OEfvWtqg PADYZuLT2ZBFfFXW/eM8GluEpdU0Q7YHuQB6ro6aQOzC6RmW8HyWBeXMpW3VNMNcTKpE BwunJTkyFmQib4H8GbayqursdgeyvikDCUDuTnLiMoGz+WidGqppgsTIpVH3w+8JuZIU 1TrDQV3viN6nnumOEGJASJ2uQOku0tQkd7PPNFLGXYYzuTsm3ztLWJz2nFA6qNHkeCxU 1Krg== X-Gm-Message-State: AMke39k1fXHKjyTI7vdsHmXRoJsg/auAvS/0bX3vUFRghBdSmRb04ckkNYMxwKYvdkwIx/GQ X-Received: by 10.28.134.67 with SMTP id i64mr1077405wmd.5.1488267959942; Mon, 27 Feb 2017 23:45:59 -0800 (PST) Received: from Macintosh-6.local ([163.117.139.231]) by smtp.gmail.com with ESMTPSA id m29sm1115456wrm.38.2017.02.27.23.45.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 23:45:59 -0800 (PST) To: Neal Cardwell References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es>

From: marcelo bagnulo braun Message-ID: Date: Tue, 28 Feb 2017 08:45:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 28 Feb 2017 07:46:06 -0000 thanks, makes sense to me now. With PRR it behaves somehow similar than slow start (depending on the PRR mode, with CRB i think it even goes slower than slow start, while with SSRB it goes 1 MSS faster per RTT). However with RFC 6675 it would send the all ssthresh packets right after the first ack, correct? Should we reccomend that RACK is used with PRR? Regards, marcelo El 27/02/17 a las 13:57, Neal Cardwell escribió: > On Mon, Feb 27, 2017 at 6:23 AM, marcelo bagnulo braun > > wrote: > > Thanks for the replies, both from Neal and Yuchung, but i am > (more) confused now. > > >From Neal's reply, i understand that in the situation i described > the cwnd fall to 1 MSS and from Yuchung's reply it seems it falls > to half its value. What am i missing? > > > In the situation you sketch, both are true, but at different time > scales. :-) > > Short-term: upon the first ACK, which causes the sender to enter fast > recovery, the sender will set the cwnd to 1. > > Long-term: over the course of fast recovery, the sender will gradually > increase (slow-start) the cwnd upward; at the end of recovery cwnd > will equal the ssthresh set by the congestion control algorithm, which > will be half of the cwnd before entering recovery. > > (This is all assuming the sender is using PRR and IETF standard > congestion control, aka Reno.) > > Hope that clarifies things a bit, > neal > > El 23/02/17 a las 23:14, Yuchung Cheng escribió: > > > > On Thu, Feb 23, 2017 at 1:59 PM, Neal Cardwell > > >> > wrote: > > > > On Thu, Feb 23, 2017 at 3:43 PM, marcelo bagnulo braun > > >> wrote: > > Hi, > > Let me try to rephrase/expand. > > As I understand it, the response to congestion depends > on the > intensity of the congestion signal. > If a few packets are lost, the CWND is reduced to > half. This > is why afaiu, the response to 3 (or more) duplicated > ACKs is > to reduce CWND by half (or some other number in cubic) > > However, if all the packets in flight are lost, there > are no > duplicated acks, and the loss is detected through the > RTO. In > this case, the congestion signal is more intense and > the CWND > is reduced to 1 MSS. > > In the example i included below, all the packets in > flight are > lost, but TLP+RACK manages to recover without using > the RTO. > So, i guess my question is: in this case, what happens > to the > CWND? is it reduced to half or is it set to 1 MSS? > > A more direct answer is that CWND is reduced to half. > > We can put more details in the draft on the impact of C.C.. > The original rationale behind halving cwnd post Fast Recovery > is that ACK clock is still going so the congestion is not > severe enough to warrant a complete cwnd reset (=1). So if > TLP+RACK was able to recover the loss within 2-3 RTTs, we > should react similar to the 3 dupack thresh based recovery. HTH > > > > At a high level, that is a decision for congestion > control, and > RACK is a loss detection aglorithm, and tries to stay > orthogonal > to congestion control. > > But on a practical level, a TCP sender ideally should be > using the > state of the art recovery algorithm, PRR -- > https://tools.ietf.org/html/rfc6937 > > > -- for fast recovery. If it > does that then in the situation you sketch it will > slow-start up > from a cwnd of 1, allowing 1 packet in flight, up to the > ssthresh > set by the congestion control algorithm. This is basically the > response that the sender would have had to an RTO as well. > So from > a practical standpoint it doesn't matter much that with > RACK the > sender enters recovery instead of RTO - either way the sender > should be slow-starting up from a cwnd of 1 up to ssthresh. > > neal > > > Regards, marcelo > > > El 23/02/17 a las 21:29, Neal Cardwell escribió: > > Hi, > > Thanks for the question. > > In the draft -- > https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 > > > > -- > we try to address that in section 7.5: > > 7.5. Interaction with congestion control > > RACK intentionally decouples loss detection from > congestion control. > RACK only detects losses; it does not modify the > congestion control > algorithm [RFC5681][RFC6937]. > > Thus, in any scenario like the one you describe, where > RACK (with or without a TLP probe) marks one or more > packets as lost, the sender should use its normal > congestion control response to packet loss. So if the > sender is using Reno or CUBIC, it should leave > congestion > avoidance and enter fast recovery, and cut cwnd and > ssthresh as it would with any other loss detection > algorithm. > > Does that help clear up this question? > > If there is a particular section that was unclear > on this > point or seemed to imply otherwise, please let us > know so > we can revise it. :-) > > Thanks! > neal > > > On Thu, Feb 23, 2017 at 2:30 AM, marcelo bagnulo braun > > > > >>> > > wrote: > > Hi, > > After reading draft-ietf-tcpm-rack-01, I have a > question about the > impact of the impact of the use of RACK and TLP in > congestion control. > > If this issue has been discussed earlier, I > apologize > and please > point me to the right thread in the archive. > > So, consider the following situation. A TCP sender > using RACK and > TLP as defined in the draft has at a given > moment a > large number > on packets in flight. Suppose that all packets > are lost. I > understand the reaction of the sender in this > case is > that it will > fire a Tail Loss Probe after the PTO expires > i.e. 2RTT > later. > > Suppose that the probe makes it and an ack for > that > probe is > returned. Since the probe is a new packet or a > retransmission of > the latest packet, RACK at the sender is likely to > mark all > previous packets as lost and retransmit them. > All this > is done > while staying in congestion avoidance phase, > afaiu. > > This seems a significant departure from current > congestion control > mechanisms, i think. I mean, this is not the > case of a > spurious > isolated drop. All packets in flight were > lost, which > can be a > pretty large number of packets. Staying in > congestion > avoidance > after a single packet made it through seems more > optimistic than > the current situation, i would say. > > Am i missing something? > > Regards, marcelo > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/tcpm > > > > > >> > > > > > > > From nobody Tue Feb 28 00:08:31 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C91D128B44 for ; Tue, 28 Feb 2017 00:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 Ct8YiLicpKrC for ; Tue, 28 Feb 2017 00:08:28 -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 64D341289B0 for ; Tue, 28 Feb 2017 00:08:28 -0800 (PST) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 40AF429C1D2 for ; Tue, 28 Feb 2017 17:08:26 +0900 (JST) Received: by mail-oi0-f47.google.com with SMTP id f192so2225804oic.3 for ; Tue, 28 Feb 2017 00:08:26 -0800 (PST) X-Gm-Message-State: AMke39lSwV5TlOS8AyHSg6YtFGYc0Lx4yAQF///NKQbFGdaWImp3wW/65S5gZYp3sVHwSeow/PMann4HsMLxwQ== X-Received: by 10.202.117.81 with SMTP id q78mr443510oic.182.1488269304858; Tue, 28 Feb 2017 00:08:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.82.27 with HTTP; Tue, 28 Feb 2017 00:08:24 -0800 (PST) In-Reply-To: References: From: Yoshifumi Nishida Date: Tue, 28 Feb 2017 00:08:24 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a1134e27e3f134b054992b30d Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-cubic-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 28 Feb 2017 08:08:30 -0000 --001a1134e27e3f134b054992b30d Content-Type: text/plain; charset=UTF-8 Hello, I have the following comments on the draft. 1: P3. ".. all Reno style TCP standards and their variants, including TCP RENO, TCP NewReno, TCP-SACK, ..." -> It seems to me that RFC2018 doesn't fit into Reno style variants very well as it doesn't include congestion control mechanism. I personally think it would be better to use RFC6675 here, but this is also a NewReno variants (with SACK options). I am thinking that referring 6582 and 6675 as TCP-NewReno might be an option. 2: P6. Section 4.1 ".. such as TCP-NewReno and TCP-SACK..." -> same as 1:, It seems to me that RFC2018 doesn't fit here very well. 3: P6. Section 4.1 "beta_cubic" is used for Eq.2, but it is not mentioned which value should be used here. It might be good to add something like "We will describe how to set beta_cubic in 4.5"? 4: P7. It's not very clear to me what we should do if it's in TCP-friendly region, but cwnd is larger than W_max. Do we apply TCP-friendly algorithm or convex algorithm? I also think it's not clear what we should do during slow-start period. (I think Marcelo made similar comments before.) 5: P9 Section 4.6 Can't we simplify the code like this? Also, using 1.0 and 2.0 might be better as beta_cubic is 0.7? If (W_max < W_last_max) { W_max = W_max * (1 + beta_cubic) / 2; } W_last_max = W_max; 6: P11 Section 5.1 I understand that 0.4 is better than 0.04 or 4. But, I'm not very sure why it's not 0.3 or 0.5. Is it possible to provide some rationale here? 7: P12 Section 5.5 I personally think what is described here can be explained in Introduction or Design principle section. Because this seems to be a part of fundamental concepts of CUBIC. Also, even If we create really aggressive window adjustment logic, can't it cause congestion collapse? 8: P12 Section 5.8 It might be fine, but using MUST in the discussion section may look a bit confusing? -- Yoshi On Wed, Feb 15, 2017 at 1:13 AM, Yoshifumi Nishida wrote: > Hello, > > In addition to the dctcp draft, TCP chairs conclude that > draft-ietf-tcpm-cubic-04 is ready for WGLC as well and decided to initiate > the call. > > The WGLC for this draft runs until * Friday March 3 *. > Please send your feedback to the ML. > > BTW, the intended status of the draft is Informational. > The draft is available from the following URL. > https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04 > > Thanks, > -- > Yoshi > --001a1134e27e3f134b054992b30d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

I have the following comments on= the draft.

1: =C2=A0P3. ".. all Reno style T= CP standards and their variants, including TCP RENO, TCP NewReno, TCP-SACK,= ..."=C2=A0

=C2=A0 =C2=A0 =C2=A0-> It seems to me that RF= C2018 doesn't fit into Reno style variants very well as it doesn't = include congestion control mechanism.=C2=A0 I personally think it would be = better to use RFC6675 here, but this is also a NewReno variants (with SACK = options). I am thinking that referring 6582 and 6675 as TCP-NewReno might b= e an option.=C2=A0

=C2=A0 =C2=A0

2: P6. Section 4.1 &qu= ot;.. such as TCP-NewReno and TCP-SACK..."

=C2=A0 =C2=A0 -&g= t; same as 1:, It seems to me that RFC2018 doesn't fit here very well.<= /div>

3: P6. Section 4.1

=C2=A0 =C2=A0 "b= eta_cubic" is used for Eq.2, but it is not mentioned which value shoul= d be used here.

=C2=A0 =C2=A0 It might be good to add something l= ike "We will describe how to set beta_cubic in 4.5"?

4: P7.=C2=A0

=C2=A0 =C2=A0 It's not very clear t= o me what we should do if it's in TCP-friendly region, but cwnd is larg= er than W_max. Do we apply TCP-friendly algorithm or convex algorithm?=C2= =A0

=C2=A0 =C2=A0 I also think it's not clear what we should = do during slow-start period. (I think Marcelo made similar comments before.= )

5: P9 Section 4.6

=C2=A0 =C2=A0 Can= 9;t we simplify the code like this? Also, using 1.0 and 2.0 might be better= as beta_cubic is 0.7?

=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2= =A0 =C2=A0 If (W_max < W_last_max) {

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 W_max =3D W_max * (1 + beta_cubic) / 2;

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 W_last_max =3D W_max;

=C2=A0 =C2=A0

= 6: P11 Section 5.1

=C2=A0 =C2=A0 I understand that 0.4 is better = than 0.04 or 4. But, I'm not very sure why it's not 0.3 or 0.5.

=C2=A0 =C2=A0 Is it possible to provide some rationale here?

7: P12 Section 5.5

=C2=A0 =C2=A0 I personally t= hink what is described here can be explained in Introduction or Design prin= ciple section.

=C2=A0 =C2=A0 Because this seems to be a part of f= undamental concepts of CUBIC.=C2=A0

=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 Also, even If we create really aggressive window adjustment = logic, can't it cause congestion collapse?

8: = P12 Section 5.8

=C2=A0 =C2=A0 It might be fine, but using MUST in= the discussion section may look a bit confusing?=C2=A0

Yoshi =C2=A0

On Wed, Feb 15, 2017 at 1:13 AM, Yoshifu= mi Nishida <nishida@sfc.wide.ad.jp> wrote:

Hello,

In additio= n to the dctcp draft, TCP chairs conclude that draft-ietf-tcpm-cubic-04 is = ready for WGLC as well and decided to initiate the call.

The WGLC for this draft runs until * Friday March 3 *.=C2=A0

Please send your feedback to the ML.

B= TW, the intended status of the draft is Informational.=C2=A0

The = draft is available from the following URL.

htt= ps://tools.ietf.org/html/draft-ietf-tcpm-cubic-04

Thanks,

Yoshi

--001a1134e27e3f134b054992b30d-- From nobody Tue Feb 28 00:55:06 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD8D12706D; Tue, 28 Feb 2017 00:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 nq7MXESaS-CK; Tue, 28 Feb 2017 00:55:04 -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 0CA65126D74; Tue, 28 Feb 2017 00:55:03 -0800 (PST) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id EC9BC29C1D4; Tue, 28 Feb 2017 17:55:01 +0900 (JST) Received: by mail-ot0-f178.google.com with SMTP id k4so3677564otc.0; Tue, 28 Feb 2017 00:55:01 -0800 (PST) X-Gm-Message-State: AMke39nf3j4bj7WEPAK0dwp6WlQGO9sO9fA2E+ZfMWTpQXONVJ+BZ4fPzzqltXnm8j4q3Bsqj/9tNMkMjeDb7g== X-Received: by 10.157.60.230 with SMTP id t35mr541106otf.34.1488272100799; Tue, 28 Feb 2017 00:55:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.82.27 with HTTP; Tue, 28 Feb 2017 00:55:00 -0800 (PST) In-Reply-To: References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es>

From: Yoshifumi Nishida Date: Tue, 28 Feb 2017 00:55:00 -0800 X-Gmail-Original-Message-ID: Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=94eb2c19054ce5baab0549935992 Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 28 Feb 2017 08:55:05 -0000 --94eb2c19054ce5baab0549935992 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2017 at 11:45 PM, marcelo bagnulo braun wrote: > thanks, makes sense to me now. > > With PRR it behaves somehow similar than slow start (depending on the PRR > mode, with CRB i think it even goes slower than slow start, while with SSRB > it goes 1 MSS faster per RTT). > However with RFC 6675 it would send the all ssthresh packets right after > the first ack, correct? > I think this is not very precise. It depends on the calculation of pipe size. Figure 3.1 in RFC6937 might be helpful to see the difference. -- Yoshi --94eb2c19054ce5baab0549935992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On M= on, Feb 27, 2017 at 11:45 PM, marcelo bagnulo braun <<= a href=3D"mailto:marcelo@it.uc3m.es" target=3D"_blank">marcelo@it.uc3m.es> wrote:

thanks, makes sense = to me now.

With PRR it behaves somehow similar than slow start (depending on the PRR m= ode, with CRB i think it even goes slower than slow start, while with SSRB = it goes 1 MSS faster per RTT).
However with RFC 6675 it would send the all ssthresh packets right after th= e first ack, correct?

I think this is n= ot very precise. It depends on the calculation of pipe size.

Figu= re 3.1 in RFC6937 might be helpful to see the difference. =C2=A0

= --

Yoshi

--94eb2c19054ce5baab0549935992-- From nobody Tue Feb 28 01:03:37 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79EA1294F5 for ; Tue, 28 Feb 2017 01:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 PDnVSeL-csim for ; Tue, 28 Feb 2017 01:03:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77BD126CD8 for ; Tue, 28 Feb 2017 01:03:02 -0800 (PST) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A630629C1D4 for ; Tue, 28 Feb 2017 18:03:00 +0900 (JST) Received: by mail-ot0-f178.google.com with SMTP id k4so3789750otc.0 for ; Tue, 28 Feb 2017 01:03:00 -0800 (PST) X-Gm-Message-State: AMke39kzgvX27CE43lmy6ZXUjv29OlwTMswYxjOH3LojWEiGwtZxrlabcVovg6GRdCsENGQXZLhZTjkGr8nSAQ== X-Received: by 10.157.59.164 with SMTP id k33mr533087otc.193.1488272579411; Tue, 28 Feb 2017 01:02:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.82.27 with HTTP; Tue, 28 Feb 2017 01:02:59 -0800 (PST) In-Reply-To: References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es>

From: Yoshifumi Nishida Date: Tue, 28 Feb 2017 01:02:59 -0800 X-Gmail-Original-Message-ID: Message-ID: To: tcpm IETF list Content-Type: multipart/alternative; boundary=001a11492d1e6ccb3d0549937627 Archived-At: Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 28 Feb 2017 09:03:36 -0000 --001a11492d1e6ccb3d0549937627 Content-Type: text/plain; charset=UTF-8 Sorry.. I meant the figure in Section 3.1. -- Yoshi On Tue, Feb 28, 2017 at 12:55 AM, Yoshifumi Nishida wrote: > On Mon, Feb 27, 2017 at 11:45 PM, marcelo bagnulo braun < > marcelo@it.uc3m.es> wrote: > >> thanks, makes sense to me now. >> >> With PRR it behaves somehow similar than slow start (depending on the PRR >> mode, with CRB i think it even goes slower than slow start, while with SSRB >> it goes 1 MSS faster per RTT). >> However with RFC 6675 it would send the all ssthresh packets right after >> the first ack, correct? >> > > I think this is not very precise. It depends on the calculation of pipe > size. > Figure 3.1 in RFC6937 might be helpful to see the difference. > -- > Yoshi > --001a11492d1e6ccb3d0549937627 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry.. I meant the figure in Section 3.1.

Yoshi

On Tue= , Feb 28, 2017 at 12:55 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp= > wrote:

<= div class=3D"gmail_extra">
On Mo= n, Feb 27, 2017 at 11:45 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
thanks, makes sense t= o me now.

With PRR it behaves somehow similar than slow start (depending on the PRR m= ode, with CRB i think it even goes slower than slow start, while with SSRB = it goes 1 MSS faster per RTT).
However with RFC 6675 it would send the all ssthresh packets right after th= e first ack, correct?

I think th= is is not very precise. It depends on the calculation of pipe size.
Figure 3.1 in RFC6937 might be helpful to see the difference. =C2=A0
--
Yoshi

--001a11492d1e6ccb3d0549937627-- From nobody Tue Feb 28 09:35:21 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805F4129651 for ; Tue, 28 Feb 2017 09:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 BIa5fjlrr6UQ for ; Tue, 28 Feb 2017 09:35:19 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B241294A9 for ; Tue, 28 Feb 2017 09:35:19 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id l7so14140508ioe.3 for ; Tue, 28 Feb 2017 09:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uOE+S12zU/XQzVza8SIqy1l5BODU87yaxj78KAJ2EgM=; b=by90N1WvhAEWHJpVIjJBcSTG03Sg9YAux7rONnqzTMx/M4iykU1wYK/p/5l6uQNmpJ YcpejQszzdU7PnzuAxIrpwMvkzceq54V3yBeGxh217FnPCQ/EzzJTGCl+2lLAWAwm87c rb0rkqDKCmVO3Sb9+/rhhfMp+LXVGZAoLBoIhZANn8Nun/0bjs2bOu89kq6+BCBzXtf9 XGEE9K6nDJf01cf3pCvcz8oqlMMxtZVlau+FCkKYQQjJFTFjkmhhHyDlcB91wFZdSiNP SOSp7lbcijg8RG2Td2z2GkbuC0M8qFZV3uaoYzdMUrUwHrL/n2bUih9+RdA3IJlrc/gP vz6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uOE+S12zU/XQzVza8SIqy1l5BODU87yaxj78KAJ2EgM=; b=JHGHxSMP4wN/9uCEl9fxgCKKB0vIK4CVnZtHU3MqIAE930TZ4FRvOmGmIHfPbs3s90 Q85zAM4CzPNAdBxRMIs7S5gSm4bpKUVIE6jKlTdMh4ZFwb/XZR+Va5QEFEwTaBussQE1 +hWUUxGHN7ZLK4ZKqHOYFY6XR4sj9/LbQSFDKfBYlCDX1ROArFS+CzQ9Rb6R+fljKnUQ F0KtfKpR4AWlLEHxiJHJY9sA8GF/aFZB2fbawP34HuShvYbpC4IVAHCd17VE3WHh+zW7 G/SJ3BJ8E4FoCvg3n+HKKKopQwWalEV0oixMuRXZgqE0361Zmug7KqrWiWkPyG0FxVdt Ad8g== X-Gm-Message-State: AMke39nLL/y+1eMnBk9OGzC3iuIdoExK4qjjeg4Qyxk7Ss2e9pe8gWr6NmWOGaa0Sq5npn/rn9qw8zMQDBvc/+AU X-Received: by 10.107.172.7 with SMTP id v7mr4331310ioe.49.1488303318163; Tue, 28 Feb 2017 09:35:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Tue, 28 Feb 2017 09:34:37 -0800 (PST) In-Reply-To: References: <00c831e7-9068-5734-e94a-f7729125c1d0@it.uc3m.es>

From: Yuchung Cheng Date: Tue, 28 Feb 2017 09:34:37 -0800 Message-ID: To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=94eb2c05a38099644805499a9e02 Archived-At: Cc: draft-ietf-tcpm-rack@ietf.org, tcpm IETF list Subject: Re: [tcpm] RACK, TLP and congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 28 Feb 2017 17:35:20 -0000 --94eb2c05a38099644805499a9e02 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 28, 2017 at 12:55 AM, Yoshifumi Nishida wrote: > On Mon, Feb 27, 2017 at 11:45 PM, marcelo bagnulo braun < > marcelo@it.uc3m.es> wrote: > >> thanks, makes sense to me now. >> >> With PRR it behaves somehow similar than slow start (depending on the PRR >> mode, with CRB i think it even goes slower than slow start, while with SSRB >> it goes 1 MSS faster per RTT). >> However with RFC 6675 it would send the all ssthresh packets right after >> the first ack, correct? >> > > I think this is not very precise. It depends on the calculation of pipe > size. > Figure 3.1 in RFC6937 might be helpful to see the difference. > Right. On a valid ACK, RFC6675 always send up to (cwnd - pipe) of packets. The only exception is the first ACK that triggering the recovery. Even if cwnd <= pipe, it still forces one retransmit. PRR (and BBR) has the same flavor of exception to keep ACK clocking. -- > Yoshi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --94eb2c05a38099644805499a9e02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2017 at 12:55 AM, Yoshifumi Nishida &= lt;nishida@sfc.= wide.ad.jp> wrote:

On Mon, Feb 27, 2017 at 11:45 PM, marcelo bagnulo braun <marcelo@it= .uc3m.es> wrote:
thanks, = makes sense to me now.

With PRR it behaves somehow similar than slow start (depending on the PRR m= ode, with CRB i think it even goes slower than slow start, while with SSRB = it goes 1 MSS faster per RTT).
However with RFC 6675 it would send the all ssthresh packets right after th= e first ack, correct?

I think th= is is not very precise. It depends on the calculation of pipe size.
Figure 3.1 in RFC6937 might be helpful to see the difference. =C2=A0

Right. On a valid ACK, RFC6675 always= send up to (cwnd - pipe) of packets. The only exception is the first ACK t= hat triggering the recovery. Even if cwnd <=3D pipe, it still forces one= retransmit. PRR (and BBR) has the same flavor of exception to keep ACK clo= cking.

=
--
Yos= hi

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--94eb2c05a38099644805499a9e02-- From nobody Tue Feb 28 15:03:48 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6A129436 for ; Tue, 28 Feb 2017 15:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 VpMbimbOwwLC for ; Tue, 28 Feb 2017 15:03:44 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73964129435 for ; Tue, 28 Feb 2017 15:03:44 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id h10so86769126ith.1 for ; Tue, 28 Feb 2017 15:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DnGCdsMUyQN9iqKmVjMpsVluQh5wiBTpvQFYlJ+W4eE=; b=PjDu3Ohk9HivzY+HlvM7EcvLvz2siqZwomoZGtivD0catNMSUTIe5lhNpuJqigoKPj B5Peix8AY0hklj8Bx125cnQvWARwdjTs0xaA5UtPCOf1ar5iahRGTMz53V/l2ZkYqyO/ avwctGx5405KIb7wngGUyWnRoohBHmr8bBojAP1vhwSaAspqUqWpiBzFPQxfoovicOew 8+26+bCcs1hvR4uQr1vN53Ib6MRH1vHUTc23DERVSKI+nzdQKOqTMw5PEs57IzcWf+aG LQ85kmBVbpheDwsdERFTXsOiXg5PXbjQQ0kYmdCIt5QFY62KSFInsxwiF9laE2DmwfgH B0jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DnGCdsMUyQN9iqKmVjMpsVluQh5wiBTpvQFYlJ+W4eE=; b=ubqWWVAKBxtz8AerzL+vIyZwqt1iR6xZD6dOJ779Y+VRLW+8raEiLHncU3tjlC3X8+ rlScPlbrpGEH27Hbs7U+PiHeXrcG+TpO+Koc3fWGP0T9eIbqASnTpNXPIM3sRqPiq9KM Ad7EBNs1Y44V4U1Ffkiaei2bUUEyhrrDSvyYquT5Nl1769fWOjoQH85ktpJGonhdqsPX GLdwahEwbgN1jbMdjDBbLY+xQiy/JtWSUaPzYkrx7upLtt0zfyKAhmSRsZXZ1WyUDuP4 KviBx3Pu+KL0xzvHhfVhENc4If6AWyYqLaNnFutbiv3+kmOPHMY7u+r6IOfoOBDpJmQg vUiQ== X-Gm-Message-State: AMke39lQj8yg3NwaF3/OJZeB5ZZSTK1xaFEN5PlpcqPt4+/fIYkgR90wp7BZsmL7PZQ2bxl3q4gP2Eg9BxVjCVbS X-Received: by 10.36.64.70 with SMTP id n67mr1204266ita.21.1488323022982; Tue, 28 Feb 2017 15:03:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Tue, 28 Feb 2017 15:03:02 -0800 (PST) In-Reply-To: References: From: Yuchung Cheng Date: Tue, 28 Feb 2017 15:03:02 -0800 Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a1135a57a18fcbf05499f35ae Archived-At: Cc: Abdul Kabbani Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 28 Feb 2017 23:03:46 -0000 --001a1135a57a18fcbf05499f35ae Content-Type: text/plain; charset=UTF-8 The wordings on cwnd adjustment in section 3.3 can be more clear: """ Rather than always halving the congestion window as described in [RFC3168], when the sender receives an indication of congestion (ECE), the sender MUST update cwnd as follows: cwnd = cwnd * (1 - DCTCP.Alpha / 2) Thus, when no sent byte experienced congestion, DCTCP.Alpha equals zero, and cwnd is left unchanged. When all sent bytes experienced congestion, DCTCP.Alpha equals one, and cwnd is reduced by half. Lower levels of congestion will result in correspondingly smaller reductions to cwnd. """ AFAICT DCTCP paper only adjusts cwnd at most every round trip (which is also how Linux implements it). But the text implies the cwnd reduction can happen for every ECE mark? On Tue, Feb 14, 2017 at 8:31 AM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Hi, > > TCPM chairs are not aware of outstanding issues in > draft-ietf-tcpm-dctcp-04 "Datacenter TCP (DCTCP): TCP Congestion Control > for Datacenters". > > Therefore, this e-mail starts a working group last call for > draft-ietf-tcpm-dctcp-04. > > The WGLC runs until Friday March 3. Please send any comments to the TCPM > mailing list by then. Statements supporting the publication of the document > are also helpful. > > We assume that TCPM working group is aware of the IPR disclosure related > to draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.org/ipr/2319/). > A separate note will be sent out to confirm that all IPR has already been > disclosed, in conformance with BCPs 78 and 79. > > The draft is available at https://tools.ietf.org/html/ > draft-ietf-tcpm-dctcp-04 > > Thanks > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a1135a57a18fcbf05499f35ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The wordings on cwnd adjustment in section 3.3 can be more= clear:

"""

Rather than al= ways halving the congestion window as described in

=C2=A0 =C2=A0[= RFC3168], when the sender receives an indication of congestion

= =C2=A0 =C2=A0(ECE), the sender MUST update cwnd as follows:

<= /div>

=C2=A0 =C2=A0 =C2=A0 cwnd =3D cwnd * (1 - DCTCP.Alpha / 2)

<= div>

=C2=A0 =C2=A0Thus, when no sent byte experienced congest= ion, DCTCP.Alpha equals

=C2=A0 =C2=A0zero, and cwnd is left u= nchanged.=C2=A0 When all sent bytes experienced

=C2=A0 =C2=A0cong= estion, DCTCP.Alpha equals one, and cwnd is reduced by half.

=C2= =A0 =C2=A0Lower levels of congestion will result in correspondingly smaller=

=C2=A0 =C2=A0reductions to cwnd.

""&qu= ot;

AFAICT DCTCP paper only adjusts cwnd at most e= very round trip (which is also how Linux implements it). But the text impli= es the cwnd reduction can happen for every ECE mark?

On Tue, Feb 1= 4, 2017 at 8:31 AM, Scharf, Michael (Nokia - DE) <michael.scharf@no= kia.com> wrote:

Hi,

TCPM chairs are not aware of outstanding issues in draft-ietf-tcpm-dctcp-04= "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters"= .

Therefore, this e-mail starts a working group last call for draft-ietf-tcpm= -dctcp-04.

The WGLC runs until Friday March 3. Please send any comments to the TCPM ma= iling list by then. Statements supporting the publication of the document a= re also helpful.

We assume that TCPM working group is aware of the IPR disclosure related to= draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.org/ipr/2319/). A separate note will be sent out to confirm that all IPR = has already been disclosed, in conformance with BCPs 78 and 79.

The draft is available at https://tools.ietf.org= /html/draft-ietf-tcpm-dctcp-04

Thanks

Michael
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a1135a57a18fcbf05499f35ae--