Re: [Taps] I-D Action: draft-ietf-taps-minset-00.txt

Tommy Pauly <tpauly@apple.com> Tue, 14 November 2017 00:20 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0A1288A9 for <taps@ietfa.amsl.com>; Mon, 13 Nov 2017 16:20:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level:
X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 GIV_T9JSx5YL for <taps@ietfa.amsl.com>; Mon, 13 Nov 2017 16:20:18 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 2FDF41200CF for <taps@ietf.org>; Mon, 13 Nov 2017 16:20:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510618815; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8yYbSr/o7K56/hRoAz4rYQl0MZYYrJVCbZogECB4mx0=; b=LNbg5VGT9ca+1n/SsEIKGQa1dkrfxKvhtvmknYSlyInPi1JqM4BEpnZd4pajUROC WRaIuodrPXsvfTPluQipmwbAbik+PUbe70G7p85VaGdhuic6ueDyIrdrRi9lXXFF j3OVInH68PX81gcQIJLfXiq/fS1e4g+OvH+4WobWrEHXTHDIJ8xx68fP7nWGboI/ zu0rgcLTmR8HoQhc+a91ZbBlr/iwTyxzThCixTel7YVs+pMfTOx/f5mHy4JosBOK qso5YEW8+hc6KBGZQwGbzSrY8LF0V0H3fkQAdOeCUAhYgO8jDgi5TELmKXKeX3dM fzeR9qovtZcuYVcku/oJig==;
Received: from relay1.asia.apple.com ( [17.82.200.18]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id B1.A0.07591.FB63A0A5; Tue, 14 Nov 2017 08:20:15 +0800 (MYT)
X-AuditID: 1152fe11-8cbff70000001da7-b5-5a0a36bf1319
Received: from sng-mmpp-sz02.asia.apple.com ( [17.84.80.27]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id BC.D1.23340.FB63A0A5; Tue, 14 Nov 2017 08:20:15 +0800 (MYT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_qHrzD+79HyBacvu/S/LTpg)"
Received: from [17.235.149.253] by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZD00FXNSXQOH20@sng-mmpp-sz02.asia.apple.com>; Tue, 14 Nov 2017 08:20:15 +0800 (SGT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <DDD570C4-FA0B-441A-A02B-31D97F940EB8@apple.com>
Date: Tue, 14 Nov 2017 08:20:14 +0800
In-reply-to: <7403AB1A-33FC-461A-B88F-B8DB8FC08881@ifi.uio.no>
Cc: "taps@ietf.org" <taps@ietf.org>
To: Michael Welzl <michawe@ifi.uio.no>
References: <150871580801.24896.1276317669567869148@ietfa.amsl.com> <7403AB1A-33FC-461A-B88F-B8DB8FC08881@ifi.uio.no>
X-Mailer: Apple Mail (2.3445.5.5)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUiGHRCSHe/GVeUwfGXchY/zu5ktbgT48Dk sWTJTyaP1asfMgcwRXHZpKTmZJalFunbJXBlfPrwirXg8HLGitYLrcwNjLt6GbsYOTkkBEwk mrZ9Y+5i5OIQEljJJNFx6wUzTOLqnzmMEIkdjBKtTS/BOngFBCV+TL7HAmIzC4RJdG2/DdYg JNDAJHFuamEXIweHsICExOY9iSBhNgEViePfNjCDhHkFbCRObQabIixgKzFt13JWEJtFQFVi //L5YDangJ3EmjcrmSCmK0s8ntUItklEQE3ixPLVbCBjhATKJX7fsIW4UlHi4aYuVpArJQQW sEn82DCNaQKj0Cwkh85CcugsoHZmAXWJKVNyIcLaEk/eXWCFsNUkFv5exIQsvoCRbRWjeG5i Zo5uZp6hXmJxZqJeYkFBTqpecn7uJkZwPPwT3ME4daHhIUYBDkYlHl4ZRa4oIdbEsuLK3EOM EhzMSiK8FrxAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rx9kZ8ihQTSE0tSs1NTC1KLYLJMHJxS DYyz6rZpFx3RsU9lWP07Y2tHSvQVwXeLA1uEzjkfSemV8W1kn2q8n3nODb3sPYoOd5Yaqm4+ /q2poeHuisdeS+auPTE1JK3s5ERGEfuS/d0s7YfiXmWnJH/+9C3qj/5qqzf9V77PtpyxSfXw ql0i/XwlzCeOVnU+eS3x+8vyuTyXn4Qp1IR6XGRXYinOSDTUYi4qTgQAtlcvn4MCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUiGBIgrbvfjCvK4MA7IYsfZ3eyWtyJcWDy WLLkJ5PH6tUPmQOYorhsUlJzMstSi/TtErgyPn14xVpweDljReuFVuYGxl29jF2MnBwSAiYS V//MAbK5OIQEdjBKtDa9BEvwCghK/Jh8jwXEZhYIk+jafpsZxBYSaGCSODe1sIuRg0NYQEJi 855EkDCbgIrE8W8bmEHCvAI2Eqc2g00RFrCVmLZrOSuIzSKgKrF/+Xwwm1PATmLNm5VMENOV JR7PagTbJCKgJnFi+Wo2kDFCAuUSv2/YQlypKPFwUxfrBEb+WUhum4XktllAHcwC6hJTpuRC hLUlnry7wAphq0ks/L2ICVl8ASPbKkbRotScxEpDvcTizES9xIKCnFS95PzcTYyg8A06IbSD 8eN+g0OMAhyMSjy8pxS5ooRYE8uKK3MPMUpwMCuJ8FrwAoV4UxIrq1KL8uOLSnNSiw8xSnOw KInzakZ9ihQSSE8sSc1OTS1ILYLJMnFwSjUwcjc7RP86fodJsuly3+J7k1JPqokGK1UxnH3+ Kyek4dUBAYOXGlLbznqEim3Wdnp2duG+dzxVRd/TxF921Hxct5YtwSo6Rr3d4VvuKdGmZ8uS y/58ydKX/D/7iJFHmcSbf7Xcr2NTa7q32yxM0xQUtlptEn5c8uQktfM7q6b063zaF5xxwq5V iaU4I9FQi7moOBEAYGjPBlsCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/ZyL1UNJ63gGb4u_Ojlh0OMPp2Aw>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-minset-00.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 00:20:20 -0000

A couple initial comments on the minset document:

In Section 4:

- Title should be "4.  A MinSet Abstract Interface" not "4.  An MinSet Abstract Interface"

For this:

3.  Not offer any of the transport features of these protocols and
       the LEDBAT congestion control mechanism that do not require
       application-specific knowledge (to give maximum flexibility to a
       TAPS system)

Could this be written as "that can be performed automatically" or something, rather than "do not require application-specific knowledge"? It ends up having a lot of negatives that get confusing.

I'd like to see the reference removed to Post Sockets indicating that it would require any protocol changes or the system on both ends. As discussed on the other thread, Post does not require any changes to the peer for compatibility.

TLS:

We can discuss in the group, but I think that security can stay a separate document for now. You wouldn't "fall back" to TLS—TLS is just something you can use underneath the TAPS API, and you either have security or you don't. That shouldn't be changing underneath you.

General:

Much of the document is phrased in terms of "fall-back" to TCP, UDP, etc. While I understand where this is coming from, I'm wondering from a larger perspective if this is the right framing. As the document reads now, there's this underlying normative assumption that "TCP and UDP are less preferred" and MPTCP or SCTP etc is preferred over them. This may be true for some systems, but maybe not always. The set of transports that a TAPS system may eventually use hopefully won't be just limited to the set in the survey, but include things like QUIC, etc. And depending on the scenario, maybe we prefer something over TCP, and then fall-back to some other less preferred mode. Or, the application may not allow falling back at all, but simply wants to reuse its transport code that uses a TAPS API between different protocols it uses for different, mutually exclusive scenarios.

So, I would be tempted to change the first two requirements from:

   1.  Support one-sided deployment with a fall-back to TCP (or UDP)
   2.  Offer all the transport features of (MP)TCP, UDP(-Lite), LEDBAT
       and SCTP that require application-specific knowledge

To:

   1.  Support basic functionality required for all transports (the 
	minimal set for TCP and UDP)
   2.  Offer all extended transport features that require application-
	specific knowledge (such as options for (MP)TCP, UDP(-Lite), LEDBAT
       and SCTP)

Then, for each feature listed, you have essentially this format:

   o  [Feature name]
      Protocols: SCTP
      [Description]
      Fall-back to TCP: [do nothing/not supported]
      Fall-back to UDP: [do nothing/not supported]

How about something like:

   o  [Feature name]
      Supported by: SCTP
      Ignored by: TCP
      Incompatible with: UDP
      [Description]

This way, we list how each protocol will treat it, but we're not making normative preferential statements, and we're not relying on the notion of falling back. I think "falling back" is something that belongs in documents around happy eyeballs and racing, etc, and baking in which protocol is a fallback and which is the primary may be quite misleading to implementers.

Thoughts?

Best,
Tommy


> On Oct 23, 2017, at 4:38 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> Hi everyone,
> 
> This update addresses 2 out of 3 major comments that we got at the last meeting:
> 
> 1) also fall-back to UDP  => done.  This turned out to be much easier than I thought because the set of transport features for which TCP is a possible fall-back is, with *one* exception (receiving a message) strictly a superset of transport features for which UDP is a possible fall-back.   Sorry for the clumsy sentence but the point is, TCP itself is of course *not* strictly a superset of UDP itself, but that doesn’t matter.  Anyway, because of this superset relationship, we were able to just mark limitations that arise when requiring to fall back to UDP with (!UDP).
> 
> 2) make it clearer that the abstract interface description of the min set is *not* an API proposal => done. I hope this is now clear enough for folks.
> 
> 3) make it less TCP-specific, also consider fall-back to e.g. TLS => not done. Maybe next time?
> 
> Thanks for the very useful feedback, everyone who was there last time!
> 
> Also, there are now considerations on how to begin. With the minset as it was, it is possible for TAPS to choose UDP as a protocol and for the application to later request reliability. At least such deadlocks must be prevented - I’m not claiming that what we put in there is generally ideal (in fact the text explains why it isn’t), but it is one possible approach that avoids such deadlocks.
> 
> 
> Chairs: I’d like to request a 20-minute slot for this update, if possible  (I think this should be enough including discussions, as my presentation would probably fit in about 10 minutes).
> 
> Cheers,
> Michael
> 
> 
> 
>> On Oct 23, 2017, at 1:43 AM, internet-drafts@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Services WG of the IETF.
>> 
>>       Title           : A Minimal Set of Transport Services for TAPS Systems
>>       Authors         : Michael Welzl
>>                         Stein Gjessing
>> 	Filename        : draft-ietf-taps-minset-00.txt
>> 	Pages           : 53
>> 	Date            : 2017-10-22
>> 
>> Abstract:
>>  This draft recommends a minimal set of IETF Transport Services
>>  offered by end systems supporting TAPS, and gives guidance on
>>  choosing among the available mechanisms and protocols.  It is based
>>  on the set of transport features given in the TAPS document draft-
>>  ietf-taps-transports-usage-08.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-taps-minset/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-taps-minset-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-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/
>> 
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps