Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 16 March 2017 19:07 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 CC9F0129A0B; Thu, 16 Mar 2017 12:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wP6u2_bsmGWm; Thu, 16 Mar 2017 12:07:01 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C62CC129A08; Thu, 16 Mar 2017 12:07:01 -0700 (PDT)
Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:5cab:ac90:959:b802]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B38081B016DE; Thu, 16 Mar 2017 21:04:39 +0000 (GMT)
Reply-To: gorry@erg.abdn.ac.uk
References: <58C66BB3.1000003@erg.abdn.ac.uk> <CY4PR21MB027775A417785976A70C6B11B6260@CY4PR21MB0277.namprd21.prod.outlook.com> <58CA5461.9010108@erg.abdn.ac.uk> <CY4PR21MB0277226072E5425C8947726BB6260@CY4PR21MB0277.namprd21.prod.outlook.com>
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "draft-ietf-tcpm-dctcp@ietf.org" <draft-ietf-tcpm-dctcp@ietf.org>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
Message-ID: <7c765760-b36f-69af-46dc-e53d4a56a699@erg.abdn.ac.uk>
Date: Thu, 16 Mar 2017 19:06:59 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0277226072E5425C8947726BB6260@CY4PR21MB0277.namprd21.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/oFWWLSPt-AYFvojZzdGqyAbFd9o>
Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 19:07:05 -0000

Thanks,

Gorry

On 16/03/2017 18:30, Praveen Balasubramanian wrote:
> It is pretty clear that all the considerations are for ACK packet loss:
>
> " However, if one or more ACK packets are dropped, it is possible that a subsequent ACK will cumulatively acknowledge
>       a mix of CE and non-CE segments. This will, of course, result in a less accurate congestion estimate. There are some potential considerations:"
>
> The fact that CE is being set also implies this is a response packet.
>
> "If packet loss mostly occurs under heavy congestion, most drops will occur during an unbroken string of CE packets,
>           and the estimate will be unaffected."
>
> I wasn't sure this needed further qualification but I don't see the harm adding ACK to qualify the packet loss, so fixed.
>
> -----Original Message-----
> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> Sent: Thursday, March 16, 2017 2:01 AM
> To: Praveen Balasubramanian <pravb@microsoft.com>
> Cc: tcpm@ietf.org; draft-ietf-tcpm-dctcp@ietf.org
> Subject: Re: WGLC comments for draft-ietf-tcpm-dctcp-04
>
> I wonder if the following could be easily also resolved, see suggestion below.
>
> On 16/03/2017, 02:52, Praveen Balasubramanian wrote:
>> In section 6:
>>
>> This statement could be better written:
>>
>> "If the estimation gain is small relative to the packet loss rate, the estimate may not be too inaccurate."
>>
>> - First, I think the loss rate noted, may be the loss rate for the
>> return path (i.e., the opposite direction to the packets bing
>> CE-marked?)
>> - Second, may not be too inacurrate sounds odd - do you think the accuracy is acceptable for normal use?
>>
>> If this relates to ACK loss, the following statement isn't necessarily true. And especially wculd be far from true for an internet with asymmetric routing:
>>
>> "o  If packet loss mostly occurs under heavy congestion, most drops
>>         will occur during an unbroken string of CE packets, and the
>>         estimate will be unaffected.
>> "
>>
>>>>>>  Yes these considerations are for the case where ACKs are lost reducing the accuracy of Alpha. The further sentence says that the impact of such loss has not been measured so its hard for me to say whether it will be "acceptable for normal use". Also, none of this applies to the internet and AFAIK routing is symmetric in the datacenter. I propose that we leave this text as is.
> - Is it worth inserting "ACK" in the following, to disambiguate packet loss from ACK loss.
>
>     "o  If ACK packet loss mostly occurs under heavy congestion, most drops
>         will occur during an unbroken string of CE packets, and the
>         estimate will be unaffected.
>
> Gorry
>