From nobody Sat Oct 1 13:13:06 2016 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 681D612B10D for ; Sat, 1 Oct 2016 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[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=-2.996, 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 2U8p2U4eFOmc for ; Sat, 1 Oct 2016 13:13:02 -0700 (PDT) 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 88E0A12B04E for ; Sat, 1 Oct 2016 13:13:02 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id t83so164620609oie.3 for ; Sat, 01 Oct 2016 13:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+xSUKggMHdYNLQiOL0VDkfbLl/z4ghaHC/6mci9Agtg=; b=VCYviQGx3dohapjN9OLS/MCDvCJb1IZvOJjIU0fzXjffCys9J8/0xk6Gh0xxoRIwql G7DkOjrY6Xtn2Ay1yB7LlI2O9YIEmo/gcZ/dDAQs0t+hPN36QyzrcPJnktHG+zCQD3Au to6HiRgGbWDf3yR5GFZxFZ/1Q0po8vExX476flk6r2h9cJ+A2TZcQwLQqww+PMAIfA9q mF7JAVrtkRDqbj9DrknwOMHQIAPBDInv7uClxF/pFQoSlSWA6fO5kBesvIZduo9Aj3b6 vPH8QuaqV7z/fUq0ADnLf8s1zyJZYwhY7MdMVJtLP4qmFOPBnJe6MoNkRSsxevPFMiDp l2Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+xSUKggMHdYNLQiOL0VDkfbLl/z4ghaHC/6mci9Agtg=; b=WGpCBm4RLnk2Q9uzwiOMGIwi7LuQoAEflIQ65X3CMXwoGqvECwfKzHpHAUkAw7oDfu 9ZRlo/vxUIKZvFTIz9/khmKaWq5X3bGHSAFZ3Ak16OgE9TQqMrSA/goje5AeC5w0LErG D7TeLGkGBX1y6SOLOCwFhgAW2NvUHTVfwRIJqvm1JyVoe38oE4SHP+cAPm9JSt6ZEI08 3fpcykI0e12eLQ8X/ILRonW4+WSm5f66g4D1Nr+xfeiUvKmnoLwPBGk2Gk/gxx2Yodsh I8JqipbeqXTD4yYH+GhC5XZ9MclIolzqmHbHBVuflYnzypbGWsNwvw59sOMFJbTcpt4F Itmg== X-Gm-Message-State: AA6/9Rmwc/a2rf9pPxzSRZkkYQwS4/0sJko8vApxY4HNSK0Y9U3VZ2mvfTOn48vWCCL9XVLZcc35XtlojldvpITC X-Received: by 10.202.5.195 with SMTP id 186mr10944444oif.99.1475352780602; Sat, 01 Oct 2016 13:13:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.182.65 with HTTP; Sat, 1 Oct 2016 13:12:30 -0700 (PDT) In-Reply-To: References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Neal Cardwell Date: Sat, 1 Oct 2016 16:12:30 -0400 Message-ID: To: Lisong Xu Content-Type: multipart/alternative; boundary=94eb2c18d24e687599053dd3566c Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Another question about cubic 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: Sat, 01 Oct 2016 20:13:04 -0000 --94eb2c18d24e687599053dd3566c Content-Type: text/plain; charset=UTF-8 On Fri, Sep 30, 2016 at 11:00 PM, Lisong Xu wrote: > Hi Yuchung, > > A quick clarification about your example "3 packet drops in round trip 1 > plus 6 > packet drops in round trip 2 mean 2 loss events." > > If the 6 packet drops happen during the fast recovery of the 3 packet > drops, TCP stays in the fast recovery until all lost packets are > successfully recovered. In this case (assuming no retransmissions are > lost), ssthresh is reduced only once, and there is only one loss event. > Right? > If we're talking about the Linux implementation, then (sadly) I'm pretty sure the answer is that it depends on the sequence number of the packets lost in the second round. :-) If the losses in the second round are above high_seq (high_seq = snd_nxt at the start of a recovery episode) then tcp_fastretrans_alert() should finish the first recovery event and then start a second recovery event (if tcp_time_to_recover() is true it will fall through to tcp_enter_recovery()). If the losses in the second round (or further rounds) are all below high_seq then when all the holes are filled and snd_una passes high_seq there should be no need for a second recovery event. IMHO this is a tricky problem with many specifications of loss-based congestion control. On the one hand, if consecutive rounds with loss are treated as a single recovery event and do not cut ssthresh again, then a flow could be sending too fast and losing thousands of packets every round, for an unbounded time. On the other hand, if consecutive rounds with loss are *not* treated as a single recovery event, and instead are separate recovery events with consecutive multiplicative reductions of ssthresh, then throughput would quickly collapse into the ground in many situations. So perhaps the Linux TCP stack is striking a reasonable balance in that trade-off. I don't know what other TCP stacks do. neal > > Thanks > Lisong > > > > On 9/30/2016 2:22 PM, Yuchung Cheng wrote: > >> A small suggestion: the loss event may imply one single packet drop. >> But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss >> event, not N loss events. And 3 packet drops in round trip 1 plus 6 >> packet drops in round trip 2 mean 2 loss events. A fast recovery can >> span across many round trips if retransmission is lost again. >> >> It might be worth clarifying that otherwise the (incorrect) >> implementation will be a lot slower. >> >> On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu wrote: >> >>> Thanks, Marcelo! >>> >>> We will revise the draft to more clearly explain the protocol behavior >>> according to your discussion with Joe yesterday. >>> >>> Thanks >>> >>> Lisong >>> >>> >>> >>> On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: >>> >>>> Hi, >>>> >>>> Does cubic assumes that there is a different phase when the connection >>>> starts? i.e. slow start? It may be worthwhile stating this explicitly? >>>> >>>> In the current draft, it always reffers to a packet loss event, but I >>>> couldnt find how is the packet loss detected i.e. via duplicated ACKs >>>> or via >>>> timeout. Is the reaction of cubic the same in both cases? Does it >>>> reduces >>>> the window to 1 MSS and enters in slow start if the loss is detected >>>> via a >>>> timeout? >>>> >>>> Sorry if this is already in the draft and i missed it. >>>> >>>> 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 >>> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --94eb2c18d24e687599053dd3566c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 30, 2016 at 11:00 PM, Lisong Xu <xu@unl.edu> wrote:
Hi Yuchung,

A quick clarification about your example "3 packet drops in round trip= 1 plus 6
packet drops in round trip 2 mean 2 loss events."

 If the 6 packet drops happen during the fast recovery of the 3 packet drops= , TCP stays in the fast recovery until all lost packets are successfully re= covered. In this case (assuming no retransmissions are lost), ssthresh is r= educed only once, and there is only one loss event. Right?
=
If we're talking about the Linux implementation, then (sadly) I'= ;m pretty sure the answer is that it depends on the sequence number of the = packets lost in the second round. :-) If the losses in the second round are= above high_seq (high_seq =3D snd_nxt at the start of a recovery episode) t= hen tcp_fastretrans_alert() should finish the first recovery event and then= start a second recovery event (if tcp_time_to_recover() is true it will fa= ll through to =C2=A0tcp_enter_recovery()). If the losses in the second roun= d (or further rounds) are all below high_seq then when all the holes are fi= lled and snd_una passes high_seq there should be no need for a second recov= ery event.

IMHO this is a tricky problem with many specifications of loss-based c= ongestion control. On the one hand, if consecutive rounds with loss are tre= ated as a single recovery event and do not cut ssthresh again, then a flow = could be sending too fast and losing thousands of packets every round, for = an unbounded time. On the other hand, if consecutive rounds with loss are *= not* treated as a single recovery event, and instead are separate recovery = events with consecutive multiplicative reductions of ssthresh, then through= put would quickly collapse into the ground in many situations.

So perhaps the Lin= ux TCP stack is striking a reasonable balance in that trade-off. I don'= t know what other TCP stacks do.

=
neal

=C2=A0

Thanks
Lisong


On 9/30/2016 2:22 PM, Yuchung Cheng wrote:
A small suggestion: the loss event may imply one single packet drop.
But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss
event, not N loss events. And 3 packet drops in round trip 1 plus 6
packet drops in round trip 2 mean 2 loss events. A fast recovery can
span across many round trips if retransmission is lost again.

It might be worth clarifying that otherwise the (incorrect)
implementation will be a lot slower.

On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu <xu@unl.edu> wrote:
Thanks, Marcelo!

We will revise the draft to more clearly explain the protocol behavior
according to your discussion with Joe yesterday.

Thanks

Lisong



On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote:
Hi,

Does cubic assumes that there is a different phase when the connection
starts? i.e. slow start? It may be worthwhile stating this explicitly?

In the current draft, it always reffers to a packet loss event, but I
couldnt find how is the packet loss detected i.e. via duplicated ACKs or vi= a
timeout. Is the reaction of cubic the same in both cases? Does it reduces the window to 1 MSS and enters in slow start if the loss is detected via a<= br> timeout?

Sorry if this is already in the draft and i missed it.

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

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

--94eb2c18d24e687599053dd3566c-- From nobody Sat Oct 1 15:20:32 2016 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 84B25128E18 for ; Sat, 1 Oct 2016 15:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.797 X-Spam-Level: X-Spam-Status: No, score=-3.797 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, 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 stSpbrCgV0cH for ; Sat, 1 Oct 2016 15:20:28 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 99AE8128874 for ; Sat, 1 Oct 2016 15:20:28 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id j69so88910265itb.0 for ; Sat, 01 Oct 2016 15:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xpJXljuRT8xrip/Xkc7LThTqRhUFU/cbHRw6ckpBVsU=; b=p035e5X/hQaHVYGHZF7VPcz9iyWl2ntk5ykt+4MSEIrYHIBxhfs/n4RBp2zOnzJ4kd gK3uYispJBbNrpkW7jP0czpAs/wKV4RqUZ0kt9goHv+cvetq945PTSyAB/FR19G23bB9 78teIrhI8J9cNV9mr2DZZc7AS5iXCTcxAc8HotnGbtdFF9qT1yqYNlE11rmDd2XOWJAZ JcvqWxDyNJfQqlEvyOkTO+018MRZ9JTDyM9fstQjNID2aUR/jMSMV9E0vbyAZHeJNKIb 9/Z8Y6PZYTLD+Dxt0XN7zh1SMOGtXQpxbGhLF3WqX1PTzYM+jOqxtczoDqJzj6A+qGdA JD3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xpJXljuRT8xrip/Xkc7LThTqRhUFU/cbHRw6ckpBVsU=; b=j6fj+xg61Jv/LRjNnu5fYRKetxag78p7EJrUDKpsJuPPjvdTiTz0AW9eno4EFrVppr IxXQDrZaCL8PFtGuS7iWCrDp8ELb7Y9ad5P7FbHMNcm3hyewyXgAaYJcGrTnqCDz7uSi JrR4A5RxCb39l5MWIEO7cF8WxJdKdjCRQijsMG/OH3Je79TM+GgB6fvdExf0judtJFiT 9G2W44mMVSnIi/9t/pS8yT2rRR+OUhvhkGCGyLNHK1HfLj/TMFc4hSBM9CrB+D6CODKi 3hDJkkXQnRp0KUISjykR7ABNk9UYvfKKlc/z8v+yFT8hXt8/HIqFSM9njHEwwaUpHZVf 4qsw== X-Gm-Message-State: AA6/9RlRyRjsHWZc3ZxnNjUEDLHB4KFf0qUVdp8c1qLz2jRrZTJfvtSCClJfs1ZkRHJYRkpwc+4mGPSIxVzPtS5R X-Received: by 10.36.185.30 with SMTP id w30mr3013696ite.97.1475360427673; Sat, 01 Oct 2016 15:20:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Sat, 1 Oct 2016 15:19:47 -0700 (PDT) In-Reply-To: References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Yuchung Cheng Date: Sat, 1 Oct 2016 15:19:47 -0700 Message-ID: To: Neal Cardwell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Another question about cubic 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: Sat, 01 Oct 2016 22:20:30 -0000 Thanks Neal on the detail of the Linux's approach, here is the standard way: RFC5681, end of section 4. ""Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case." If I understand the Cubic design correctly, the loss of a retransmission in subsequent rounds during fast recovery, should be treated as additional loss events, because its design does not have recovery state or open state. This matches the current draft as well. On Sat, Oct 1, 2016 at 1:12 PM, Neal Cardwell wrote: > On Fri, Sep 30, 2016 at 11:00 PM, Lisong Xu wrote: >> >> Hi Yuchung, >> >> A quick clarification about your example "3 packet drops in round trip 1 >> plus 6 >> packet drops in round trip 2 mean 2 loss events." >> >> If the 6 packet drops happen during the fast recovery of the 3 packet >> drops, TCP stays in the fast recovery until all lost packets are >> successfully recovered. In this case (assuming no retransmissions are lost), >> ssthresh is reduced only once, and there is only one loss event. Right? > > > If we're talking about the Linux implementation, then (sadly) I'm pretty > sure the answer is that it depends on the sequence number of the packets > lost in the second round. :-) If the losses in the second round are above > high_seq (high_seq = snd_nxt at the start of a recovery episode) then > tcp_fastretrans_alert() should finish the first recovery event and then > start a second recovery event (if tcp_time_to_recover() is true it will fall > through to tcp_enter_recovery()). If the losses in the second round (or > further rounds) are all below high_seq then when all the holes are filled > and snd_una passes high_seq there should be no need for a second recovery > event. > > IMHO this is a tricky problem with many specifications of loss-based > congestion control. On the one hand, if consecutive rounds with loss are > treated as a single recovery event and do not cut ssthresh again, then a > flow could be sending too fast and losing thousands of packets every round, > for an unbounded time. On the other hand, if consecutive rounds with loss > are *not* treated as a single recovery event, and instead are separate > recovery events with consecutive multiplicative reductions of ssthresh, then > throughput would quickly collapse into the ground in many situations. > > So perhaps the Linux TCP stack is striking a reasonable balance in that > trade-off. I don't know what other TCP stacks do. > > neal > > >> >> >> Thanks >> Lisong >> >> >> >> On 9/30/2016 2:22 PM, Yuchung Cheng wrote: >>> >>> A small suggestion: the loss event may imply one single packet drop. >>> But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss >>> event, not N loss events. And 3 packet drops in round trip 1 plus 6 >>> packet drops in round trip 2 mean 2 loss events. A fast recovery can >>> span across many round trips if retransmission is lost again. >>> >>> It might be worth clarifying that otherwise the (incorrect) >>> implementation will be a lot slower. >>> >>> On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu wrote: >>>> >>>> Thanks, Marcelo! >>>> >>>> We will revise the draft to more clearly explain the protocol behavior >>>> according to your discussion with Joe yesterday. >>>> >>>> Thanks >>>> >>>> Lisong >>>> >>>> >>>> >>>> On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: >>>>> >>>>> Hi, >>>>> >>>>> Does cubic assumes that there is a different phase when the connection >>>>> starts? i.e. slow start? It may be worthwhile stating this explicitly? >>>>> >>>>> In the current draft, it always reffers to a packet loss event, but I >>>>> couldnt find how is the packet loss detected i.e. via duplicated ACKs >>>>> or via >>>>> timeout. Is the reaction of cubic the same in both cases? Does it >>>>> reduces >>>>> the window to 1 MSS and enters in slow start if the loss is detected >>>>> via a >>>>> timeout? >>>>> >>>>> Sorry if this is already in the draft and i missed it. >>>>> >>>>> 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 >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Sun Oct 2 09:21:41 2016 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 5E57C126D74 for ; Sun, 2 Oct 2016 09:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, 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 5CF_Yx_ioqrA for ; Sun, 2 Oct 2016 09:21:38 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 7E3CC124281 for ; Sun, 2 Oct 2016 09:21:38 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id i202so20092769ioi.2 for ; Sun, 02 Oct 2016 09:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=92xbhJBn52nmHAbJLg9TS35TVHr7C8pHmPmkZ+3/7zc=; b=CgD66s8ECOsANE1pJDdZmkoLzY7jZc53fx17ECAqjVEo5qJIHFLz4bFhLNZtL5nuwh 7v6PJqjFOckIEcclwU3lKy3Xu+LMbybiMmApw+x6CQM/y7POplqJ/aZtq6Zh4BBHYHkH cyNiNXHKLv7uv2pFKDoeEXEV6LprS+eX146tEpbNrulQrx1SoFx3kBehpvx1BWXd9QH0 sg5veC2pAjj4L12LYvtRmpr/ElAZqtuTH+Kff86JBv3S/cFTtGr/WUDk3ly41TW0wB6E VIqq5aiIJi7bFNytMjIHk3opAAcxnGnN646DBw77KL6faReYCR4m5CoF3wOoOrP3Glew DbkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=92xbhJBn52nmHAbJLg9TS35TVHr7C8pHmPmkZ+3/7zc=; b=N+i2OXbcybqNM3Mp2+GMe/wAkkDZIyDl430bVftxg7FMRTDLVQvxtptlHofJQHfj1m ae8RO+bZf5bPt2AddIpA2ph/w50DK0ISq56/BnWugqXFcuaVIUYEw3ZuAQAmTxj3mVN8 t7QvJb0DzUXkdKC+cfhHByxE0a0BZ1E++3cvNVtzbyJNnLs74h5wIQGjMGmPTts4h/PU q7TZJ4ftNmLolE2ltD7LcirHoosJAg3RFuh5iG1OBurv01UJDwQKRNZTf15RMuoJ3xRb GDZIjvaL5/pnp90BBxPveaanuozmWXTWUE4Cb6uWNXfSGZYMPEAld4onDcpdqjPbIIgu 26cQ== X-Gm-Message-State: AA6/9RkBNGIRiOWB9Pf1WFrM4nV/qvHEuJMeo3H6yWEkldtOMCMGQlWeRQptJJIvnVMw3pO1f0/xZYzHgiCB3gtl X-Received: by 10.107.10.201 with SMTP id 70mr5763318iok.165.1475425297583; Sun, 02 Oct 2016 09:21:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Sun, 2 Oct 2016 09:20:56 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Sun, 2 Oct 2016 09:20:56 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] comments for draft-ietf-tcpm-rack-00.txt 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: Sun, 02 Oct 2016 16:21:40 -0000 On Sat, Oct 1, 2016 at 3:53 PM, Yuchung Cheng wrote: > On Fri, Sep 30, 2016 at 12:20 AM, Yoshifumi Nishida > wrote: >> Hello, >> >> Thanks for an interesting proposal. >> I've read the draft-ietf-tcpm-rack-00.txt and have the following comments on >> the draft. >> Please point out if I miss something. >> >> 1: I think the draft should mention how to control pipe size during loss >> recovery. >> When RACK identifies lost packets, how it reduces cwnd? > If RACK marks a packet lost, the pipe is reduced by 1. > > RACK does not change cwnd at all. It's congestion control's job. We > intentionally want to decouple loss detection (what to send) from > congestion control (how fast to send). But this is certainly worth > clarifying more. > >> >> 2: Similar to 1:, doesn't RACK have a certain back-off mechanism? I couldn't >> find it in the draft. >> It is nice that it can find the lost of retransmitted packets, but does >> it retransmits them again with the same settings? >> It seems to me that RACK might become aggressive under heavy congestions >> as it keeps retransmitting packets with short intervals while other TCPs >> wait for RTO. > The concern of RACK interaction with current CC is valid. But again > RACK only detects losses. The congestion control decides how fast to > retransmit these packets under heavy or other congestion conditions. > If the retransmission is too aggressive, C.C. is to blame. > > In reality, this has been true with Cubic-PRR under policers. Without > RACK, Cubic used to timeout a lot under policer by failing to detect > loss retransmission. With RACK, it detects them quickly and that > exposes PRR is too aggressive. I've briefly mentioned this in RACK > presentation in tcpm of 94 meeting. I have signed up another talk in > next maprg to detail this issue. > >> >> 3: I am not very sure if using the minimum value in all RTT measurements for >> RACK.min_RTT is a really good option. >> If RTT is significantly increased all of sudden, it might cause lots of >> spurious retransmits unless reordering window is dynamically adjusted. > Many people have expressed the same concern. I am re-evaluating this part. > > But we chose of min RTT for a reason (which was not clear in the > draft): with default loss-based CC + buffer-bloat, the current RTT > when loss occurs can be 10x-100x (no kidding) of the min-RTT. For > example, if the min-RTT is only 10ms (e.g., for many CDN caches placed > inside ISPs), arming a reordering timer of 1000/4 = 250ms makes little > sense, because the reordering is not tied to the present bottleneck > queue status, but often the underlying link (wireless). > > That's said, min_RTT has issues too. > >> >> 4: It is a bit confusing to me that the abstract says "modern TCP >> implementations that can support per-packet timestamps.." because I thought >> it was referring timestamp option. But, RACK actually doesn't rely on it. I >> might prefer to say something like keep tracking transmit time per packet. > Sure, we can reword to per packet transmit time and explicitly clarify > this is NOT TCP timestamp options. > >> >> 5: I guess you might want to add explanations of "RACK packet" and >> "RACK.ack_ts" in Section 4. I think their definitions are not very clear. > Sorry about that. How about: > > > "Packet.xmit_ts" refers to the transmission time of some data > sequences sent by a TCP data segment. If the sequences have been > retransmitted multiple times, it is the latest transmission. The > sender needs to keep track of Packet.xmit_ts of all unacknowledged > data sequences. The time granularity must be at least millisecond. > > "RACK.xmit_ts" refers to the highest (i.e., most recent) > Packet.xmit_ts being tracked currently. > > > > >> >> Thanks, >> -- >> Yoshi >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From nobody Mon Oct 3 09:56:18 2016 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 634F012940E for ; Mon, 3 Oct 2016 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham 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 9R1FMooR3dM3 for ; Mon, 3 Oct 2016 09:56:15 -0700 (PDT) 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 C32F4129405 for ; Mon, 3 Oct 2016 09:56:14 -0700 (PDT) Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 65EFA2A0D93 for ; Tue, 4 Oct 2016 01:56:12 +0900 (JST) Received: by mail-ua0-f180.google.com with SMTP id n13so155694646uaa.3 for ; Mon, 03 Oct 2016 09:56:12 -0700 (PDT) X-Gm-Message-State: AA6/9RndrHRP8iS4xr7zFFyo7suXMnGf89pu2lEVpf5WNKEBhXtp+X/IPyouqIJ4li/haTDEJhCOr7RlQbTZSg== X-Received: by 10.176.3.231 with SMTP id 94mr14543518uau.16.1475513771056; Mon, 03 Oct 2016 09:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.7 with HTTP; Mon, 3 Oct 2016 09:56:10 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Mon, 3 Oct 2016 09:56:10 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yuchung Cheng Content-Type: multipart/alternative; boundary=94eb2c0568022f6a2d053df8d2e2 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] comments for draft-ietf-tcpm-rack-00.txt 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, 03 Oct 2016 16:56:17 -0000 --94eb2c0568022f6a2d053df8d2e2 Content-Type: text/plain; charset=UTF-8 Hi Yuchung, Thanks for the comments. On Sun, Oct 2, 2016 at 9:20 AM, Yuchung Cheng wrote: > On Sat, Oct 1, 2016 at 3:53 PM, Yuchung Cheng wrote: > > On Fri, Sep 30, 2016 at 12:20 AM, Yoshifumi Nishida > > wrote: > >> Hello, > >> > >> Thanks for an interesting proposal. > >> I've read the draft-ietf-tcpm-rack-00.txt and have the following > comments on > >> the draft. > >> Please point out if I miss something. > >> > >> 1: I think the draft should mention how to control pipe size during loss > >> recovery. > >> When RACK identifies lost packets, how it reduces cwnd? > > If RACK marks a packet lost, the pipe is reduced by 1. > > > > RACK does not change cwnd at all. It's congestion control's job. We > > intentionally want to decouple loss detection (what to send) from > > congestion control (how fast to send). But this is certainly worth > > clarifying more. > Yes, while decoupling CC is fine, I think it would be good to see some clarifications. I guess you already have some recommended CC for RACK (and it's probably not RFC5681) >> 2: Similar to 1:, doesn't RACK have a certain back-off mechanism? I > couldn't > >> find it in the draft. > >> It is nice that it can find the lost of retransmitted packets, but > does > >> it retransmits them again with the same settings? > >> It seems to me that RACK might become aggressive under heavy > congestions > >> as it keeps retransmitting packets with short intervals while other TCPs > >> wait for RTO. > > The concern of RACK interaction with current CC is valid. But again > > RACK only detects losses. The congestion control decides how fast to > > retransmit these packets under heavy or other congestion conditions. > > If the retransmission is too aggressive, C.C. is to blame. > OK. I see the point. But, this seems to say that we'll need to find a proper CC for RACK. > > In reality, this has been true with Cubic-PRR under policers. Without > > RACK, Cubic used to timeout a lot under policer by failing to detect > > loss retransmission. With RACK, it detects them quickly and that > > exposes PRR is too aggressive. I've briefly mentioned this in RACK > > presentation in tcpm of 94 meeting. I have signed up another talk in > > next maprg to detail this issue. > >> > >> 3: I am not very sure if using the minimum value in all RTT > measurements for > >> RACK.min_RTT is a really good option. > >> If RTT is significantly increased all of sudden, it might cause > lots of > >> spurious retransmits unless reordering window is dynamically adjusted. > > Many people have expressed the same concern. I am re-evaluating this > part. > > > > But we chose of min RTT for a reason (which was not clear in the > > draft): with default loss-based CC + buffer-bloat, the current RTT > > when loss occurs can be 10x-100x (no kidding) of the min-RTT. For > > example, if the min-RTT is only 10ms (e.g., for many CDN caches placed > > inside ISPs), arming a reordering timer of 1000/4 = 250ms makes little > > sense, because the reordering is not tied to the present bottleneck > > queue status, but often the underlying link (wireless). > > > > That's said, min_RTT has issues too. > > > >> > >> 4: It is a bit confusing to me that the abstract says "modern TCP > >> implementations that can support per-packet timestamps.." because I > thought > >> it was referring timestamp option. But, RACK actually doesn't rely on > it. I > >> might prefer to say something like keep tracking transmit time per > packet. > > Sure, we can reword to per packet transmit time and explicitly clarify > > this is NOT TCP timestamp options. > Thanks! >> > >> 5: I guess you might want to add explanations of "RACK packet" and > >> "RACK.ack_ts" in Section 4. I think their definitions are not very > clear. > > Sorry about that. How about: > > > > > > "Packet.xmit_ts" refers to the transmission time of some data > > sequences sent by a TCP data segment. If the sequences have been > > retransmitted multiple times, it is the latest transmission. The > > sender needs to keep track of Packet.xmit_ts of all unacknowledged > > data sequences. The time granularity must be at least millisecond. > > > > "RACK.xmit_ts" refers to the highest (i.e., most recent) > > Packet.xmit_ts being tracked currently. > Yes, I think this is clear. What I meant was the draft doesn't have concrete definitions of RACK packet and RACK.ack_ts, while they are used in the logics in Section 5.2. I can infer them, though. -- Yoshi --94eb2c0568022f6a2d053df8d2e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yuchung,

Thanks for the comments.

On Sun, Oct 2, 2= 016 at 9:20 AM, Yuchung Cheng <ycheng@google.com> wrote:
=
On Sat,= Oct 1, 2016 at 3:53 PM, Yuchung Cheng <ycheng@google.com> wrote:
> On Fri, Sep = 30, 2016 at 12:20 AM, Yoshifumi Nishida
> <nishid= a@sfc.wide.ad.jp> wrote:
>> Hello,
>>
>> Thanks for an interesting proposal.
>> I've read the draft-ietf-tcpm-rack-00.txt and have the followi= ng comments on
>> the draft.
>> Please point out if I miss something.
>>
>> 1: I think the draft should mention how to control pipe size durin= g loss
>> recovery.
>>=C2=A0 =C2=A0 =C2=A0When RACK identifies lost packets, how it reduc= es cwnd?
> If RACK marks a packet lost, the pipe is reduced by 1.
>
> RACK does not change cwnd at all. It's congestion control's jo= b. We
> intentionally want to decouple loss detection (what to send) from
> congestion control (how fast to send). But this is certainly worth
> clarifying more.

Yes, = while decoupling CC is fine, I think it would be good to see some clarifica= tions.
I guess you already have some recommended CC for RACK (and= it's probably not RFC5681)

>> 2: Similar to 1:, doesn't RACK have a certain back-off mechani= sm? I couldn't
>> find it in the draft.
>>=C2=A0 =C2=A0 =C2=A0It is nice that it can find the lost of retrans= mitted packets, but does
>> it retransmits them again with the same settings?
>>=C2=A0 =C2=A0 =C2=A0It seems to me that RACK might become aggressiv= e under heavy congestions
>> as it keeps retransmitting packets with short intervals while othe= r TCPs
>> wait for RTO.
> The concern of RACK interaction with current CC is valid. But again > RACK only detects losses. The congestion control decides how fast to > retransmit these packets under heavy or other congestion conditions. > If the retransmission is too aggressive, C.C. is to blame.

OK. I see the point.=C2=A0
B= ut, this seems to say that we'll need to find a proper CC for RACK.
=C2=A0
> In reality, this has been true with Cubic-PRR under policers. Without<= br> > RACK, Cubic used to timeout a lot under policer by failing to detect > loss retransmission. With RACK, it detects them quickly and that
> exposes PRR is too aggressive. I've briefly mentioned this in RACK=
> presentation in tcpm of 94 meeting. I have signed up another talk in > next maprg to detail this issue.
>>
>> 3: I am not very sure if using the minimum value in all RTT measur= ements for
>> RACK.min_RTT is a really good option.
>>=C2=A0 =C2=A0 =C2=A0If RTT is significantly increased all of sudden= , it might cause lots of
>> spurious retransmits unless reordering window is dynamically adjus= ted.
> Many people have expressed the same concern. I am re-evaluating this p= art.
>
> But we chose of min RTT for a reason (which was not clear in the
> draft): with default loss-based CC + buffer-bloat, the current RTT
> when loss occurs can be 10x-100x (no kidding) of the min-RTT. For
> example, if the min-RTT is only 10ms (e.g., for many CDN caches placed=
> inside ISPs), arming a reordering timer of 1000/4 =3D 250ms makes litt= le
> sense, because the reordering is not tied to the present bottleneck > queue status, but often the underlying link (wireless).
>
> That's said, min_RTT has issues too.
>
>>
>> 4: It is a bit confusing to me that the abstract says "modern= TCP
>> implementations that can support per-packet timestamps.." bec= ause I thought
>> it was referring timestamp option. But, RACK actually doesn't = rely on it. I
>> might prefer to say something like keep tracking transmit time per= packet.
> Sure, we can reword to per packet transmit time and explicitly clarify=
> this is NOT TCP timestamp options.
Thanks!

>>
>> 5: I guess you might want to add explanations of "RACK packet= " and
>> "RACK.ack_ts" in Section 4. I think their definitions ar= e not very clear.
> Sorry about that. How about:
>
>
>=C2=A0 =C2=A0 "Packet.xmit_ts" refers to the transmission tim= e of some data
> sequences sent by a TCP data segment. If the sequences have been
> retransmitted multiple times, it is the latest transmission. The
> sender needs to keep track of Packet.xmit_ts of all unacknowledged
> data sequences. The time granularity must be at least millisecond.
>
>=C2=A0 =C2=A0 "RACK.xmit_ts" refers to the highest (i.e., mos= t recent)
> Packet.xmit_ts being tracked currently.

Yes, I think this is clear. What I meant was the draft do= esn't have concrete definitions of RACK packet and RACK.ack_ts, while t= hey are used in the logics in Section 5.2. I can infer them, though.
<= div>=C2=A0
--
Yoshi
--94eb2c0568022f6a2d053df8d2e2-- From nobody Mon Oct 3 12:16:28 2016 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 AADB81294B7; Mon, 3 Oct 2016 12:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.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 PX4PdFStGY8T; Mon, 3 Oct 2016 12:16:26 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0050.outbound.protection.outlook.com [216.32.180.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1748129484; Mon, 3 Oct 2016 12:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1/ATawhdZaKTeVfQyNmOM+OEN2x6AzMhSOplDVvCCs0=; b=yhqe5u7dC7hJ5vWdpi2AMrHBF0lf+cmi/tWCRGaQgT35Gywb+x3erY8v8mBOG0xN2bnRANmWfm6aRhZjLHvhtH0hPce70cUQwkbJ6foBFfk1pSi0UqxaOt2X7aySHrBH/jBW4eDC+ztCUZkgi4syLg7tWgursvofIZhzrsWom2w= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.143.19] (129.93.4.25) by DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.619.10; Mon, 3 Oct 2016 19:16:24 +0000 To: Neal Cardwell , Yuchung Cheng References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <8372fd13-f3b2-d8e6-c61d-c66fd5e8803f@unl.edu> Date: Mon, 3 Oct 2016 14:16:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C338AA9CEC7B7937C002A50D" X-Originating-IP: [129.93.4.25] X-ClientProxiedBy: DM2PR21CA0014.namprd21.prod.outlook.com (10.161.137.152) To DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) X-MS-Office365-Filtering-Correlation-Id: c5d45fa9-f027-4d0b-0079-08d3ebc1c49a X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 2:64bSjt88LDxIJXaSxojOZht2qug4BIpYCDdo8Aooz6HlIpVNRDZ4T7pfQ7umW+FBr5xJB/0N0c0joenDTzHkBbLgcSsNxDzbcX8b+G6Wi2he+X3vV/DeodfJ3KXcq33XEon/mXcS81X+ozmf6yiIhP3f43pp/E9GAgQgoPsVx/c9lV0kNsxHePpqqsGCQLdW; 3:rOQNKWX3qifdpFOmQ/9x0zft0gpcmxlcEWALE0tdZrVrxhBLT7pcpzX4UjVwDQXZwJvKYb9/dVWwbOW9HfSKBL7iG66+yijuBHHCCWvfk8KHoMQYHo1G5pD8sbaC8eIh X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR08MB2522; 25:eiDhnp2qVUF3RvCNWn+uMzSs5hqlmbntoE+31UPIo?= =?us-ascii?Q?UKpk7BGeCS4Y1sefXNDbH+2CQoQtnlHRRi7pEpasVd5+CmrNWqmcqbPhyuQE?= =?us-ascii?Q?pNW5NGcNxxWVVUTdz5op0iYkjWkNvWqLk/1b7EX7hO8APqesFEZkCZyBwUeo?= =?us-ascii?Q?VFw8z7aQOLT0NNXoG7ZDGAD6gHT524GU2PrbF0ekJfc4UUHVwjjfMDcgoyqr?= =?us-ascii?Q?d1WrkVrqIl80km0y+7OXhwbeJoqL+yLUmTkbrsmMZlB92MNJWtfcDhD6tNMD?= =?us-ascii?Q?tO6au2OHFIsYwuqB8zYltdQgFUqHrjOPPIo23PFSSIXK7JQ+urVxYBlSG9sV?= =?us-ascii?Q?e42EEGMd5YMnsMuADLFyjoLqnhWTMRx3Nu5378E2m/ySX9+Rpd2Ky4R6twBP?= =?us-ascii?Q?fGVnvkoIVnWrJJyuCYRxmg67sSjQFpO23gVmHC0g1odNsqDUs7uJTvuOE61D?= =?us-ascii?Q?cmgBvseCMJOt2JAgyP+NOavt14IgGzehiuvsYtNzqk3RPJrjMPF37NW130kM?= =?us-ascii?Q?/dOCunccQEu4ZExoOjxKvabQvNu9Cz4SmBwiyqKnIUgpHi+iXMtWEEVGQ50f?= =?us-ascii?Q?VnUcQqMie0NbYN3zoHW79dCbVWL2rZi48mcPo/wOVrEocwavbnhVQOH1W+Mv?= =?us-ascii?Q?Wl7lxciFSV9/fTrK5J0YKNslg3Y5DuEp1zNFa4DG0XWcykV6AVucM2eofO0x?= =?us-ascii?Q?34Qlzfdp4slD+wmL6nTfS1r6Au/87YxhV9MuseYyO/8LGEmssDCYHj3+w9ql?= =?us-ascii?Q?k6pXEaQksA1YSYTZJQnT8w0h1BH5b1Kpr6IzjvI2nqZRar0+QG8ut4QpYm+5?= =?us-ascii?Q?hdWGxk1wL1Nqpa4isUx7YEd7tc710gjD66s9t9gZB/cXkqKVbPfDj9kyQBMJ?= =?us-ascii?Q?3AutRowYhMonzhlLDKRAs00iI1GYPon2bj28UpIps//MRrzXkBfOB1HiuJzj?= =?us-ascii?Q?piW6aLNKN3XWHudh9OAj8zidBMJT6hVNF1ayfV+NKs3XlHvzdlkR8mv+0j5i?= =?us-ascii?Q?+M=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 31:iSJsNpzOP3xF2nL9CGBsrbE6TcrzMO/6amTPU3OwHysyLYWYBC0qnC4U80kgwSyWsJgcUaEHvzu0lsDKsN/KwDVRcV43yNDZ07mG01KxxuP+FYo1ZoR0jL4XSSrtqoD1Yx5SiapzCdgFGMHemY8+JTDnmPwQoyzkwdgJB7vDR1aZruuShh5huHjbRhdvnrEyfEgJII8G3Brvdkkz2SJYMXjfwVe5VfM7vf+5o7lQpLI=; 20:bxen+wv4srmlw9EQMJkSK8lSsnuu2WlGyQKf/gSKHQ4yUyIW/UT6+IB5ifHnEndRv+H9nSeoNKn0kLF9MMvughvRngXLw10kpMr0+A3iZfvLbXwuxrsvIUJisGhpZM13TvhtQftqqBSp6ed0Wr0mxd/zTYpqITH4yx9sYjGPi5o2DYSYGdMIy6ERsN9lXE9a49/BuodFU5662HkCnneIOoLFf/nnxiChruovYPqF1MM2ckVivbchO195LMqL3FdLKtCbZmCA305XvWcb6AV+h1tXJaHmlccJjQ8Hxl3/PeD6a9S9ew3lddsVV9VkaNn8XR63lef7slHf1+y3yRWg4aexCOg5bdGRvUVxiKgVadMDadYEuu6sabbUX0eRnUasCcuFZyynkXVSOlpUTJKpsvd5cqw7+l7fLPJQBMtSnZdpOrQFquReTNaNR1vulLnxacWgVjBfkeXmAhJ/DVQ0rIP8ckWJuBrXK4hhtudJ043h/wvkS66q24Io7eXIJgXw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM5PR08MB2522; BCL:0; PCL:0; RULEID:; SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 4:rt6vlgnwf44sx1HF/6KT/McydrNu74LAJQybVb38bMkeW2AYGWYO4U2FVicDk/8ZThW6pFVSBonFGjijtevCkaRWzlCzYnjvxvjXNEvT/AWtlqAilx7l4R27l7ZN/kNZOLeGFr+CSMF05XD4LSJZcYeA1aUir9FHNxSD0pGRrT5Y1I6qlX1H1md+L/CNfbnYEBOD/HbmgLCYJtmdTdcXz1kY8RnmRT/L3FMDF9j/z4oLhxrB+TuPHeeXYWirB9ymPE+0Tqzi8uicIBNqSvObL8GKbzUNEJNrGoGYxq8C0XjzkCc12mOPWYlj4XKVXa1Jjefe/in/EadGjqCIDlXaRplMBY74uExXT6PN3wWpp561FKGgCxB1PyP6r1UsCrnNeifNfNKBXl1gjfcVozrmCw== X-Forefront-PRVS: 008421A8FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(377454003)(189002)(24454002)(199003)(65956001)(8676002)(270700001)(97736004)(84326002)(15975445007)(19617315012)(2906002)(93886004)(86362001)(77096005)(68736007)(7906003)(31696002)(66066001)(42186005)(81156014)(33646002)(31686004)(4326007)(65806001)(81166006)(75432002)(105586002)(16236675004)(88552002)(92566002)(19580405001)(512874002)(76176999)(5660300001)(90282001)(189998001)(2950100002)(4001350100001)(5001770100001)(101416001)(6116002)(50986999)(3846002)(7736002)(19580395003)(89122001)(54356999)(65826007)(7846002)(64126003)(586003)(106356001)(36756003)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB2522; H:[10.211.143.19]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR08MB2522; 23:G3zd9VEX83z61NlX1goxz9aVjb6+uR5LjDfqoTNWZ?= =?us-ascii?Q?0rAJ6QdLKc4ANXjV1vxVk/bivkXk6buH6NUKX+9u9+uXLAROKc4AmYIaFZVu?= =?us-ascii?Q?pDhSlUHtlBeYGoLvRVNEZO0XDFsKY/twbWJgW0hmY09M8hGdWWEivY5fZxwl?= =?us-ascii?Q?fQL9He7X7DAR0+/VPp3uA/I9R122ln9zceiKLukVxXoio8GEB3CGqFIFLdr4?= =?us-ascii?Q?wHef03N7ccEsuW8chtHFjB0zmKdhGmW2CL2KGvdZRrsfxzCmaEeLg2OTRtnU?= =?us-ascii?Q?S5AqMWKzYIsXzxf2zuC71EzV916J6D8Wj8DHjUS7iWBtwwOsl2gGQZyL7DpF?= =?us-ascii?Q?K7G2ikvDCX426PZzaBuJnMITpHQe/fiRU2kU+MIF5X2OL/Ej5UcrhckglC1B?= =?us-ascii?Q?gZol4CxRQiEBWl8x9by5Gkp97Y71fnSkTMqxvyaqNNmHOmr0ZlewfZ2MwEeY?= =?us-ascii?Q?p9UnBlGZrJlR6/UWL+wossOpQxWtlT77k0Uie8AeIovWb1NNWIeb7yDpgope?= =?us-ascii?Q?mJIKarMh2caYKMcJ7o8+GR2ywHcR4Zo1Ojf2p9/1wQqFsJyfmnlp0W+mQvCG?= =?us-ascii?Q?nwHtDPg6ATcaX/7H06oWBMHSxOaygWkcTQ2f5ibZAHrxucVt50brCOD9PE16?= =?us-ascii?Q?W3mXd+zuUBeT3++yGk43LUYXEpmUCGJx4YsSHjfHmH32e3CJ1zweugNiZ5J+?= =?us-ascii?Q?L4P3eL0bqfWergF8unWvIGVQ8i/6Y9M+sGIYkRkUdWLmpF3TEiNVWMZLUVK3?= =?us-ascii?Q?bLADy4URdr3fyA67gYDV6xiHnyB5Rt1Q+kWphuwtfyg2YVyedNxh77w/Em9Y?= =?us-ascii?Q?oXr+eTTWYgxgP29IbXptNM0/Ugy2k0ByGcykOvO9GT6CE49RY5LBaEw9nyRP?= =?us-ascii?Q?O7cgTkroY8flLk43wJjSh3YS0LQkgW/Wc4bp7XzRVfac19rTvPJ01sG4MVO/?= =?us-ascii?Q?9tjfKkadv5gIv1TudIUF8RgHyWfIsERMJbuQ35CHFLrkqJykSXjBc8w1TmTT?= =?us-ascii?Q?vFdcJs2FiGJ9VXHZYMJ1tNzqUTHf0opDRbXN24kUCgFErq3P3vQCgWDHt7HE?= =?us-ascii?Q?1/AzSersRh5t0x2oB+IRXBKCLd6y19Fb8/RPY09hsC3ax4Paxq6OMeeY73U3?= =?us-ascii?Q?TLPSyjpS4XIR2duTjGwZej2e7VaPRzl5OUcDZMtS1c2KhKsJf3LHYWE/0vRI?= =?us-ascii?Q?Q674EHzg486Ic03tJWTpEO1gcod1uobqRkfHcHRK3E4UdEjE2Ioc5i661bYf?= =?us-ascii?Q?XtSvCOnGlwTmWEY/isaWW1Fe6LmEsUtieV4mFCW+qq5qMYaqnm9GjfRCoBrw?= =?us-ascii?Q?B9Jxk5+wjqfOiPTqv2ASC17r+zGmJzuaj1UWwLx8kpwZpjLriQ2PFYqTXQrx?= =?us-ascii?Q?DYquWVMgztteqP8oWGN/3YpHyDvYxiJPNUaqBsoKy/L3fWmgGYuj03NW/XNk?= =?us-ascii?Q?GguVDefkExTse70c6K+R/ehUK3K28U=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 6:IjIHcWdrOXd5SLCOZq9wmaYxFY0VKf1mOCROsNLsKADFbjErrhq5zLRekdiBB/hd84ffqhEZe5JtSZen1ps8elToPiHjzy8unc9SkHforjGsStLOqG1lBRz0hfK19HNTpF+X7rpfnTzoivBvM3TjP7/vgNzaG3ry04aTYfUj6vgYBDDmQsqvhUt7QLzLz1fC7ThOp0UwiOXUDuV0ZozQ8xSKwmKSll16kUW5t7mi69mNtWGsaGSBkowp91udJ26bVu5OzaQQBLkh/OWi20UBN2tmfouGxwtXuZwsRcx5UW4=; 5:AnoElZiHq9AUbw842Qe5JOLPCU6XdsOWPQfM9sxal5a0NGsyH/GrfIb3de4/cAd7pA55wL25rryaaa4D4lo+PvyxXMbxMvU63DHwmquSNvl7hcJyodYk20kkd4iTX/v3OpOgZajm0do86cAMHz+sRQ==; 24:2VpDZfYN78Tqnpjlln7HZKK4bnes6BDs9TXiU4kQrENWeLCKITP3GVLfBx8KxjLI4kxeFmi6v+O/AJm2B/V+YCiZg4TexWawjKfr2vDEsT0=; 7:HC6QsA6j7oaYiqmuPPhqXn5lN4EozTUcqYyOItBI4LPRvOtyt5sAfF6D9M1vVOtopWG8HYzgvLV1rDts4BNwSk7+x0grkGCnjhsjidzZpMiBFw/Vx/q4OQ7lIxGRjiaP/ss6BPw2uVSx1p/YwDDG16JMlz/71csmEematv7RuOHroktzuJSMLJyqQTl6ZSp9FkFcxz0sM32EVRCr3WJ4R1lKaftxS6rjwbyrCA8SlCjS+NzRAAoSbi1r7uLlp8JMJfXJDyP6QLo4IssjUJll+rvQCW4gPNkvLn7mA06sF8Ab636TYQsL5vAz6u/7yMEY SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2016 19:16:24.4570 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2522 Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Another question about cubic 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, 03 Oct 2016 19:16:27 -0000 --------------C338AA9CEC7B7937C002A50D Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Thanks, Neal and Yuchung. Lisong On 10/1/2016 3:12 PM, Neal Cardwell wrote: > On Fri, Sep 30, 2016 at 11:00 PM, Lisong Xu > wrote: > > Hi Yuchung, > > A quick clarification about your example "3 packet drops in round > trip 1 plus 6 > packet drops in round trip 2 mean 2 loss events." > > If the 6 packet drops happen during the fast recovery of the 3 > packet drops, TCP stays in the fast recovery until all lost > packets are successfully recovered. In this case (assuming no > retransmissions are lost), ssthresh is reduced only once, and > there is only one loss event. Right? > > > If we're talking about the Linux implementation, then (sadly) I'm > pretty sure the answer is that it depends on the sequence number of > the packets lost in the second round. :-) If the losses in the second > round are above high_seq (high_seq = snd_nxt at the start of a > recovery episode) then tcp_fastretrans_alert() should finish the first > recovery event and then start a second recovery event (if > tcp_time_to_recover() is true it will fall through to > tcp_enter_recovery()). If the losses in the second round (or further > rounds) are all below high_seq then when all the holes are filled and > snd_una passes high_seq there should be no need for a second recovery > event. > > IMHO this is a tricky problem with many specifications of loss-based > congestion control. On the one hand, if consecutive rounds with loss > are treated as a single recovery event and do not cut ssthresh again, > then a flow could be sending too fast and losing thousands of packets > every round, for an unbounded time. On the other hand, if consecutive > rounds with loss are *not* treated as a single recovery event, and > instead are separate recovery events with consecutive multiplicative > reductions of ssthresh, then throughput would quickly collapse into > the ground in many situations. > > So perhaps the Linux TCP stack is striking a reasonable balance in > that trade-off. I don't know what other TCP stacks do. > > neal > > > Thanks > Lisong > > > > On 9/30/2016 2:22 PM, Yuchung Cheng wrote: > > A small suggestion: the loss event may imply one single packet > drop. > But AFAIK about Cubic, N>0 packet drops in one round trip is 1 > loss > event, not N loss events. And 3 packet drops in round trip 1 > plus 6 > packet drops in round trip 2 mean 2 loss events. A fast > recovery can > span across many round trips if retransmission is lost again. > > It might be worth clarifying that otherwise the (incorrect) > implementation will be a lot slower. > > On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu > wrote: > > Thanks, Marcelo! > > We will revise the draft to more clearly explain the > protocol behavior > according to your discussion with Joe yesterday. > > Thanks > > Lisong > > > > On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: > > Hi, > > Does cubic assumes that there is a different phase > when the connection > starts? i.e. slow start? It may be worthwhile stating > this explicitly? > > In the current draft, it always reffers to a packet > loss event, but I > couldnt find how is the packet loss detected i.e. via > duplicated ACKs or via > timeout. Is the reaction of cubic the same in both > cases? Does it reduces > the window to 1 MSS and enters in slow start if the > loss is detected via a > timeout? > > Sorry if this is already in the draft and i missed it. > > 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 > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --------------C338AA9CEC7B7937C002A50D Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Thanks, Neal and Yuchung.

Lisong


On 10/1/2016 3:12 PM, Neal Cardwell wrote:
On Fri, Sep 30, 2016 at 11:00 PM, Lisong Xu <xu@unl.edu> wrote:
Hi Yuchung,

A quick clarification about your example "3 packet drops in round trip 1 plus 6
packet drops in round trip 2 mean 2 loss events."

 If the 6 packet drops happen during the fast recovery of the 3 packet drops, TCP stays in the fast recovery until all lost packets are successfully recovered. In this case (assuming no retransmissions are lost), ssthresh is reduced only once, and there is only one loss event. Right?

If we're talking about the Linux implementation, then (sadly) I'm pretty sure the answer is that it depends on the sequence number of the packets lost in the second round. :-) If the losses in the second round are above high_seq (high_seq = snd_nxt at the start of a recovery episode) then tcp_fastretrans_alert() should finish the first recovery event and then start a second recovery event (if tcp_time_to_recover() is true it will fall through to  tcp_enter_recovery()). If the losses in the second round (or further rounds) are all below high_seq then when all the holes are filled and snd_una passes high_seq there should be no need for a second recovery event.

IMHO this is a tricky problem with many specifications of loss-based congestion control. On the one hand, if consecutive rounds with loss are treated as a single recovery event and do not cut ssthresh again, then a flow could be sending too fast and losing thousands of packets every round, for an unbounded time. On the other hand, if consecutive rounds with loss are *not* treated as a single recovery event, and instead are separate recovery events with consecutive multiplicative reductions of ssthresh, then throughput would quickly collapse into the ground in many situations.

So perhaps the Linux TCP stack is striking a reasonable balance in that trade-off. I don't know what other TCP stacks do.

neal

 

Thanks
Lisong



On 9/30/2016 2:22 PM, Yuchung Cheng wrote:
A small suggestion: the loss event may imply one single packet drop.
But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss
event, not N loss events. And 3 packet drops in round trip 1 plus 6
packet drops in round trip 2 mean 2 loss events. A fast recovery can
span across many round trips if retransmission is lost again.

It might be worth clarifying that otherwise the (incorrect)
implementation will be a lot slower.

On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu <xu@unl.edu> wrote:
Thanks, Marcelo!

We will revise the draft to more clearly explain the protocol behavior
according to your discussion with Joe yesterday.

Thanks

Lisong



On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote:
Hi,

Does cubic assumes that there is a different phase when the connection
starts? i.e. slow start? It may be worthwhile stating this explicitly?

In the current draft, it always reffers to a packet loss event, but I
couldnt find how is the packet loss detected i.e. via duplicated ACKs or via
timeout. Is the reaction of cubic the same in both cases? Does it reduces
the window to 1 MSS and enters in slow start if the loss is detected via a
timeout?

Sorry if this is already in the draft and i missed it.

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

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


--------------C338AA9CEC7B7937C002A50D-- From nobody Fri Oct 7 09:14:19 2016 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 9F62912962D for ; Fri, 7 Oct 2016 09:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 OpxzpMmBU-p6 for ; Fri, 7 Oct 2016 09:14:16 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71111295AD for ; Fri, 7 Oct 2016 09:14:15 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 6D9E05264E9A3; Fri, 7 Oct 2016 16:14:10 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u97GED6L025906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2016 16:14:14 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u97GDvWc023571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Oct 2016 18:14:13 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.135]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Fri, 7 Oct 2016 18:14:09 +0200 From: "Scharf, Michael (Nokia - DE)" To: marcelo bagnulo braun , tcpm IETF list Thread-Topic: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt Thread-Index: AQHSGt9M+ypbrLeY3kK4GVTGDCsUp6CRbHoAgAvJINA= Date: Fri, 7 Oct 2016 16:14:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48AE5F72@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <147521493612.18534.2870935234304413131.idtracker@ietfa.amsl.com> <5da0c3b3-fcd3-8a97-6d32-09ac66a90084@it.uc3m.es> In-Reply-To: <5da0c3b3-fcd3-8a97-6d32-09ac66a90084@it.uc3m.es> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt 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: Fri, 07 Oct 2016 16:14:17 -0000 Just looking at the first lines... Is "Intended status: Informational" inde= ed the intent? Michael -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo brau= n Sent: Friday, September 30, 2016 8:14 AM To: tcpm IETF list Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt Hi, After the presentation and discussion in Berlin, we have submitted a new ve= rsion of the draft that includes the details of how to add ECN support to T= CP control packets and retransmissions. Comments are welcome. Regards, marcelo -------- Mensaje reenviado -------- Asunto: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt Fecha: Thu, 29 Sep 2016 22:55:36 -0700 De: internet-drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Adding Explicit Congestion Notification (ECN) to= TCP control packets and TCP retransmissions Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-bagnulo-tcpm-generalized-ecn-00.txt Pages : 23 Date : 2016-09-29 Abstract: This document describes an experimental modification to ECN to allow the use of ECN to the following TCP packets: SYNs, Pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-generalized-ecn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Oct 7 09:52:22 2016 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 BE1B912956C for ; Fri, 7 Oct 2016 09:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 7VEEt52o9d_a for ; Fri, 7 Oct 2016 09:52:18 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 138EA128B44 for ; Fri, 7 Oct 2016 09:52:17 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id k125so43302183wma.1 for ; Fri, 07 Oct 2016 09:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=CdJveK8NQIBa+N0BwSylucWECP0NmEywqiXBkIoogVg=; b=el98FAtR2ZlV6z/tx0r6kmMGTK8c9aWBZwJeafc32dLvZGfu5Bwk16Y6S+wzw5b3uu wegOdL1kSPD6VobNt6Nl4+koGFsAJS1kfdldfEGmCKj5V0jXSHMVpQ6pD3IakmuG0xDK 3HOhRHFu69W7CaLwgyRtyGI+i4emtQB8LLUP49rGXucdLJLcTNcTXFEF0NlP8p3vaJX9 0hHXQGU8cpYqm5opYqwHB0Db4GikXWc4+cyJ1su8p5YFkWTGfpoo3nTXzrHehcTiBjhL didg2l7DkcKnjxj+EmyZImW9a0YyLG7ZOm5R1P17GcOnMZwc77UnmA1CCoWrgpVO6Zsz swng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CdJveK8NQIBa+N0BwSylucWECP0NmEywqiXBkIoogVg=; b=TZOr93c11b3pl1L58OrF3YOReZ72ZeKMFj1/z0CArQBZB+eiR4gFGamJu8u3jya/Es vrp8LCVS0b6rQc+YCqd8mFicZhFnadDzUNA0bOeXpKlIJI+UFjikmkV9V6Z2kPCkADgM dwTR1GRMSEMCPDU/Binh+2D1ia0IX1BapGqtfVQjgWtLFIHTSvvZdkREJOXrymIUceKZ zNwVmaI0TGY2qGwVe+mOj8MlPco+Uh+io6leKg5u6IkVaLEG9bsswGZeJpskiGhz/7eE Af3Hukaew7W2+Oa6GfSdma4KNJyHaRhk09JYzMEt63su2ZExZ49U0PhX13nss5ljPrUa up+w== X-Gm-Message-State: AA6/9RkshYYpALUcUXN4cqZTrfH+ObmNxffjoLjRJ0jdNKLdxBzhjAPVlYy2NXuDRo82b4yM X-Received: by 10.28.6.6 with SMTP id 6mr21381246wmg.27.1475859135494; Fri, 07 Oct 2016 09:52:15 -0700 (PDT) Received: from Macintosh-6.local (41.175.16.95.dynamic.jazztel.es. [95.16.175.41]) by smtp.gmail.com with ESMTPSA id a1sm20535060wjl.28.2016.10.07.09.52.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 09:52:14 -0700 (PDT) To: "Scharf, Michael (Nokia - DE)" , tcpm IETF list References: <147521493612.18534.2870935234304413131.idtracker@ietfa.amsl.com> <5da0c3b3-fcd3-8a97-6d32-09ac66a90084@it.uc3m.es> <655C07320163294895BBADA28372AF5D48AE5F72@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: marcelo bagnulo braun Message-ID: <67fa93b3-1a9e-259f-8972-8b57c0496e24@it.uc3m.es> Date: Fri, 7 Oct 2016 18:52:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D48AE5F72@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt 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: Fri, 07 Oct 2016 16:52:22 -0000 Hi Michael, I guess not. Shopuld be experimental, correct? Sorry for the mistake. Regards, marcelo El 07/10/16 a las 18:14, Scharf, Michael (Nokia - DE) escribi: > Just looking at the first lines... Is "Intended status: Informational" indeed the intent? > > Michael > > > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Friday, September 30, 2016 8:14 AM > To: tcpm IETF list > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt > > Hi, > > After the presentation and discussion in Berlin, we have submitted a new version of the draft that includes the details of how to add ECN support to TCP control packets and retransmissions. > > Comments are welcome. > > Regards, marcelo > > > > > -------- Mensaje reenviado -------- > Asunto: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt > Fecha: Thu, 29 Sep 2016 22:55:36 -0700 > De: internet-drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Adding Explicit Congestion Notification (ECN) to TCP control packets and TCP retransmissions > Authors : Marcelo Bagnulo > Bob Briscoe > Filename : draft-bagnulo-tcpm-generalized-ecn-00.txt > Pages : 23 > Date : 2016-09-29 > > Abstract: > This document describes an experimental modification to ECN to allow > the use of ECN to the following TCP packets: SYNs, Pure ACKs, Window > probes, FINs, RSTs and retransmissions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-generalized-ecn/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-00 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Oct 7 09:53:29 2016 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 5BBE9129663 for ; Fri, 7 Oct 2016 09:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 vxSEWDffZpUF for ; Fri, 7 Oct 2016 09:53:21 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D0712965B for ; Fri, 7 Oct 2016 09:53:21 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A995AF6E3A0E8; Fri, 7 Oct 2016 16:53:15 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u97GrI8a013423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2016 16:53:19 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u97GrIcY032174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Oct 2016 18:53:18 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.135]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Fri, 7 Oct 2016 18:53:18 +0200 From: "Scharf, Michael (Nokia - DE)" To: marcelo bagnulo braun , tcpm IETF list Thread-Topic: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt Thread-Index: AQHSGt9M+ypbrLeY3kK4GVTGDCsUp6CRbHoAgAvJIND//+lugIAAIcYg Date: Fri, 7 Oct 2016 16:53:18 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48AE6C01@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <147521493612.18534.2870935234304413131.idtracker@ietfa.amsl.com> <5da0c3b3-fcd3-8a97-6d32-09ac66a90084@it.uc3m.es> <655C07320163294895BBADA28372AF5D48AE5F72@FR712WXCHMBA15.zeu.alcatel-lucent.com> <67fa93b3-1a9e-259f-8972-8b57c0496e24@it.uc3m.es> In-Reply-To: <67fa93b3-1a9e-259f-8972-8b57c0496e24@it.uc3m.es> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt 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: Fri, 07 Oct 2016 16:53:24 -0000 At least this is what the abstract states... Michael -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Sent: Friday, October 07, 2016 6:52 PM To: Scharf, Michael (Nokia - DE) ; tcpm IETF list= Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.= txt Hi Michael, I guess not. Shopuld be experimental, correct? Sorry for the mistake. Regards, marcelo El 07/10/16 a las 18:14, Scharf, Michael (Nokia - DE) escribi=F3: > Just looking at the first lines... Is "Intended status: Informational" in= deed the intent? > > Michael > > > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo br= aun > Sent: Friday, September 30, 2016 8:14 AM > To: tcpm IETF list > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.tx= t > > Hi, > > After the presentation and discussion in Berlin, we have submitted a new = version of the draft that includes the details of how to add ECN support to= TCP control packets and retransmissions. > > Comments are welcome. > > Regards, marcelo > > > > > -------- Mensaje reenviado -------- > Asunto: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt > Fecha: Thu, 29 Sep 2016 22:55:36 -0700 > De: internet-drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : Adding Explicit Congestion Notification (ECN)= to TCP control packets and TCP retransmissions > Authors : Marcelo Bagnulo > Bob Briscoe > Filename : draft-bagnulo-tcpm-generalized-ecn-00.txt > Pages : 23 > Date : 2016-09-29 > > Abstract: > This document describes an experimental modification to ECN to allow > the use of ECN to the following TCP packets: SYNs, Pure ACKs, Window > probes, FINs, RSTs and retransmissions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-generalized-ecn/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Oct 13 00:13:08 2016 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 94ACE1298A7 for ; Thu, 13 Oct 2016 00:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham 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 YejqOoswX_wH for ; Thu, 13 Oct 2016 00:12:54 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219421298AA for ; Thu, 13 Oct 2016 00:12:51 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1buaC8-0000k7-Pj; Thu, 13 Oct 2016 09:12:48 +0200 Received: from imdea-networks.net.redimadrid.es ([193.145.14.145] helo=[172.16.8.49]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1buaC8-0004kn-7R; Thu, 13 Oct 2016 09:12:48 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2016 09:12:46 +0200 Message-Id: To: "Scharf, Michael (Nokia - DE)" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 47137 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: ADA5AC6BAE8B488DA6622B48B28DEFCF05288C59 X-UiO-SPAM-Test: remote_host: 193.145.14.145 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 40 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 13 Oct 2016 07:13:03 -0000 Hi Michael, At the last IETF, you said (from the minutes): "There is value in documenting the implementations, there may be = opportunities to modernise the wording. You can make significant = improvements as you edit the document.=E2=80=9D I remember saying that we=E2=80=99d appreciate concrete suggestions, but = we didn=E2=80=99t get any - so, with the cutoff deadline approaching, = I=E2=80=99m repeating my request=E2=80=A6 anything specific you=E2=80=99d = suggest to change, so we can consider it? Cheers, Michael From nobody Thu Oct 13 02:27:53 2016 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 EA9131296FD for ; Thu, 13 Oct 2016 02:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 UPzS12aMmqe9 for ; Thu, 13 Oct 2016 02:27:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62C01296FC for ; Thu, 13 Oct 2016 02:27:49 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C089E3FFAA3C0; Thu, 13 Oct 2016 09:27:45 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9D9Rl0u014569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 09:27:48 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u9D9RlCT012419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Oct 2016 11:27:47 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.135]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 13 Oct 2016 11:27:47 +0200 From: "Scharf, Michael (Nokia - DE)" To: Michael Welzl Thread-Topic: draft-touch-tcpm-2140bis: wording improvement suggestions? Thread-Index: AQHSJSFhCiXpX1Uw7keMznYEAkDILKCmG9og Date: Thu, 13 Oct 2016 09:27:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 13 Oct 2016 09:27:52 -0000 SGkgTWljaGFlbCwNCg0KTXkgY29tbWVudCB3YXMgZS5nLiByZWdhcmRpbmcgIlNlY3Rpb24gMTAu IEltcGxlbWVudGF0aW9uIE9ic2VydmF0aW9ucyIsIHdoaWNoIGRpc2N1c3NlcyBUL1RDUCBpbiB0 aHJlZSBsb25nIHBhcmFncmFwaHMgYW5kIHRoZW4gaGFzIG9uZSBzZW50ZW5jZSBhbmQgYSBzaW1w bGUgdGFibGUgb24gTGludXgga2VybmVsIHZlcnNpb24gNC42IGFuZCBGcmVlQlNEIDEwICh3aGlj aCBJIGxpa2UpLg0KDQpJIHBlcnNvbmFsbHkgdGhpbmsgVC9UQ1AgY291bGQgYmUgYnkgYW5kIGxh cmdlIGJlIG1vdmVkIHRvIGFuIGFwcGVuZGl4IGFuZCB0aGUgZG9jdW1lbnQgc2hvdWxkIGZvY3Vz IG9uIHdoYXQgaGFzIGJlZW4gd2lkZWx5IGRlcGxveWVkIGluIHRoZSBsYXN0IHR3byBkZWNhZGVz Lg0KDQpCZXN0IHJlZ2FyZHMNCg0KTWljaGFlbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBNaWNoYWVsIFdlbHpsIFttYWlsdG86bWljaGF3ZUBpZmkudWlvLm5vXSANClNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDEzLCAyMDE2IDk6MTMgQU0NClRvOiBTY2hhcmYsIE1pY2hh ZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+DQpDYzogdGNwbUBpZXRm Lm9yZw0KU3ViamVjdDogZHJhZnQtdG91Y2gtdGNwbS0yMTQwYmlzOiB3b3JkaW5nIGltcHJvdmVt ZW50IHN1Z2dlc3Rpb25zPw0KDQpIaSBNaWNoYWVsLA0KDQpBdCB0aGUgbGFzdCBJRVRGLCB5b3Ug c2FpZCAoZnJvbSB0aGUgbWludXRlcyk6DQoNCiJUaGVyZSBpcyB2YWx1ZSBpbiBkb2N1bWVudGlu ZyB0aGUgaW1wbGVtZW50YXRpb25zLCB0aGVyZSBtYXkgYmUgb3Bwb3J0dW5pdGllcyB0byBtb2Rl cm5pc2UgdGhlIHdvcmRpbmcuIFlvdSBjYW4gbWFrZSBzaWduaWZpY2FudCBpbXByb3ZlbWVudHMg YXMgeW91IGVkaXQgdGhlIGRvY3VtZW50LuKAnQ0KDQpJIHJlbWVtYmVyIHNheWluZyB0aGF0IHdl 4oCZZCBhcHByZWNpYXRlIGNvbmNyZXRlIHN1Z2dlc3Rpb25zLCBidXQgd2UgZGlkbuKAmXQgZ2V0 IGFueSAtIHNvLCB3aXRoIHRoZSBjdXRvZmYgZGVhZGxpbmUgYXBwcm9hY2hpbmcsIEnigJltIHJl cGVhdGluZyBteSByZXF1ZXN04oCmIGFueXRoaW5nIHNwZWNpZmljIHlvdeKAmWQgc3VnZ2VzdCB0 byBjaGFuZ2UsIHNvIHdlIGNhbiBjb25zaWRlciBpdD8NCg0KQ2hlZXJzLA0KTWljaGFlbA0KDQo= From nobody Thu Oct 13 03:10:52 2016 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 4D91312971C for ; Thu, 13 Oct 2016 03:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham 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 ci5oZ684heVJ for ; Thu, 13 Oct 2016 03:10:47 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83B81295D2 for ; Thu, 13 Oct 2016 03:10:47 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bucyM-0001UO-4Q for tcpm@ietf.org; Thu, 13 Oct 2016 12:10:46 +0200 Received: from imdea-networks.net.redimadrid.es ([193.145.14.145] helo=[172.16.8.49]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bucyK-00063L-Ux; Thu, 13 Oct 2016 12:10:45 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 13 Oct 2016 12:10:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Nokia - DE)" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 47151 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 69135C557FD39B549B2A2BA38EDD7641714DFE24 X-UiO-SPAM-Test: remote_host: 193.145.14.145 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 49 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 13 Oct 2016 10:10:50 -0000 That was useful, thanks! Michael > On 13. okt. 2016, at 11.27, Scharf, Michael (Nokia - DE) = wrote: >=20 > Hi Michael, >=20 > My comment was e.g. regarding "Section 10. Implementation = Observations", which discusses T/TCP in three long paragraphs and then = has one sentence and a simple table on Linux kernel version 4.6 and = FreeBSD 10 (which I like). >=20 > I personally think T/TCP could be by and large be moved to an appendix = and the document should focus on what has been widely deployed in the = last two decades. >=20 > Best regards >=20 > Michael >=20 >=20 > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: Thursday, October 13, 2016 9:13 AM > To: Scharf, Michael (Nokia - DE) > Cc: tcpm@ietf.org > Subject: draft-touch-tcpm-2140bis: wording improvement suggestions? >=20 > Hi Michael, >=20 > At the last IETF, you said (from the minutes): >=20 > "There is value in documenting the implementations, there may be = opportunities to modernise the wording. You can make significant = improvements as you edit the document.=E2=80=9D >=20 > I remember saying that we=E2=80=99d appreciate concrete suggestions, = but we didn=E2=80=99t get any - so, with the cutoff deadline = approaching, I=E2=80=99m repeating my request=E2=80=A6 anything specific = you=E2=80=99d suggest to change, so we can consider it? >=20 > Cheers, > Michael >=20 From nobody Thu Oct 13 06:21:59 2016 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 34E6D129454 for ; Thu, 13 Oct 2016 06:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, 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 87xV-BHKZj6x for ; Thu, 13 Oct 2016 06:21:56 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 245001294F8 for ; Thu, 13 Oct 2016 06:21:56 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id o19so82190330ito.1 for ; Thu, 13 Oct 2016 06:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uY9/F1f9r2TBgyJiqBEwHzwM1XjHQsqKcDMxTED75bc=; b=O5KWaczvSl+T2x0NM13AURXuIYXFahVKmBFmwS/SuW7Dxc75yEd/6oLZd201MjItDG eYsakb0CtgAyEpyOM2UDCQajrDMHI/21SsMiOYT3CuM9DEKSlXG6U3F5C0SQTq9IadU1 mIlONLZ1MAYXFmlKLaemSdglcuKfj1aphA+kqajOy5HySR9snbmfhAe0sHz2GDFw89+x piijlTbrJIXbCnqrdgGS16CllAieSH9MrvihCp9t9SncOY5oybgTgpcXJ2XGIIY8IjD2 FxAfgXgNeLjGNKFt3kpSvNODJjrx+XYZhK3f7rbr8hdewocSfV/uLDje+p7ZwybtITqZ 3WjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uY9/F1f9r2TBgyJiqBEwHzwM1XjHQsqKcDMxTED75bc=; b=LKBYiau2RBbB1nKvMhmPdIEwOQ0wtMIKAE+56BchlgwSKNT4VsWSOqOtCqZrZu0bne VCRgKD4ZcZ05AAicaEtDhagB6LafpDq7cUfQtRREEtk0go1Kpdwbasv2hpVTyTyJ1pIe fHUN3DG3bX52aQzC0f562o/gRRbeofG9sGdeKYiWdgxSWPEfrgMKx2WGx2xmBdo0x/fb 2tEWGVCjMY+yD73pHN5NS8SS0O9vF8UXHplV1xCPplEUA50nx+Qd8nRchkhkoE+RaofB eQMqG0hpCyJenqr7HRtBLbBeK89gafefVF9QG9R5rrGXgAkpmScMUSpg40oZ8wg0+5KA hT0A== X-Gm-Message-State: AA6/9RmpQK9u5P3GQCiVZIqN+9d1x3NTX2fP6viO3pBRPR1edPpsSwcNzRAEr5ZmenvByaEV4RJ0YYVgSAV00351 X-Received: by 10.36.159.69 with SMTP id c66mr8057876ite.97.1476364915340; Thu, 13 Oct 2016 06:21:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Thu, 13 Oct 2016 06:21:14 -0700 (PDT) In-Reply-To: <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> From: Yuchung Cheng Date: Thu, 13 Oct 2016 06:21:14 -0700 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 13 Oct 2016 13:21:58 -0000 I remained my objection that WG spends time on this. If this is BCP, please show that it _actually_ improves performance on busy servers (!=3D running netperf over same ip pair 1000 times). The draft claims it potentially improves performance and lists a variety of reason it may not (thanks). But do we really know it helps? I only have negative data points (based on Linux's impl) and would appreciate positive data points before we move forward. On Thu, Oct 13, 2016 at 3:10 AM, Michael Welzl wrote: > That was useful, thanks! > > Michael > > >> On 13. okt. 2016, at 11.27, Scharf, Michael (Nokia - DE) wrote: >> >> Hi Michael, >> >> My comment was e.g. regarding "Section 10. Implementation Observations",= which discusses T/TCP in three long paragraphs and then has one sentence a= nd a simple table on Linux kernel version 4.6 and FreeBSD 10 (which I like)= . >> >> I personally think T/TCP could be by and large be moved to an appendix a= nd the document should focus on what has been widely deployed in the last t= wo decades. >> >> Best regards >> >> Michael >> >> >> -----Original Message----- >> From: Michael Welzl [mailto:michawe@ifi.uio.no] >> Sent: Thursday, October 13, 2016 9:13 AM >> To: Scharf, Michael (Nokia - DE) >> Cc: tcpm@ietf.org >> Subject: draft-touch-tcpm-2140bis: wording improvement suggestions? >> >> Hi Michael, >> >> At the last IETF, you said (from the minutes): >> >> "There is value in documenting the implementations, there may be opportu= nities to modernise the wording. You can make significant improvements as y= ou edit the document.=E2=80=9D >> >> I remember saying that we=E2=80=99d appreciate concrete suggestions, but= we didn=E2=80=99t get any - so, with the cutoff deadline approaching, I=E2= =80=99m repeating my request=E2=80=A6 anything specific you=E2=80=99d sugge= st to change, so we can consider it? >> >> Cheers, >> Michael >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Oct 13 07:18:39 2016 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 33CB11294F7 for ; Thu, 13 Oct 2016 07:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham 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 G0DuWT_Z17IF for ; Thu, 13 Oct 2016 07:18:29 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7508F1298E6 for ; Thu, 13 Oct 2016 07:18:28 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bugq2-0003D0-Ta for tcpm@ietf.org; Thu, 13 Oct 2016 16:18:26 +0200 Received: from imdea-networks.net.redimadrid.es ([193.145.14.145] helo=[172.16.8.49]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bugq1-0006wJ-Vv; Thu, 13 Oct 2016 16:18:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Thu, 13 Oct 2016 16:18:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <082F8364-EE54-4EC0-B44D-F69D1BE515E7@ifi.uio.no> References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> To: Yuchung Cheng X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 47160 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D3EB48902302B9C8216EF08A8E9B09B43A79E821 X-UiO-SPAM-Test: remote_host: 193.145.14.145 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 54 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 13 Oct 2016 14:18:37 -0000 Hi Yuchung, First, we had a clear =E2=80=9Cno=E2=80=9D for the BCP suggestion at the = last meeting, so we don=E2=80=99t need to discuss this context. It=E2=80=99= s Informational. Second, can you be a bit more specific about =E2=80=9Cit=E2=80=9D in = your statement below? (I suspect you mean ssthresh?) Note that we intend to make the language more neutral based on your = comment at the last meeting, but we have not *yet* done so. Since you say =E2=80=9Cthanks=E2=80=9D to us giving reasons =E2=80=9Cit" = may *not* improve performance, I wonder: maybe the only thing that has = changed since you commented on it in the last meeting is that you now = actually read it? Cheers, Michael > On 13. okt. 2016, at 15.21, Yuchung Cheng wrote: >=20 > I remained my objection that WG spends time on this. If this is BCP, > please show that it _actually_ improves performance on busy servers > (!=3D running netperf over same ip pair 1000 times). >=20 > The draft claims it potentially improves performance and lists a > variety of reason it may not (thanks). But do we really know it helps? > I only have negative data points (based on Linux's impl) and would > appreciate positive data points before we move forward. >=20 >=20 > On Thu, Oct 13, 2016 at 3:10 AM, Michael Welzl = wrote: >> That was useful, thanks! >>=20 >> Michael >>=20 >>=20 >>> On 13. okt. 2016, at 11.27, Scharf, Michael (Nokia - DE) = wrote: >>>=20 >>> Hi Michael, >>>=20 >>> My comment was e.g. regarding "Section 10. Implementation = Observations", which discusses T/TCP in three long paragraphs and then = has one sentence and a simple table on Linux kernel version 4.6 and = FreeBSD 10 (which I like). >>>=20 >>> I personally think T/TCP could be by and large be moved to an = appendix and the document should focus on what has been widely deployed = in the last two decades. >>>=20 >>> Best regards >>>=20 >>> Michael >>>=20 >>>=20 >>> -----Original Message----- >>> From: Michael Welzl [mailto:michawe@ifi.uio.no] >>> Sent: Thursday, October 13, 2016 9:13 AM >>> To: Scharf, Michael (Nokia - DE) >>> Cc: tcpm@ietf.org >>> Subject: draft-touch-tcpm-2140bis: wording improvement suggestions? >>>=20 >>> Hi Michael, >>>=20 >>> At the last IETF, you said (from the minutes): >>>=20 >>> "There is value in documenting the implementations, there may be = opportunities to modernise the wording. You can make significant = improvements as you edit the document.=E2=80=9D >>>=20 >>> I remember saying that we=E2=80=99d appreciate concrete suggestions, = but we didn=E2=80=99t get any - so, with the cutoff deadline = approaching, I=E2=80=99m repeating my request=E2=80=A6 anything specific = you=E2=80=99d suggest to change, so we can consider it? >>>=20 >>> Cheers, >>> Michael >>>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Oct 15 16:30:00 2016 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 D49311295A4 for ; Sat, 15 Oct 2016 16:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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.431, 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 3XrvLkkpeuyv for ; Sat, 15 Oct 2016 16:29:57 -0700 (PDT) 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 80594129451 for ; Sat, 15 Oct 2016 16:29:57 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q192so156055983iod.0 for ; Sat, 15 Oct 2016 16:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kNDCnPvYpNIdQJt3aAvZrcnRR7FxWQ2DRLFs+b2iUmc=; b=jC244lF+mJUStOK0rwTOnDsGfrhUhja+G56P8cuHxEYJisSB8VbRj2zqYNA2FRKnXx JHo4GiJGmGQ3BTk7RQCwyXdfdVyyOz8ZVAU3Ec29vgmoglnwC8VGs4m/+LrQjfMIRs81 YjEGNDQzfEzc0IzOwRVhVmVBiuocPW3oh/yaQHZ5aAexdBZBYmxC5vs6PwLfDYjRydlo lnqnim42JWHM1G05/NywEo2Aq3nQXCWH/Vob+Iu6cZ420J+Gr/Keoi2hR3cFTRKGchIs NoZsLheXhjpd26Sp/2zPbjB5a1R8A9ZFE4NYQjbChemOWlaiseh8P8HvdCoFM6U0Vn+F GQ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kNDCnPvYpNIdQJt3aAvZrcnRR7FxWQ2DRLFs+b2iUmc=; b=PS0CaMPIO+lkV4X28NiBP/Uqtw0cRriQAjIwYLk2bVwulO9BDyH61R/11AqRGO88dM 0hQvZlWWFlr8scZqD5WEkkmWkRzNvwH8vUFqZVN7a0rzvqtGNLj84zgPNreUlYKkrOwD g9wTGVXWD4GZdUhMGRcNKzpjtAZHzNaHulAZI8OuzLIo9vQ+zbdEpg79p9xjsOT65Rv7 y5Of8FHn5NlTCf2OBCwO4zW8CVBehEJzLkIEQR980edyKZVpalL+FnLU344ZedvH6kGB +djC0PUvNxQ9gkk8gwQ3UYqtLdVXTKIqfQue/0IgVWX+nCb24ZkLiN61NPLrmP3OZtrk TPFA== X-Gm-Message-State: AA6/9RmML2h6LkyzSALUJVYCI9VUwwQ4hD+RC1cTLU7hHAoJ393CZplkkncP85IrKeGsmmazXqRK+sc5YY8LVw2Q X-Received: by 10.107.136.65 with SMTP id k62mr5311224iod.99.1476574196398; Sat, 15 Oct 2016 16:29:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Sat, 15 Oct 2016 16:29:15 -0700 (PDT) In-Reply-To: <082F8364-EE54-4EC0-B44D-F69D1BE515E7@ifi.uio.no> References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> <082F8364-EE54-4EC0-B44D-F69D1BE515E7@ifi.uio.no> From: Yuchung Cheng Date: Sat, 15 Oct 2016 16:29:15 -0700 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=001a113ed25c766494053eefb841 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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: Sat, 15 Oct 2016 23:30:00 -0000 --001a113ed25c766494053eefb841 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2016 at 7:18 AM, Michael Welzl wrote: > > Hi Yuchung, > > First, we had a clear =E2=80=9Cno=E2=80=9D for the BCP suggestion at the = last meeting, so we don=E2=80=99t need to discuss this context. It=E2=80=99s Informational. ack > > Second, can you be a bit more specific about =E2=80=9Cit=E2=80=9D in your= statement below? > (I suspect you mean ssthresh?) It means the TCB sharing done by real implementation (e.g. Linux metrics cache and FreeBSD). > > Note that we intend to make the language more neutral based on your comment at the last meeting, but we have not *yet* done so. > Since you say =E2=80=9Cthanks=E2=80=9D to us giving reasons =E2=80=9Cit" = may *not* improve performance, I wonder: maybe the only thing that has changed since you commented on it in the last meeting is that you now actually read it? I have read the drafts more than once since its initial version. To double check I didn't miss something important I re-read again before replying this email. Since we want to update RFC2140, I assume we believe metrics cache are useful (so it is informational to IETF people). I am asking the (positive) data points, not simply the fact it's been implemented. Now let's look into the details of the actual info suggested for sharing, and lets skip ssthresh since we've discussed. RTT/RTTVAR: RTT is readily available after SYN, so the most useful place is SYN timeout. But the draft says we should not set anything more aggressive than the minimum requirement by standard, which is 1sec by RFC6298. How can fast connection retry SYN faster to lower handshake time? or I mis-read the draft. Recently a detailed investigation on Linux RTO also question the form of RTT caching (paper ). Also another report by Anna: MSS,PMTU: I know MSS cache is useful for Fast Open b/c we need to decide how much to put in SYN. Other than that I really don't know how this helps performance for something we communicated at handshake. Would that reduce potential middlebox issues? not clear. cwnd/ssthresh: we've covered this. The bis draft lists newly identified issues with TCB (e.g. ECMP) but it's unclear whether the implementor should do something or just ignore. To conclude, my one question is after ~20 years of RFC2140 published, is the current implementation of TCB sharing useful (by data)? If the draft does not address this question, what's new in this informational bis? [to be specific, I am not asking to incorporate my comments into the next revision. I am asking data] > > Cheers, > Michael > > > > On 13. okt. 2016, at 15.21, Yuchung Cheng wrote: > > > > I remained my objection that WG spends time on this. If this is BCP, > > please show that it _actually_ improves performance on busy servers > > (!=3D running netperf over same ip pair 1000 times). > > > > The draft claims it potentially improves performance and lists a > > variety of reason it may not (thanks). But do we really know it helps? > > I only have negative data points (based on Linux's impl) and would > > appreciate positive data points before we move forward. > > > > > > On Thu, Oct 13, 2016 at 3:10 AM, Michael Welzl wrote: > >> That was useful, thanks! > >> > >> Michael > >> > >> > >>> On 13. okt. 2016, at 11.27, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > >>> > >>> Hi Michael, > >>> > >>> My comment was e.g. regarding "Section 10. Implementation Observations", which discusses T/TCP in three long paragraphs and then has one sentence and a simple table on Linux kernel version 4.6 and FreeBSD 10 (which I like). > >>> > >>> I personally think T/TCP could be by and large be moved to an appendix and the document should focus on what has been widely deployed in the last two decades. > >>> > >>> Best regards > >>> > >>> Michael > >>> > >>> > >>> -----Original Message----- > >>> From: Michael Welzl [mailto:michawe@ifi.uio.no] > >>> Sent: Thursday, October 13, 2016 9:13 AM > >>> To: Scharf, Michael (Nokia - DE) > >>> Cc: tcpm@ietf.org > >>> Subject: draft-touch-tcpm-2140bis: wording improvement suggestions? > >>> > >>> Hi Michael, > >>> > >>> At the last IETF, you said (from the minutes): > >>> > >>> "There is value in documenting the implementations, there may be opportunities to modernise the wording. You can make significant improvements as you edit the document.=E2=80=9D > >>> > >>> I remember saying that we=E2=80=99d appreciate concrete suggestions, = but we didn=E2=80=99t get any - so, with the cutoff deadline approaching, I=E2=80= =99m repeating my request=E2=80=A6 anything specific you=E2=80=99d suggest to change, so we c= an consider it? > >>> > >>> Cheers, > >>> Michael > >>> > >> > >> _______________________________________________ > >> 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 > --001a113ed25c766494053eefb841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 13, 2016 at 7:18 AM, Michael Welzl <= ;michawe@ifi.uio.no> wrote:>
> Hi Yuchung,
>
> First, we had a clear =E2=80=9Cno= =E2=80=9D for the BCP suggestion at the last meeting, so we don=E2=80=99t n= eed to discuss this context. It=E2=80=99s Informational.
ack
>
= > Second, can you be a bit more specific about =E2=80=9Cit=E2=80=9D in y= our statement below?
> (I suspect you mean ssthresh?)
It means the= TCB sharing done by real implementation (e.g. Linux metrics cache and Free= BSD).


