From nobody Sat Apr 2 10:33:14 2016 Return-Path: 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 66F5112D1B1 for ; Sat, 2 Apr 2016 10:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ujUwq9vTieFr for ; Sat, 2 Apr 2016 10:33:10 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813DE12D197 for ; Sat, 2 Apr 2016 10:33:10 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g127so207926321ywf.2 for ; Sat, 02 Apr 2016 10:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=qgaMpIDvgPtf6x1mne9T1Kv08kvDhyGXxC1ksNBFa9o=; b=WQFNjhldOt0+mHVGQAxdarzbhx7eE76s3HPsA5EyDdusmSjalj9YkEBVq6TGWpuevx y0Dpo3rc3GLvAkqUuZz2dqGksRLm8XxtraYjLAuzdDvPg6NXDKvVZhk1WlkkcgUD7jNc Vk+M8EJeK8LoB/BR2pHiZUInFmi0wcGTFp0O7/G/V3IIacPdkPTC0h1dzCQ+pofU0nU/ iec7kRVj6gsq1KAS48Iin0bL+w2wpYGpBA81O1VmjpDiYb4Lp0Y+yeLLCJkIycCwBHNY QNA4pDjrptS022sGcT8jejyaBqZ6upDDe5crPKb7lhuJtIxOnv890B5QzKbQDU2w4V1Z 2zWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=qgaMpIDvgPtf6x1mne9T1Kv08kvDhyGXxC1ksNBFa9o=; b=S6XJYAh7zX/Os8GcQ8e5MjMCgoHFojklv7wurhpFNt2gLGiUjg4B1UG7jVwpJuUWJI SsZ2K5rTWWHuXzNaJIyvB4AsZnH19+L7Wm7Ft4KcQDxRE1VV0Sw4FArn+k4wKqmOnPHF G7cLLKP5H/IaVgQeXepoYnhLPrpYWY+yHyEFRJi70cVUhM8JuS09YgQUbGtXyy2FVkv4 xbEwxB47OUPFMKzP01u6S5rjjiY+HTWsWtuwCYw6Q9ApfdD5HcSzaOQZ+vdskia26hWQ lNyr6XY8d74HhKT4TK4SzsHEE/LUCC3gkVbLKBbaLGGAmvtI8KKxdYsgnlcqMddDgWsY cJwQ== X-Gm-Message-State: AD7BkJKJdAwgHOWtXiYzTSCV6Vsl726nfTudXH5frfeYmP7B0ZSeCP3tRtEercdzKwwAoZG4cRI/yKosnErb1A== MIME-Version: 1.0 X-Received: by 10.13.236.142 with SMTP id v136mr4361655ywe.340.1459618389855; Sat, 02 Apr 2016 10:33:09 -0700 (PDT) Received: by 10.37.70.198 with HTTP; Sat, 2 Apr 2016 10:33:09 -0700 (PDT) Date: Sat, 2 Apr 2016 14:33:09 -0300 Message-ID: From: Aaron Falk To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=94eb2c0846aaa29718052f83e3cb Archived-At: Cc: "taps@ietf.org" Subject: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 17:33:13 -0000 --94eb2c0846aaa29718052f83e3cb Content-Type: text/plain; charset=UTF-8 Couple of minor comments on the draft : - No mention of ECN in phase 2. Am I missing something? - You had asked about what app-oriented IETF groups might be able to review the API. It's a good question for draft-ietf-taps-transports-usage as well. Wonder if the wg has any suggestions? Perhaps we should raise the question in APPSAWG although they don't seem to be meeting this IETF... --aaron --94eb2c0846aaa29718052f83e3cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Couple of minor comments on the draft:
<= ul>
  • No mention of ECN in phase 2.=C2=A0 Am I missing something?
    • =
  • You had asked about what app-oriented IETF groups might be able to revi= ew the API.=C2=A0 It's a good question for draft-ietf-taps-transports-u= sage as well.=C2=A0 Wonder if the wg has any suggestions?=C2=A0 Perhaps we = should raise the question in APPSAWG although they don't seem to be mee= ting this IETF...

    • --aaron
    --94eb2c0846aaa29718052f83e3cb-- From nobody Sat Apr 2 11:18:03 2016 Return-Path: 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 B8DA112D171 for ; Sat, 2 Apr 2016 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 G0fd54HBguPC for ; Sat, 2 Apr 2016 11:17:59 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC78112D150 for ; Sat, 2 Apr 2016 11:17:59 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id d68so71815003ywe.1 for ; Sat, 02 Apr 2016 11:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=IcLO3lyQjCuosNCb0AhnHB2cFrH9AQOArNZxn/Ofm9w=; b=YncEptCl1DkUOqVfYJvG6TfoJPd8CXAeYD69bBjsOuT0bijBymF3YozKuSKEjmXdpK gZVhdX+500baTOi3OB7HPu2jpgMn2tNxMDPDgxRFLv12ItB5yVxu95L+4Z4fA8SZmqwY 7MNOHU45QUNAucV4ZOtmuIJWSE++e7wSZPHSo8Cvd3GgxMPun3qngw7+HoOw+BlnCzSk DVvKQLkHOwz7lc8G1BjT8eQRWeyG0nMmNX69OPlsJlNe7oOgL3/x0ZmyKgOoH8Q+kYUQ dfQjNAPOUMIGEEfu/vcVhZju0B1sUdG8DxbU/WZsgdACwLY3/AUJx08RFTFvfO8pTBuQ 9tJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IcLO3lyQjCuosNCb0AhnHB2cFrH9AQOArNZxn/Ofm9w=; b=Saxq8olpqP2wq8WtNaNjTFUME6d5PWrvTk/kb83AfjjuKFtaUvZJyCGULr9K/RIfx5 hfx45LvcD7Sq2uUZTul5Zr3sZiXY3CbWWnAuuQNw+vShlYS9l9nLBGeBnvrt2RkGe6Fq Cdlf4ck7Xqc/ekC828u1R7V2rctj7MdRgJ1Y30oSP+AYz+BHKx3E0e7tnyjVzPwPgStb Mog0vGfB9oM/s9p6D+9ExhcoDy8MTiWPsZ5cYvfskuHCe93+hjk+Ptk6ckGD5mmLkxqS mERbBVwSw3yscLB66f4rmSO0pBag20dvVuDtwvTcP3HkpQcbF/pT6Op0NStAxv0ds+jS TZNw== X-Gm-Message-State: AD7BkJIiIC+MfXHBeNNyKMONFYno5pBeLoiZBFfy+K3zFIebnfSwvILl1LctSon4ZtbtK/o6LkWI1GY8l9vK1A== MIME-Version: 1.0 X-Received: by 10.129.108.3 with SMTP id h3mr5765768ywc.64.1459621078991; Sat, 02 Apr 2016 11:17:58 -0700 (PDT) Received: by 10.37.214.13 with HTTP; Sat, 2 Apr 2016 11:17:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2016 15:17:58 -0300 Message-ID: From: Spencer Dawkins at IETF To: Aaron Falk Content-Type: multipart/alternative; boundary=001a114d9a28eb87df052f84839f Archived-At: Cc: Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 18:18:01 -0000 --001a114d9a28eb87df052f84839f Content-Type: text/plain; charset=UTF-8 Hi, Aaron and Gorry, On Sat, Apr 2, 2016 at 2:33 PM, Aaron Falk wrote: > Couple of minor comments on the draft > > : > > - No mention of ECN in phase 2. Am I missing something? > - You had asked about what app-oriented IETF groups might be able to > review the API. It's a good question for draft-ietf-taps-transports-usage > as well. Wonder if the wg has any suggestions? Perhaps we should raise > the question in APPSAWG although they don't seem to be meeting this IETF... > > If you can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at the welcome reception, you might ask if Dispatch is the right place to ask about these drafts - now that APP is part of ART, Dispatch has a broader scope than just RAI, and they are meeting this time (on Monday morning, so ask fast) ... Spencer --001a114d9a28eb87df052f84839f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi, Aaron and Gorry,

    On Sat, Apr 2, 2016 at 2:33 PM, Aaron Falk <aaron.f= alk@gmail.com> wrote:
    Co= uple of minor comments on the draft:
  • No mention of ECN in phase 2.=C2=A0 Am I missing something?
    • <= li>You had asked about what app-oriented IETF groups might be able to revie= w the API.=C2=A0 It's a good question for draft-ietf-taps-transports-us= age as well.=C2=A0 Wonder if the wg has any suggestions?=C2=A0 Perhaps we s= hould raise the question in APPSAWG although they don't seem to be meet= ing this IETF...

    If y= ou can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at the welc= ome reception, you might ask if Dispatch is the right place to ask about th= ese drafts - now that APP is part of ART, Dispatch has a broader scope than= just RAI, and they are meeting this time (on Monday morning, so ask fast) = ...

    Spencer
    --001a114d9a28eb87df052f84839f-- From nobody Sat Apr 2 11:20:37 2016 Return-Path: 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 8058612D14B for ; Sat, 2 Apr 2016 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d-tXYfotsSV3 for ; Sat, 2 Apr 2016 11:20:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1CC12D150 for ; Sat, 2 Apr 2016 11:20:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t10so21363315ywa.0 for ; Sat, 02 Apr 2016 11:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PYyeqKo/uXcIxUIgsFvCMwxszNsyfbpQ9/y56r8X8tU=; b=IY2ZrjCoAZdnmHHM6ZTZB2SrWEOc02LmMZkXoSf6EouojgSa9nMVpM1K6g7WWBzikE cxHbTc45NnuV0NPZ46Ox7O7M/wnTZSS7f1jVBmTmb3I6eFiXTZk/G7UTTbArmL47xOta 6hmu3LD0UTw4FYEk7oR26uWdfO+EUtPMQ8yCU9ApmZMGzEIUDwJXAw8GMbMhdbloLh+h O7T6tmdbXFCy3hSz9BT8A8nfsaVxD30+aVTeg3KPgOXTTxGEUAAU0zbOWnmkG3Zcjfjm otrDXoQ7NxryNX5eZB265r2/By4DiFILoJmp6dGYtqfdclqeE3Xt92Tsf68XwlWlKoN9 A5vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PYyeqKo/uXcIxUIgsFvCMwxszNsyfbpQ9/y56r8X8tU=; b=MMiR4CsTcLkkmD5WVmLZoqVfA1rvxpKmGmTzNIkKkVHQmEaNlf2yj29G374fqj9CLP Uj73nONJcpyzKey/39zCdeAW6p8qSe215CFIyRMQbszhRTR+4zWCgAqR2SYtW1t4OVKO O5fWsXKfQEpRaTEa5Mat+oR+Obs8T5Oapzscab5QlE7BJVRkS4mJop9I3utBarnxSGNr za7CtD6X8YDOtf38/7PUSd6tIajU9FE3Cc5XUUWH9/KwBlPqX3k84Vt7zTUuDh6pHb3X 000Ml1qNvPJvFz9iKXqjBJAdpFO8dH2B6yWrsACsubCQ//VOCjNLvITgY0QTojrUUujw tmOA== X-Gm-Message-State: AD7BkJLg2fZcbbjqWYD8N09lEr3EM7BSwHixtuw+tiHxebScK9FFO9w839y5FyhCgWVSUhJshNs16OXHMPpeHQ== MIME-Version: 1.0 X-Received: by 10.129.71.5 with SMTP id u5mr7867117ywa.91.1459621233926; Sat, 02 Apr 2016 11:20:33 -0700 (PDT) Received: by 10.37.70.198 with HTTP; Sat, 2 Apr 2016 11:20:33 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2016 15:20:33 -0300 Message-ID: From: Aaron Falk To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a114d719627a69c052f848db3 Archived-At: Cc: Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 18:20:36 -0000 --001a114d719627a69c052f848db3 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 2, 2016 at 3:17 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Aaron and Gorry, > > On Sat, Apr 2, 2016 at 2:33 PM, Aaron Falk wrote: > >> Couple of minor comments on the draft >> >> : >> >> - No mention of ECN in phase 2. Am I missing something? >> - You had asked about what app-oriented IETF groups might be able to >> review the API. It's a good question for draft-ietf-taps-transports-usage >> as well. Wonder if the wg has any suggestions? Perhaps we should raise >> the question in APPSAWG although they don't seem to be meeting this IETF... >> >> > If you can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at the > welcome reception, you might ask if Dispatch is the right place to ask > about these drafts - now that APP is part of ART, Dispatch has a broader > scope than just RAI, and they are meeting this time (on Monday morning, so > ask fast) ... > > Spencer > So, is DISPATCH the new APPSAWG? If so, we need to add it to our conflict avoid list (esp since we conflict with it this week). --aaron --001a114d719627a69c052f848db3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Sat, Apr 2, 2016 at 3:17 PM, Spencer Dawkins at IETF <s= pencerdawkins.ietf@gmail.com> wrote:
    Hi, Aaron and Gorry,
    <= br>
    On Sat, Apr 2, 2016 at 2:33 = PM, Aaron Falk <aaron.falk@gmail.com> wrote:
    Couple of minor comments on the draft:
    • No mention of ECN in phase 2.=C2=A0 Am I= missing something?
    • You had asked about what app-oriented IETF = groups might be able to review the API.=C2=A0 It's a good question for = draft-ietf-taps-transports-usage as well.=C2=A0 Wonder if the wg has any su= ggestions?=C2=A0 Perhaps we should raise the question in APPSAWG although t= hey don't seem to be meeting this IETF...

    If you can corner Mary Barnes, Cullen Jenni= ngs, or Murray Kucherawy at the welcome reception, you might ask if Dispatc= h is the right place to ask about these drafts - now that APP is part of AR= T, Dispatch has a broader scope than just RAI, and they are meeting this ti= me (on Monday morning, so ask fast) ...

    Spencer


    So, is DISPATCH the = new APPSAWG?=C2=A0 If so, we need to add it to our conflict avoid list (esp= since we conflict with it this week).=C2=A0

    --aar= on

    --001a114d719627a69c052f848db3-- From nobody Sat Apr 2 11:42:23 2016 Return-Path: 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 92CC512D196 for ; Sat, 2 Apr 2016 11:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 z9k25e2ronzS for ; Sat, 2 Apr 2016 11:42:19 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B39212D182 for ; Sat, 2 Apr 2016 11:42:19 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g3so210369904ywa.3 for ; Sat, 02 Apr 2016 11:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4LYADcX2oQqYF20S4f4cLzPBQWyJyaMQ1dBib6lu4L4=; b=crgoK9ePwz5qCPnNX3pDWUWAF9XFp/irmQfISGju4wcQuQfDYjhq0lGdqm4Fv08TGC YhQJXvmK5j/4z1ceBSGqTXuyJaZ+XWhxg+2DfROr1Rotv+5x/mIlHSHSPxIg9nQkaOQZ u4NUf9G1tpA6YaVS/1/stvqDpNr6MEY9D9TC/7u3APMl/XSpO10poAoAsM8KskBvLlx4 8NkbvUX7kuZUitNe1YD0gPXzPEBmg1vTRzOJy3CIJ7DaJWKt4P3NVDROrBjJ3G0rfESB YZnMd5HV/36fwxfv+eaya2kvpDg9DfmUdAmTyEGmkQgPk1TptXbVZGcL+032vfqv+BCo LMwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4LYADcX2oQqYF20S4f4cLzPBQWyJyaMQ1dBib6lu4L4=; b=AGHFalWbZ/6A6ynqcmfqRGiQsFYyZt5asYuRI3JfDYiONJaZYNKFo2h/KVpxia7K9+ WPZFydah0H/sCTK6iUhBpi6WsMsdL4k2fWnL+xyKg0nKhQSk0liUmrKOcmD82L82dGI1 uilVyJDbh6FqzuQFG3tbbvWOl1UMHfAEg3f+EqaTPpLTWxzs5oQrYFhi+jKkgl/5Stj/ +nnYuSDvnu6g90xXBNHDJ1/8bD88TohMTt0mPoOm1tTszWg7rge6dn0WRaR3kCmnvfz5 PSb6Q78YXv6Zyjcm5Ajg0DWcFpPC4Ze8UNlElrOztlQIn0JoOQaqFOjnlhTA2VGaDliy fyzg== X-Gm-Message-State: AD7BkJJWV7Z+YuVqFSUv2X4+3Xa0N+b1k9cP/GAyyMAOlKkQTMsGcV8D5Vs1YyQBESGjHV2SXGV1wc+nlkF+zw== MIME-Version: 1.0 X-Received: by 10.129.94.9 with SMTP id s9mr10148307ywb.307.1459622538714; Sat, 02 Apr 2016 11:42:18 -0700 (PDT) Received: by 10.37.214.13 with HTTP; Sat, 2 Apr 2016 11:42:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2016 15:42:18 -0300 Message-ID: From: Spencer Dawkins at IETF To: Aaron Falk Content-Type: multipart/alternative; boundary=001a11491bbaed3ccc052f84dac8 Archived-At: Cc: Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 18:42:21 -0000 --001a11491bbaed3ccc052f84dac8 Content-Type: text/plain; charset=UTF-8 Hi, Aaron, On Sat, Apr 2, 2016 at 3:20 PM, Aaron Falk wrote: > > > On Sat, Apr 2, 2016 at 3:17 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Aaron and Gorry, >> >> On Sat, Apr 2, 2016 at 2:33 PM, Aaron Falk wrote: >> >>> Couple of minor comments on the draft >>> >>> : >>> >>> - No mention of ECN in phase 2. Am I missing something? >>> - You had asked about what app-oriented IETF groups might be able to >>> review the API. It's a good question for draft-ietf-taps-transports-usage >>> as well. Wonder if the wg has any suggestions? Perhaps we should raise >>> the question in APPSAWG although they don't seem to be meeting this IETF... >>> >>> >> If you can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at >> the welcome reception, you might ask if Dispatch is the right place to ask >> about these drafts - now that APP is part of ART, Dispatch has a broader >> scope than just RAI, and they are meeting this time (on Monday morning, so >> ask fast) ... >> >> Spencer >> > > > So, is DISPATCH the new APPSAWG? If so, we need to add it to our conflict > avoid list (esp since we conflict with it this week). > > --aaron > I'm not entirely clear on that, but I think it's kinda turning into the ART Open Area Meeting (APPSAWG actually works on stuff that doesn't have its own working group, like TSVWG). So, DISPATCH is more like TSVAREA than TSVWG. In related news, I just talked to Cullen, and he said Dispatch puts up advertisements for drafts all the time. Is all you/Gorry want to do is get a slide into the chair slide deck that says "these drafts in TSV could use ART clue and attention", that should be fine (but putting together a slide that says whatever you want to ask is the key action). I hope that helps, Spencer --001a11491bbaed3ccc052f84dac8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi, Aaron,

    On Sat, Apr 2, 2016 at 3:20 PM, Aaron Falk <= aaron.falk@gmail.= com> wrote:


    On Sat, Apr 2, 2016 at 3:17 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
    Hi, Aaron and Gorry,

    On Sat, Apr 2, 2016 at 2:33 PM,= Aaron Falk <aaron.falk@gmail.com> wrote:
    Couple of minor comments on the draft:
    • No mention of ECN in phase 2.=C2=A0 Am I miss= ing something?
    • You had asked about what app-oriented IETF group= s might be able to review the API.=C2=A0 It's a good question for draft= -ietf-taps-transports-usage as well.=C2=A0 Wonder if the wg has any suggest= ions?=C2=A0 Perhaps we should raise the question in APPSAWG although they d= on't seem to be meeting this IETF...
    =

    If you can corner Mary Barnes, Cullen Jennings, = or Murray Kucherawy at the welcome reception, you might ask if Dispatch is = the right place to ask about these drafts - now that APP is part of ART, Di= spatch has a broader scope than just RAI, and they are meeting this time (o= n Monday morning, so ask fast) ...
    =
    Spencer


    So, is DISPATCH the new APPSAW= G?=C2=A0 If so, we need to add it to our conflict avoid list (esp since we = conflict with it this week).=C2=A0

    --aaron

    I'm not entirely clear on that, but= I think it's kinda turning into the ART Open Area Meeting (APPSAWG act= ually works on stuff that doesn't have its own working group, like TSVW= G). So, DISPATCH is more like TSVAREA than TSVWG.

    = In related news, I just talked to Cullen, and he said Dispatch puts up adve= rtisements for drafts all the time. Is all you/Gorry want to do is get a sl= ide into the chair slide deck that says "these drafts in TSV could use= ART clue and attention", that should be fine (but putting together a = slide that says whatever you want to ask is the key action).

    =
    I hope that helps,

    Spencer=C2=A0
    <= /div>
    --001a11491bbaed3ccc052f84dac8-- From nobody Sat Apr 2 12:49:06 2016 Return-Path: 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 425E012D1AF for ; Sat, 2 Apr 2016 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fln3L7MGI4c4 for ; Sat, 2 Apr 2016 12:49:03 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C903D12D128 for ; Sat, 2 Apr 2016 12:49:03 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g3so211365084ywa.3 for ; Sat, 02 Apr 2016 12:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Hub8Xue/+rt2c3zTx3fxUz6TxhraibdtF7NMqjoOQmQ=; b=tJU0bgXm+byChgyFgEY1RDzr269hGpjLcDa83JXee65WjXURWHX7ARaR1Lf+9GcYIC JYmbG5AbRWx8l4Wuhb/xQwn9OniGHqxT2ayxA+wGY4C/v+rCVgejPtNrZIuY+oizuupp ATCTYtk5/KN75i1zgPbMBx9LnielTRAG8/UqUn4tpQsCet5RI5RbKwA+o+xmQOwvacdT aSwFSIxcc1Nw5XJIxUGgBD7bbArN8p0BTszggCH8lT0+0821MHsfY3MXaYzfVVo0eubS iGH4ipY5UVITVdiQx0h21FaMiJvNW39wqWOQNRpwwvI4q7GA3bqjo7j8T9PFefIbyqZ7 q5ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Hub8Xue/+rt2c3zTx3fxUz6TxhraibdtF7NMqjoOQmQ=; b=jpOtu+SXPtj3EZqk02giftopfrZCqQcrHS0r2Yqp2LS+f1BnusJE8Xgjg+ZfQsNWBL NVga1CbueD2xHqQtasS3yfUfgmxlN/bTalB8pwq0r0UUzKDRUv6NxIbzRmXpGugWGEOn cDpeE/Gp8xJ9ATsu4f1Qkl84y87RG+ktJNrgO3rE3orbbAikVr/uaWXIIIK3r9JDSMXt x5v+Qpnm3VIR4wfIuZGOvTZbmcqVNu0ZQCea+P/ew0nCmwo8I3zPdskSED+D4MAxE+P6 KPNiNOOXUixb+q3/E9eH8CechPHe4G4jwPf8xZs/ZDzy7F+AfkYdXaowTMslJc0EuGNq ys4w== X-Gm-Message-State: AD7BkJLaInBm8RS3arM3oYjArkWzhjJ/5vuI8rktMakHvzAk2qjNC67n3O4hTCp5Z+rwNGPvAthJTP5o07mUnw== MIME-Version: 1.0 X-Received: by 10.37.230.86 with SMTP id d83mr15650308ybh.139.1459626542996; Sat, 02 Apr 2016 12:49:02 -0700 (PDT) Received: by 10.37.70.198 with HTTP; Sat, 2 Apr 2016 12:49:02 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2016 16:49:02 -0300 Message-ID: From: Aaron Falk To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=94eb2c0b161299a26c052f85c9a0 Archived-At: Cc: Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 19:49:05 -0000 --94eb2c0b161299a26c052f85c9a0 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Is all you/Gorry want to do is get a slide into the chair slide deck that > says "these drafts in TSV could use ART clue and attention", that should be > fine (but putting together a slide that says whatever you want to ask is > the key action). > > To me the key question is whether it is premature. It might be useful to get a few more protocols beyond TCP, SCTP, and UDP to better illustrate the range of features. Interested in other opinions. --aaron --94eb2c0b161299a26c052f85c9a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On S= at, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com> wrote:
    Is all you/Gorry want to do is get a slide into the chair slide deck tha= t says "these drafts in TSV could use ART clue and attention", th= at should be fine (but putting together a slide that says whatever you want= to ask is the key action).


    To me the key question is whether it is premature.= =C2=A0 It might be useful to get a few more protocols beyond TCP, SCTP, and= UDP to better illustrate the range of features.=C2=A0 Interested in other = opinions.

    --aaron
    --94eb2c0b161299a26c052f85c9a0-- From nobody Sat Apr 2 15:23:12 2016 Return-Path: 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 C400212D5B3 for ; Sat, 2 Apr 2016 15:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.77, T_RP_MATCHES_RCVD=-0.01] 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 v71cenKdlwEr for ; Sat, 2 Apr 2016 15:23:08 -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 EBC9412D5B0 for ; Sat, 2 Apr 2016 15:23:07 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1amTwe-0001VF-Ny; Sun, 03 Apr 2016 00:23:04 +0200 Received: from [200.61.9.66] (helo=[172.16.3.19]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1amTwd-0002yN-TT; Sun, 03 Apr 2016 00:23:04 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_0A4C3984-9622-46FF-A863-B9D42245BA36" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Michael Welzl In-Reply-To: Date: Sat, 2 Apr 2016 19:23:10 -0300 Message-Id: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> References: To: Aaron Falk X-Mailer: Apple Mail (2.3112) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 15 sum msgs/h 7 total rcpts 39927 max rcpts/h 54 ratelimit 0 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: D8515DDE8AD64F5206B5D60030EC844AD4429477 X-UiO-SPAM-Test: remote_host: 200.61.9.66 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 4 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 22:23:11 -0000 --Apple-Mail=_0A4C3984-9622-46FF-A863-B9D42245BA36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2. apr. 2016, at 16.49, Aaron Falk wrote: >=20 > On Sat, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF = > = wrote: > Is all you/Gorry want to do is get a slide into the chair slide deck = that says "these drafts in TSV could use ART clue and attention", that = should be fine (but putting together a slide that says whatever you want = to ask is the key action). >=20 >=20 > To me the key question is whether it is premature. It might be useful = to get a few more protocols beyond TCP, SCTP, and UDP to better = illustrate the range of features. Interested in other opinions. As an author of the -usage document, this being premature is indeed also = my concern. I=E2=80=99d feel more comfortable doing this with the next = version, at the next IETF. Cheers, Michael --Apple-Mail=_0A4C3984-9622-46FF-A863-B9D42245BA36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On 2. apr. 2016, at 16.49, Aaron Falk <aaron.falk@gmail.com> wrote:

    On Sat, = Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> = wrote:
    Is all you/Gorry want to do is get a slide into the chair = slide deck that says "these drafts in TSV could use ART clue and = attention", that should be fine (but putting together a slide that says = whatever you want to ask is the key action).


    To me the key question is whether it is = premature.  It might be useful to get a few more protocols beyond = TCP, SCTP, and UDP to better illustrate the range of features.  = Interested in other = opinions.

    As an author of the -usage document, this being = premature is indeed also my concern. I=E2=80=99d feel more comfortable = doing this with the next version, at the next IETF.

    Cheers,
    Michael

    = --Apple-Mail=_0A4C3984-9622-46FF-A863-B9D42245BA36-- From nobody Sun Apr 3 04:54:14 2016 Return-Path: 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 32D2212D5DD for ; Sun, 3 Apr 2016 04:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 naWKLeIdy3gE for ; Sun, 3 Apr 2016 04:54:11 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEAC12D520 for ; Sun, 3 Apr 2016 04:54:09 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 369651B00259; Sun, 3 Apr 2016 13:06:14 +0100 (BST) Received: from 190.111.246.165 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Sun, 3 Apr 2016 12:54:06 +0100 Message-ID: In-Reply-To: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> Date: Sun, 3 Apr 2016 12:54:06 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Aaron Falk , gorry@erg.abdn.ac.uk, Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 11:54:14 -0000 When someone talks about using TCP or SCTP then they are typically using an API to the transport that hides a lot of details. My present draft is only about the Datagram aspects of the API. For UDP applications, many times you need require options or IP-level functions along with UDP. I'd personally love to get helpful review inputs the ART area people (applications/real-time) to figure this out. I was hoping we could put the text in the WG draft after we got this input. But maybe, this can't happen soon... and we need a different plan? I'll maybe see you people today perhaps to decide how best to present this? Gorry > >> On 2. apr. 2016, at 16.49, Aaron Falk wrote: >> >> On Sat, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF >> > >> wrote: >> Is all you/Gorry want to do is get a slide into the chair slide deck >> that says "these drafts in TSV could use ART clue and attention", that >> should be fine (but putting together a slide that says whatever you want >> to ask is the key action). >> >> >> To me the key question is whether it is premature. It might be useful >> to get a few more protocols beyond TCP, SCTP, and UDP to better >> illustrate the range of features. Interested in other opinions. > > As an author of the -usage document, this being premature is indeed also > my concern. I’d feel more comfortable doing this with the next version, > at the next IETF. > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Sun Apr 3 06:15:30 2016 Return-Path: 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 365BE12D1C0 for ; Sun, 3 Apr 2016 06:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.77, T_RP_MATCHES_RCVD=-0.01] 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 1xum4rx-d544 for ; Sun, 3 Apr 2016 06:15:25 -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 8431212D107 for ; Sun, 3 Apr 2016 06:15:25 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1amhsB-0002C2-6m; Sun, 03 Apr 2016 15:15:23 +0200 Received: from [200.61.9.66] (helo=[172.16.3.23]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1amhsA-0002qG-A2; Sun, 03 Apr 2016 15:15:23 +0200 References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13D15) From: Michael Welzl Date: Sun, 3 Apr 2016 10:15:11 -0300 To: gorry@erg.abdn.ac.uk X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 39955 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 644EAA9D7AECD6CBDEA8BDE9AF1006BE50F70313 X-UiO-SPAM-Test: remote_host: 200.61.9.66 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 21 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 13:15:29 -0000 Sent from my iPhone > On 3. apr. 2016, at 08.54, w= rote: >=20 > When someone talks about using TCP or SCTP then they are typically using > an API to the transport that hides a lot of details. My present draft is > only about the Datagram aspects of the API. For UDP applications, many > times you need require options or IP-level functions along with UDP. I'd > personally love to get helpful review inputs the ART area people > (applications/real-time) to figure this out. >=20 > I was hoping we could put the text in the WG draft after we got this > input. But maybe, this can't happen soon... and we need a different plan? it sounds good to me; when i said premature i was thinking of my own doc, no= t this udp one > I'll maybe see you people today perhaps to decide how best to present > this? jfyi not me, not going to be at reception >=20 > Gorry >=20 >>=20 >>> On 2. apr. 2016, at 16.49, Aaron Falk wrote: >>>=20 >>> On Sat, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF >>> > >>> wrote: >>> Is all you/Gorry want to do is get a slide into the chair slide deck >>> that says "these drafts in TSV could use ART clue and attention", that >>> should be fine (but putting together a slide that says whatever you want= >>> to ask is the key action). >>>=20 >>>=20 >>> To me the key question is whether it is premature. It might be useful >>> to get a few more protocols beyond TCP, SCTP, and UDP to better >>> illustrate the range of features. Interested in other opinions. >>=20 >> As an author of the -usage document, this being premature is indeed also >> my concern. I=E2=80=99d feel more comfortable doing this with the next ve= rsion, >> at the next IETF. >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Sun Apr 3 17:21:03 2016 Return-Path: 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 78F8A12D122 for ; Sun, 3 Apr 2016 17:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3PFHhKEMi1CV for ; Sun, 3 Apr 2016 17:21:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9649B12D0CB for ; Sun, 3 Apr 2016 17:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5670; q=dns/txt; s=iport; t=1459729260; x=1460938860; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=lchfk2CfPVLbgb3+zBrhIJCDxxWdm2orvp8R1pd2guo=; b=Ml2AE1sEAijYxI/+jW/vkAaSvLLwEFxXEGqr5pKmon0IxiULf7Lk2IQg KaJxuoup8KrtDGvs93E0PewOfqMRqoltIkthnuPCrECJFlteIvFitpiLs ESMSIHGUStmBhe5S7UR+j3kQnV1QF1dYrjMwebt15VALD3qub9HGEvRSF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgCEsgFX/4kNJK1dgze8cgENI4FPh?= =?us-ascii?q?g0CgSQ4FAEBAQEBAQFlJ4RCAQEEOj8QCyElDwVJiDq7LwEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBARWKaoQgAQEFg0OCKwWOQYlAjX4Kjw+PGh4BAUKEBxyGfQcCF4EdA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.24,438,1454976000"; d="scan'208";a="256914336" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 00:20:59 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u340KwTq030455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2016 00:20:59 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u340KwcI001978; Sun, 3 Apr 2016 17:20:58 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u340Kw5Y001977; Sun, 3 Apr 2016 17:20:58 -0700 Date: Sun, 3 Apr 2016 17:20:58 -0700 From: Toerless Eckert To: Aaron Falk Message-ID: <20160404002058.GA30737@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 00:21:02 -0000 1. Steps 1 and 2 look to me like "inside sausage factory", aka: trying to reverse engineer the justification for some sane service descriptions from past IETF work and real implementation knowledge on the side. I think it would be lovely if Step 3 could end up as a separte document thats used going forward, and 1.1 are for folks in historic interest (aka: separate them out). But i am sure there is all type of important IETF/TAPS reasoning why this is not desirable ;-) 2. Unless i am overlooking something, pass 2 and 3 do not define weell enough how the transport service endpoints work (aka: what we call sockets in BSD, but that really work the same logically in all OS, even those that tried not to call them sockets). And it would make the transport service description pretty useless if that was not made clearer. Eg: Consider someone used the transport service definitions of this drat randomnly, there is no way to figure out which would or would not succeed, because there is no definition how send/received packets are associated to transport service endpoints. Example: LISTEN.UDP: Pass 1 primitive: 'receive'. Parameters: 1 local IP address (optional); 1 destination transport address. If you really mean to say destination (remote) transport address, then this is not the listen() of the socket API, and i would not know how this listen would work, eg: what would happen if multiple parallel calls to this are made by competing apps on the same host. Demultiplexing protocol (UDP) packes is obviously the key part of the transport service. One approach would be to define a transport service endpoint as a packet signature that is "owned" by this transport service endpoint: (LocalIP,LocalPort,Porto,DstIP,DstPort) A "server" transport service endpoint owns (LocalIP,LocalPort,Proto*,*). This is what you get when you do socket(Proto), bind(LocalIP,LocalPort). This could be represented in the API as BIND(LocalAddr,LocalPort). Details here include: - LocalAddr can be one explicit address or ANY{-AF} ANY{-AF} is lready quite egregious in existing socket APIs, 0.0.0.0 indicates only AF=IPv4 ANY, whereas :: indicates IPv4 and IPv6 ANY (AFAIK). - LocalPort = ANY means you do get an allocation of a "free" port. Which means that you need some API call OR a return value showing the actually LocalPort. Indeed, if we wanted to define a good API, wee wanted to have some ANY-Range{MIN..MAX} parameter option given how we (IETF) have defined UDP port ranges with specific semantics. So, The BIND API call has success/failure critera that can also be detailled. I can do SEND/RECEIVE on this communications endpoint, this is probably what we'd call the "unconnected" mode. Of course there is the CONNECT paradigm for connected sockets. IMHO, it is also crucial to worry about the local port in the API. In your writeup it looks like you only consider that the local port is automatically assigned implicit by CONNECT. Which is fine in many cases, but not if you want some upfront signaling like ICE. In those cases, you do a BIND first to know your local port and then do some signaling... And maybe later you do a CONNECT . In another mail thread you asked about reraching out to ART. IMHO, a crucial aspect for the application folks is the demultiplexing model. Without defining what packets a transport endpoint has ownership of, all bets are off. Eg: If i just had a 5-tuple ownership model, i do not own a local port, so i would have to potentially redo a signaling that expects local port ownership for every connection, because i could not necessarily get to every remote site with my local port, because some other app may have it. 3. Having lamented on the above: The socket APIs are pretty good with all of the above, i am just worried about making sure we actually capture it in our IETF specs. BUT: The socket APIs IMHO do quite well suck on doing the same for IP multicast. Aka: For unicast, the packet signature is well embodied in the socket, aka: a socket has the right options of packet ownerships (non-connected, connected). For IP multicast, that concept does not exist well, and it would be lovely if we could have an API definition that introduces the same level of ownership. Eg: Socket ownership is always around local port or 5-tuple connection. Which is just the granularity useful in unicast. In IP multicast it does not make sense. If i am application A with eg: (S,G) traffic over Port P1, i do certainly not want some other application B to also use (S,G) traffic over port P2: In the network, we would now get traffic for A go to all receivers of B and vice versa. Aka: its an attack vector, albeit in most cases not intentional but by stupidity of address selection. So, for IP multicast, you really want to BIND (own) to (RemoteAddr) - not Port, not Proto - for ASM, and to (LocalAddr,RemoteAddr) for SSM. And of course in IPv6 the permissible binding could be derived from RemoteAddr (indicates ASM or SSM). Now, of course, this does not help me for App B on another host to mess up my multicast traffic trees, but the whole point is about creating a transport service definition that is IMHO as good and logical as possible for the service as we can make it, and right now, the APIs are really 30 years developed and pretty good for unicast, but multicast is just an afterthought, and quite illogical by just following the unicast API model and adding some *yuck* setsockopts. Cheers toerless From nobody Sun Apr 3 18:18:48 2016 Return-Path: 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 E88CE12D11A for ; Sun, 3 Apr 2016 18:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.77, T_RP_MATCHES_RCVD=-0.01] 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 eWtBbZPcXv5V for ; Sun, 3 Apr 2016 18:18:44 -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 894F112D103 for ; Sun, 3 Apr 2016 18:18:44 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1amtA8-0008NC-5I; Mon, 04 Apr 2016 03:18:40 +0200 Received: from [200.61.9.66] (helo=[172.16.3.19]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1amtA7-0001pq-FA; Mon, 04 Apr 2016 03:18:40 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Michael Welzl In-Reply-To: <20160404002058.GA30737@cisco.com> Date: Sun, 3 Apr 2016 22:18:35 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6F1DA28D-3F1E-4293-9BED-CAB4F767522B@ifi.uio.no> References: <20160404002058.GA30737@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3112) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 13 sum msgs/h 5 total rcpts 39979 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: 6A6E516E8DD7145727BDC0B403DDB28C0F19EF5C X-UiO-SPAM-Test: remote_host: 200.61.9.66 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 32 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , " Fairhurst" , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 01:18:47 -0000 Hi, I don=E2=80=99t want to go into specifics about this draft, that should = be up to its authors=E2=80=A6 just a general point: > On 3. apr. 2016, at 21.20, Toerless Eckert wrote: >=20 > 1. Steps 1 and 2 look to me like "inside sausage factory", aka: > trying to reverse engineer the justification for some sane service = descriptions > from past IETF work and real implementation knowledge on the side. I = think > it would be lovely if Step 3 could end up as a separte document = thats used > going forward, and 1.1 are for folks in historic interest (aka: = separate them out). >=20 > But i am sure there is all type of important IETF/TAPS reasoning why = this is > not desirable ;-) Step 2 is a better practical basis for developing an API than step 3. I=E2=80=99d agree about step 1; this only exists to systematically = arrive at steps 2 and 3. The reasoning behind the three steps is explained in = draft-ietf-taps-transports-usage Cheers, Michael From nobody Mon Apr 4 09:20:44 2016 Return-Path: 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 DB64512D1BF for ; Mon, 4 Apr 2016 09:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 e_KxPaRYRRbI for ; Mon, 4 Apr 2016 09:20:39 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7C26812D170 for ; Mon, 4 Apr 2016 09:20:39 -0700 (PDT) Received: from [IPv6:2001:67c:370:152:54ad:d7ab:6b39:ddd2] (unknown [IPv6:2001:67c:370:152:54ad:d7ab:6b39:ddd2]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1BED71B001DB; Mon, 4 Apr 2016 17:32:51 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (13E233) In-Reply-To: <6F1DA28D-3F1E-4293-9BED-CAB4F767522B@ifi.uio.no> Date: Mon, 4 Apr 2016 13:20:35 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160404002058.GA30737@cisco.com> <6F1DA28D-3F1E-4293-9BED-CAB4F767522B@ifi.uio.no> To: Michael Welzl Archived-At: Cc: Aaron Falk , Toerless Eckert , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 16:20:43 -0000 The process stuff is I think in the WG draft. The questions on port usage of= UDP and the implications on the service model - these are things I would li= ke to explore.=20 Let's see if we can find some additional text on this for the next rev. Gorry > On 3 Apr 2016, at 22:18, Michael Welzl wrote: >=20 > Hi, >=20 > I don=E2=80=99t want to go into specifics about this draft, that should be= up to its authors=E2=80=A6 just a general point: >=20 >> On 3. apr. 2016, at 21.20, Toerless Eckert wrote: >>=20 >> 1. Steps 1 and 2 look to me like "inside sausage factory", aka: >> trying to reverse engineer the justification for some sane service descr= iptions >> from past IETF work and real implementation knowledge on the side. I thi= nk >> it would be lovely if Step 3 could end up as a separte document thats us= ed >> going forward, and 1.1 are for folks in historic interest (aka: separate= them out). >>=20 >> But i am sure there is all type of important IETF/TAPS reasoning why thi= s is >> not desirable ;-) >=20 > Step 2 is a better practical basis for developing an API than step 3. > I=E2=80=99d agree about step 1; this only exists to systematically arrive a= t steps 2 and 3. >=20 > The reasoning behind the three steps is explained in draft-ietf-taps-trans= ports-usage >=20 > Cheers, > Michael From nobody Mon Apr 4 10:32:47 2016 Return-Path: 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 EA21312D118 for ; Mon, 4 Apr 2016 10:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 czj-H9mPAqPn for ; Mon, 4 Apr 2016 10:32:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8827A12D12E for ; Mon, 4 Apr 2016 10:32:45 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u34HVul3017724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 10:31:57 -0700 (PDT) To: Toerless Eckert , Aaron Falk References: <20160404002058.GA30737@cisco.com> From: Joe Touch Message-ID: <5702A50B.3040300@isi.edu> Date: Mon, 4 Apr 2016 10:31:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160404002058.GA30737@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Gorry Fairhurst , "taps@ietf.org" , touch@isi.edu Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:32:47 -0000 On 4/3/2016 5:20 PM, Toerless Eckert wrote: > Eg: Consider someone used the transport service definitions of this drat randomnly, > there is no way to figure out which would or would not succeed, because there is > no definition how send/received packets are associated to transport service endpoints. > > Example: LISTEN.UDP: > Pass 1 primitive: 'receive'. > Parameters: 1 local IP address (optional); 1 destination transport address. It should be: local IP address or ANY it's not really "optional"; it's more like ANY is the default until overridden local port (selected explicitly or "let the OS pick") remote IP address or ANY (same thing as above) remote port or ANY NOTE: any of these can be indicated for most existing implementations of UDP. The local side is set using the BIND call and the remote side set using the CONNECT call - which is a bit confusing because UDP is connectionless. That's why the CONNECT used here is confusing - it's used more like BIND than CONNECT and ignores the existing CONNECT semantics. ---- Note that this should allow some cases that aren't really well understood or implemented, e.g.: two different OS endpoints listen as follows: A on loc-IP ANY loc-port 80 B on loc-IP 10.0.0.1 loc-port 80 I.e., there's ambiguity as to whether ANY means EVERY or "any except those more specifically bound". ---- Additionally, there's no such thing as CLOSE for UDP. CLOSE happens on the OS endpoint, not the connection. AFAIR, this is the difference between unix close() and shutdown(). The former disconnects both the connection and the OS endpoint, whereas the latter "undoes" the corresponding connect() but not the socket creation, allowing half-open connections (I wonder - is shutdown() implemented for UDP? does it clear out the remote IP/port expectations?) Joe From nobody Mon Apr 4 10:37:01 2016 Return-Path: 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 6FA6912D61D for ; Mon, 4 Apr 2016 10:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 dDSmuppKuBPK for ; Mon, 4 Apr 2016 10:36:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE2712D118 for ; Mon, 4 Apr 2016 10:36:52 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u34Ha896018531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 10:36:09 -0700 (PDT) To: Toerless Eckert , Aaron Falk References: <20160404002058.GA30737@cisco.com> <5702A50B.3040300@isi.edu> From: Joe Touch Message-ID: <5702A608.3040201@isi.edu> Date: Mon, 4 Apr 2016 10:36:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702A50B.3040300@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Gorry Fairhurst , "taps@ietf.org" , touch@isi.edu Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:36:59 -0000 On 4/4/2016 10:31 AM, Joe Touch wrote: > AFAIR, this is the difference between unix close() and shutdown(). The > former disconnects both the connection and the OS endpoint, whereas the > latter "undoes" the corresponding connect() but not the socket creation, > allowing half-open connections (I wonder - is shutdown() implemented for > UDP? does it clear out the remote IP/port expectations?) Just dug a bit deeper - seems like shutdown() [in man section 3] just decouples the send and receive close of the unix socket, so it still does both connection and OS endpoint operations but decouples send and receive. I have not found an operation that lets you specifically close a TCP connection without affecting the unix socket (i.e., to issue a half close but not disconnect the send side of the OS endpoint) - though that might not have any useful meaning. For UDP, I wonder what happens if you issue multiple connects... (if I have time, I'll try this and check, but if others have experience, let us know) Joe From nobody Mon Apr 4 10:45:41 2016 Return-Path: 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 298B012D14E for ; Mon, 4 Apr 2016 10:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ukNZANwl3_P5 for ; Mon, 4 Apr 2016 10:45:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A636812D128 for ; Mon, 4 Apr 2016 10:45:38 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u34HipME019954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 10:44:52 -0700 (PDT) To: gorry@erg.abdn.ac.uk, Michael Welzl References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> From: Joe Touch Message-ID: <5702A813.90908@isi.edu> Date: Mon, 4 Apr 2016 10:44:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Spencer Dawkins , touch@isi.edu Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:45:40 -0000 On 4/3/2016 4:54 AM, gorry@erg.abdn.ac.uk wrote: > When someone talks about using TCP or SCTP then they are typically using > an API to the transport that hides a lot of details. I'm not sure I agree with this. IMO, TCP defines an API that is intended to provide a service capability that it renders on top of less-capable underlying services. UDP does this much less so, so that might be a simpler place to start, but only because the level of service is simpler - not because of "hiding a lot of details". Joe From nobody Mon Apr 4 10:55:09 2016 Return-Path: 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 B93B612D115 for ; Mon, 4 Apr 2016 10:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 uPn6AMwZuNhG for ; Mon, 4 Apr 2016 10:55:05 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0599A12D0A8 for ; Mon, 4 Apr 2016 10:55:05 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id B76271B001A7; Mon, 4 Apr 2016 19:07:10 +0100 (BST) Received: from 31.133.155.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 4 Apr 2016 18:55:04 +0100 Message-ID: <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> In-Reply-To: <5702A813.90908@isi.edu> References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> Date: Mon, 4 Apr 2016 18:55:04 +0100 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, Aaron Falk , Michael Welzl , touch@isi.edu, Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:55:07 -0000 I was thinking in terms of what we were trying to achieve within TAPS, and from that perspective things like: ECN-marks, Maximum datagram/segment size, etc. I do not think through the TCP API (for instance), since these concern the path and are only needed by CC or PMTUD algorithms within TCP. These same values do need to be accessed (visible) over the current UDP API so that apps can implement mechanisms that use these. Gorry > On 4/3/2016 4:54 AM, gorry@erg.abdn.ac.uk wrote: >> When someone talks about using TCP or SCTP then they are typically using >> an API to the transport that hides a lot of details. > > I'm not sure I agree with this. > > IMO, TCP defines an API that is intended to provide a service capability > that it renders on top of less-capable underlying services. > > UDP does this much less so, so that might be a simpler place to start, > but only because the level of service is simpler - not because of > "hiding a lot of details". > > Joe > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Mon Apr 4 11:07:56 2016 Return-Path: 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 3A2BB12D564 for ; Mon, 4 Apr 2016 11:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 30bgIJINMq8M for ; Mon, 4 Apr 2016 11:07:52 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F9712D134 for ; Mon, 4 Apr 2016 11:07:52 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u34I6NWa023846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 11:06:24 -0700 (PDT) To: gorry@erg.abdn.ac.uk References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> From: Joe Touch Message-ID: <5702AD1F.6080303@isi.edu> Date: Mon, 4 Apr 2016 11:06:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u34I6NWa023846 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Spencer Dawkins , Michael Welzl , touch@isi.edu Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:07:55 -0000 Hi, Gorry, On 4/4/2016 10:55 AM, gorry@erg.abdn.ac.uk wrote: > I was thinking in terms of what we were trying to achieve within TAPS, and > from that perspective things like: ECN-marks, Maximum datagram/segment > size, etc. I do not think through the TCP API (for instance), since these > concern the path and are only needed by CC or PMTUD algorithms within TCP. > > These same values do need to be accessed (visible) over the current UDP > API so that apps can implement mechanisms that use these. These are different things, IMO. The TCP API needs a way to set any flags in the TCP header, either directly or indirectly. TCP does NOT require a way to set the MSS or segment size, IMO - that ought to be something it figures out from the interface parameters, IP settings, remote end, and path. It may be useful to set these things for instrumentation purposes, but not for regular operation. For MSS and segment size, the same ought to be true for UDP. For ECN, UDP ought to be ignorant - as should its API. The only question is whether the UDP API should have a "pass through" for signals from lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the UDP API; they're part of the OS endpoint API to these other protocols. Joe > > Gorry > >> On 4/3/2016 4:54 AM, gorry@erg.abdn.ac.uk wrote: >>> When someone talks about using TCP or SCTP then they are typically using >>> an API to the transport that hides a lot of details. >> >> I'm not sure I agree with this. >> >> IMO, TCP defines an API that is intended to provide a service capability >> that it renders on top of less-capable underlying services. >> >> UDP does this much less so, so that might be a simpler place to start, >> but only because the level of service is simpler - not because of >> "hiding a lot of details". >> >> Joe >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> From nobody Mon Apr 4 11:24:06 2016 Return-Path: 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 11CD812D17A for ; Mon, 4 Apr 2016 11:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 nNM-SFUxa8QL for ; Mon, 4 Apr 2016 11:24:03 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 782E212D190 for ; Mon, 4 Apr 2016 11:24:03 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 998F91B001DB; Mon, 4 Apr 2016 19:36:08 +0100 (BST) Received: from 2001:67c:370:152:d4e3:8a4e:41ec:430 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 4 Apr 2016 19:24:02 +0100 Message-ID: <7daecb443d1b93875027c4d945c594df.squirrel@erg.abdn.ac.uk> In-Reply-To: <5702AD1F.6080303@isi.edu> References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> <5702AD1F.6080303@isi.edu> Date: Mon, 4 Apr 2016 19:24:02 +0100 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, Aaron Falk , Michael Welzl , touch@isi.edu, Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:24:05 -0000 Hi Joe, We don't seem to be agreeing. > Hi, Gorry, > > On 4/4/2016 10:55 AM, gorry@erg.abdn.ac.uk wrote: >> I was thinking in terms of what we were trying to achieve within TAPS, >> and >> from that perspective things like: ECN-marks, Maximum datagram/segment >> size, etc. I do not think through the TCP API (for instance), since >> these >> concern the path and are only needed by CC or PMTUD algorithms within >> TCP. >> >> These same values do need to be accessed (visible) over the current UDP >> API so that apps can implement mechanisms that use these. > > These are different things, IMO. > > The TCP API needs a way to set any flags in the TCP header, either > directly or indirectly. > Agree > TCP does NOT require a way to set the MSS or segment size, IMO - that > ought to be something it figures out from the interface parameters, IP > settings, remote end, and path. It may be useful to set these things for > instrumentation purposes, but not for regular operation. > Agree. > For MSS and segment size, the same ought to be true for UDP. > No. It's true that UDP needs to know this, but this info needs to arrive at the App, either from a primitive that returns the size or from a failed send call when probing for a maximum datagram size. The app also may need to control DF if it wants to do path probing of PMTU, whereas in TCP this is handed within the transport protocol.. > For ECN, UDP ought to be ignorant - as should its API. The only question > is whether the UDP API should have a "pass through" for signals from > lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the > UDP API; they're part of the OS endpoint API to these other protocols. > I don't understand what you are saying about an "OS endpoint API to IP". To me the API has to signal per-datagram on send whether ECT(0) or ECT(1) or neither is to be set, the receive API needs to see the received ECN field for each datagram. Do you see a different way to do this? Gorry > Joe > >> >> Gorry >> >>> On 4/3/2016 4:54 AM, gorry@erg.abdn.ac.uk wrote: >>>> When someone talks about using TCP or SCTP then they are typically >>>> using >>>> an API to the transport that hides a lot of details. >>> >>> I'm not sure I agree with this. >>> >>> IMO, TCP defines an API that is intended to provide a service >>> capability >>> that it renders on top of less-capable underlying services. >>> >>> UDP does this much less so, so that might be a simpler place to start, >>> but only because the level of service is simpler - not because of >>> "hiding a lot of details". >>> >>> Joe >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> > From nobody Mon Apr 4 11:31:11 2016 Return-Path: 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 E1A2112D76F for ; Mon, 4 Apr 2016 11:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0-bNimX6bqwf for ; Mon, 4 Apr 2016 11:31:03 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BA212D735 for ; Mon, 4 Apr 2016 11:31:02 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u34IUWT8027066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 11:30:33 -0700 (PDT) To: gorry@erg.abdn.ac.uk References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> <5702AD1F.6080303@isi.edu> <7daecb443d1b93875027c4d945c594df.squirrel@erg.abdn.ac.uk> From: Joe Touch Message-ID: <5702B2C8.5030005@isi.edu> Date: Mon, 4 Apr 2016 11:30:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <7daecb443d1b93875027c4d945c594df.squirrel@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u34IUWT8027066 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Spencer Dawkins , Michael Welzl , touch@isi.edu Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:31:07 -0000 On 4/4/2016 11:24 AM, gorry@erg.abdn.ac.uk wrote: > Hi Joe, > > We don't seem to be agreeing. Not yet at least ;-) ... >> For MSS and segment size, the same ought to be true for UDP. >> > No. It's true that UDP needs to know this, but this info needs to arrive > at the App, either from a primitive that returns the size or from a failed > send call when probing for a maximum datagram size. The app also may need > to control DF if it wants to do path probing of PMTU, whereas in TCP this > is handed within the transport protocol.. Ahh - I see this now. However, IMO, that ought to be something it gets from the IP layer, not from UDP. UDP has an MSS that's defined by the protocol itself which is not all that useful to indicate to the app. >> For ECN, UDP ought to be ignorant - as should its API. The only question >> is whether the UDP API should have a "pass through" for signals from >> lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the >> UDP API; they're part of the OS endpoint API to these other protocols. >> > I don't understand what you are saying about an "OS endpoint API to IP". > To me the API has to signal per-datagram on send whether ECT(0) or ECT(1) > or neither is to be set, the receive API needs to see the received ECN > field for each datagram. > > Do you see a different way to do this? Here's the issue - when a message arrives, right now we think of it being "from UDP" as part of the UDP API. However, there are no ECN markings in UDP. It makes sense to forward the IP source/dest in the UDP API because that part of the IP header is defined as part of UDP (as the pseudoheader). However, it makes no sense to have that information available as part of what UDP passes to the app per se. So maybe each UDP message is allowed to forward a single opaque (to UDP) structure that contains information from any of its underlying layers (i.e., a pass-through signal mechanism). But I would consider that not really integral to the API of UDP. I do agree this needs to be per message, not per endpoint. Joe > > Gorry > >> Joe >> >>> >>> Gorry >>> >>>> On 4/3/2016 4:54 AM, gorry@erg.abdn.ac.uk wrote: >>>>> When someone talks about using TCP or SCTP then they are typically >>>>> using >>>>> an API to the transport that hides a lot of details. >>>> >>>> I'm not sure I agree with this. >>>> >>>> IMO, TCP defines an API that is intended to provide a service >>>> capability >>>> that it renders on top of less-capable underlying services. >>>> >>>> UDP does this much less so, so that might be a simpler place to start, >>>> but only because the level of service is simpler - not because of >>>> "hiding a lot of details". >>>> >>>> Joe >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>> >> From nobody Mon Apr 4 12:49:51 2016 Return-Path: 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 9846812D855 for ; Mon, 4 Apr 2016 12:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 prrV7Jv6FRHR for ; Mon, 4 Apr 2016 12:49:47 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id D0C9412D858 for ; Mon, 4 Apr 2016 12:49:44 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 8135A1B001A7; Mon, 4 Apr 2016 21:01:48 +0100 (BST) Received: from 2001:67c:370:152:f8a8:b448:92d3:5408 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 4 Apr 2016 20:49:44 +0100 Message-ID: <78b2e990fa6a83f886c59dd56c178b9e.squirrel@erg.abdn.ac.uk> In-Reply-To: <5702B2C8.5030005@isi.edu> References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> <5702AD1F.6080303@isi.edu> <7daecb443d1b93875027c4d945c594df.squirrel@erg.abdn.ac.uk> <5702B2C8.5030005@isi.edu> Date: Mon, 4 Apr 2016 20:49:44 +0100 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, Aaron Falk , Michael Welzl , touch@isi.edu, Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:49:50 -0000 See below > > On 4/4/2016 11:24 AM, gorry@erg.abdn.ac.uk wrote: >> Hi Joe, >> >> We don't seem to be agreeing. > > Not yet at least ;-) > > ... >>> For MSS and segment size, the same ought to be true for UDP. >>> >> No. It's true that UDP needs to know this, but this info needs to arrive >> at the App, either from a primitive that returns the size or from a >> failed >> send call when probing for a maximum datagram size. The app also may >> need >> to control DF if it wants to do path probing of PMTU, whereas in TCP >> this >> is handed within the transport protocol.. > > Ahh - I see this now. However, IMO, that ought to be something it gets > from the IP layer, not from UDP. UDP has an MSS that's defined by the > protocol itself which is not all that useful to indicate to the app. > I see what you are saying for reading the MTU less headers, but whatever the method, the APP needs to work out what to do with this. For setting DF this is not necessarily an IP setting for all packets, it can be a per UDP datagram choice. >>> For ECN, UDP ought to be ignorant - as should its API. The only >>> question >>> is whether the UDP API should have a "pass through" for signals from >>> lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the >>> UDP API; they're part of the OS endpoint API to these other protocols. >>> >> I don't understand what you are saying about an "OS endpoint API to IP". >> To me the API has to signal per-datagram on send whether ECT(0) or >> ECT(1) >> or neither is to be set, the receive API needs to see the received ECN >> field for each datagram. >> >> Do you see a different way to do this? > > Here's the issue - when a message arrives, right now we think of it > being "from UDP" as part of the UDP API. However, there are no ECN > markings in UDP. It makes sense to forward the IP source/dest in the UDP > API because that part of the IP header is defined as part of UDP (as the > pseudoheader). However, it makes no sense to have that information > available as part of what UDP passes to the app per se. > > So maybe each UDP message is allowed to forward a single opaque (to UDP) > structure that contains information from any of its underlying layers > (i.e., a pass-through signal mechanism). But I would consider that not > really integral to the API of UDP. > > I do agree this needs to be per message, not per endpoint. > That sounds a lot like you are thinking about a concrete API. And I agree, to implement this, you can do exactly that and provide additional data per datagram buffer to communicate the DSCP, ECN, TTL ... Gorry > Joe >> >> Gorry >> >>> Joe >>> >>>> >>>> Gorry >>>> >>>>> On 4/3/2016 4:54 AM, gorry@erg.abdn.ac.uk wrote: >>>>>> When someone talks about using TCP or SCTP then they are typically >>>>>> using >>>>>> an API to the transport that hides a lot of details. >>>>> >>>>> I'm not sure I agree with this. >>>>> >>>>> IMO, TCP defines an API that is intended to provide a service >>>>> capability >>>>> that it renders on top of less-capable underlying services. >>>>> >>>>> UDP does this much less so, so that might be a simpler place to >>>>> start, >>>>> but only because the level of service is simpler - not because of >>>>> "hiding a lot of details". >>>>> >>>>> Joe >>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>> >>> > From nobody Mon Apr 4 13:25:11 2016 Return-Path: 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 EA4B512D111 for ; Mon, 4 Apr 2016 13:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 e3PmYs23Cc3t for ; Mon, 4 Apr 2016 13:25:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4997812D825 for ; Mon, 4 Apr 2016 13:25:05 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u34KOnPG014039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 13:24:50 -0700 (PDT) To: gorry@erg.abdn.ac.uk References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> <5702AD1F.6080303@isi.edu> <7daecb443d1b93875027c4d945c594df.squirrel@erg.abdn.ac.uk> <5702B2C8.5030005@isi.edu> <78b2e990fa6a83f886c59dd56c178b9e.squirrel@erg.abdn.ac.uk> From: Joe Touch Message-ID: <5702CD91.9070101@isi.edu> Date: Mon, 4 Apr 2016 13:24:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <78b2e990fa6a83f886c59dd56c178b9e.squirrel@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u34KOnPG014039 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Spencer Dawkins , Michael Welzl , touch@isi.edu Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:25:09 -0000 On 4/4/2016 12:49 PM, gorry@erg.abdn.ac.uk wrote: ... >>> No. It's true that UDP needs to know this, but this info needs to arrive >>> at the App, either from a primitive that returns the size or from a >>> failed >>> send call when probing for a maximum datagram size. The app also may >>> need >>> to control DF if it wants to do path probing of PMTU, whereas in TCP >>> this >>> is handed within the transport protocol.. >> >> Ahh - I see this now. However, IMO, that ought to be something it gets >> from the IP layer, not from UDP. UDP has an MSS that's defined by the >> protocol itself which is not all that useful to indicate to the app. >> > I see what you are saying for reading the MTU less headers, but whatever > the method, the APP needs to work out what to do with this. For setting DF > this is not necessarily an IP setting for all packets, it can be a per UDP > datagram choice. Sure, but again that argues for a transparent supplement to the UDP API, not for a UDP-specific API. >>>> For ECN, UDP ought to be ignorant - as should its API. The only >>>> question >>>> is whether the UDP API should have a "pass through" for signals from >>>> lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the >>>> UDP API; they're part of the OS endpoint API to these other protocols. >>>> >>> I don't understand what you are saying about an "OS endpoint API to IP". >>> To me the API has to signal per-datagram on send whether ECT(0) or >>> ECT(1) >>> or neither is to be set, the receive API needs to see the received ECN >>> field for each datagram. >>> >>> Do you see a different way to do this? >> >> Here's the issue - when a message arrives, right now we think of it >> being "from UDP" as part of the UDP API. However, there are no ECN >> markings in UDP. It makes sense to forward the IP source/dest in the UDP >> API because that part of the IP header is defined as part of UDP (as the >> pseudoheader). However, it makes no sense to have that information >> available as part of what UDP passes to the app per se. >> >> So maybe each UDP message is allowed to forward a single opaque (to UDP) >> structure that contains information from any of its underlying layers >> (i.e., a pass-through signal mechanism). But I would consider that not >> really integral to the API of UDP. >> >> I do agree this needs to be per message, not per endpoint. >> > That sounds a lot like you are thinking about a concrete API. Way more abstract. The issue is that these features are not inherent in UDP - they are inherent in the IP over which UDP runs (and depend on that IP version). > And I agree, > to implement this, you can do exactly that and provide additional data per > datagram buffer to communicate the DSCP, ECN, TTL ... My point is that - at the abstract level - UDP should not have an API that talks about DSCP, ECN, or TTL - that ought to be something opaque that UDP hands down underneath. We shouldn't need to update the UDP API whenever IP or other layers change. Joe From nobody Mon Apr 4 15:31:41 2016 Return-Path: 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 6BFB912D85F for ; Mon, 4 Apr 2016 15:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 58_42WbFj3Xu for ; Mon, 4 Apr 2016 15:31:29 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6A912D646 for ; Mon, 4 Apr 2016 15:31:29 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2F0DE1B001A7; Mon, 4 Apr 2016 23:43:34 +0100 (BST) Received: from 190.111.246.165 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 4 Apr 2016 23:31:28 +0100 Message-ID: In-Reply-To: <5702CD91.9070101@isi.edu> References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> <5702AD1F.6080303@isi.edu> <7daecb443d1b93875027c4d945c594df.squirrel@erg.abdn.ac.uk> <5702B2C8.5030005@isi.edu> <78b2e990fa6a83f886c59dd56c178b9e.squirrel@erg.abdn.ac.uk> <5702CD91.9070101@isi.edu> Date: Mon, 4 Apr 2016 23:31:28 +0100 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, Aaron Falk , Michael Welzl , touch@isi.edu, Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:31:40 -0000 > > > On 4/4/2016 12:49 PM, gorry@erg.abdn.ac.uk wrote: > ... >>>> No. It's true that UDP needs to know this, but this info needs to >>>> arrive >>>> at the App, either from a primitive that returns the size or from a >>>> failed >>>> send call when probing for a maximum datagram size. The app also may >>>> need >>>> to control DF if it wants to do path probing of PMTU, whereas in TCP >>>> this >>>> is handed within the transport protocol.. >>> >>> Ahh - I see this now. However, IMO, that ought to be something it gets >>> from the IP layer, not from UDP. UDP has an MSS that's defined by the >>> protocol itself which is not all that useful to indicate to the app. >>> >> I see what you are saying for reading the MTU less headers, but whatever >> the method, the APP needs to work out what to do with this. For setting >> DF >> this is not necessarily an IP setting for all packets, it can be a per >> UDP >> datagram choice. > > Sure, but again that argues for a transparent supplement to the UDP API, > not for a UDP-specific API. > >>>>> For ECN, UDP ought to be ignorant - as should its API. The only >>>>> question >>>>> is whether the UDP API should have a "pass through" for signals from >>>>> lower layers, whether IP, Ethernet, etc. IMO, those aren't part of >>>>> the >>>>> UDP API; they're part of the OS endpoint API to these other >>>>> protocols. >>>>> >>>> I don't understand what you are saying about an "OS endpoint API to >>>> IP". >>>> To me the API has to signal per-datagram on send whether ECT(0) or >>>> ECT(1) >>>> or neither is to be set, the receive API needs to see the received ECN >>>> field for each datagram. >>>> >>>> Do you see a different way to do this? >>> >>> Here's the issue - when a message arrives, right now we think of it >>> being "from UDP" as part of the UDP API. However, there are no ECN >>> markings in UDP. It makes sense to forward the IP source/dest in the >>> UDP >>> API because that part of the IP header is defined as part of UDP (as >>> the >>> pseudoheader). However, it makes no sense to have that information >>> available as part of what UDP passes to the app per se. >>> >>> So maybe each UDP message is allowed to forward a single opaque (to >>> UDP) >>> structure that contains information from any of its underlying layers >>> (i.e., a pass-through signal mechanism). But I would consider that not >>> really integral to the API of UDP. >>> >>> I do agree this needs to be per message, not per endpoint. >>> >> That sounds a lot like you are thinking about a concrete API. > > Way more abstract. The issue is that these features are not inherent in > UDP - they are inherent in the IP over which UDP runs (and depend on > that IP version). > >> And I agree, >> to implement this, you can do exactly that and provide additional data >> per >> datagram buffer to communicate the DSCP, ECN, TTL ... > > My point is that - at the abstract level - UDP should not have an API > that talks about DSCP, ECN, or TTL - that ought to be something opaque > that UDP hands down underneath. > And does this particular list of things vary between IPv4 or IPv6? - I suggest not really, apart from different naming of the TTL to HOP_COUNT? > We shouldn't need to update the UDP API whenever IP or other layers > change. > That's a good goal. > Joe > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > Gorry From nobody Mon Apr 4 15:42:10 2016 Return-Path: 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 48DF012D8A6 for ; Mon, 4 Apr 2016 15:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7t_dxnTNjdko for ; Mon, 4 Apr 2016 15:42:08 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024A412D8B9 for ; Mon, 4 Apr 2016 15:42:07 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u34MfLBT006583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2016 15:41:22 -0700 (PDT) To: gorry@erg.abdn.ac.uk References: <5EEA6A8D-7EFA-4946-AB1A-EF876BC97332@ifi.uio.no> <5702A813.90908@isi.edu> <7235c7e80b8eaf8823e244fb762a5801.squirrel@erg.abdn.ac.uk> <5702AD1F.6080303@isi.edu> <7daecb443d1b93875027c4d945c594df.squirrel@erg.abdn.ac.uk> <5702B2C8.5030005@isi.edu> <78b2e990fa6a83f886c59dd56c178b9e.squirrel@erg.abdn.ac.uk> <5702CD91.9070101@isi.edu> From: Joe Touch Message-ID: <5702ED91.3050000@isi.edu> Date: Mon, 4 Apr 2016 15:41:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u34MfLBT006583 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Spencer Dawkins , Michael Welzl , touch@isi.edu Subject: Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:42:09 -0000 On 4/4/2016 3:31 PM, gorry@erg.abdn.ac.uk wrote: >> My point is that - at the abstract level - UDP should not have an API >> > that talks about DSCP, ECN, or TTL - that ought to be something opaque >> > that UDP hands down underneath. >> > > And does this particular list of things vary between IPv4 or IPv6? - I > suggest not really, apart from different naming of the TTL to HOP_COUNT? IPv6 has a flow label. They support different options, including: IPv6 doesn't add an ID field unless fragmentation occurs. IPv6 allows jumbograms. Regardless, these are IP issues, though - they should be transparent at the UDP API (though the UDP API could support passing this info opaquely along in either direction). Joe From nobody Wed Apr 6 08:23:28 2016 Return-Path: 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 63A8F12D660 for ; Wed, 6 Apr 2016 08:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 GPzP4svxPRKV for ; Wed, 6 Apr 2016 08:23:26 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 BFDA112D11F for ; Wed, 6 Apr 2016 08:19:55 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by comcast with SMTP id npF5abxHwVEtunpFLaj0Rv; Wed, 06 Apr 2016 15:19:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459955995; bh=mDBvAFUSWFEJr9uPnZ1mNDrXE4/tTU3YLdmsIENMgtM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=JS4uSZZ1eZNw/IHmGx7GWPxlQp4RejxZ5HHDlxCv854f+RpCIOKGXHE0WiFB35FuO 33xHHdWPYIgmqau1atMwkfKp+p9kZaVaK870Hdop3AxWtedxtUJDZ/OMgZC0XAi2d4 mHPZkbS/ZigJsttVBIhvYlgpmuQX1p8pE0+MqSqIzXUEyypfL8V4ypglCOd/p+l69/ 6vWyzerqvmmB1KVDcsMeyUAxIWVMiRRCDUK112Ry/jXQO/X75HW4HtH0L2nXJomlpN IJleJpzxc7rS9u2eQaEcg3RlobbWB4k2Q1evo69uYweKPltmPtHJVlCuIVR0JMQXWD ygrPA7c0EH9PQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-16v.sys.comcast.net with comcast id f3Ku1s0071nMCLR013KuSX; Wed, 06 Apr 2016 15:19:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u36FJrCT013663 for ; Wed, 6 Apr 2016 11:19:53 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u36FJrnF013656; Wed, 6 Apr 2016 11:19:53 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: taps@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Apr 2016 11:19:53 -0400 Message-ID: <877fgawyqu.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:23:27 -0000 I'm reading parts of draft-fairhurst-taps-transports-usage-udp-01 because it was presented in the Dispatch session of the meeting, so I don't have all the context for this draft. But a couple of comments struck me: The description seems to be connection-oriented, in that it only describes usages involving two endpoints establishing a connection and then using it. Indeed, even the process of establishing a listening port based on which connections will be created is not described. E.g., the description of the CONNECT primitive says "The CONNECT primitive allows the association of source and port sets to a socket ...", but doesn't describe where the socket comes from, or that packets can arrive on a socket before the receiver has done a CONNECT. Perhaps these concepts are discussed in the document that establishes the framework for this draft. At the least, the use of listening ports needs to be formalized. In section 3.1 is: SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS function sets the hop limit field to be used in the field of an IPv4 header of a packet that carries an UDP datagram. For IPv6 unicast datagrams, this is functionally equivalent to the SET_TTL IPv4 function. GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS function reads the value from the hop count field in the IPv6 header of a received UDP datagram. For IPv6 unicast datagrams, this is functionally equivalent to GET_TTL IPv4 function. I might be wrong, but it looks like "IPv4" and "IPv6" are mistaken for each other in three places in these items. How does the application get notified that a packet has arrived? The only event that is defined is ERROR_REPORT. The RECEIVE primitive is called by the application, but application has to first know that there is a packet to receive. Dale From nobody Wed Apr 6 09:39:11 2016 Return-Path: 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 2474812D531 for ; Wed, 6 Apr 2016 09:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Q0ya850WaL1b for ; Wed, 6 Apr 2016 09:39:07 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id DC95312D162 for ; Wed, 6 Apr 2016 09:39:06 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 95DB51B001C8; Wed, 6 Apr 2016 17:51:16 +0100 (BST) Received: from 31.133.155.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 6 Apr 2016 17:39:05 +0100 Message-ID: <1289953456f002c1c71e90d9998a67de.squirrel@erg.abdn.ac.uk> In-Reply-To: <877fgawyqu.fsf@hobgoblin.ariadne.com> References: <877fgawyqu.fsf@hobgoblin.ariadne.com> Date: Wed, 6 Apr 2016 17:39:05 +0100 From: gorry@erg.abdn.ac.uk To: "Dale R. Worley" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: taps@ietf.org Subject: Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:39:10 -0000 Thanks - appreciated. > I'm reading parts of draft-fairhurst-taps-transports-usage-udp-01 > because it was presented in the Dispatch session of the meeting, so I > don't have all the context for this draft. But a couple of comments > struck me: > > The description seems to be connection-oriented, in that it only > describes usages involving two endpoints establishing a connection and > then using it. Indeed, even the process of establishing a listening > port based on which connections will be created is not described. E.g., > the description of the CONNECT primitive says "The CONNECT primitive > allows the association of source and port sets to a socket ...", but > doesn't describe where the socket comes from, or that packets can arrive > on a socket before the receiver has done a CONNECT. > I agree - the current format from the text comes from the existing text for TCP and SCTP in another draft. and I think we may need to work out how to handle > Perhaps these concepts are discussed in the document that establishes > the framework for this draft. At the least, the use of listening ports > needs to be formalized. > I probably need help - I think there are different many ways in which UDP uses ports. Offers from anyone on how to get started would be great. > In section 3.1 is: > > SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS function sets the > hop limit field to be used in the field of an IPv4 header of a > packet that carries an UDP datagram. For IPv6 unicast datagrams, > this is functionally equivalent to the SET_TTL IPv4 function. > > GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS function reads the > value from the hop count field in the IPv6 header of a received > UDP datagram. For IPv6 unicast datagrams, this is functionally > equivalent to GET_TTL IPv4 function. > > I might be wrong, but it looks like "IPv4" and "IPv6" are mistaken for > each other in three places in these items. > Indeed. We will fix this. > How does the application get notified that a packet has arrived? The > only event that is defined is ERROR_REPORT. The RECEIVE primitive is > called by the application, but application has to first know that there > is a packet to receive. > One contribution in the parallel TAPS meeting suggested the WG could use a call-back API - that may be worth exploring. > Dale > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > Thanks Dale, Gorry From nobody Wed Apr 6 10:54:24 2016 Return-Path: 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 E07CE12D18B for ; Wed, 6 Apr 2016 10:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 vojVRvVBSDle for ; Wed, 6 Apr 2016 10:54:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD6012D1BF for ; Wed, 6 Apr 2016 10:54:18 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u36Hrist025673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2016 10:53:44 -0700 (PDT) To: gorry@erg.abdn.ac.uk, "Dale R. Worley" References: <877fgawyqu.fsf@hobgoblin.ariadne.com> <1289953456f002c1c71e90d9998a67de.squirrel@erg.abdn.ac.uk> From: Joe Touch Message-ID: <57054D27.8050505@isi.edu> Date: Wed, 6 Apr 2016 10:53:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1289953456f002c1c71e90d9998a67de.squirrel@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: taps@ietf.org, touch@isi.edu Subject: Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:54:23 -0000 On 4/6/2016 9:39 AM, gorry@erg.abdn.ac.uk wrote: ... >> I'm reading parts of draft-fairhurst-taps-transports-usage-udp-01 >> because it was presented in the Dispatch session of the meeting, so I >> don't have all the context for this draft. But a couple of comments >> struck me: >> >> The description seems to be connection-oriented, in that it only >> describes usages involving two endpoints establishing a connection and >> then using it. Indeed, even the process of establishing a listening >> port based on which connections will be created is not described. E.g., >> the description of the CONNECT primitive says "The CONNECT primitive >> allows the association of source and port sets to a socket ...", but >> doesn't describe where the socket comes from, or that packets can arrive >> on a socket before the receiver has done a CONNECT. For connection-oriented protocols, this should never happen. For connectionless protocols, "CONNECT" is often the basic primitive by which a user indicates the socket pair (address/port) of the remote end. It would be useful to separate these two concepts: - pinning parameters of the remote socket pair - establishing pairwise state ... >> Perhaps these concepts are discussed in the document that establishes >> the framework for this draft. At the least, the use of listening ports >> needs to be formalized. >> > I probably need help - I think there are different many ways in which UDP > uses ports. Offers from anyone on how to get started would be great. See below. I'm glad to help with this further if useful - some additional notes below: Joe Pass1: First, it would be useful to introduce the idea of a communication endpoint as seen from inside a program (or the OS). Unix uses the term "socket" for this (which is awful because we use the term "socket pair" to mean something different). I'd suggest using the term "CHANNEL" at least for now. So the primitives needed, *assuming an OS primitive to create a new, blank CHANNEL*, are: SET_LOCAL_SOCKETPAIR CHANNEL IP? PORTNUM? nail down specific local IP address and/or port numbers as associated with a CHANNEL object corresponds to bind() in Unix... SET_REMOTE_SOCKETPAIR CHANNEL IP? PORTNUM? nail down specific remote IP address and/or port numbers as associated with a CHANNEL object corresponds to connect() in Unix (yes, for UDP, even though it is connectionless) SEND CHANNEL MESSAGE (IP PORTNUM)? PARAMS? emit a UDP message with the indicated contents over the indicated channel if the CHANNEL does not have a set remote socket pair, then also requires the remote socketpair RECEIVE CHANNEL PARAMS? obtain a UDP message from the indicated CHANNEL returns the message and its remote socketpair Send and receive may have per-message parameters that are optional, as indicated above. Note that I've deliberately avoided a few terms and reused others. I can't find better words for send/receive than those, but I would never think of "listen" as something that necessarily returns a message (it might return an indicator that a message is available, in the manner of the select() call) I don't think it makes sense to talk about CLOSE in any way for UDP connections. At best, we would talk about discarding the CHANNEL object. And yes, I don't think you can talk about any of this without a model for the process/OS side of the communication entity. Joe From nobody Thu Apr 7 11:42:14 2016 Return-Path: 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 EED3512D564 for ; Thu, 7 Apr 2016 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 5sy95MEE0SP4 for ; Thu, 7 Apr 2016 11:42:10 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 0C27F12D195 for ; Thu, 7 Apr 2016 11:42:09 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by comcast with SMTP id oEsQae47hVEtuoEsbandOc; Thu, 07 Apr 2016 18:42:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460054529; bh=z25WBoZs0aoRHDF5YWwbCSdeiDe0OCDGrys3Qbu5a2E=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ovlrVNNOSg+qTn65ZZEqSmlS31Gj/km2zeRvYrmoyQF6MuDnXLwtgt32ry8Oc1AQg T/eH782EYdJioK4ekZ4XXIyPwfT0lXO44oK9hRVXgl0vYdCreEDtlEQyEXpZK8NlH0 rgo0u9NaGHpyQ6LxECNQYNVWhEk+/Jbg0YaA8E83mi7MP4FcoSkwyWKzr9IFHXjrTV RdCGFOzm4zn03sTGJVluhtornrTN7KkWhXY4TtsD7WlEXy4l1a698rUbZAHlJ9mvRa TbA+BJJWabGa9/D6+sozaph0iUMbUV4YgBU5wOL3eDpJOq6MkZUof6tzDTZpqJlZI7 SWM1KnYpI1vHw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id fWi81s00C1nMCLR01Wi8Ut; Thu, 07 Apr 2016 18:42:09 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u37Ig708022904; Thu, 7 Apr 2016 14:42:07 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u37Ig6pI022900; Thu, 7 Apr 2016 14:42:06 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: gorry@erg.abdn.ac.uk In-Reply-To: <1289953456f002c1c71e90d9998a67de.squirrel@erg.abdn.ac.uk> (gorry@erg.abdn.ac.uk) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 07 Apr 2016 14:42:06 -0400 Message-ID: <87egahtg5d.fsf@hobgoblin.ariadne.com> Archived-At: Cc: taps@ietf.org Subject: Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:42:12 -0000 gorry@erg.abdn.ac.uk writes: > I agree - the current format from the text comes from the existing text > for TCP and SCTP in another draft. and I think we may need to work out > how to handle > [...] > I probably need help - I think there are different many ways in which UDP > uses ports. Offers from anyone on how to get started would be great. Even in TCP, the semantics of connection setup is more complicated that you'd think at first. If I have it correctly, it runs: Passive Active Endpoint Endpoint Create socket Bind socket to listening address Activate listening Create socket Connect Incoming connection event Accept connection At least in the protocol, it's possible for both endpoints to be active, but they have to have prior agreement regarding the addresses and ports and send their initial packets within one RTT of each other, so I don't know if that possibility is ever used in practice. Or whether the Berkeley sockets API supports it. OTOH, the TAPS work might not be attempting to capture the semantics of connection setup. The process for UDP is not much simpler. My memory is: Passive Active Endpoint Endpoint Create socket Bind socket to listening address Create socket Send-to -or- Connect, then Send Incoming connection event Connect (in the TAPS paradigm) Incoming packet event Receive packet Dale From nobody Thu Apr 7 11:44:59 2016 Return-Path: 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 E89EF12D533 for ; Thu, 7 Apr 2016 11:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 j3qqgNqPnFS6 for ; Thu, 7 Apr 2016 11:44:55 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 7128C12D508 for ; Thu, 7 Apr 2016 11:44:55 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by comcast with SMTP id oEtwaEc498DPnoEvGa2TCS; Thu, 07 Apr 2016 18:44:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460054694; bh=LD5N98DE8fXNxXpoGDED39epEJhFQYOV5mKak5SwBJM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=dyksuQGBaABcitHgCYXpCGWFOIVaG/nRI5tkkVOk0TDryQCics08ZjUphXHqy2wOU i0giprd6xsad0DEke3IvV86lGxLhp3VG9MpMtyVraH+DYjg6ddFG+apWka+XN7GiNt tyf8mNjsfWp0SXAWvcWWEbsY1/QJ0a498G2lqyu+idKSduvHmP1cHUV1T9l5QkTXtX +M/HA7aUencz3Pq33XDJF6usywGKnAThRQhPlIVxoEz3Ccnlu9fNfXabXlMadRKCSV G7qw+vQresQ1PbCb9fHTmGcA+kCgZFwezMO/s9IPECSmE0ckJTN2kKcw/aDS5B0F7r 8+/bpt8u5/+SQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-03v.sys.comcast.net with comcast id fWkt1s00D1nMCLR01WktCo; Thu, 07 Apr 2016 18:44:54 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u37IiqvQ023174; Thu, 7 Apr 2016 14:44:53 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u37Iiqde023170; Thu, 7 Apr 2016 14:44:52 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Joe Touch In-Reply-To: <57054D27.8050505@isi.edu> (touch@isi.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 07 Apr 2016 14:44:51 -0400 Message-ID: <87bn5ltg0s.fsf@hobgoblin.ariadne.com> Archived-At: Cc: gorry@erg.abdn.ac.uk, taps@ietf.org, touch@isi.edu Subject: Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:44:57 -0000 Joe Touch writes: > For connectionless protocols, "CONNECT" is often the basic primitive by > which a user indicates the socket pair (address/port) of the remote end. The trouble I see is that the concept of "listening" is not covered. The passive or listening endpoint doesn't initiate a "connect" operation to indicate the address/port of the remote end, that is indicated by the arrival of a packet from the remote end. As I read the draft, it seems to assume that both ends can do a "connect" before they exchange any packets at all. Dale From nobody Thu Apr 7 12:13:35 2016 Return-Path: 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 B7D1412D547 for ; Thu, 7 Apr 2016 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 DemHNi3WW23L for ; Thu, 7 Apr 2016 12:13:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC87412D1F0 for ; Thu, 7 Apr 2016 12:13:28 -0700 (PDT) Received: from [207.151.56.219] (guest-wireless-207-151-056-219.usc.edu [207.151.56.219]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u37JC1Ys026882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2016 12:12:12 -0700 (PDT) To: "Dale R. Worley" References: <87bn5ltg0s.fsf@hobgoblin.ariadne.com> From: Joe Touch Message-ID: <5706B0FF.5090501@isi.edu> Date: Thu, 7 Apr 2016 12:11:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <87bn5ltg0s.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: gorry@erg.abdn.ac.uk, taps@ietf.org, touch@isi.edu Subject: Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:13:34 -0000 On 4/7/2016 11:44 AM, Dale R. Worley wrote: > Joe Touch writes: >> For connectionless protocols, "CONNECT" is often the basic primitive by >> which a user indicates the socket pair (address/port) of the remote end. > > The trouble I see is that the concept of "listening" is not covered. It depends on what you mean by "listen". If you mean "wait for a message", that's a "read" If you mean "coordinate state with the other end", that is not part of UDP semantics. > The passive or listening endpoint doesn't initiate a "connect" operation > to indicate the address/port of the remote end, that is indicated by the > arrival of a packet from the remote end. As I read the draft, it seems > to assume that both ends can do a "connect" before they exchange any > packets at all. IMO that's a failure of the current text to match UDP semantics. Joe From nobody Thu Apr 7 12:24:03 2016 Return-Path: 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 1DFD912D5BF for ; Thu, 7 Apr 2016 12:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 eNsvGpP5iMYe for ; Thu, 7 Apr 2016 12:23:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E9B12D54F for ; Thu, 7 Apr 2016 12:23:58 -0700 (PDT) Received: from [207.151.56.219] (guest-wireless-207-151-056-219.usc.edu [207.151.56.219]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u37JNHZr000469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2016 12:23:27 -0700 (PDT) To: "Dale R. Worley" , gorry@erg.abdn.ac.uk References: <87egahtg5d.fsf@hobgoblin.ariadne.com> From: Joe Touch Message-ID: <5706B3A3.3090309@isi.edu> Date: Thu, 7 Apr 2016 12:23:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <87egahtg5d.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: taps@ietf.org, touch@isi.edu Subject: Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:24:02 -0000 On 4/7/2016 11:42 AM, Dale R. Worley wrote: > gorry@erg.abdn.ac.uk writes: >> I agree - the current format from the text comes from the existing text >> for TCP and SCTP in another draft. and I think we may need to work out >> how to handle >> [...] >> I probably need help - I think there are different many ways in which UDP >> uses ports. Offers from anyone on how to get started would be great. > > Even in TCP, the semantics of connection setup is more complicated that > you'd think at first. If I have it correctly, it runs: > > Passive Active > Endpoint Endpoint > > Create socket > Bind socket to listening address There's a step here where you get to set the limit on how many pending connection requests can be allowed (the listen() call), but that's an OS-ism IMO, not a protocol or API issue. > Activate listening > > Create socket optionally bind to local address > Connect > > Incoming connection event > Accept connection an optional parameter to this accept call involves whether the remote socket pair is specified or not. > At least in the protocol, it's possible for both endpoints to be active, > but they have to have prior agreement regarding the addresses and ports almost - they only need to agree on the port one one side exactly; in both cases, the addresses need to reach each other but could be one of any number of addresses on the machine. E.g.: A calls B.alpha using dest port 80 while B calls A.omega using source port 80 > and send their initial packets within one RTT of each other, so I don't > know if that possibility is ever used in practice. It happens routinely if you end up calling yourself. > Or whether the > Berkeley sockets API supports it. It should, as per above. > OTOH, the TAPS work might not be attempting to capture the semantics of > connection setup. It had better, IMO. > The process for UDP is not much simpler. My memory is: > > Passive Active > Endpoint Endpoint > > Create socket > Bind socket to listening address you only need to bind to a port; the address can float you can optionally also lock the remote address using the "connect" call, even though it doesn't issue a connection. > Create socket > Send-to -or- Connect, then Send or bind too. Same reasons - you can pin the local or remote socket pair. > Incoming connection event > Connect (in the TAPS paradigm) IMO, this should be removed. There can't be state associated with UDP. > Incoming packet event > Receive packet The receive packet for UDP passes more information than for TCP; in UDP, you need to indicate where the message came from too. From nobody Mon Apr 11 23:56:25 2016 Return-Path: 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 8FD4612E5DD for ; Mon, 11 Apr 2016 23:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 IfNy3eyE_K16 for ; Mon, 11 Apr 2016 23:56:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49E312E5DB for ; Mon, 11 Apr 2016 23:56:21 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-ab-570c9c13e6ee Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.AC.16963.31C9C075; Tue, 12 Apr 2016 08:56:19 +0200 (CEST) Received: from [150.132.141.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.248.2; Tue, 12 Apr 2016 08:56:18 +0200 From: Zaheduzzaman Sarker Organization: Ericsson AB To: , Aaron Falk Message-ID: <570C9C10.9020902@ericsson.com> Date: Tue, 12 Apr 2016 08:56:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM2K7tK7wHJ5wg+cbRSzafk9jtbgT48Dk sXPWXXaPJUt+MgUwRXHZpKTmZJalFunbJXBlfNr+gK3gGHPFopshDYx/mLoYOTkkBEwkurYv Z4awxSQu3FvP1sXIxSEkcIRR4sHB+8wQzhpGiZ/zJzB2MXJwsAnYSDxe7AfSwC8gKbGhYTdY s4iAmcTjL+8YQWxhAVOJiRMngNm8AtoSCya8AVvGIqAq8XP6UXYQW1QgRqJtyyImiBpBiZMz n7CA2MwCFhIz559nhLDlJba/ncMMslZIQFei62XcBEb+WUg6ZiHpmIWkYwEj8ypG0eLU4uLc dCMjvdSizOTi4vw8vbzUkk2MwLA7uOW31Q7Gg88dDzEKcDAq8fAuCOMJF2JNLCuuzD3EKMHB rCTCyzcbKMSbklhZlVqUH19UmpNafIhRmoNFSZw3J/JfmJBAemJJanZqakFqEUyWiYNTqoEx RjaA983D/AXXd/QIGZ/ZEfLm8L/Q+aFBWVv33U5KvdSt/Vqw82jnY6N+L5XFB+7/tDt7oj1b MkH/aJPCJZNpCi+iP2QkfZ336MmFLautNoenfzO6rJFjoK3vPWdvRuspmRfZT7++nPRr9lLV u1W/euqcD047vrjjmFfaf+6b4qxn/6lM+vveWomlOCPRUIu5qDgRAKGFwWM3AgAA Archived-At: Subject: [Taps] Draft version of TAPS WG minutes form IETF95 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 06:56:23 -0000 Hi folks, The note takers did a great job to capture the meeting minutes. Thanks a lot. A draft version of the minutes have been uploaded: https://www.ietf.org/proceedings/95/minutes/minutes-95-taps . Please review the minutes and send comments to the list. -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER zaheduzzaman.sarker@ericsson.com ================================================== From nobody Tue Apr 12 09:06:38 2016 Return-Path: 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 1D40312DA0A for ; Tue, 12 Apr 2016 09:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dzUdNss0dcfJ for ; Tue, 12 Apr 2016 09:06:25 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F34912D9FB for ; Tue, 12 Apr 2016 09:06:25 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id d68so30419870ywe.1 for ; Tue, 12 Apr 2016 09:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=A13Uf9iK0O4dIH3Ah4nS4Bp4glDNC1h09NELhWw0XnE=; b=TK9ojLSzHL2o8OISzme6e5OY+ro2i4Z5pR+W28FAlnxdoWFnHrEd2U5Cg59iY7l6rU h4jSkBn+NOKstGw3ZtOXQOmtmOIQAEceCX4tgQwQYJ4YEvt/xLvE5UcjFolaAuiJdRM7 3QlxRkw0IyavU1tckEw04dpKvZcjeditDCa7ic6PE3sFg7d7Tio5RFRMEaaV8zHrkICW mhgNcztAgrD2OzqvCHHE2HC7EFSJ6ilR6LukmynZgKMmYw4fujwtASQ6z29eNed+1YqI 2OjNq8PO1MjoxyuXHKf3Wz9Gjp1VutS383cErUTIgOZp6yQXeXLm7Vn1xGffulR9k7oR GG7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=A13Uf9iK0O4dIH3Ah4nS4Bp4glDNC1h09NELhWw0XnE=; b=Km5+TJNf1rHIE2Gi0S35+LgJS/YGMpAmTYEEC/D61pD3b5O1+pzHPddxa7ObP+KYVJ +1Q7FRVR+VmMHyDUHRYfQYLDY6ky+J1vQALOa9oQEAxmnkoW0cfrEg2okBv2jptmLE+K XFav4jU5ECtKUlwwPuP3SvLiaPUeGIdcF8z5BTGrZlxJOFhQulLbO0VJdWbxft5qRoKl pGd9uyMpwwpgcUBXYNBbbikZpFP20Un0rZtiqH4ZZ7Z/zI5/6+t0MhOgLREnK06QBYIJ LkiSsSgW4Itwiv5cOVUfBcExOJAKHblKFs1yx+BM49Q+OvcerseDOdog/XXIVqybud0t AmGg== X-Gm-Message-State: AOPr4FUPzHRI7Nx7Xypxtknt0YKZNCnTAuaYs+p9jg7JoBfDrT7HwMAO5LsvlInvfZIQlJ6prtZGQwzjxiA46Q== X-Received: by 10.13.215.80 with SMTP id z77mr2326767ywd.278.1460477184355; Tue, 12 Apr 2016 09:06:24 -0700 (PDT) MIME-Version: 1.0 References: <570C9C10.9020902@ericsson.com> In-Reply-To: <570C9C10.9020902@ericsson.com> From: Aaron Falk Date: Tue, 12 Apr 2016 16:06:15 +0000 Message-ID: To: Zaheduzzaman Sarker , taps@ietf.org Content-Type: multipart/alternative; boundary=94eb2c075e9cc6b21b05304bd747 Archived-At: Subject: Re: [Taps] Draft version of TAPS WG minutes form IETF95 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:06:37 -0000 --94eb2c075e9cc6b21b05304bd747 Content-Type: text/plain; charset=UTF-8 Thanks, Zahed. For those of you not at the TAPS meeting in Buenos Aires, Zahed is our new co-chair and is already making an impact by helping with the minutes. W00t! --aaron On Tue, Apr 12, 2016 at 2:56 AM Zaheduzzaman Sarker < zaheduzzaman.sarker@ericsson.com> wrote: > Hi folks, > > The note takers did a great job to capture the meeting minutes. Thanks a > lot. > > A draft version of the minutes have been uploaded: > > https://www.ietf.org/proceedings/95/minutes/minutes-95-taps . > > Please review the minutes and send comments to the list. > > -- > Zahed > > ================================================== > ANM ZAHEDUZZAMAN SARKER > > zaheduzzaman.sarker@ericsson.com > ================================================== > --94eb2c075e9cc6b21b05304bd747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Thanks, Zahed.=C2=A0 For those of you not at the TAPS meet= ing in Buenos Aires, Zahed is our new co-chair and is already making an imp= act by helping with the minutes.=C2=A0 W00t!

    --aaron

    On Tue, Apr 12, 201= 6 at 2:56 AM Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
    Hi folks,

    The note takers did a great job to capture the meeting minutes. Thanks a lot.

    A draft version of the minutes have been uploaded:

    https://www.ietf.org/proceedings/95/minut= es/minutes-95-taps .

    Please review the minutes and send comments to the list.

    --
    Zahed

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    ANM ZAHEDUZZAMAN SARKER

    zahed= uzzaman.sarker@ericsson.com
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
    --94eb2c075e9cc6b21b05304bd747-- From nobody Wed Apr 27 01:16:06 2016 Return-Path: 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 B88CA12B05D for ; Wed, 27 Apr 2016 01:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 9dcUeqmSrUpI for ; Wed, 27 Apr 2016 01:16:04 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 A593312B03C for ; Wed, 27 Apr 2016 01:16:03 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1avKdd-0000jQ-9Z for taps@ietf.org; Wed, 27 Apr 2016 10:16:01 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1avKdc-0002u0-O9 for taps@ietf.org; Wed, 27 Apr 2016 10:16:01 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> Date: Wed, 27 Apr 2016 10:16:00 +0200 To: taps WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 41027 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.536, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 52A10BCF6B86055EDF8354CFC0B180A901460F28 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9840 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] About old APIs from RFCs, and TAPS' real goal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 08:16:05 -0000 Hi all, This is mainly about criticism from Toerless. I thought of sending him a = private email (after I wanted to have a chat with him in Buenos Aires = but ran out of time), but thinking some more, I decided that this is = probably a matter of general interest: it's about the bigger picture of = TAPS. Toerless has repeatedly criticized the use of RFCs as a basis for = developing the API in TAPS, when we have newer, better APIs available. ***side note*** Before continuing, let me pause and diverge a bit: much of Toerless' = criticism was related to the UDP API, and, as far as I understand, = multicast in particular (which isn't the focus of TAPS). Some of his = concrete points may be absolutely right and, not knowing enough, I = definitely don't take issue with them. Speaking for my own documents = (drafts I'm co-authoring), I also do not want to be *religious* about = using only the RFCs as a basis when it simply doesn't make sense - = however I would like to use them as much as possible and consider = diverging from my rules an exception, meaning that text should be marked = or even put in an appendix. The reason for being so attached to the RFCs = is that OSes have different concrete APIs, for good reason, and I think = we want to maintain the freedom developers have in implementing their = APIs as they wish. ***main point of this email*** Thinking about Toerless' general point of using more modern APIs made me = think of the bigger picture again. For example, one cool recent feature = in TCP APIs is the SO_SNDLOWAT socket option, which allows better = control of the sender buffer. Not including it in an API document = "sucks" and it IS nice to include it in a description of an API. It is, however, also pretty irrelevant to the point of TAPS. Anyone is = free to implement the SO_SNDLOWAT socket option today, we don't need = TAPS for that. Neither do we need to change TCP for that. It's not even = necessary to describe it for TCP to be able to use it (won't hurt but = also won't gain us much). I started the TAPS effort to ENABLE AUTOMATION. This actually means *hiding* as much as possible. Today's stacks are = highly optimized and a lot of automation happens - but some things are = IMPOSSIBLE to automatize unless they are exposed in an API and an = application uses them. SCTP contains some obvious examples: unordered = delivery of messages and partial reliability. Try doing this to an = application that expects a reliable byte stream. So, no system even = tries to automatically use SCTP underneath the socket layer because many = of its benefits could never be utilized. This is why we need to do something. This is why TAPS exists - to = specify that an API really should contain these transport service = features (as we call them), so that more (richer) automation becomes = possible. That's the whole point here. These are the transport service = features that, in draft-gjessing-taps-minset, we call "functional". At the last meeting, we authors of draft-gjessing-taps-minset got the = feedback that we shouldn't put so much effort into trying to minimize = the number of exposed services. I agree with this feedback, but here = nevertheless I explain WHY we tried to minimize the number of services = and why the charter says "the subset of those Transport Services, as = identified in item 1, that end systems supporting TAPS will provide" - = because, to me (and in line with the charter, I claim), the REAL goal of = TAPS is to identify all these functional transport service features and = explain how a TAPS system providing them could be implemented. I agree = it makes sense to document more but I want to stress that that's not the = main point. In other words, I think if we'd end up with a list of ONLY = the functional transport service features of all the protocols we = consider, and then explain how they can be provided, then TAPS has = reached its goal: it would enable benefiting from other-than-TCP-or-UDP = protocols. It's my impression that discussions in TAPS are perhaps too much fueled = by thinking about what modern APIs can do (as opposed to the old RFCs). = I think there's no harm in that and it can be useful, but the REAL value = comes from something else and we shouldn't lose focus on what really = matters here. In other words, I believe that Toerless' criticism may be = about things that aren't really very relevant to the goal of TAPS = (because implementing them is not related to increasing the ability to = automatize usage of mechanisms provided by protocols other than TCP and = UDP - just like SO_SNDLOWAT can be implemented today, using TCP, and = doesn't change anything about the intended automation). Note that I say = may, because perhaps I AM missing the point as I didn't understand = enough about the UDP API things he talked about, I do apologize if this = is all just me misunderstanding him! Thoughts? (I am a little worried that nothing that I wrote is new to people, = everyone agrees with me, and this is just me not getting Toerless' = points :( ) Cheers, Michael From nobody Wed Apr 27 14:26:33 2016 Return-Path: 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 6E45412DC3A for ; Wed, 27 Apr 2016 14:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 NbPUdnbjzL0N for ; Wed, 27 Apr 2016 14:26:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7AE12B04B for ; Wed, 27 Apr 2016 14:26:28 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u3RLPo5C025575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Apr 2016 14:25:50 -0700 (PDT) To: Michael Welzl , taps WG References: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> From: Joe Touch Message-ID: <57212E5E.1010201@isi.edu> Date: Wed, 27 Apr 2016 14:25:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [Taps] About old APIs from RFCs, and TAPS' real goal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 21:26:32 -0000 On 4/27/2016 1:16 AM, Michael Welzl wrote: > Thinking about Toerless' general point of using more modern APIs made > me think of the bigger picture again. For example, one cool recent > feature in TCP APIs is the SO_SNDLOWAT socket option, which allows > better control of the sender buffer. Not including it in an API > document "sucks" and it IS nice to include it in a description of an > API. This is an interesting example. It affects how a user-level process interacts with the protocol implementation inside the OS but has NOTHING to do with TCP. I'm not sure where I would put that. It clearly isn't part of the TCP API. Nor, e.g., would be the "nice" level of the process that's feeding data to TCP -- yet both could affect performance between two applications. It seems like there's a gap here you could drive a truck through that needs to be addressed. I'm not sure where, though - i.e., whether this is part of TAPS or not. Joe