Re: [multipathtcp] [Taps] MPTCP Socket API and TAPS
Michael Welzl <michawe@ifi.uio.no> Tue, 19 July 2016 21:10 UTC
Return-Path: <michawe@ifi.uio.no>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3612D8B9; Tue, 19 Jul 2016 14:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 Ta0q7OD4eC8M; Tue, 19 Jul 2016 14:10:41 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 9021712D88B; Tue, 19 Jul 2016 14:10:41 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1bPcHn-00027e-Tf; Tue, 19 Jul 2016 23:10:39 +0200
Received: from [46.189.28.92] (helo=[10.24.255.5]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1bPcHn-0004cT-9A; Tue, 19 Jul 2016 23:10:39 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <D1F27A4D-732E-49BC-A575-DACA67F7EE9E@ifi.uio.no>
Date: Tue, 19 Jul 2016 23:10:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E2B315F-C916-4292-A1C0-BA8C90976E86@ifi.uio.no>
References: <8230F063-8EF2-4B05-BF90-AB1E8832968E@ifi.uio.no> <D1F27A4D-732E-49BC-A575-DACA67F7EE9E@ifi.uio.no>
To: multipathtcp@ietf.org, "taps@ietf.org" <taps@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 14 sum msgs/h 5 total rcpts 44704 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: D91FCB212C552FA7F305F5629ED2B3EFAB2B8003
X-UiO-SPAM-Test: remote_host: 46.189.28.92 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 80 max/h 10 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0-2sxY6jWZghEiH3Wkf9VdQFehc>
Subject: Re: [multipathtcp] [Taps] MPTCP Socket API and TAPS
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2016 21:10:43 -0000
and now it seems I can’t get the MPTCP group’s email address right… Sorry folks! > On 19. jul. 2016, at 23.09, Michael Welzl <michawe@ifi.uio.no> wrote: > > OMG! > Typo below - NEAT is the a research project implementing TAPS, and I wrote this email after the social… enough said… > > very sorry: I meant to say: please discuss on the TAPS mailing list. > > >> On 19. jul. 2016, at 23.05, Michael Welzl <michawe@ifi.uio.no> wrote: >> >> [ Please discuss on the NEAT mailing list ] >> >> >> Hi, >> >> The TAPS WG is trying to identify which services transport protocols offer, and then identify which of these services should be exposed to an application that tries to communicate while being agnostic to the transport protocol below. A TAPS system should then make a choice about the right transport protocol and configure it autonomously, and implement e.g. protocol fall-backs and such. >> >> Some transport services must be exposed or else they could never be used (e.g. unordered message delivery). Some can optimize performance if they are exposed and cannot be used without application involvement, but won’t make an application fail if they are not used (e.g. turning the Nagle algorithm on/off). The remaining ones could be “automatized”, i.e. a TAPS protocol could potentially make a decision on its own about them. >> >> Note that this raises the abstraction level of the API applications use to talk to the network. As always, this comes with benefits (of automatizing more things, and not requiring one specific transport protocol, ..), but also with reduced control over the available resources. As an extreme example, nobody in their right mind would write wireshark over TAPS :-) >> >> One proposal is to consider everything related to the usage of multiple paths automatable. That is, not expose it as a TAPS service. >> >> What do people here think about this? >> >> Cheers, >> Michael >> >> _______________________________________________ >> 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
- Re: [multipathtcp] [Taps] MPTCP Socket API and TA… Michael Welzl