>
> Note that we intend to make the language more= neutral based on your comment at the last meeting, but we have not *yet* d= one so.
> Since you say =E2=80=9Cthanks=E2=80=9D to us giving reasons= =E2=80=9Cit" may *not* improve performance, I wonder: maybe the only = thing that has changed since you commented on it in the last meeting is tha= t you now actually read it?
I have read the drafts more than once since = its initial version. To double check I didn't miss something important = I re-read again before replying this email.

Since we want to update = RFC2140, I assume we believe metrics cache are useful (so it is information= al to IETF people). I am asking the (positive) data points, not simply the = fact it's been implemented.

Now let's look into the details = of the actual info suggested for sharing, and lets skip ssthresh since we&#= 39;ve discussed.

RTT/RTTVAR: RTT is readily available after SYN, so = the most useful place is SYN timeout. But the draft says we should not set = anything more aggressive than the minimum requirement by standard, which is= 1sec by RFC6298. How can fast connection retry SYN faster to lower handsha= ke time? or I mis-read the draft. Recently a detailed investigation on Linu= x RTO also question the form of RTT caching (paper). A= lso another report by Anna:=C2=A0

MSS,PMTU: I know MSS cache is usef= ul for Fast Open b/c we need to decide how much to put in SYN. Other than t= hat I really don't know how this helps performance for something we com= municated at handshake. Would that reduce potential middlebox issues? not c= lear.

cwnd/ssthresh: we've covered this.

The bis draft li= sts newly identified issues with TCB (e.g. ECMP) but it's unclear wheth= er the implementor should do something or just ignore. To conclude, my one = question is after ~20 years of RFC2140 published, is the current implementa= tion of TCB sharing useful (by data)?

If the draft does not address= this question, what's new in this informational bis?

[to be specific, I am not asking to incorporate my comments into th= e next revision. I am asking data]

