Re: [Taps] First draft of an article for the IETF journal

David Ros <dros@simula.no> Wed, 21 May 2014 13:45 UTC

Return-Path: <dros@simula.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA551A069D for <taps@ietfa.amsl.com>; Wed, 21 May 2014 06:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 VJptdWKzeFqL for <taps@ietfa.amsl.com>; Wed, 21 May 2014 06:45:09 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93851A06A3 for <taps@ietf.org>; Wed, 21 May 2014 06:45:08 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id r20so2753113wiv.15 for <taps@ietf.org>; Wed, 21 May 2014 06:45:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=27UUWpn7ZP+nhpKOQy8O0hDYdBIV8JmnXFBp0Z9pNCI=; b=lej9F9IWu9nS62cWIR2UW2/eIxVOCVE8iVHfORX6J62feOYBE5vPe/+86iOTWiduct TVBPiHXbxCDrIGJlHTZYk/tlNqV5DI2H8Dq8OQRmrPuzKfn+RSNd97MKSJkLlKiqSEhP kU5yomOxQUPODNlR1eVry0PB4K4LfY/jLqJLbDfPDjzmOt4I/yiLa/U8eaMFnTRJ2xU3 qVjzHa2x1U2ZRK68nowsw1BRzwrg6vYCfFW7vT6EgBOwefpLpYfUXO4eWSzw5GxDFrZi u2F7i/FIWmNPOD0NPbHvJ7Ff8mQ6pJoktmP2QgIFnGoIX9uhHzMSAfiyFWHEni/WboTJ 7R2w==
X-Gm-Message-State: ALoCoQmI/7HFPPLp/qP0ENix5X1rzYxucDSW7QiHlQ3S5mukLMtlmMiN0gbNvbgSOSduppzxFQ1F
X-Received: by 10.194.242.66 with SMTP id wo2mr43627809wjc.37.1400679906877; Wed, 21 May 2014 06:45:06 -0700 (PDT)
Received: from [192.168.0.88] (ARennes-356-1-196-14.w2-13.abo.wanadoo.fr. [2.13.139.14]) by mx.google.com with ESMTPSA id by1sm22645107wjc.26.2014.05.21.06.45.05 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 06:45:05 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CD99EE2B-48C4-4CE6-B56C-C847EA354F20"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: David Ros <dros@simula.no>
In-Reply-To: <CALiXHoy4YibDSQEhK+u5hQiRORJc8YcmZag3BngWsTajbbm+Yw@mail.gmail.com>
Date: Wed, 21 May 2014 15:45:02 +0200
Message-Id: <800BC3A3-682D-4C15-A65D-660BA821E0DD@simula.no>
References: <CALiXHoy4YibDSQEhK+u5hQiRORJc8YcmZag3BngWsTajbbm+Yw@mail.gmail.com>
To: Aaron Falk <falk-ietf@dgftech.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/p1OyenvGMYjEIRha7xRDsrtPyK4
Cc: Michael Welzl <michawe@ifi.uio.no>, taps@ietf.org
Subject: Re: [Taps] First draft of an article for the IETF journal
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 21 May 2014 13:45:13 -0000

On 21 May 2014, at 15:41, Aaron Falk <falk-ietf@dgftech.com> wrote:

> On Wed, May 21, 2014 at 5:11 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> My opinion: at first, we should focus on things that can be installed one-sided, on the sender side only. Yes it's limited, but a number of things are possible there. E.g., pluggable congestion controls in TCP have always worked without involving the receiver - but right now, pluggable congestion control isn't an IETF matter. Happy Eyeballs can be done without coordinating with a receiver, at least for the case that we're using well-known ports and the receiver listens on more than one protocol.
> 
> I've forgotten the details of 'Happy Eyeballs'.  Can you provide a cite?
>  

Hi,

http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02

Cheers,

David


> 
> But yes, quite quickly one runs into limitations there; anyway, for divide-and-conquer  :-)   reasons, I think we want to go with a sender-side-only-installation assumption for now.
> 
> Seems worth exploring the implications of such an approach where you have the same app sitting on top of very different APIs (e.g., Berkeley socket vs TAPS) at either end of the connection.  That combined with an app where either endpoint might be a sender.
> 
>  
> Though, I'm not sure if we have had enough discussions on this and if absolutely everyone is on the same page (though, indirectly perhaps, as our draft charter states that signaling is out of scope, and signaling would be needed to align both ends).
> 
> yup
> 
> cheers,
> 
> --aaron
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps