RE: Call for participation: Transport Services

"LOCHIN Emmanuel" <Emmanuel.LOCHIN@isae.fr> Wed, 09 October 2013 13:59 UTC

Return-Path: <Emmanuel.LOCHIN@isae.fr>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E3C11E8197 for <tsv-area@ietfa.amsl.com>; Wed, 9 Oct 2013 06:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb+NS-7Mktuk for <tsv-area@ietfa.amsl.com>; Wed, 9 Oct 2013 06:59:08 -0700 (PDT)
Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7C15D11E818C for <tsv-area@ietf.org>; Wed, 9 Oct 2013 06:59:07 -0700 (PDT)
Received: from supmail (unknown [10.132.1.9]) by smtpext.isae.fr (Postfix) with ESMTP id 47C8422E4E7; Wed, 9 Oct 2013 15:58:59 +0200 (CEST)
Received: from wali.isae.fr (wali.isae.fr [10.132.1.26]) by supmail (Postfix) with ESMTP id 03D7EC884F6; Wed, 9 Oct 2013 15:59:05 +0200 (CEST)
User-Agent: SOGoMail 2.0.7
X-Forward: 81.56.87.55
MIME-Version: 1.0
from: LOCHIN Emmanuel <Emmanuel.LOCHIN@isae.fr>
subject: RE: Call for participation: Transport Services
message-id: <41d2-52556100-a9-40e9f900@220307164>
to: l.wood@surrey.ac.uk
content-type: text/plain; charset="utf-8"
date: Wed, 09 Oct 2013 15:59:05 +0200
in-reply-to: <290E20B455C66743BE178C5C84F12408374274D589@EXMB01CMS.surrey.ac.uk>
content-transfer-encoding: quoted-printable
Cc: transport-services@ifi.uio.no, tsv-area@ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2013 13:59:12 -0000

 
Le Mercredi 9 Octobre 2013 12:18 CEST, <l.wood@surrey.ac.uk> a écrit: 
> 
> Subscribed...
> 
> Interesting to hear that sctp is alive and well in a browser.

FYI, Multipath TCP seems enabled in iOS 7 
http://appleinsider.com/articles/13/09/20/apple-found-to-be-using-advanced-multipath-tcp-networking-in-ios-7

EL

> It's not quite an API, but I wrote 
> http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports
> to be able to select between multiple ways of transporting upper-layer protocols. At the least, it would aid programmers in explicit testing/debugging...
> 
> Lloyd Wood
> http://sat-net.com/L.Wood/
> 
> 
> ________________________________________
> From: Michael Welzl [michawe@ifi.uio.no]
> Sent: 09 October 2013 11:03
> To: Wood L  Dr (Electronic Eng)
> Cc: Joe Touch; tsv-area@ietf.org; transport-services@ifi.uio.no
> Subject: Re: Call for participation: Transport Services
> 
> [  Saying what I should have said before: Let's please have this discussion on the transport-services@ifi.uio.no<mailto:transport-services@ifi.uio.no> list (in cc); subscription info: https://sites.google.com/site/transportprotocolservices/  ]
> 
> Indeed, also SCTP works over UDP, and is being shipped that way with Firefox already. Then you have LEDBAT, over UDP, being used in BitTorrent; then, you have, also over UDP, Google's QUIC and Adobe's RTMFP. Let's not forget the SCTP'ish services provided in the form of a TCP++ in Minion. And, finally, we could use e.g. native SCTP today, with Happy Eyeballs.
> 
> For example, to get faster delivery of messages without requiring their correct order, I could choose, just to name a few:
> - TCP with Minion, if the other side supports it (from a quick glance at the two drafts, I couldn't see how Minion support on the other side is identified / negotiated? Either I missed it, or this part is still undecided)
> - SCTP native, if the network and the other side supports it (which I can test with Happy Eyeballs)
> - SCTP over UDP, if the network and the other side supports it
> - QUIC, I think
> 
> If we could hide these choices under a common API, and identify which services have enough agreement behind them (because they're published in RFCs and/or deployed and used in applications), then we could perhaps work towards a cleaner and more flexible situation. Not agreeing on things means that we'll get more and more transports-over-UDP in applications for which the programming effort pays off, and many applications that don't work as good as they could because the benefit of using something other than TCP just doesn't outweigh the effort for the programmer.
> 
> Consider the web: we've long known that web transfers work better with SCTP: http://www.eecis.udel.edu/~leighton/firefox.html
> but only now, a transport-level improvement for the web is happening thanks to Google's QUIC, because we first needed a company that is in control of both the server and the browser for the programming effort to be worth it.  (Why let your browser do happy eyeballs, and put SCTP code in there, when servers don't support SCTP anyway? Why support SCTP in your server when browsers don't request it?)  If SCTP usage would have been provided automatically, hidden underneath the API, with a fall-back, we could have had a faster web long ago, I reckon.
> 
> Cheers,
> Michael
> 
> 
> On 9. okt. 2013, at 06:45, <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>> <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>> wrote:
> 
> Transport protocols are built over UDP these days - LTP, Saratoga, even DCCP and SCTP. That UDP goes underneath
> for convenience doesn't change the question about what services apps can be offered, and require - and UDP goes
> through all the NATs I'm familiar with in operation.
> 
> (Really looking forward to the UDP-Lite in UDP get-through-NAT document!)
> 
> Lloyd Wood
> http://sat-net.com/L.Wood/
> 
> 
> ________________________________________
> From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu]
> Sent: 08 October 2013 21:15
> To: Michael Welzl
> Cc: tsv-area@ietf.org
> Subject: Re: Call for participation: Transport Services
> 
> Hi, Michael, et al.,
> 
> I find it difficult to resolve this with the fact that basically only
> TCP* gets through NATs, and the lack of widespread use of DCCP and SCTP.
> 
> (* more specifically, transport "6" with a passing resemblance to TCP's
> header format, esp. SYN segments)
> 
> I.e., what's the point in an app asking for what it wants if the only
> answer is "TCP"?
> 
> This might be an interesting topic for a research prototype, but
> otherwise seems out of scope for the IETF - esp., as was noted, given
> the IETF's current 'appreciation' for the role of APIs in protocol design.
> 
> Joe
> 
> On 10/8/2013 4:57 AM, Michael Welzl wrote:
> Dear all,
> 
> Sorry if you receive multiple copies of this! I sent it to all the lists
> with potentially interested folks...  (this should be okay to do
> according to RFC5434, which says "various mailing lists").
> 
> A community of interest is being formed to gauge whether there is
> sufficient interest to host a BOF at the London IETF, on the topic of
> "Transport Services". The intention is to create a WG that would define
> the set of services that transport protocols offer to applications, such
> that applications could at some point in the future request a service,
> not a protocol. This could foster innovation (protocols could be tried
> out, with a fall-back, without requiring the application programmer to
> include such functionality); it could also give more freedom to whatever
> resides below the API to automatically make the best out of what it
> currently has available.
> 
> If you're interested in this problem space, please visit the related

> webpage that I have set up:
> https://sites.google.com/site/transportprotocolservices/
> There you'll find an initial stab at a charter and all information about
> the mailing list - please join us and participate in discussions! Thanks!
> 
> Cheers,
> Michael