>
> Cheers,
> Mich= ael
>
>
> > On 13. okt. 2016, at 15.21, Yuchung Cheng = <ycheng@google.com> wrote:> >
> > I remained my objection that WG spends time on thi= s. If this is BCP,
> > please show that it _actually_ improves per= formance on busy servers
> > (!=3D running netperf over same ip pa= ir 1000 times).
> >
> > The draft claims it potentially i= mproves performance and lists a
> > variety of reason it may not (= thanks). But do we really know it helps?
> > I only have negative = data points (based on Linux's impl) and would
> > appreciate p= ositive data points before we move forward.
> >
> >
&g= t; > On Thu, Oct 13, 2016 at 3:10 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> >> Th= at was useful, thanks!
> >>
> >> Michael
> &g= t;>
> >>
> >>> On 13. okt. 2016, at 11.27, Sc= harf, Michael (Nokia - DE) <= michael.scharf@nokia.com> wrote:
> >>>
> >&g= t;> Hi Michael,
> >>>
> >>> My comment was= e.g. regarding "Section 10. Implementation Observations", which = discusses T/TCP in three long paragraphs and then has one sentence and a si= mple table on Linux kernel version 4.6 and FreeBSD 10 (which I like).
&g= t; >>>
> >>> I personally think T/TCP could be by a= nd large be moved to an appendix and the document should focus on what has = been widely deployed in the last two decades.
> >>>
> = >>> Best regards
> >>>
> >>> Michael=
> >>>
> >>>
> >>> -----Origin= al Message-----
> >>> From: Michael Welzl [mailto:michawe@ifi.uio.no]
> >>> Se= nt: Thursday, October 13, 2016 9:13 AM
> >>> To: Scharf, Mic= hael (Nokia - DE) <michael.s= charf@nokia.com>
> >>> Cc: tcpm@ietf.org
> >>> Subject: draft-touch-tcpm-214= 0bis: wording improvement suggestions?
> >>>
> >>= ;> Hi Michael,
> >>>
> >>> At the last IET= F, you said (from the minutes):
> >>>
> >>> &= quot;There is value in documenting the implementations, there may be opport= unities to modernise the wording. You can make significant improvements as = you edit the document.=E2=80=9D
> >>>
> >>> I= remember saying that we=E2=80=99d appreciate concrete suggestions, but we = didn=E2=80=99t get any - so, with the cutoff deadline approaching, I=E2=80= =99m repeating my request=E2=80=A6 anything specific you=E2=80=99d suggest = to change, so we can consider it?
> >>>
> >>>= Cheers,
> >>> Michael
> >>>
> >>=
> >> _______________________________________________
> &= gt;> tcpm mailing list
> >> tcpm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >=
> > _______________________________________________
> > = tcpm mailing list
> > tcpm@ietf.o= rg
> > = https://www.ietf.org/mailman/listinfo/tcpm
>
--001a113ed25c766494053eefb841-- From nobody Sun Oct 16 20:39:07 2016 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 14AC9129569; Sun, 16 Oct 2016 20:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham 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 e9FdRYCjkhPa; Sun, 16 Oct 2016 20:39:05 -0700 (PDT) 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 F0458129568; Sun, 16 Oct 2016 20:39:04 -0700 (PDT) Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B56D327847E; Mon, 17 Oct 2016 12:39:01 +0900 (JST) Received: by mail-vk0-f48.google.com with SMTP id 83so137264301vkd.0; Sun, 16 Oct 2016 20:39:01 -0700 (PDT) X-Gm-Message-State: AA6/9RmQvAZqndG3trt3bQRJa50V7to2PzQJaoI1F4ie5Np6sxhUG1tXCvF2RQfXyspAveHNAbAXKj7SzsDbFg== X-Received: by 10.31.199.199 with SMTP id x190mr16581345vkf.117.1476675540251; Sun, 16 Oct 2016 20:39:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.7 with HTTP; Sun, 16 Oct 2016 20:38:59 -0700 (PDT) From: Yoshifumi Nishida Date: Sun, 16 Oct 2016 20:38:59 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a1148390a067d96053f0751b5 Archived-At: Cc: "tcpm-chairs@ietf.org" Subject: [tcpm] agenda for tcpm meeting at IETF 97 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, 17 Oct 2016 03:39:07 -0000 --001a1148390a067d96053f0751b5 Content-Type: text/plain; charset=UTF-8 Hello, According to the preliminary agenda,( https://datatracker.ietf.org/meeting/97/agenda.html), we will have a 2.5-hour meeting slot on ** 11/14 Monday morning (9:30 - 12:00) **. If you're planning to present something, please provide us the following info. 1: presenter's name 2: draft name / presentation title 3: length of the presentation Thanks, -- tcpm co-chairs --001a1148390a067d96053f0751b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
According to the preliminary agenda,(https://datatracker.ie= tf.org/meeting/97/agenda.html), we will have a 2.5-hour meeting slot on= ** 11/14 Monday morning (9:30 - 12:00) **.

If you're planning to present something, please provide us the= following info.=C2=A0

=C2=A0 =C2= =A01: presenter's name
=C2=A0 =C2=A02: draft name / presentation tit= le
=C2=A0 =C2=A03: length of the presentation

Thanks,
--
tcpm c= o-chairs
--001a1148390a067d96053f0751b5-- From nobody Mon Oct 17 14:36:28 2016 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 773C9129471 for ; Mon, 17 Oct 2016 14:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431] autolearn=ham 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 PIEbXipiw6Ee for ; Mon, 17 Oct 2016 14:36:25 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 943381294A1 for ; Mon, 17 Oct 2016 14:36:25 -0700 (PDT) Received: from [107.17.163.150] ([107.17.163.150]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u9HLa4lJ011354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Oct 2016 14:36:06 -0700 (PDT) From: Joe Touch To: Yuchung Cheng , Michael Welzl References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> <082F8364-EE54-4EC0-B44D-F69D1BE515E7@ifi.uio.no> Message-ID: <95959006-ef57-e24e-3396-020564d04a1e@isi.edu> Date: Mon, 17 Oct 2016 14:36:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0BB8A00426E42B699A8D4E79" X-MailScanner-ID: u9HLa4lJ011354 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 17 Oct 2016 21:36:27 -0000 This is a multi-part message in MIME format. --------------0BB8A00426E42B699A8D4E79 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, Yuchung, 2140 sharing benefits depend on the length of the new connection and the amount to which its parameters vary from TCP's defaults. All connections start with defaults; the difference is whether they depend on previous/concurrent connections or are fixed in advance.The extent to which the metrics cache is useful thus depends on the actual connections at the time. Regarding some of those metrics: On 10/15/2016 4:29 PM, Yuchung Cheng wrote: > ... > > RTT/RTTVAR: RTT is readily available after SYN, so the most useful > place is SYN timeout. But the draft says we should not set anything > more aggressive than the minimum requirement by standard, which is > 1sec by RFC6298. How can fast connection retry SYN faster to lower > handshake time? or I mis-read the draft. Recently a detailed > investigation on Linux RTO also question the form of RTT caching > (paper > ). > Also another report by Anna: RTTVAR won't be meaningful for several RTTs and it is important in how RTT is interpreted. RTTs shouldn't be spun down too low with 2140, but they could be much higher. I.e., the opposite condition of the paper you're citing. The extent to which these values affects new connects decreases over time, so they are more important for the first few round trips (as is true for most shared parameters). > MSS,PMTU: I know MSS cache is useful for Fast Open b/c we need to > decide how much to put in SYN. Other than that I really don't know how > this helps performance for something we communicated at handshake. > Would that reduce potential middlebox issues? not clear. SYNs can contain data even without FO. Having past or concurrent context can be also be useful to detect when multipath routing is occuring (when it changes with a new connection) or when routes are not stable (when the values vary over time). > cwnd/ssthresh: we've covered this. > > The bis draft lists newly identified issues with TCB (e.g. ECMP) but > it's unclear whether the implementor should do something or just > ignore. To conclude, my one question is after ~20 years of RFC2140 > published, is the current implementation of TCB sharing useful (by data)? The answer depends on the context of the connections. What we can know is whether this is consistent with TCP (it is) and whether it has the potential for providing more information to the new connection (it does). What a new connection does with the information is up to the implementer. > If the draft does not address this question, what's new in this > informational bis? A more detailed discussion of what has been implemented and the issues involved. Joe --------------0BB8A00426E42B699A8D4E79 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi, Yuchung,

2140 sharing benefits depend on the length of the new connection and the amount to which its parameters vary from TCP's defaults. All connections start with defaults; the difference is whether they depend on previous/concurrent connections or are fixed in advance.The extent to which the metrics cache is useful thus depends on the actual connections at the time.

Regarding some of those metrics:


On 10/15/2016 4:29 PM, Yuchung Cheng wrote:
...

RTT/RTTVAR: RTT is readily available after SYN, so the most useful place is SYN timeout. But the draft says we should not set anything more aggressive than the minimum requirement by standard, which is 1sec by RFC6298. How can fast connection retry SYN faster to lower handshake time? or I mis-read the draft. Recently a detailed investigation on Linux RTO also question the form of RTT caching (paper). Also another report by Anna:

RTTVAR won't be meaningful for several RTTs and it is important in how RTT is interpreted. RTTs shouldn't be spun down too low with 2140, but they could be much higher. I.e., the opposite condition of the paper you're citing.

The extent to which these values affects new connects decreases over time, so they are more important for the first few round trips (as is true for most shared parameters).

MSS,PMTU: I know MSS cache is useful for Fast Open b/c we need to decide how much to put in SYN. Other than that I really don't know how this helps performance for something we communicated at handshake. Would that reduce potential middlebox issues? not clear.

SYNs can contain data even without FO. Having past or concurrent context can be also be useful to detect when multipath routing is occuring (when it changes with a new connection) or when routes are not stable (when the values vary over time).

cwnd/ssthresh: we've covered this.

The bis draft lists newly identified issues with TCB (e.g. ECMP) but it's unclear whether the implementor should do something or just ignore. To conclude, my one question is after ~20 years of RFC2140 published, is the current implementation of TCB sharing useful (by data)?

The answer depends on the context of the connections. What we can know is whether this is consistent with TCP (it is) and whether it has the potential for providing more information to the new connection (it does). What a new connection does with the information is up to the implementer.

If the draft does not address this question, what's new in this informational bis?

A more detailed discussion of what has been implemented and the issues involved.

Joe
--------------0BB8A00426E42B699A8D4E79-- From nobody Mon Oct 17 16:44:45 2016 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 58E9D1299AA for ; Mon, 17 Oct 2016 16:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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, RP_MATCHES_RCVD=-0.431, 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 kxerlixuX-fR for ; Mon, 17 Oct 2016 16:44:42 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 A2FD11299AB for ; Mon, 17 Oct 2016 16:44:42 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q192so205502959iod.0 for ; Mon, 17 Oct 2016 16:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rGoxHd2iYUguW6RQXukfK+yEjCob5H+ycthIDHkGSHY=; b=Qnx1DZ6HiPJJ3ul+mtaIz2ktTf8jIwm896seE7LlCA1QZ6uzOFg2IZo07h5KbxET+8 oVq+Jn+VgdQuuR8H0zKKucymaraKNixSWJ60k2nixVWMFY9ktDJPDJ7xzXu3gtcnSHA5 AazdzzK9tJf67xivjOJkIdnXP+URWn8HleoUseooKXZ99gtP8rXcIB7g24WHZrzSFivz gap1PcTTBKqgC5NbzmthKPKPjA3PfnBwMw5udCaDC6yxaH22tcf+WhLW4jXz86j4FNa4 Rej0OzUjip8KA+egrqf5Yiwthb621Dv7bCTt/b5t9cnOEGFqUqNSQmtZ/zwgJlUgTxgx oRng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rGoxHd2iYUguW6RQXukfK+yEjCob5H+ycthIDHkGSHY=; b=jOxuUnIzgVZO8GMCoYYCJAvcnvJ2gtnEDX5aTanYh7wHabp7k+31LbJA7sb6LZo4VG gkljgJ+XAYslDeieUeme/4fndD7RMZ47q25lRxJdKUStmHP01G5PdGLFQVebg4aMYEOV uS22YzOqa3fpoGcuxSwkz0qjqmNrQ96znbqZV+ooGsFgPmW8KFxg4escCWTP9uVkOUvQ uKK5tExtY6pMfgHUKLoEozmCuCsDmq9WZk+dWKBXMuLE52UJX1N/bq6tfNSMeVgURDTw byZmcWaI5G/odQAu/w4rVwEWIpFMK9aNzfqQr2iH3WklrickylYiILnxs6bt3T4yo1J6 3fPA== X-Gm-Message-State: AA6/9RnXqWkimKm1+3JJeZ+BI/2rba4ZiR4IHwb371haBb8LT6HH99pDA0khFGS/UuEJrUp9A7tte8NS90NLiDej X-Received: by 10.107.29.21 with SMTP id d21mr26408491iod.10.1476747881896; Mon, 17 Oct 2016 16:44:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Mon, 17 Oct 2016 16:44:01 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Mon, 17 Oct 2016 16:44:01 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=001a1140a4faecbd88053f18289c Archived-At: Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Subject: Re: [tcpm] agenda for tcpm meeting at IETF 97 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, 17 Oct 2016 23:44:44 -0000 --001a1140a4faecbd88053f18289c Content-Type: text/plain; charset=UTF-8 On Sun, Oct 16, 2016 at 8:38 PM, Yoshifumi Nishida wrote: > Hello, > According to the preliminary agenda,(https://datatracker.ie > tf.org/meeting/97/agenda.html), we will have a 2.5-hour meeting slot on > ** 11/14 Monday morning (9:30 - 12:00) **. > > If you're planning to present something, please provide us the following > info. > > 1: presenter's name > Yuchung Cheng > 2: draft name / presentation title > TLP + RACK performance evaluation (draft: draf-ietf-tcpm-rack) > 3: length of the presentation > 25m (including Q&A) We are continuing to improve RACK. The new draft would try to address the comments since last meeting, and include a new section of Tail Loss Probe. We'll talk about experiment of RACK and its relationship to C.C.: without RACK it's difficult to keep TCP running at high speed under moderate losses. > > Thanks, > -- > tcpm co-chairs > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a1140a4faecbd88053f18289c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 16, 2016 at 8:38 PM, Yoshifumi Nishida &l= t;nishida@sfc.w= ide.ad.jp> wrote:
Hello,
According to the preliminary agenda,(https://data= tracker.ietf.org/meeting/97/agenda.html), we will have a 2.5-= hour meeting slot on ** 11/14 Monday morning (9:30 - 12:00) **.

If you're planning to present something, p= lease provide us the following info.=C2=A0

=C2=A0 =C2=A01: presenter's name
Yuchung Cheng=C2=A0
=C2=A0 =C2=A02: draft name / = presentation title
TLP + RACK perfor= mance evaluation (draft: draf-ietf-tcpm-rack)
=C2=A0 =C2=A03= : length of the presentation
25m (includ= ing Q&A)

We are continuing to improve RACK. Th= e new draft would try to address the comments since last meeting, and inclu= de a new section of Tail Loss Probe. We'll talk about experiment of RAC= K and its relationship to C.C.: without RACK it's difficult to keep TCP= running at high speed under moderate losses.
=C2=A0
Thanks,
--
tcpm co-chairs

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


--001a1140a4faecbd88053f18289c-- From nobody Thu Oct 20 14:29:14 2016 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 48B8A1296FF for ; Thu, 20 Oct 2016 14:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.369 X-Spam-Level: X-Spam-Status: No, score=0.369 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.431] autolearn=ham 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 3lsDH6zpDMWL for ; Thu, 20 Oct 2016 14:29:10 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id C6A581296FC for ; Thu, 20 Oct 2016 14:29:10 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 5E791176F3 for ; Thu, 20 Oct 2016 14:29:10 -0700 (PDT) Date: Thu, 20 Oct 2016 14:29:10 -0700 From: hiren panchasara To: tcpm@ietf.org Message-ID: <20161020212910.GF11808@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KJY2Ze80yH5MUxol" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [tcpm] Partial ack during sack recovery 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, 20 Oct 2016 21:29:12 -0000 --KJY2Ze80yH5MUxol Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi All, In FreeBSD stack, we don't really let respective congestion control algo decide the cwnd and ssthresh specially during loss. I am attempting to fix it such that we really follow what the CC algo dictates. For regular acks, in FreeBSD, we check for ABC/RFC3465 and let CC algo know about the ack with bytes acked and it decides the cwnd. I am not sure what's the correct way when a partial ack is received within sack recovery period. RFC6675 '5. Algorithm Details' has the section on if a packet is allowed to be sent based on pipe and cwnd in this situation. (We, FreeBSD, don't have full rfc implementation but I can see and add this case). My question is, who should decide cwnd on such an ack and how? And the guidance from RFC6675 (above) be followed after the cwnd is set? May be I am missing something obvious. Thanks for your time. Cheers, Hiren --KJY2Ze80yH5MUxol Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJYCTchXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l0MkH/1HrVoYWky2y6HcpwQZ8ONGe YJbiS+QbVE7hdpdFZhK6GYlDdWEphvJwinauOFnrPNHE4tIKqcQC9RxbYoK5jNaT SziozPjBrjTrIW2yxhBx3nMdouBBmXhVnpDt7utywzdxUsx//k84tkSs9HFBqFSI bENkUBFxKi2nPqSknibCc0v3wNXRoUCl9CO0XFWE1CKfdwYsLWqF8NI1k7sfncGA qw5n9ewPlzIjoxmSZqO9+iFTSQcr6gTjgErtOxIdj8JJ8rBpQA7PIA2vUve3Ac6V OTDUbyyO1usvYAN9W5nex73C2ppEDGn6IqAquig+z9cLk8UtFhIYkei1EnExKp0= =LW+U -----END PGP SIGNATURE----- --KJY2Ze80yH5MUxol-- From nobody Thu Oct 20 17:53:26 2016 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 93C7D12947C for ; Thu, 20 Oct 2016 17:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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, RP_MATCHES_RCVD=-0.431, 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 rJb7ntp2EtZ3 for ; Thu, 20 Oct 2016 17:53:22 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 7AC44124281 for ; Thu, 20 Oct 2016 17:53:22 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m138so129468001itm.0 for ; Thu, 20 Oct 2016 17:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o6W4NCZyQ9Vv8uJpoB75pBOLZFpQBi/Cy9MmNrtT4/U=; b=dgAkoh589M5kL8TVlJik4YWBa+5yiCno6ddrcuwVCDbjnmz4Fb8EX1n9Y6HdIiTuEf iBAdO9Qwbu9+LFEtCUDS3LJwFyvScLrWdX0mXjVSb8lLFhaUWDv2cuPB590ByPts4/9+ SKLRmBTvoFnh+I8nGK2YQo61PrH5QZZiQxSWnq+eQV0HpGyGEeoR6kcIN3b07hkEeasQ fu/V00QR6s54LjL6qgI3FHtVIc9MPbAHL8oMfHr3lGy28ypddkBBFwjAQkXZaauhUVr9 Q2iZWL5LMm6Q+fReAvM5SMrVWGufwcPMwsX/MCcCwgyUqMwttnG4kIWNNuE123dhitHp z5Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o6W4NCZyQ9Vv8uJpoB75pBOLZFpQBi/Cy9MmNrtT4/U=; b=Dw1wJMCJbc+xAIORSyW3hHdRLPXCbFeb4YPX/dbq484Bw3PthtFCjJNMPLZMD8ZwKN QYMHwR24ay6VHXh+EuBS6ECDuyJ9L9qzzB/YmXPJFtyjiuY+tlzeKM4cdnd/AA5Nue0d j4H3xQiHkmunWxEi6KFxrgnndv2ku2SzwHumNAxh4bsyriH/iPFfhMOLoo9hdepzvMx8 +kSjquq9CFa1hhYbM27mrrGnGHD+m5dcqkqK8XkKqVM2N/GIsn/6uokbtqTfpQeHjwYQ 3x2E2vs8vssrz/8a96wourTeHK1eX1fjR0tlYo3Pyb6pO9D6XJcpdfqO/mQf28zEUd2Z 32Dg== X-Gm-Message-State: AA6/9RlAPULZkPCljrNFUiQ96P8M6A3ZQgxpYRUr8MF8S4btQJ7e9Ew6FklOhmb3vwTonSxq0vex61XclQ0MDCj0 X-Received: by 10.107.29.21 with SMTP id d21mr3871895iod.10.1477011201590; Thu, 20 Oct 2016 17:53:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Thu, 20 Oct 2016 17:52:41 -0700 (PDT) In-Reply-To: <20161020212910.GF11808@strugglingcoder.info> References: <20161020212910.GF11808@strugglingcoder.info> From: Yuchung Cheng Date: Thu, 20 Oct 2016 17:52:41 -0700 Message-ID: To: hiren panchasara Content-Type: multipart/alternative; boundary=001a1140a4fa006013053f557882 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Partial ack during sack recovery 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: Fri, 21 Oct 2016 00:53:24 -0000 --001a1140a4fa006013053f557882 Content-Type: text/plain; charset=UTF-8 RFC6675 section 5. (4) Invoke fast retransmit and enter loss recovery as follows: (4.1) RecoveryPoint = HighData When the TCP sender receives a cumulative ACK for this data octet, the loss recovery phase is terminated. (4.2) ssthresh = cwnd = (FlightSize / 2) The congestion window (cwnd) and slow start threshold (ssthresh) are reduced to half of FlightSize per [RFC5681 ]. Additionally, note that [RFC5681 ] requires that any segments sent as part of the Limited Transmit mechanism not be counted in FlightSize for the purpose of the above equation. AFAIU cwnd and ssthresh remain const during recovery. in other words, during recovery you are sending 50% slower (than before recovery) On Thu, Oct 20, 2016 at 2:29 PM, hiren panchasara < hiren@strugglingcoder.info> wrote: > Hi All, > > In FreeBSD stack, we don't really let respective congestion control > algo decide the cwnd and ssthresh specially during loss. > I am attempting to fix it such that we really follow what the CC algo > dictates. > > For regular acks, in FreeBSD, we check for ABC/RFC3465 and let CC algo > know about the ack with bytes acked and it decides the cwnd. > > I am not sure what's the correct way when a partial ack is received > within sack recovery period. > > RFC6675 '5. Algorithm Details' has the section on if a packet is allowed > to be sent based on pipe and cwnd in this situation. (We, FreeBSD, don't > have full rfc implementation but I can see and add this case). > > My question is, who should decide cwnd on such an ack and how? And the > guidance from RFC6675 (above) be followed after the cwnd is set? > > May be I am missing something obvious. Thanks for your time. > Cheers, > Hiren > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a1140a4fa006013053f557882 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC6675 section 5.

   (4) Invoke fast retransmit and enter loss recovery as foll=
ows:

       (4.1) RecoveryPoint =3D HighData

             When the TCP sender receives a cumulative ACK for this data
             octet, the loss recovery phase is terminated.

       (4.2) ssthresh =3D cwnd =3D (FlightSize / 2)

             The congestion window (cwnd) and slow start threshold
             (ssthresh) are reduced to half of FlightSize per [RFC5681].
             Additionally, note that [RFC5681] requir=
es that any
             segments sent as part of the Limited Transmit mechanism not
             be counted in FlightSize for the purpose of the above
             equation.


=
AFAIU cwnd and ssthresh remain const during recovery. in other words, durin=
g recovery you are sending 50% slower (than before recovery)

<= br>
On Thu, Oct 20, 2016 at 2:29 PM, hiren pancha= sara <hiren@strugglingcoder.info> wrote:
Hi All,

In FreeBSD stack, we don't really let respective congestion control
algo decide the cwnd and ssthresh specially during loss.
I am attempting to fix it such that we really follow what the CC algo dicta= tes.

For regular acks, in FreeBSD, we check for ABC/RFC3465 and let CC algo
know about the ack with bytes acked and it decides the cwnd.

I am not sure what's the correct way when a partial ack is received
within sack recovery period.

RFC6675 '5. Algorithm Details' has the section on if a packet is al= lowed
to be sent based on pipe and cwnd in this situation. (We, FreeBSD, don'= t
have full rfc implementation but I can see and add this case).

My question is, who should decide cwnd on such an ack and how? And the
guidance from RFC6675 (above) be followed after the cwnd is set?

May be I am missing something obvious. Thanks for your time.
Cheers,
Hiren

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


--001a1140a4fa006013053f557882-- From nobody Fri Oct 21 16:22:34 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05C1294F2; Fri, 21 Oct 2016 16:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709206744.28214.6906658523721359738.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:07 -0700 Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 97 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:07 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:30:00) Monday, Morning Session I 0930-1200 Room Name: Park Ballroom 2 size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg httpbis tcpinc mptcp taps tsvarea tsvwg quic plus Second Priority: maprg aqm rtcweb rmcat Third Priority: ippm teas Special Requests: --------------------------------------------------------- From nobody Sun Oct 23 06:33:14 2016 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 111771296DC for ; Sun, 23 Oct 2016 06:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 Y95tUe5kANh9 for ; Sun, 23 Oct 2016 06:33:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51901296D2 for ; Sun, 23 Oct 2016 06:33:11 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EB6EBA6725D9D; Sun, 23 Oct 2016 13:33:06 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9NDX9hf032306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 23 Oct 2016 13:33:09 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9NDUj8i012223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Oct 2016 15:33:08 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Sun, 23 Oct 2016 15:31:18 +0200 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org" Thread-Topic: Small nits in draft-ietf-tcpm-dctcp-02 Thread-Index: AdItMbsIl8Rgybz4SguDBFLZWDr53Q== Date: Sun, 23 Oct 2016 13:31:16 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B3D718@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tcpm-dctcp@tools.ietf.org" Subject: [tcpm] Small nits in draft-ietf-tcpm-dctcp-02 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: Sun, 23 Oct 2016 13:33:13 -0000 Hi, As we want to move forward the DCTCP document, I had (again) a look at the = current version. I run into three nits that should be simple to fix: Section 1: "The queue must be short enough to absorb incast bursts without = excessive packet loss." Is this "short" really the intended meaning here? Figure 1: "m" is not introduced as far as I can see; this is only an editor= ial issue. Section 8: The security considerations could probably comment on, or refer = to, the statements on security concerns in Section 3.4 ("The security conce= rns addressed by both these RFCs might not apply in controlled environments= like datacenters, and it might not be necessary to cater to both the prese= nce of non-ECN servers."). This would result in a more comprehensive Sectio= n 8. Thanks Michael From nobody Wed Oct 26 22:11:37 2016 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 BC63B129B2C for ; Wed, 26 Oct 2016 22:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 X8bxO7VYyB3M for ; Wed, 26 Oct 2016 22:11:35 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 061CC129B29 for ; Wed, 26 Oct 2016 22:11:34 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id i127so34750283oia.2 for ; Wed, 26 Oct 2016 22:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7nj/b0avSo4entIPwmOj+dbANsFkRSjcctI9fO1WUig=; b=d5zyiScgSDA3Ht+L4ysFFLmhMkH4QmfMIFKe2PGPGWl8ZWfnQTV1SaXiBSyRCkozJ8 8UbIidKsv9uxLCPrfnHlep1GkJuSSFum9KyOPYoYPEQYuKobv3Ir7K3/zRJoYQZ+NA/R dRPOG6YeZlloHG/OF9omYnq6uuiPdgitSrM9y9wWmN9oIW82AUfL/F+BcaatFIPxbPm2 VQ4vu/54zjOAWoZE9SlEgQYeIzJ1ru3jSCMYLPTmV9e/6thE87oK1kLBc7TxFuq1YYJM 0P+d9ztz5Ys6UJnIu1aXUo+QsEHOWbR3gZPxAjoTVVYH7ZRbX3QOR/rKZ3MKp6Gyj69z ydjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7nj/b0avSo4entIPwmOj+dbANsFkRSjcctI9fO1WUig=; b=aBl409c5JPuxSDNcquevpKbt5604QnBBFG7Mv0F6jTkd0OgIjwjLfKhg/telH9mM1I H39fbfGWQ1hjTGAv9dId/gPppyjFWJbnsd1tKI3Rjv3/AbPtdPIVLt9LHpVvpIVI+8uH /N7sVK4+fC5OEsdMcuPwt9II1xajnnLivJFY8JByetZ+FbcRJm5k7CCIdXHDyCEsE3dS eoZuIA4C6MDt6ABLJ7ntgNEX+TMQvU0b/EHe5KOUQerOvEXbyu/Ypr30vnCNeUHJbm6B JUVqc4OJ+MqrieDbo09bd4hGz+aPCo+Z3crlq4Qo4AklubZXw70ZbvI297emcj+cAQ5N T25w== X-Gm-Message-State: ABUngvcZYHvrX4tfen64+LjoBlIwBRIP0YqkOEzVBioE5WOQ8oEEO2reRymTDqI0McShqoFvMlqQic6emoFKaUrm X-Received: by 10.36.0.210 with SMTP id 201mr941073ita.60.1477545093198; Wed, 26 Oct 2016 22:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.98.132 with HTTP; Wed, 26 Oct 2016 22:10:52 -0700 (PDT) In-Reply-To: <95959006-ef57-e24e-3396-020564d04a1e@isi.edu> References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> <082F8364-EE54-4EC0-B44D-F69D1BE515E7@ifi.uio.no> <95959006-ef57-e24e-3396-020564d04a1e@isi.edu> From: Yuchung Cheng Date: Wed, 26 Oct 2016 22:10:52 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 27 Oct 2016 05:11:37 -0000 On Mon, Oct 17, 2016 at 2:36 PM, Joe Touch wrote: > Hi, Yuchung, > > 2140 sharing benefits depend on the length of the new connection and the > amount to which its parameters vary from TCP's defaults. All connections > start with defaults; the difference is whether they depend on > previous/concurrent connections or are fixed in advance.The extent to which > the metrics cache is useful thus depends on the actual connections at the > time. > > Regarding some of those metrics: > > > On 10/15/2016 4:29 PM, Yuchung Cheng wrote: > > ... > > RTT/RTTVAR: RTT is readily available after SYN, so the most useful place is > SYN timeout. But the draft says we should not set anything more aggressive > than the minimum requirement by standard, which is 1sec by RFC6298. How can > fast connection retry SYN faster to lower handshake time? or I mis-read the > draft. Recently a detailed investigation on Linux RTO also question the form > of RTT caching (paper). Also another report by Anna: > > > RTTVAR won't be meaningful for several RTTs and it is important in how RTT > is interpreted. RTTs shouldn't be spun down too low with 2140, but they > could be much higher. I.e., the opposite condition of the paper you're > citing. > > The extent to which these values affects new connects decreases over time, > so they are more important for the first few round trips (as is true for > most shared parameters). > > MSS,PMTU: I know MSS cache is useful for Fast Open b/c we need to decide how > much to put in SYN. Other than that I really don't know how this helps > performance for something we communicated at handshake. Would that reduce > potential middlebox issues? not clear. > > > SYNs can contain data even without FO. Having past or concurrent context can > be also be useful to detect when multipath routing is occuring (when it > changes with a new connection) or when routes are not stable (when the > values vary over time). > > cwnd/ssthresh: we've covered this. > > The bis draft lists newly identified issues with TCB (e.g. ECMP) but it's > unclear whether the implementor should do something or just ignore. To > conclude, my one question is after ~20 years of RFC2140 published, is the > current implementation of TCB sharing useful (by data)? > > > The answer depends on the context of the connections. What we can know is > whether this is consistent with TCP (it is) and whether it has the potential > for providing more information to the new connection (it does). What a new > connection does with the information is up to the implementer. > > If the draft does not address this question, what's new in this > informational bis? > > > A more detailed discussion of what has been implemented and the issues > involved. OK I am convinced if the purpose is updated new issues then the -bis makes sense. IMO the most crucial feature of connection sharing is caching negative info, not positive info: pathological behaviors of the path and servers that can resort in total dis-connectivity. This is especially true for new features that uses new options and 'uncommon' protocol behaviors (e.g, TFO, tcp-inc watch out). Worst case I've seen is middle-box completely blocks all further packets from an IP after seeing a SYN-data packet. Some middle-box would wipe every option in SYN once if the SYN has an experimental option. The connection would work but no wscale and sack warrant poor performance, and the user is left wondering why his expensive new phone is so slow. While using IP-based indexing can still be too coarse for negative caching it works fine here by being conservative of bad paths (i.e. when in doubt don't try the fancy new feature). > > Joe From nobody Thu Oct 27 10:05:14 2016 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 DE7E512957F for ; Thu, 27 Oct 2016 10:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.331 X-Spam-Level: X-Spam-Status: No, score=-7.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431] autolearn=ham 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 GnOxLAsyEtI5 for ; Thu, 27 Oct 2016 10:05:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 27F061295EA for ; Thu, 27 Oct 2016 10:05:10 -0700 (PDT) Received: from [128.9.184.79] ([128.9.184.79]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u9RH444L002899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Oct 2016 10:04:05 -0700 (PDT) To: Yuchung Cheng References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> <082F8364-EE54-4EC0-B44D-F69D1BE515E7@ifi.uio.no> <95959006-ef57-e24e-3396-020564d04a1e@isi.edu> From: Joe Touch Message-ID: <9ab25eb3-8621-232d-2aa0-c0f540ad1af4@isi.edu> Date: Thu, 27 Oct 2016 10:04:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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, 27 Oct 2016 17:05:12 -0000 On 10/26/2016 10:10 PM, Yuchung Cheng wrote: > IMO the most crucial feature of connection sharing > is caching negative info, not positive info: pathological behaviors of > the path and servers that can resort in total dis-connectivity. The goal of 2140 sharing is to reduce transients. The sort of negative information you're considering isn't a transient. Thus I'm worried about the impact of caching it for the following reasons: - many of the mechanisms you mentioned aren't dual-stack (e.g., tcp-inc, or consider TCP-AO). There's not necessarily a "if secure doesn't work, retry without it". - the probe test for each connection could be intended to yield a different result, e.g., security often is configured differently for different ports within a host. - negative cached results could cause a host to fail to recover from errors, e.g., until the cache is cleared E.g., TCP-AO failures MUST NOT be cached for different SYN destination ports to the same host or to any port to a different host We'd have to look into each of the other variants more closely to determine whether negative caching makes sense or not. IMO, this could be mentioned with a strong warning to avoid negative caching unless based on specific analysis of a given feature. Joe From nobody Thu Oct 27 18:04:19 2016 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 E0E0612944C for ; Thu, 27 Oct 2016 18:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 1G1tCe-zStuD for ; Thu, 27 Oct 2016 18:04:16 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 137D9129440 for ; Thu, 27 Oct 2016 18:04:16 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id p136so35180193oic.1 for ; Thu, 27 Oct 2016 18:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BrLGwxgQpoPHhTfiPRTYlDqOSDqVyvnTt1Yw19PAM48=; b=l+sKu9iYFFgpqxP8fSB8Cm5hGPYjSYk39kpp2DbTtD25auC4FBT0d7IXphmYon5R8K yQzodEznchEFDnGCr7cFixHns9Csr1wWaCoHAEh8aNsIUuUx7KityvKgHXRUZd1PIB5W m0fbA17/QauNImwVFsvrRnY7IrwmVlFdiGoNdhqFHBrNl+JoEIhbdnfuLzvY4oiTEf7T OsCELYYevkYvNejx8nGxF1/nxoXvzdrwssiSSXZY+MM+rtPho4AEKIKrBAfvM7ejPGiz g6c05CDaPh0eR3GCKDPLpHFmvONWZvQmr55GMUM3fJnlITJKbushF6Lm6ajkqkvs51Ws 4Q9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BrLGwxgQpoPHhTfiPRTYlDqOSDqVyvnTt1Yw19PAM48=; b=Ge8S5fra6wB8p5h8ds0rX+3TG5lywlsoZIUKlhOqsJ8wE1aYHVY0VDV7Hdvjzf3QWC 1TukRrEF9a4Z/zkIMiEEt+DNxRcLgeGMNnMipTRcRmnqIy1xG3U1u7uOcoXPxnjG4Rbs o6CCrbYhqxjeSmHhIWbkzuye/K1WG6lgiOXlfASaYjdNrI9r1UTlp9ksTOU1/mL8PayC 5I1znN/Zsma4g9Se+lBp1eSjtFIdoJbkdgCjZUxKCAxb0aBl0YyfE0zbtESg97gtLWVD 5ubxUPqoMv5sRzWlHogab3/PHhL4oEuSdk9R9U9DPRqjqMF+2PwCzVBh+xhonomREITH 9ihA== X-Gm-Message-State: ABUngvcl1O27WD+UG+bTUxcMed5KE7uU5INyd76ZVozCPI6ZfHb3tgG9dnzZu0V6Z34ul8PJEdtflg+od/NP3AqJ X-Received: by 10.107.136.65 with SMTP id k62mr8649277iod.99.1477616655135; Thu, 27 Oct 2016 18:04:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Thu, 27 Oct 2016 18:03:34 -0700 (PDT) In-Reply-To: <9ab25eb3-8621-232d-2aa0-c0f540ad1af4@isi.edu> References: <655C07320163294895BBADA28372AF5D48AEFEB3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <49A1F90E-9D44-48B7-9BFF-E46798FC4C47@ifi.uio.no> <082F8364-EE54-4EC0-B44D-F69D1BE515E7@ifi.uio.no> <95959006-ef57-e24e-3396-020564d04a1e@isi.edu> <9ab25eb3-8621-232d-2aa0-c0f540ad1af4@isi.edu> From: Yuchung Cheng Date: Thu, 27 Oct 2016 18:03:34 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] draft-touch-tcpm-2140bis: wording improvement suggestions? 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: Fri, 28 Oct 2016 01:04:18 -0000 On Thu, Oct 27, 2016 at 10:04 AM, Joe Touch wrote: > > > On 10/26/2016 10:10 PM, Yuchung Cheng wrote: >> IMO the most crucial feature of connection sharing >> is caching negative info, not positive info: pathological behaviors of >> the path and servers that can resort in total dis-connectivity. > > The goal of 2140 sharing is to reduce transients. The sort of negative > information you're considering isn't a transient. Thus I'm worried about > the impact of caching it for the following reasons: I agree with your assessment of bad reaction to negative cache could result in worse result overall, and many of them need to be carefully done case by case. but my high level point is that I found the usefulness of negative caching is larger, in fact much larger than caching RTT and other TCP vars. > > - many of the mechanisms you mentioned aren't dual-stack (e.g., tcp-inc, > or consider TCP-AO). There's not necessarily a "if secure doesn't work, > retry without it". > > - the probe test for each connection could be intended to yield a > different result, e.g., security often is configured differently for > different ports within a host. > > - negative cached results could cause a host to fail to recover from > errors, e.g., until the cache is cleared > > E.g., TCP-AO failures MUST NOT be cached for different SYN destination > ports to the same host or to any port to a different host > > We'd have to look into each of the other variants more closely to > determine whether negative caching makes sense or not. IMO, this could > be mentioned with a strong warning to avoid negative caching unless > based on specific analysis of a given feature. > > Joe From nobody Fri Oct 28 08:01:39 2016 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 E31DE129739 for ; Thu, 27 Oct 2016 12:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.033 X-Spam-Level: X-Spam-Status: No, score=-103.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 etBEJ-uI_sWp for ; Thu, 27 Oct 2016 12:26:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14BE12970F for ; Thu, 27 Oct 2016 12:26:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CC3B8B803A6; Thu, 27 Oct 2016 12:26:57 -0700 (PDT) To: ananth@cisco.com, randall@lakerest.net, mdalal@cisco.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, nishida@sfc.wide.ad.jp, michael.scharf@nokia.com, tuexen@fh-muenster.de X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161027192657.CC3B8B803A6@rfc-editor.org> Date: Thu, 27 Oct 2016 12:26:57 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 28 Oct 2016 08:01:36 -0700 Cc: tcpm@ietf.org, tuexen@fh-muenster.de, rfc-editor@rfc-editor.org Subject: [tcpm] [Technical Errata Reported] RFC5961 (4845) 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, 27 Oct 2016 19:27:00 -0000 The following errata report has been submitted for RFC5961, "Improving TCP's Robustness to Blind In-Window Attacks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5961&eid=4845 -------------------------------------- Type: Technical Reported by: Michael Tüxen Section: 3.2 Original Text ------------- 1) If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND), silently drop the segment. Corrected Text -------------- 1) If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ < RCV.NXT || SEG.SEQ >= RCV.NXT+ RCV.WND), silently drop the segment. Notes ----- The condition being corrected should be the opposite of (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), which is stated in the second item of the enumeration. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5961 (draft-ietf-tcpm-tcpsecure-13) -------------------------------------- Title : Improving TCP's Robustness to Blind In-Window Attacks Publication Date : August 2010 Author(s) : A. Ramaiah, R. Stewart, M. Dalal Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Fri Oct 28 19:06:37 2016 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 4A885129457; Fri, 28 Oct 2016 19:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=k9A7tzd8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=iI7mUFeQ 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 qg_62Il39Jtz; Fri, 28 Oct 2016 19:06:28 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C55F129406; Fri, 28 Oct 2016 19:06:28 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=wshj/vu8tdaxE+1uMKH3/tJHVcrbOR9VRDb5id85GQ7fWpN1SEF5yi7z dU5dym+8IRoucDp/T+W46rbDWNGYPXch+aK/hiyRY49LOn4GMaesWh13k r+picxq7unS1JL0qY8JSQUJCIWXNq8sJLvxB2AcReygwXozFr6Cne+J3o A=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477706788; x=1509242788; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=16IJOsCZuSNMMwtwEOOZysn6KlqKNaJxxzOapUMgA2w=; b=k9A7tzd8gnQ1QZSYfrS56DAbOPTzoEZhz5rQc0Txv6Ys+gKTRg5+gSQE i1UDxHq5o9ZetjScYvGqTXkfhPQoOxFiW0nWWxVPAkwcf6qDG8DG4Al/f bdly+O6dxz/vUEmC8SgcPzpqnsArF+hBaSMVBjaRV8U55ZTVWd0ByuvsH Q=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 21:06:27 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2016 08:06:27 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T26PP2027336 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 22:06:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u9T26PP2027336 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477706786; bh=n79s6MMdD/hnmoqIEl3u7VSmKkE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=iI7mUFeQNakMYKDgKF4fJo3p7l9V5tZqY21mbblr26y1g+a96V0k8ZaXvaG/FdPXm GVfW54B0Z1YQlfInjyN3lSVZJOV4DsUNTYC4lZ0bf/Ex1IAbBgqlcxQyxmFTtHzE83 /i1BP5hvjMFZz5dPK9w7BIgkjzfAOxAnr83cOIxY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u9T26PP2027336 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 28 Oct 2016 22:04:40 -0400 Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T266gu013805 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Oct 2016 22:06:07 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB316.corp.emc.com ([10.146.3.94]) with mapi id 14.03.0266.001; Fri, 28 Oct 2016 22:06:06 -0400 To: "tsvwg@ietf.org" , "tcpm@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: New Version Notification for draft-black-tsvwg-ecn-experimentation-02.txt Thread-Index: AQHSMYhxPK/++Q1yqUuTvYdsXsouuaC+rfCg Date: Sat, 29 Oct 2016 02:06:05 +0000 Message-ID: References: <147770651989.24883.8392540470740722082.idtracker@ietfa.amsl.com> In-Reply-To: <147770651989.24883.8392540470740722082.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: [tcpm] FW: New Version Notification for draft-black-tsvwg-ecn-experimentation-02.txt 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: Sat, 29 Oct 2016 02:06:30 -0000 VGhlIGNoYW5nZXMgaW4gIHRoZSAtMDIgdmVyc2lvbiBmcm9tIHRoZSAtMDEgYXJlIHByaW1hcmls eSBjb3VydGVzeSBvZiBhDQp0aG9yb3VnaCByZXZpZXcgYnkgQm9iIEJyaXNjb2UuDQoNCldoZXRo ZXIgdG8gcmVxdWlyZSAoTVVTVCkgb3Igc3Ryb25nbHkgZW5jb3VyYWdlIChTSE9VTEQpIHVzZSBv ZiBFQ1QoMCkNCmFuZCBub3QgRUNUKDEpIGlzIGFuIG9wZW4gaXNzdWUgdGhhdCBvdWdodCB0byBi ZSBkaXNjdXNzZWQgaW4gU2VvdWwgKFRTVldHDQppcyB0aGUgbGlrZWx5IHZlbnVlKS4NCg0KQXMg YW4gaW5kaXZpZHVhbCwgSSByZXF1ZXN0IHRoYXQgdGhpcyBkcmFmdCBiZSBwdXQgb24gdGhlIFRT VldHIGFnZW5kYSBmb3INClNlb3VsIHdpdGggYSByZXF1ZXN0IGZvciBUU1ZXRyBXRyBhZG9wdGlv bi4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDE2IDEwOjAyIFBNDQpUbzogQmxhY2ss IERhdmlkDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJsYWNr LXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWJsYWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDIudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhdmlkIEJsYWNrIGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1ibGFjay10c3Z3Zy1lY24tZXhwZXJp bWVudGF0aW9uDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3Rp ZmljYXRpb24gKEVDTikgRXhwZXJpbWVudGF0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE2LTEwLTI4 DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ibGFjay10c3Z3 Zy1lY24tZXhwZXJpbWVudGF0aW9uLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJsYWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRp b24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJs YWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDINCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYmxhY2stdHN2d2ctZWNuLWV4cGVyaW1l bnRhdGlvbi0wMg0KDQpBYnN0cmFjdDoNCiAgIE11bHRpcGxlIHByb3RvY29sIGV4cGVyaW1lbnRz IGhhdmUgYmVlbiBwcm9wb3NlZCB0aGF0IGludm9sdmUgY2hhbmdlcw0KICAgdG8gRXhwbGljaXQg Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgYXMgc3BlY2lmaWVkIGluIFJGQyAzMTY4Lg0K ICAgVGhpcyBtZW1vIHN1bW1hcml6ZXMgdGhlIHByb3Bvc2VkIGFyZWFzIG9mIGV4cGVyaW1lbnRh dGlvbiB0byBwcm92aWRlDQogICBhbiBvdmVydmlldyB0byB0aGUgSW50ZXJuZXQgY29tbXVuaXR5 IGFuZCB1cGRhdGVzIFJGQyAzMTY4LCBhDQogICBQcm9wb3NlZCBTdGFuZGFyZCBSRkMsIHRvIGFs bG93IHRoZSBleHBlcmltZW50cyB0byBwcm9jZWVkIHdpdGhvdXQNCiAgIHJlcXVpcmluZyBhIHN0 YW5kYXJkcyBwcm9jZXNzIGV4Y2VwdGlvbiBmb3IgZWFjaCBFeHBlcmltZW50YWwgUkZDIHRvDQog ICB1cGRhdGUgUkZDIDMxNjguICBFYWNoIGV4cGVyaW1lbnQgaXMgc3RpbGwgcmVxdWlyZWQgdG8g YmUgZG9jdW1lbnRlZA0KICAgaW4gYW4gRXhwZXJpbWVudGFsIFJGQy4gIEluIGFkZGl0aW9uLCB0 aGlzIG1lbW8gbWFrZXMgcmVsYXRlZCB1cGRhdGVzDQogICB0byB0aGUgRUNOIHNwZWNpZmljYXRp b25zIGZvciBSVFAgaW4gUkZDIDY2NzkgYW5kIHRvIHRoZSBFQ04NCiAgIHNwZWNpZmljYXRpb25z IGZvciBEQ0NQIGluIFJGQyA0MzQxLCBSRkMgNDM0MiBhbmQgUkZDIDU2MjIuICBUaGlzDQogICBt ZW1vIGFsc28gcmVjb3JkcyB0aGUgY29uY2x1c2lvbiBvZiB0aGUgRUNOIE5vbmNlIGV4cGVyaW1l bnQgaW4gUkZDDQogICAzNTQwLCBvYnNvbGV0ZXMgUkZDIDM1NDAgYW5kIHJlY2xhc3NpZmllcyBp dCBhcyBIaXN0b3JpYyB0byBlbmFibGUNCiAgIG5ldyBleHBlcmltZW50YWwgdXNlIG9mIHRoZSBF Q1QoMSkgY29kZXBvaW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun Oct 30 04:00:36 2016 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 97AF512943E for ; Sun, 30 Oct 2016 04:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.096 X-Spam-Level: X-Spam-Status: No, score=-4.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] autolearn=ham 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 LWTH_KrmsB97 for ; Sun, 30 Oct 2016 04:00:33 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1051293EC for ; Sun, 30 Oct 2016 04:00:33 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c0nqn-0007Jf-Qx for tcpm@ietf.org; Sun, 30 Oct 2016 12:00:29 +0100 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx3.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c0nqm-00074u-Cx for tcpm@ietf.org; Sun, 30 Oct 2016 12:00:29 +0100 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_16C7AF84-2FD3-4EF2-8EBF-2E03D39295BB" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <22F5A21A-7DD1-41B6-89C4-6258129D440B@ifi.uio.no> References: <147782499926.20736.711254288289596804.idtracker@ietfa.amsl.com> To: tcpm@ietf.org Date: Sun, 30 Oct 2016 12:00:30 +0100 X-Mailer: Apple Mail (2.3251) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 6 sum msgs/h 4 total rcpts 48064 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6839F7A565A4BBF99EC4CD27267B1D37247D29AB X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 350 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-01.txt 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: Sun, 30 Oct 2016 11:00:35 -0000 --Apple-Mail=_16C7AF84-2FD3-4EF2-8EBF-2E03D39295BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, FYI, new ABE draft posted, see below. This is a minor update to refer to = draft-black-tsvwg-ecn-experimentation-02 which is a broader document to = allow for ECN experimentation. For the alternative backoff changes = required to RFC3168, it takes the role of = draft-khademi-tsvwg-ecn-response-00. Cheers, Michael > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-khademi-tcpm-alternativebackoff-ecn-01.txt > Date: October 30, 2016 at 11:56:39 AM GMT+1 > To: Gorry Fairhurst , Grenville Armitage = , Naeem Khademi , Godred = Fairhurst , Michael Welzl > Resent-From: >=20 >=20 > A new version of I-D, draft-khademi-tcpm-alternativebackoff-ecn-01.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-khademi-tcpm-alternativebackoff-ecn > Revision: 01 > Title: TCP Alternative Backoff with ECN (ABE) > Document date: 2016-10-30 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-khademi-tcpm-alternativebackoff= -ecn-01.txt > Status: = https://datatracker.ietf.org/doc/draft-khademi-tcpm-alternativebackoff-ecn= / > Htmlized: = https://tools.ietf.org/html/draft-khademi-tcpm-alternativebackoff-ecn-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-khademi-tcpm-alternativebackoff-= ecn-01 >=20 > Abstract: > This memo updates the TCP sender-side reaction to a congestion > notification received via Explicit Congestion Notification (ECN). > The updated method reduces FlightSize in Congestion Avoidance by a > smaller amount than the TCP reaction to loss. The intention is to > achieve good throughput when the queue at the bottleneck is smaller > than the bandwidth-delay-product of the connection. This is more > likely when an Active Queue Management (AQM) mechanism has used ECN > to CE-mark a packet, than when a packet was lost. Future versions = of > this document will also describe a corresponding method for SCTP. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_16C7AF84-2FD3-4EF2-8EBF-2E03D39295BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

FYI, = new ABE draft posted, see below.
This is a minor = update to refer to draft-black-tsvwg-ecn-experimentation-02 which is a broader = document to allow for ECN experimentation. For the alternative backoff = changes required to RFC3168, it takes the role of draft-khademi-tsvwg-ecn-response-00.

Cheers,
Michael


Begin = forwarded message:

From: = <internet-drafts@ietf.org>
Subject: = New Version = Notification for draft-khademi-tcpm-alternativebackoff-ecn-01.txt
Date: = October 30, 2016 at 11:56:39 AM = GMT+1
To: = Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Grenville Armitage <garmitage@swin.edu.au>, Naeem Khademi <naeemk@ifi.uio.no>, = Godred Fairhurst <gorry@erg.abdn.ac.uk>, Michael Welzl <michawe@ifi.uio.no>
Resent-From: = <michawe@ifi.uio.no>


A new version = of I-D, draft-khademi-tcpm-alternativebackoff-ecn-01.txt
has= been successfully submitted by Michael Welzl and posted to the
IETF repository.

Name: = draft-khademi-tcpm-alternativebackoff-ecn
Revision: 01
Title: TCP = Alternative Backoff with ECN (ABE)
Document date: = 2016-10-30
Group: Individual Submission
Pages:= = 10
URL: =            https://www.ietf.org/internet-drafts/draft-khademi-tcpm-alterna= tivebackoff-ecn-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-khademi-tcpm-alternative= backoff-ecn/
Htmlized: =       https://tools.ietf.org/html/draft-khademi-tcpm-alternativebacko= ff-ecn-01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-khademi-tcpm-alternat= ivebackoff-ecn-01

Abstract:
  This memo updates the TCP sender-side reaction = to a congestion
  notification received via = Explicit Congestion Notification (ECN).
  The = updated method reduces FlightSize in Congestion Avoidance by a
  smaller amount than the TCP reaction to loss. =  The intention is to
  achieve good = throughput when the queue at the bottleneck is smaller
=   than the bandwidth-delay-product of the connection. =  This is more
  likely when an Active = Queue Management (AQM) mechanism has used ECN
=   to CE-mark a packet, than when a packet was lost. =  Future versions of
  this document will = also describe a corresponding method for SCTP.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_16C7AF84-2FD3-4EF2-8EBF-2E03D39295BB-- From nobody Mon Oct 31 04:21:40 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E06AE1295A4; Mon, 31 Oct 2016 04:21:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147791289891.32484.6519442046228124793.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 04:21:38 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 11:21:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : More Accurate ECN Feedback in TCP Authors : Bob Briscoe Mirja Kühlewind Richard Scheffenegger Filename : draft-ietf-tcpm-accurate-ecn-02.txt Pages : 37 Date : 2016-10-31 Abstract: Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the end-points. Receivers with an ECN- capable transport protocol feed back this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently, new TCP mechanisms like Congestion Exposure (ConEx) or Data Center TCP (DCTCP) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document specifies an experimental scheme to provide more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it overloads the three existing ECN-related flags in the TCP header and provides additional information in a new TCP option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 05:36:56 2016 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 D6A0B12973E; Mon, 31 Oct 2016 05:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 mla6OkNfCmyv; Mon, 31 Oct 2016 05:36:48 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 DB7A912975C; Mon, 31 Oct 2016 05:36:43 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u9VCafnO036660; Mon, 31 Oct 2016 13:36:41 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 825931D53C1; Mon, 31 Oct 2016 13:36:41 +0100 (CET) Received: from 78.151.199.138 by webmail.entel.upc.edu with HTTP; Mon, 31 Oct 2016 13:36:00 +0100 Message-ID: <563cd49c505340a559cded05282a3dc6.squirrel@webmail.entel.upc.edu> Date: Mon, 31 Oct 2016 13:36:00 +0100 From: "Carles Gomez Montenegro" To: lwip@ietf.org, "tcpm@ietf.org Extensions" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.98.7 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Mon, 31 Oct 2016 13:36:41 +0100 (CET) Archived-At: Subject: [tcpm] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.txt] 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, 31 Oct 2016 12:36:52 -0000 Dear LWIG and TCPM WGs, Please find below pointers to our update of the TCP over Constrained-Node Networks I-D. In this version we expand the document while trying to address many of the comments received on -00. The main changes are: - Remove RFC 2119 language and rather document how TCP can be used in CNNs - Illustrate scenario (e.g. constrained to unconstrained device...) - 'Allow' window greater than 1 MSS (and Fast recovery & Fast retransmit) - Add TCP Fast Open subsection - Add Delayed ACKs section - Improve section on TCP options - Collect implementation details (Annex) Note that the home WG for this work is LWIG (as discussed in Berlin). Thanks a lot for the feedback received so far. Comments on -01 are welcome and appreciated! Cheers, Carles and Jon ---------------------------- Original Message ---------------------------- Subject: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.txt From: internet-drafts@ietf.org Date: Mon, October 31, 2016 1:13 pm To: "Jon Crowcroft" "Carles Gomez" -------------------------------------------------------------------------- A new version of I-D, draft-gomez-lwig-tcp-constrained-node-networks-01.txt has been successfully submitted by Carles Gomez and posted to the IETF repository. Name: draft-gomez-lwig-tcp-constrained-node-networks Revision: 01 Title: TCP over Constrained-Node Networks Document date: 2016-10-31 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-gomez-lwig-tcp-constrained-node-networks-01.txt Status: https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node-networks/ Htmlized: https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-gomez-lwig-tcp-constrained-node-networks-01 Abstract: This document provides a profile for the Transmission Control Protocol (TCP) over Constrained-Node Networks (CNNs). The overarching goal is to offer simple measures to allow for lightweight TCP implementation and suitable operation in such environments. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 31 08:06:26 2016 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 5BE861294F1; Mon, 31 Oct 2016 08:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham 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 EFuYW-IoASDC; Mon, 31 Oct 2016 08:06:23 -0700 (PDT) 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 7317D1294D0; Mon, 31 Oct 2016 08:06:23 -0700 (PDT) Received: from mail-ua0-f171.google.com (mail-ua0-f171.google.com [209.85.217.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D21602782F6; Tue, 1 Nov 2016 00:06:21 +0900 (JST) Received: by mail-ua0-f171.google.com with SMTP id 12so106062475uas.2; Mon, 31 Oct 2016 08:06:21 -0700 (PDT) X-Gm-Message-State: ABUngvflQtuk3FfFIVhS+txPFTF/mCnztlwl8m8fU+jQWOtPf5Y5ghzOUfbWC3b1SvhM4rbztAGWLbQtZ6E+Qw== X-Received: by 10.176.2.167 with SMTP id 36mr17549728uah.41.1477926376449; Mon, 31 Oct 2016 08:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.84.208 with HTTP; Mon, 31 Oct 2016 08:06:16 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Mon, 31 Oct 2016 08:06:16 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Subject: Re: [tcpm] agenda for tcpm meeting at IETF 97 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, 31 Oct 2016 15:06:25 -0000 Hello, If you're interested in presenting something in Seoul, please reach out to chairs. I think we still have some slots. Thanks, -- Yoshi On Sun, Oct 16, 2016 at 8:38 PM, Yoshifumi Nishida wrote: > Hello, > According to the preliminary > agenda,(https://datatracker.ietf.org/meeting/97/agenda.html), we will have a > 2.5-hour meeting slot on ** 11/14 Monday morning (9:30 - 12:00) **. > > If you're planning to present something, please provide us the following > info. > > 1: presenter's name > 2: draft name / presentation title > 3: length of the presentation > > Thanks, > -- > tcpm co-chairs From nobody Mon Oct 31 09:11:00 2016 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 488FE129873; Mon, 31 Oct 2016 09:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 dpg3Mub4Ncor; Mon, 31 Oct 2016 09:10:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EC8129856; Mon, 31 Oct 2016 09:10:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A62D6B81BEB; Mon, 31 Oct 2016 09:10:57 -0700 (PDT) To: tuexen@fh-muenster.de, ananth@cisco.com, randall@lakerest.net, mdalal@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161031161057.A62D6B81BEB@rfc-editor.org> Date: Mon, 31 Oct 2016 09:10:57 -0700 (PDT) Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Errata Verified] RFC5961 (4845) 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, 31 Oct 2016 16:10:59 -0000 The following errata report has been verified for RFC5961, "Improving TCP's Robustness to Blind In-Window Attacks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5961&eid=4845 -------------------------------------- Status: Verified Type: Technical Reported by: Michael Tüxen Date Reported: 2016-10-27 Verified by: Mirja Kühlewind (IESG) Section: 3.2 Original Text ------------- 1) If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND), silently drop the segment. Corrected Text -------------- 1) If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ < RCV.NXT || SEG.SEQ >= RCV.NXT+ RCV.WND), silently drop the segment. Notes ----- The condition should be the opposite of (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), which is stated in the second item of the enumeration. -------------------------------------- RFC5961 (draft-ietf-tcpm-tcpsecure-13) -------------------------------------- Title : Improving TCP's Robustness to Blind In-Window Attacks Publication Date : August 2010 Author(s) : A. Ramaiah, R. Stewart, M. Dalal Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Oct 31 15:31:34 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDC4129B9B; Mon, 31 Oct 2016 15:31:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795309217.23279.4641208457390778216.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 15:31:32 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:31:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : RACK: a time-based fast loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Filename : draft-ietf-tcpm-rack-01.txt Pages : 22 Date : 2016-10-31 Abstract: This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 16:09:01 2016 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 EEC8D129509; Mon, 31 Oct 2016 16:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=l7g+vDG0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=W/IDzJSp 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 GJLmZ2v3IH5E; Mon, 31 Oct 2016 16:08:59 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC8C129ACA; Mon, 31 Oct 2016 16:08:59 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=XfGhO9Sz+pIrvmtBs0KBwptCG6YmRKwaDGSgUxNowHbiFzdHN7HV0xG7 6yGvzTg3b0tswk8nkiQIHfuy6OkGQfXVO++/ATIYslhrg/l/cQ0pDJ3Xr +7qbY6cSplbE91qyRyvfZfi9sh15reSJeZUTG5vR7yMdPrmWx88DgYngP Y=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477955339; x=1509491339; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2ei2LvlOz01Y/BpZr+8NEkl01XYBRtVYHJpMeEL0CDU=; b=l7g+vDG05GJIg18rCXFjfJXON36FMKUFe+XCgCPRNE8a39pKNZakwahg +g4F5Wqbp7nnuUbdgR88PFij0/4Dzc3XWfSZ5ZudOuASrSjABm290vnJF b35aU+79Okr3YNEFd3E0RUVwfEO73bpP4s13CD2O65fGEbLayjCP8Ycp9 Q=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2016 18:08:59 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 05:08:58 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9VN8uee000800 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Oct 2016 19:08:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u9VN8uee000800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477955337; bh=jRr0tzn+pX55yYiaCbs0Remt0Fo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=W/IDzJSpwHrNBJoa9mhyt5kIJ9qxuk2k3xsq3Qzyu9Sq4Uu+/pdi/9ptxQBxrCaNN cId7yvBHPiF6jmd5K+XAbLvfa1Go39zzAWWwRYwG8zeyOPvVRO0KTkGRuWeYQ/nOV4 U8h3mOoH75m5GAsw64/GE1CYPuFT/CGSk4dvdimE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u9VN8uee000800 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 31 Oct 2016 19:07:19 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9VN8guP009807 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 31 Oct 2016 19:08:43 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Mon, 31 Oct 2016 19:08:42 -0400 To: "tsvwg@ietf.org" , "tcpm@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: I-D Action: draft-black-tsvwg-ecn-experimentation-03.txt Thread-Index: AQHSM8l4c70ay2gM4E+p3q2EkPlANKDDL3Vg Date: Mon, 31 Oct 2016 23:08:41 +0000 Message-ID: References: <147795434531.23271.3974811936089328519.idtracker@ietfa.amsl.com> In-Reply-To: <147795434531.23271.3974811936089328519.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tcpm] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-03.txt 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, 31 Oct 2016 23:09:01 -0000 Minor changes: - Bob Briscoe found a couple more small items that needed attention - idnits turned out to be correct about which boilerplate to use. Thanks, --David -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, October 31, 2016 6:52 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Explicit Congestion Notification (ECN) Experiment= ation Author : David Black Filename : draft-black-tsvwg-ecn-experimentation-03.txt Pages : 13 Date : 2016-10-31 Abstract: Multiple protocol experiments have been proposed that involve changes to Explicit Congestion Notification (ECN) as specified in RFC 3168. This memo summarizes the proposed areas of experimentation to provide an overview to the Internet community and updates RFC 3168, a Proposed Standard RFC, to allow the experiments to proceed without requiring a standards process exception for each Experimental RFC to update RFC 3168. Each experiment is still required to be documented in an Experimental RFC. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and to the ECN specifications for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic to enable new experimental use of the ECT(1) codepoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-black-tsvwg-ecn-experimentation-0= 3 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Oct 31 16:18:54 2016 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 C852F129992 for ; Mon, 31 Oct 2016 16:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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=-1.497, 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 OacdtfUDVFp8 for ; Mon, 31 Oct 2016 16:18:52 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 D5576129B37 for ; Mon, 31 Oct 2016 16:18:51 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id i127so255950797oia.2 for ; Mon, 31 Oct 2016 16:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0vXwYZvxtgCqXiCmlYMLCi7VCQWItS5Ldi7UMYtbKXA=; b=aYEHL2DnlmOevN5p//NBr/Qt0aFkbZYqC7R9S4rWG/b1mRSzgLjshMcLvRk+sHnjFj sheJuKkIuzWIgKANJUPjY58GMgTeqsr8wWTjy60nYR5LB5OH8rNN2SN6U++1gQow21M/ 9AmW42rqQ8kykq741NF1qXl/C8CmAYybAJi6Wxd1iR37xpqxcmRbn3qE+eyR6AXKuVo8 BYSVGIYpiakAoL+F/gzJQSGcX1pP5fEA1obvsCuKPhsSsITwiRMiKQ+dy+RBA4mVZUiu QtvCC6K4EhquLuLEUXoCCKZErml79ysdGom/JIqLEn/0JQvww3YrinYUwwAfbD+0yNiF vM1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=0vXwYZvxtgCqXiCmlYMLCi7VCQWItS5Ldi7UMYtbKXA=; b=lZm1cFp7HCpIduhwqW339OUte8YOnRR2BTN1uCEYYOzRoyBu31CMt5P0FJsxhFDFGb MwDq8VyKt/ZQTY8bqGWAAGJoo9WXqPAAb88VHvHiJ3zr7pNP6u/gTBnVMjOcw3mvsawa lknZm/2eOPWicim5Xjtei/HnZCUybTjerxvzGlMjrjU5R2Dmo5iRTfm2RdNolgxYwl5L AekcbX77nKhjkTMr1xl+BnHWZAZkWrDlPZil2/54tWr2NJZAM+cJrjAj3Ilmuz930JTa o8NbxtXEQyy5tamaJdD3qsKEgVcTYxeMBAHYEcsmKFBHKEnQXzvIMlYMXfQbJxrQ5a7m 38Cg== X-Gm-Message-State: ABUngvevcWJ/cTydvYkXoTkIYhb5klo1PhbsJmMPMAKnGIhIXtEzlVdjK6VkVPu7MWdc5JcKAeTwv97DZtF6HoF9 X-Received: by 10.107.29.21 with SMTP id d21mr21783859iod.10.1477955929785; Mon, 31 Oct 2016 16:18:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.163 with HTTP; Mon, 31 Oct 2016 16:18:09 -0700 (PDT) In-Reply-To: <147795309286.23279.5643447282066668625.idtracker@ietfa.amsl.com> References: <147795309286.23279.5643447282066668625.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 31 Oct 2016 16:18:09 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=001a1140a4fa30a54e0540316e56 Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rack-01.txt 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, 31 Oct 2016 23:18:54 -0000 --001a1140a4fa30a54e0540316e56 Content-Type: text/plain; charset=UTF-8 Hi group We have submitted another major rev of RACK. It now includes a new section of TLP and experimental results. ---------- Forwarded message ---------- From: Date: Mon, Oct 31, 2016 at 3:31 PM Subject: New Version Notification for draft-ietf-tcpm-rack-01.txt To: Neal Cardwell , Yuchung Cheng , tcpm-chairs@ietf.org, Nandita Dukkipati A new version of I-D, draft-ietf-tcpm-rack-01.txt has been successfully submitted by Yuchung Cheng and posted to the IETF repository. Name: draft-ietf-tcpm-rack Revision: 01 Title: RACK: a time-based fast loss detection algorithm for TCP Document date: 2016-10-31 Group: tcpm Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack- 01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rack-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-01 Abstract: This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a1140a4fa30a54e0540316e56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi group

