Re: [LOOPS] LOOPS Comments

Michael Welzl <michawe@ifi.uio.no> Thu, 14 May 2020 10:56 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35A3A090C for <loops@ietfa.amsl.com>; Thu, 14 May 2020 03:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1UvR-0CbtFAb for <loops@ietfa.amsl.com>; Thu, 14 May 2020 03:55:59 -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 8D5823A090A for <loops@ietf.org>; Thu, 14 May 2020 03:55:59 -0700 (PDT)
Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1jZBWl-0005xn-UV; Thu, 14 May 2020 12:55:47 +0200
Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1jZBWk-0003On-PT; Thu, 14 May 2020 12:55:47 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <670F7B95-65E8-4A41-A05C-9B75CBD6BAFB@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1648E4F-D4BD-4797-8D55-11B7A2861571"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Thu, 14 May 2020 12:55:42 +0200
In-Reply-To: <9dac400fd0fa48439c28e809c58a166e@huawei.com>
Cc: wangjl50 <wangjl50@chinatelecom.cn>, loops <loops@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
To: Liyizhou <liyizhou@huawei.com>
References: <CAM4esxTU68mA9TcAysBjOkxOaERcuhgdxyJs09JJt5Qx9nThUw@mail.gmail.com> <2020051413075411969414@chinatelecom.cn> <6DCD54B8-D6D4-4A08-9CDF-B79B6A2B8B57@ifi.uio.no> <9dac400fd0fa48439c28e809c58a166e@huawei.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 9DDF80D64A52F215157116A84C12DB82CBFA8889
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/XOM6XsfpJ5AaWu8yDx6cLTFSi7s>
Subject: Re: [LOOPS] LOOPS Comments
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 10:56:03 -0000


> On May 14, 2020, at 10:37 AM, Liyizhou <liyizhou@huawei.com> wrote:
> 
> Hi Michael,
>  
> --------snip-------
>  
> Talking about means for endpoints to aware the LOOPS enabled service somewhere in the middle and be correctly configured, I believe it is highly feasible for the direction from the server to the client.
>  
> I said before that I agree with Martin’s comments - but now I see that I should have excluded this particular one. I agree that things can work better "if there is a means for endpoints to explicitly request the service”, but this is also an extension of the solution space, working against the plan to narrow it down and keep things simple. I think, at least at this point in time, we should not explicitly involve end systems.
>  
> ---snip----
>  
> My guess here. It was not to imply LOOPS should include the protocol work involving the end systems for now. It is more like, in specific applicable scenarios, it would be safe to make some assumptions, e.g.  always ECT-traffic, so that LOOPS does not need to worry about non-ECT traffic. Non-ECT traffic would not be directed to LOOPS ingress.

Oh, ECT, yes, that IS a form of end system involvement - no further signaling is what I meant.

 
> The payment case at the end of the email gives another type of applications that ECT or non-ECT traffic does not matter. LOOPS works with both.

Well… you need to detect this traffic somehow. If it’s TCP, how would a LOOPS ingress know it doesn’t matter if you hide loss from it because it’s only sending so little anyway?  That doesn’t sound like a good direction. But, we could maybe make an exception for the very last packet (which is detectable due to its FIN flag). Anyway, if the receiver gets even only one packet at the end delivered, good loss recovery such as RACK can repair things.


>  In short, 2 specific applicable scenarios are the traffic directed to LOOPS segment ingress either ECT-traffic (ECN-marking required over LOOPS segments), or short flows aggregation with no much worry on cwnd adjustment caused by loss. 

So I’m sceptical about the second scenario unless you have at least a clear idea on how to detect that traffic.
Even then… I don’t like the premise of “this traffic, e.g. towards this destination port, is known to send very little so we can safely hide loss from it”. You can build a system that does that, the Internet won’t break because of it, but it’s a bad direction for a standard.

Cheers,
Michael