We have submitted a= nother major rev of RACK. It now includes a new section of TLP and experime= ntal results.

---------- Forwarded mess= age ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Mon, Oct 31, 2016 at 3:31 PM
Subject: New Versio= n Notification for draft-ietf-tcpm-rack-01.txt
To: Neal Cardwell <ncardwell@google.com>, Yuchung = Cheng <ycheng@google.com>, <= a href=3D"mailto:tcpm-chairs@ietf.org">tcpm-chairs@ietf.org, Nandita Du= kkipati <nanditad@google.com&= gt;



A new version of I-D, draft-ietf-tcpm-rack-01.txt
has been successfully submitted by Yuchung Cheng and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tcpm-rack
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RACK: a time-based fast loss detec= tion algorithm for TCP
Document date:=C2=A0 2016-10-31
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-= 01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-tcpm-rack-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-01
Abstract:
=C2=A0 =C2=A0This document presents a new TCP loss detection algorithm call= ed RACK
=C2=A0 =C2=A0("Recent ACKnowledgment").=C2=A0 RACK uses the notio= n of time, instead of
=C2=A0 =C2=A0packet or sequence counts, to detect losses, for modern TCP =C2=A0 =C2=A0implementations that can support per-packet timestamps and the=
=C2=A0 =C2=A0selective acknowledgment (SACK) option.=C2=A0 It is intended t= o replace
=C2=A0 =C2=A0the conventional DUPACK threshold approach and its variants, a= s well
=C2=A0 =C2=A0as other nonstandard approaches.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a1140a4fa30a54e0540316e56-- From nobody Mon Oct 31 17:02:28 2016 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 1E032129C03; Mon, 31 Oct 2016 17:02:16 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 QO3M4aoyL5S1; Mon, 31 Oct 2016 17:02:13 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945ED129BFF; Mon, 31 Oct 2016 17:02:12 -0700 (PDT) Received: from [77.40.224.170] (port=59439 helo=[10.0.102.204]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c1MWp-0002qz-3x; Tue, 01 Nov 2016 00:02:11 +0000 To: tsvwg IETF list , TCP Prague List , AQM IETF list , tcpm IETF list From: Bob Briscoe Message-ID: Date: Tue, 1 Nov 2016 00:02:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8104AF989CDD82CEF66EA35D" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] L4S status update 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, 01 Nov 2016 00:02:16 -0000 This is a multi-part message in MIME format. --------------8104AF989CDD82CEF66EA35D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit tsvwg, aqm, tcpm, tcpPrague mailing lists, A few people have been working away to specify and document all the aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) service, which held a successful BoF in Berlin. As the decision was to try to work across multiple WGs, I thought it would be useful to give ... ... the status collected over all activities and WGs. I've included stuff that has wider applicability but is also needed for L4S. Click on the headings to take you to the page where all these links are collected together. Source Code * Dual Queue Coupled AQM o With Curvy RED for Linux (access available shortly) o With PI2 for Linux [*UPDATED*] * Data Centre TCP (DCTCP) for o Linux (in the mainline kernel ) o FreeBSD patch o ns2 patch . * Accurate ECN TCP Feedback for Linux [*COMPLETED*, but not fully tested] *IETF specs* As the architecture explains, there are three main parts to standardisation: the identifier (#1), the network algorithms (#2) and the host algorithms (#3): * Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture and Problem Statement > [*NEW*] 1. A proposed new identifier for Low Latency, Low Loss, Scalable throughput (L4S) packets > [*UPDATED to reflect the proposed process*] and the IETF’s enabling draft to make way for this > [*NEW*] 2. Then network operators can deploy a new simple active queue management algorithm, that complies with the few constraints specified here: > Example algorithms are given in appendices. [*PI2 pseudocode added to make 2 example**appendices*] 3. And host developers can deploy new scalable TCP algorithms, e.g. Data Centre TCP (DCTCP): > Without steps #2 & #3, scalable TCPs are too aggressive to coexist with classic TCPs like Reno and Cubic, so DCTCP was initially confined to controlled networks like Data Centres, where all classic traffic sources could be upgraded (or isolated). To be safe over the public Internet, scalable TCP algorithms will need to comply with the list of requirements agreed at an informally convened meeting in Prague that have become know as the TCP Prague requirements : * One of these requirements is accurate ECN feedback, which the IETF has recognised will need an update to the TCP protocol, and it has stated the requirements a solution should comply with: > A candidate protocol to satisfy these requirements has been developed and adopted by the IETF: > [*UPDATED*] * The following drafts address other specific TCP Prague requirements: Adding ECN to TCP control packets: > [*UPDATED*] Recommendations for increasing TCP performance in low RTT networks: > Papers * Article in the IETF Journal describing the Demo in Bits-N-Bites at the IETF in Prague, July 2015. “Ultra-Low Delay for All ” IETF Journal, Nov 2015. * Description of an**ambitious demo of five low latency apps on one broadband line, 4 of which were also high throughput: “Ultra-Low Delay for All: Live Experience, Live Analysis “, Proc. ACM Multimedia Systems; Demo Session (May 2016). * “/*PI^2 : A Linearized AQM for both Classic and Scalable TCP*/ ,” Proc. ACM CONEXT 2016 (To appear Dec 2016). [*NEW*] * Finally, a pathetic apology is in order: We prepared a [*NEW*] paper for a top conference giving the full L4S story, with a massive set of testbed-based evaluations, with a wide range of link rates, RTTs, mixtures of numbers of flows in each queue, etc. etc. But we screwed up, and it got rejected without even being read - we exceeded the page limit :( We don't want to publish it on the Web until we've tried again. But if anyone wants a private copy, pls just ask. Otherwise, the following older paper is still available, but not as comprehensive or well-honed: Pre-print of paper explaining why scalable TCP algorithms solve the problem (in plain English and maths), how the Dual Queue Coupled AQM algorithm works, and recording the results of extensive testbed experiments. “`/*Data Centre to the Home’: Ultra-Low Latency for All*/ ” (2015) Thank you to everyone involved so far. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------8104AF989CDD82CEF66EA35D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit tsvwg, aqm, tcpm, tcpPrague mailing lists,

A few people have been working away to specify and document all the aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) service, which held a successful BoF in Berlin. As the decision was to try to work across multiple WGs, I thought it would be useful to give ...

... the status collected over all activities and WGs. I've included stuff that has wider applicability but is also needed for L4S. Click on the headings to take you to the page where all these links are collected together.

Source Code

IETF specs

As the architecture explains, there are three main parts to standardisation: the identifier (#1), the network algorithms (#2) and the host algorithms (#3):
  • Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture and Problem Statement
    <draft-briscoe-tsvwg-l4s-arch> [NEW]
  1. A proposed new identifier for Low Latency, Low Loss, Scalable throughput (L4S) packets
    <draft-briscoe-tsvwg-ecn-l4s-id> [UPDATED to reflect the proposed process]
    and the IETF’s enabling draft to make way for this
    <draft-black-tsvwg-ecn-experimentation> [NEW]
  2. Then network operators can deploy a new simple active queue management algorithm, that complies with the few constraints specified here:
    <draft-briscoe-tsvwg-aqm-dualq-coupled>
    Example algorithms are given in appendices. [PI2 pseudocode added to make 2 example appendices]
  3. And host developers can deploy new scalable TCP algorithms, e.g. Data Centre TCP (DCTCP):
    <draft-ietf-tcpm-dctcp>
    Without steps #2 & #3, scalable TCPs are too aggressive to coexist with classic TCPs like Reno and Cubic, so DCTCP was initially confined to controlled networks like Data Centres, where all classic traffic sources could be upgraded (or isolated). To be safe over the public Internet, scalable TCP algorithms will need to comply with the list of requirements agreed at an informally convened meeting in Prague that have become know as the TCP Prague requirements:
  • One of these requirements is accurate ECN feedback, which the IETF has recognised will need an update to the TCP protocol, and it has stated the requirements a solution should comply with:
    <RFC7560>
    A candidate protocol to satisfy these requirements has been developed and adopted by the IETF:
    <draft-ietf-tcpm-accurate-ecn> [UPDATED]
  • The following drafts address other specific TCP Prague requirements:
    Adding ECN to TCP control packets:
    <draft-bagnulo-tcpm-generalized-ecn> [UPDATED]
    Recommendations for increasing TCP performance in low RTT networks:
    <draft-bagnulo-tcpm-tcp-low-rtt>

Papers


  • Finally, a pathetic apology is in order: We prepared a [NEW] paper for a top conference giving the full L4S story, with a massive set of testbed-based evaluations, with a wide range of link rates, RTTs, mixtures of numbers of flows in each queue, etc. etc.  But we screwed up, and it got rejected without even being read - we exceeded the page limit :(

    We don't want to publish it on the Web until we've tried again. But if anyone wants a private copy, pls just ask.
    Otherwise, the following older paper is still available, but not as comprehensive or well-honed:

    Pre-print of paper explaining why scalable TCP algorithms solve the problem (in plain English and maths), how the Dual Queue Coupled AQM algorithm works, and recording the results of extensive testbed experiments.

Thank you to everyone involved so far.

Cheers


Bob
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------8104AF989CDD82CEF66EA35D-- From nobody Mon Oct 31 19:02:31 2016 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 19F34129C05 for ; Mon, 31 Oct 2016 19:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham 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 YhuModnwV04b for ; Mon, 31 Oct 2016 19:02:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849B912948F for ; Mon, 31 Oct 2016 19:02:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUH16169; Tue, 01 Nov 2016 02:02:25 +0000 (GMT) Received: from SZXEMI403-HUB.china.huawei.com (10.82.75.35) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 02:02:22 +0000 Received: from SZXEMI508-MBS.china.huawei.com ([169.254.10.152]) by SZXEMI403-HUB.china.huawei.com ([10.83.65.55]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 10:02:11 +0800 From: "Sunliyang (Marcus)" To: "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-sun-tcpm-ecn-improvement-00.txt Thread-Index: AQHSM1km4Z5IvXsAI0eWbZmXYbkXq6DDXurQ Date: Tue, 1 Nov 2016 02:02:10 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.23.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5817F7B2.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.10.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b56c87812bcc3361d3ac7b2dc0cab41e Archived-At: Subject: [tcpm] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-sun-tcpm-ecn-improvement-00=2Etxt?= 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, 01 Nov 2016 02:02:30 -0000 RGVhciBBbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IGFuIGltcHJv dmVtZW50IG9mIEVDTi4gR3JlYXRseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMsIHF1ZXN0aW9u cyBhbmQgc3VnZ2VzdGlvbnMuDQoNCktpbmQgUmVnYXJkcywNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTWFyY3VzIFN1bi/lrZnpu47pmLMgUGguRA0K Q2VudHJhbCBSZXNlYXJjaCBJbnN0aXR1dGUNCkhVQVdFSSBURUNITk9MT0dJRVMgQ08uLExURCAN CkUtbWFpbO+8mm1hcmN1cy5zdW5AaHVhd2VpLmNvbQ0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNuW5tDEw5pyIMzHml6UgMTc6MjgN CuaUtuS7tuS6ujogU3VubGl5YW5nIChNYXJjdXMpDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtc3VuLXRjcG0tZWNuLWltcHJvdmVtZW50LTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zdW4tdGNwbS1lY24taW1wcm92ZW1lbnQtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1hcmN1cyBTdW4gYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtc3VuLXRjcG0tZWNuLWlt cHJvdmVtZW50DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJQW4gSW1wcm92ZW1lbnQgb2YgRUNOIHRv IEVuaGFuY2UgVENQIEZhaXJuZXNzIFBlcmZvcm1hbmNlDQpEb2N1bWVudCBkYXRlOgkyMDE2LTEw LTMxDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXN1bi10Y3Bt LWVjbi1pbXByb3ZlbWVudC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdW4tdGNwbS1lY24taW1wcm92ZW1lbnQvDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXN1bi10Y3BtLWVjbi1p bXByb3ZlbWVudC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg VENQIGZhaXJuZXNzIHBlcmZvcm1hbmNlIGVuaGFuY2VtZW50IHNjaGVtZQ0KICAgYnkgdXNlIG9m IHR3byBwYXJhbWV0ZXJzIGNvbmdlc3Rpb24gZGVncmVlIGFuZCBsaW5rIGlkbGUgcmF0ZS4gSXQN CiAgIHVzZXMgSVAgaGVhZGVyIGZsYWcgcmVzZXJ2ZWQgZmllbGQgYW5kIEVDTiAyIGJpdHMgZmll bGQgdG8gZm9ybSBhIG5ldw0KICAgSVAgY29uZ2VzdGlvbiBhbmQgU3BhcmUgRmxhZyAoSUNTRikg YW5kIHVzZXMgM2JpdHMgb2YgcmVzZXJ2ZWQgYml0cw0KICAgaW4gdGhlIFRDUCBoZWFkZXIgdG8g Y29tcG9zZSB0aGUgVENQIENvbmdlc3Rpb24gYW5kIFNwYXJlIEZsYWcgKFRDU0YpDQogICBmaWVs ZC4gVGhpcyBtZXRob2QgaWRlbnRpZmllcyB0aGUgY29uZ2VzdGlvbiBhbmQgbGluayBpZGxlIHN0 YXR1cyB0bw0KICAgbWFrZSBzdXJlIHRoYXQgZXZlcnkgVENQIGZsb3cgY2FuIHJlY2VpdmUgdGhl IHNhbWUgZGVncmVlIG9mIGZhaXJuZXNzDQogICBhbmQgY2FuIGltcHJvdmUgVENQIHNlbmQgd2lu ZG93IGFkanVzdG1lbnQgc3BlZWQgYW5kIHRyYW5zbWlzc2lvbg0KICAgZWZmaWNpZW5jeS4NCg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=