From nobody Wed Mar 4 12:54:12 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD381ACEDF for ; Wed, 4 Mar 2015 12:54:10 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBrJJd-2amZW for ; Wed, 4 Mar 2015 12:54:07 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B4B1ACED5 for ; Wed, 4 Mar 2015 12:54:07 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-d1-54f770ed18e5 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 3E.46.21729.DE077F45; Wed, 4 Mar 2015 15:54:05 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t24Ks45u023470; Wed, 4 Mar 2015 15:54:05 -0500 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (w92exedge5.exchange.mit.edu [18.7.73.22]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t24Ks3uV012381; Wed, 4 Mar 2015 15:54:03 -0500 Received: from W92EXHUB12.exchange.mit.edu (18.7.73.21) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Mar 2015 15:52:00 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.190]) by W92EXHUB12.exchange.mit.edu ([18.7.73.21]) with mapi id 14.03.0158.001; Wed, 4 Mar 2015 15:52:56 -0500 From: Marie-Jose Montpetit To: taps WG Thread-Topic: Review of draft-ietf-taps-transports-03 Thread-Index: AQHQVr0w/GyJUE0rZEmuXo1LGXF1QA== Date: Wed, 4 Mar 2015 20:52:56 +0000 Message-ID: <8544089C-8349-405B-9661-D0685468AC7E@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.118.234.192] Content-Type: multipart/signed; boundary="Apple-Mail=_EF5BE75D-5A41-4156-836B-1DA96C187293"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WTfUgTYRzHe26327k8u6a5p9kLHkWvm0YJoxcpiBoUUSBYUenpTjfci9zN mv5RWhm9rJeVWM1eVRZaUEkvJqI2Wpgzm1GhzolaUcwMopilvd15akL/fe6+39/nnh88h0sU DZgKN1psDGuhTRQmRxWy5AXqwdyhlMTC0tXaIyOlUu3AkTKgDYdbMG33Lq2j+jS6VqpzfP2I 6B65gjJdZeUPRHf2owfVnWsrQrdKd8pX6xmTcS/DJiSnyw2l5weluZ2pdk/lL7QQfN50HETg kFwBm3/fw0SOhf6e2zzLcQVZgUDvqWogPjQC+HywWCq0FKQXwICPFoMHANZ4r4wF1QB+cGoE xsil8H1xuUTgGDIOfrrkkwgDEmFgpLcBEYJoMhEe/t6GiaUkOHLBgR4HOM8a6A6pBETJebDz 7aiSIFfCcNPJUSXgTzrUcmvUIiGVsOvdVUTcIAb2tfsmtvld1zfGFHR2v8TEI5QA6PjWjInS 6fDZxXfoGRDrmuRyTe65JvXEUga8fLAEE3kJdF8fkIi8CDaeuIH+/34hPBZ2SkVOggPeL0Dk VfDC8OMxTzwsOdEnuwamVoPZenOB2kwbTRyTqeYyaYuFYdVajdlo0zD6vBowejXWz68FZzyU B5A4oCKJpt3hFIWU3svlmz1gJo5QM4iE1KEURVSGVZ9voDlDGptnYjgPmMd/q//OTT9QoRar haFiiOT1fI/Q0/kFDGsdr8XhKKUkar5HpSjIbNrG5DBMLsOOp7NwnIJEBH81FdNZJpuxZxlN tn8xgkd4AMQjeXmdVZBzubSZM2aLeQuIVymJJ0JACoEhzzIxO37tQ0DJrxVNmIRWJP9TTEyH eDHCi7vivwliG/0vUhWCqqJW9/v+fe2SLA0HV14Jkj5r0Jkz50CC3tXdWh51f+oU94tQsd3T 07x9XXt6y59DgbIqS+oXZd+GjYEdm2Xsnl61c42r4mdRcM6+8m37A6/qNz98Cgq2ZD7u0OlX HZ1WUz/sKnnTEXE3Iylu7oe0A/7P/cMI/avB7n/dWChfXkuhnIFetljCcvRfyl8TrdEDAAA= Archived-At: Cc: Gorry Fairhurst , Aaron Falk , Vincent Roca , jonathan detchart Subject: [Taps] Review of draft-ietf-taps-transports-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:54:10 -0000 --Apple-Mail=_EF5BE75D-5A41-4156-836B-1DA96C187293 Content-Type: multipart/alternative; boundary="Apple-Mail=_8BCCA183-A80A-4537-B5C5-1B79CEE6DD45" --Apple-Mail=_8BCCA183-A80A-4537-B5C5-1B79CEE6DD45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I completed another review of the draft-ietf-taps-transports-03 in the = context of a "gap analysis=E2=80=9D when thinking of = multisource/multidestination (MS/MD) video sessions. What I mean by = MS/MD is: a) multisource: for example real-time and progressive downloads combined = with social media and user generated content (aka social television) b) multidestination: co-vieing of content either in real-time or via = progressive downloads (binging on Netflix) The draft is good and is supplying I think a common way of evaluating = the different transport protocols. I want to highlight just a few items = that i think are still missing 1. more details on secure transports and = 2. a good discussion of what reliable transport means (in the sense of = RMT and more). See details below. 1. Secure transports: I think the inclusion of (D)TLS will be good as it will highlight the = needs for secure transports to ensure some privacy. Also discussing = TCP-AO, TCP-INC and IPSEC would make it complete. However in the context = of MS/MD I think we should make sure we look into the delays that these = protocols incur. I guess we can make the assumption that all parties in = the MS/MD will use the same transport so would all experience simlar = encryption delays. I remember that at the beginning of the WG we had = made no such assumption on the use of uniform transports across = sessions. Maybe we need a discussion? List what do you think? 2. Reliable transport: I have a issue with TCP being put as completely reliable; I understand = why it is there but in terms of the MS/MD application TCP is not "fully = reliable" it's actually not reliable especially when it comes to = latency. I think the text could be enhanced by the mention of this. Video stops and sync is lost between the streams (in my world we call = that "buffering events") and the quality of experience of viewing groups = will be greatly impacted. For realtime I suppose we can look into things = like WebRTC which I do not think is being directed at things other than = voice/video conferencing right now but of course could be extended. This = also implies the use of a browser which is not always the case. But for = progressive downloads which is most of the consumed video and for the = content to keeps in sync and relevant (when one stream stops the others = become out of scope) there needs to be more reliability. Of course the = FEC protocols developed for RMT are still valid even if we look at = multiple unicast sessions and the document could refer to that? I also = think that non-block approaches (newer sliding window codes) could be = considered. And of course we should mention how congestion control fits = in all of this :-) Finally Table 4.1 has a number of features that are being addressed by = existing protocols which is fine. Do we want have a paragraph on = features that are needed but could be supplied by either not fully = standardized protocols or protocols developed in the future (see = reliability above)?=20 But in any case great job and looking forward to discuss it in Dallas. Marie-Jos=C3=A9 Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT --Apple-Mail=_8BCCA183-A80A-4537-B5C5-1B79CEE6DD45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I completed = another review of the draft-ietf-taps-transports-03 in the context of a = "gap analysis=E2=80=9D when thinking of =  multisource/multidestination (MS/MD) video sessions. What I mean = by MS/MD is:
a) multisource: for example real-time and = progressive downloads combined with social media and user generated = content (aka social television)
b) multidestination: = co-vieing of content either in real-time or via progressive downloads = (binging on Netflix)

The draft is good and is supplying = I think a common way of evaluating the different transport protocols. I = want to highlight just a few items that i think are still missing 1. =  more details on secure transports and 2. a good discussion of what = reliable transport means (in the sense of RMT and more). See details = below.

1. Secure transports:
I think the inclusion of (D)TLS = will be good as it will highlight the needs for secure transports to = ensure some privacy. Also discussing TCP-AO, TCP-INC and IPSEC would = make it complete. However in the context of MS/MD I think we should make = sure we look into the delays that these protocols incur. I guess we can = make the assumption that all parties in the MS/MD will use the same = transport so would all experience simlar encryption delays. I remember = that at the beginning of the WG we had made no such assumption on the = use of uniform transports across sessions. Maybe we need a discussion? = List what do you think?

2. Reliable transport:
I have a issue with TCP being put as completely reliable; I = understand why it is there but in terms of the MS/MD application TCP is = not "fully reliable" it's actually not reliable especially when it comes = to latency. I think the text could be enhanced by the mention of = this.

Video stops and sync is lost between the = streams (in my world we call that "buffering events") and the quality of = experience of viewing groups will be greatly impacted. For realtime I = suppose we can look into things like WebRTC which I do not think is = being directed at things other than voice/video conferencing right now = but of course could be extended. This also implies the use of a browser = which is not always the case. But for progressive downloads which is = most of the consumed video and for the  content to keeps in sync = and relevant (when one stream stops the others become out of scope) = there needs to be more reliability. Of course the FEC protocols = developed for RMT are still valid even if we look at multiple unicast = sessions and the document could refer to that? I also think that = non-block approaches (newer sliding window codes) could be considered. = And of course we should mention how congestion control fits in all of = this :-)

Finally Table 4.1 has a number of = features that are being addressed by existing protocols which is fine. = Do we want have a paragraph on features that are needed but could be = supplied by either not fully standardized protocols or protocols = developed in the future (see reliability above)? 

But in any case great job and looking forward to = discuss it in Dallas.

Marie-Jos=C3=A9

Marie-Jose Montpetit, Ph.D.
mariejo@mit.edu
@SocialTVMIT

= --Apple-Mail=_8BCCA183-A80A-4537-B5C5-1B79CEE6DD45-- --Apple-Mail=_EF5BE75D-5A41-4156-836B-1DA96C187293 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDRDCCA0Aw ggKpoAMCAQICEQDvxXGV9K8f4AQSxWSxJJPrMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0 ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTQwNzAyMTM1MzUyWhcN MTUwNzMwMTM1MzUyWjCBqzELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs aWVudCBDQSB2MTEdMBsGA1UEAxMUTWFyaWUtSm9zZSBNb250cGV0aXQxHjAcBgkqhkiG9w0BCQEW D21hcmllam9ATUlULkVEVTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMWfBmhCuS6ol1Q/ KWrhtk0nMP3xU6T6R7Q7y/VnbE6BtYxFaRQ09PzHiv9B58UDhbhNN5y59BVPWWfevOImFitx4PY0 c6wMYGxC6aR0l9VySQ0VNavkRRKujyPxxjz+GRb64mAWzP0xqutz6SaZ2Fi0lxgccRheH/d0OLTg agUCAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBRCoWStx3OeBP0pszhPjQgj z28cdDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRjbGllbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBAHdNroykei2WKB4gO19mPUIyPMBFZrw5f87upM40csBB5HBBtZO4 op6JqoMxs93UrS+KO2+UK8c4zL/lRBRfbmQ7/r+gbJn0YqMb93eEHXR2u07xiRxHrI8oaC9RGhzc NMjbuAPbxlfY55CEPA2LLT/3nibZfvy+UPV/Xdkbg71gMYICtTCCArECAQEwgYEwbDELMAkGA1UE BhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5z dGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/FcZX0rx/gBBLF ZLEkk+swCQYFKw4DAhoFAKCCAYkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMzA0MjA1MjU2WjAjBgkqhkiG9w0BCQQxFgQUDQGpJ/fOJt2MAALHMW60dXKwlDUw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYAce1OIrUKSMpRHuyf2L9eYresAYx6cJnKg dKRiVIPNxjR857HNSbprbYiGZYaMjwlMUHuGGpruCTRZNSSk+pOEr2aIG+Cyyg1M5h055yprjBvn csbHZrZOCnoo4Lshq9m/iQN4CtJOyad8huZqyuYJh05g+szmVtMNSR3z19D5LgAAAAAAAA== --Apple-Mail=_EF5BE75D-5A41-4156-836B-1DA96C187293-- From nobody Wed Mar 4 18:10:55 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B271A8A43 for ; Wed, 4 Mar 2015 18:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pImWN7IFYpHI for ; Wed, 4 Mar 2015 18:10:52 -0800 (PST) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) (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 1489C1A8A28 for ; Wed, 4 Mar 2015 18:10:52 -0800 (PST) Received: by oiav63 with SMTP id v63so9294529oia.8 for ; Wed, 04 Mar 2015 18:10:51 -0800 (PST) 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:content-type :content-transfer-encoding; bh=P+R88ki3u+usSN4w3NvBXB1QpGQtnuN5j+Zc3hoH9Ao=; b=YjysaP/bPbLI10PpoNxWk2zk/w3V7ZXZLpSDoTSSGzqm7ILKwiLwoHFoN94EkfEYxC uNdL64DHISsinfM941I7MBE+hmRGtVS72AAVXJ3phd3Zj5A2m7qOV2X+rl45XzitTfXx tuFj5EDamht6EqCURL/jVkNz92fOMe6fQJfTaLTRn14bTaEDAn19UbRAkcPB5ZXK9Gxx xDb3klILobR/xITFqM6ndmF/qYKZMA1lXpH9jpx4VtCAw2fG3j328mwErEmfmAWgJd54 QW8PP/ayPqNSkgrwInht8Uq/nKB4cTx81cv7sUrnNa8SUYEOIMMCvmWNX7sDz6Wlpcb+ msJA== X-Gm-Message-State: ALoCoQkmEddzAuaOBhm8buW12DhxAh9aNUq7VcBry4gTjRw0pyoKpDealCqX/RjUpDlC32skKUP7 MIME-Version: 1.0 X-Received: by 10.202.198.214 with SMTP id w205mr4929783oif.74.1425521451577; Wed, 04 Mar 2015 18:10:51 -0800 (PST) Received: by 10.202.87.131 with HTTP; Wed, 4 Mar 2015 18:10:51 -0800 (PST) In-Reply-To: <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> Date: Thu, 5 Mar 2015 13:10:51 +1100 Message-ID: From: Simone Ferlin-Oliveira To: taps WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Simone Ferlin-Oliveira , Olivier Mehani Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 02:10:54 -0000 Greetings, Sections 3.2 and 3.3 in draft-03 remind us that there are commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They could be further summarised, perhaps in a dedicated session to =E2=80=9Cmulti-path features=E2=80=9D, abstracting what both protocols prov= ide to applications. It could be, for example, inside section 4 as subsection. If the group agrees with that, we would like to take it (Section 4) as contributors. Thanks, Simone Ferlin and Olivier Mehani On 27 February 2015 at 23:58, Brian Trammell wrote: > Greetings, all, > > We've posted rev -03 of the taps-transports document; this includes a new= Section 3.3. on SCTP by Michael Tuexen and a new section 3.4 on UDP by Kev= in Fall; thanks Michael and Kevin! > > Comments on the new sections or the structure thereof (i.e., as input to = future transport protocol sections), or indeed on anything else in the docu= ment, are very welcome. :) > > Thanks, cheers, > > Brian > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> To: "Gorry Fairhurst" , "Mirja Kuehlewind" , "Brian Trammell" , "Mirja Kue= hlewind" , "Godred Fairhurst" , "Brian Trammell" >> Subject: New Version Notification for draft-ietf-taps-transports-03.txt >> Date: 27 Feb 2015 13:52:23 CET >> >> >> A new version of I-D, draft-ietf-taps-transports-03.txt >> has been successfully submitted by Brian Trammell and posted to the >> IETF repository. >> >> Name: draft-ietf-taps-transports >> Revision: 03 >> Title: Services provided by IETF transport protocols and = congestion control mechanisms >> Document date: 2015-02-27 >> Group: taps >> Pages: 25 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-taps-tran= sports-03.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-taps-transpo= rts/ >> Htmlized: http://tools.ietf.org/html/draft-ietf-taps-transports-03 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-trans= ports-03 >> >> Abstract: >> This document describes services provided by existing IETF protocols >> and congestion control mechanisms. It is designed to help >> application and network stack programmers and to inform the work of >> the IETF TAPS Working Group. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Mar 4 20:16:40 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2381A0161 for ; Wed, 4 Mar 2015 20:16:34 -0800 (PST) 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 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 UmdLuMTcQSIR for ; Wed, 4 Mar 2015 20:16:30 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BE61A8F3B for ; Wed, 4 Mar 2015 20:16:30 -0800 (PST) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t254Fp0O022658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 20:15:54 -0800 (PST) Message-ID: <54F7D877.2050005@isi.edu> Date: Wed, 04 Mar 2015 20:15:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Simone Ferlin-Oliveira , taps WG References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Olivier Mehani Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 04:16:34 -0000 On 3/4/2015 6:10 PM, Simone Ferlin-Oliveira wrote: > Greetings, > > Sections 3.2 and 3.3 in draft-03 remind us that there are > commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They > could be further summarised, perhaps in a dedicated session to > “multi-path features”, abstracting what both protocols provide to > applications. It could be, for example, inside section 4 as > subsection. These are multi-endpoint features. Despite the name of MPTCP and the fact that this has been pointed out repeatedly to them, let's please not continue to mislabel this as multi-path. Joe > > If the group agrees with that, we would like to take it (Section 4) as > contributors. > > Thanks, > Simone Ferlin and Olivier Mehani > > On 27 February 2015 at 23:58, Brian Trammell wrote: >> Greetings, all, >> >> We've posted rev -03 of the taps-transports document; this includes a new Section 3.3. on SCTP by Michael Tuexen and a new section 3.4 on UDP by Kevin Fall; thanks Michael and Kevin! >> >> Comments on the new sections or the structure thereof (i.e., as input to future transport protocol sections), or indeed on anything else in the document, are very welcome. :) >> >> Thanks, cheers, >> >> Brian >> >>> Begin forwarded message: >>> >>> From: internet-drafts@ietf.org >>> To: "Gorry Fairhurst" , "Mirja Kuehlewind" , "Brian Trammell" , "Mirja Kuehlewind" , "Godred Fairhurst" , "Brian Trammell" >>> Subject: New Version Notification for draft-ietf-taps-transports-03.txt >>> Date: 27 Feb 2015 13:52:23 CET >>> >>> >>> A new version of I-D, draft-ietf-taps-transports-03.txt >>> has been successfully submitted by Brian Trammell and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-taps-transports >>> Revision: 03 >>> Title: Services provided by IETF transport protocols and congestion control mechanisms >>> Document date: 2015-02-27 >>> Group: taps >>> Pages: 25 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-taps-transports-03.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >>> Htmlized: http://tools.ietf.org/html/draft-ietf-taps-transports-03 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03 >>> >>> Abstract: >>> This document describes services provided by existing IETF protocols >>> and congestion control mechanisms. It is designed to help >>> application and network stack programmers and to inform the work of >>> the IETF TAPS Working Group. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Thu Mar 5 02:09:34 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03301A8720 for ; Thu, 5 Mar 2015 02:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XevXtyfIm8q4 for ; Thu, 5 Mar 2015 02:09:31 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A4E801A1A2F for ; Thu, 5 Mar 2015 02:09:30 -0800 (PST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 502271A00F4; Thu, 5 Mar 2015 11:09:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Brian Trammell In-Reply-To: Date: Thu, 5 Mar 2015 11:09:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> To: Simone Ferlin-Oliveira X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Olivier Mehani , taps WG Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:09:33 -0000 hi Simone, > On 05 Mar 2015, at 03:10, Simone Ferlin-Oliveira = wrote: >=20 > Greetings, >=20 > Sections 3.2 and 3.3 in draft-03 remind us that there are > commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They > could be further summarised, perhaps in a dedicated session to > =E2=80=9Cmulti-path features=E2=80=9D, abstracting what both protocols = provide to > applications. It could be, for example, inside section 4 as > subsection. Modulo Joe's comment that we shouldn't confuse "multi-path" (which is = the goal...), "multi-endpoint" (...the abstraction we can use at the = endpoints to try to meet the goal...), and "multi-interface" (...and the = implementation of the abstraction) when defining a terminology here, = this sounds good to me. > If the group agrees with that, we would like to take it (Section 4) as > contributors. Thanks! Cheers, Brian > Thanks, > Simone Ferlin and Olivier Mehani >=20 > On 27 February 2015 at 23:58, Brian Trammell wrote: >> Greetings, all, >>=20 >> We've posted rev -03 of the taps-transports document; this includes a = new Section 3.3. on SCTP by Michael Tuexen and a new section 3.4 on UDP = by Kevin Fall; thanks Michael and Kevin! >>=20 >> Comments on the new sections or the structure thereof (i.e., as input = to future transport protocol sections), or indeed on anything else in = the document, are very welcome. :) >>=20 >> Thanks, cheers, >>=20 >> Brian >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> To: "Gorry Fairhurst" , "Mirja Kuehlewind" = , "Brian Trammell" , = "Mirja Kuehlewind" , "Godred Fairhurst" = , "Brian Trammell" >>> Subject: New Version Notification for = draft-ietf-taps-transports-03.txt >>> Date: 27 Feb 2015 13:52:23 CET >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-taps-transports-03.txt >>> has been successfully submitted by Brian Trammell and posted to the >>> IETF repository. >>>=20 >>> Name: draft-ietf-taps-transports >>> Revision: 03 >>> Title: Services provided by IETF transport protocols = and congestion control mechanisms >>> Document date: 2015-02-27 >>> Group: taps >>> Pages: 25 >>> URL: = http://www.ietf.org/internet-drafts/draft-ietf-taps-transports-03.txt >>> Status: = https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >>> Htmlized: = http://tools.ietf.org/html/draft-ietf-taps-transports-03 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-03 >>>=20 >>> Abstract: >>> This document describes services provided by existing IETF = protocols >>> and congestion control mechanisms. It is designed to help >>> application and network stack programmers and to inform the work of >>> the IETF TAPS Working Group. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Mar 5 03:23:27 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774551B2BDE for ; Thu, 5 Mar 2015 03:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G82ZagaCxB9y for ; Thu, 5 Mar 2015 03:23:24 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4481B2BE2 for ; Thu, 5 Mar 2015 03:23:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C4FC9D9305; Thu, 5 Mar 2015 12:23:21 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MdHXaIcZeeVk; Thu, 5 Mar 2015 12:23:21 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8B438D9304; Thu, 5 Mar 2015 12:23:21 +0100 (MET) Message-ID: <54F83CA9.8040702@tik.ee.ethz.ch> Date: Thu, 05 Mar 2015 12:23:21 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Simone Ferlin-Oliveira , taps WG References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Olivier Mehani Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:23:26 -0000 Hi Simone, thanks for this offer. The idea of this document is to first describe all existing protocols separately and then based on these descriptions detect common transport service features. And, this might be again a terminology issues, this is not about the API that is exposed to the higher layer but rather about the actual feature that are implemented below. I see this the following way: the reason for writing this document is not that someone can later read a nice summary about existing IETF (transport) protocol but it about the group doing the exercise to make sure that we don't missing something just because we all believe we are expert anyway... Having said this, I'd like to first see a complete section (3.2) on MPTCP before we start to writing something on this in section 4. However, I'm sure you could also help to provide some text in section 3.2...? That would be great! Mirja On 05.03.2015 03:10, Simone Ferlin-Oliveira wrote: > Greetings, > > Sections 3.2 and 3.3 in draft-03 remind us that there are > commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They > could be further summarised, perhaps in a dedicated session to > “multi-path features”, abstracting what both protocols provide to > applications. It could be, for example, inside section 4 as > subsection. > > If the group agrees with that, we would like to take it (Section 4) as > contributors. > > Thanks, > Simone Ferlin and Olivier Mehani > > On 27 February 2015 at 23:58, Brian Trammell wrote: >> Greetings, all, >> >> We've posted rev -03 of the taps-transports document; this includes a new Section 3.3. on SCTP by Michael Tuexen and a new section 3.4 on UDP by Kevin Fall; thanks Michael and Kevin! >> >> Comments on the new sections or the structure thereof (i.e., as input to future transport protocol sections), or indeed on anything else in the document, are very welcome. :) >> >> Thanks, cheers, >> >> Brian >> >>> Begin forwarded message: >>> >>> From: internet-drafts@ietf.org >>> To: "Gorry Fairhurst" , "Mirja Kuehlewind" , "Brian Trammell" , "Mirja Kuehlewind" , "Godred Fairhurst" , "Brian Trammell" >>> Subject: New Version Notification for draft-ietf-taps-transports-03.txt >>> Date: 27 Feb 2015 13:52:23 CET >>> >>> >>> A new version of I-D, draft-ietf-taps-transports-03.txt >>> has been successfully submitted by Brian Trammell and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-taps-transports >>> Revision: 03 >>> Title: Services provided by IETF transport protocols and congestion control mechanisms >>> Document date: 2015-02-27 >>> Group: taps >>> Pages: 25 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-taps-transports-03.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >>> Htmlized: http://tools.ietf.org/html/draft-ietf-taps-transports-03 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03 >>> >>> Abstract: >>> This document describes services provided by existing IETF protocols >>> and congestion control mechanisms. It is designed to help >>> application and network stack programmers and to inform the work of >>> the IETF TAPS Working Group. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Thu Mar 5 15:33:40 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DC91A908C for ; Thu, 5 Mar 2015 15:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RT4s_XiQOb4w for ; Thu, 5 Mar 2015 15:33:37 -0800 (PST) Received: from atp-mxout1.it.nicta.com.au (atp-mxout1.it.nicta.com.au [IPv6:2402:1800:0:8004:250:56ff:fe02:4888]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB041A9073 for ; Thu, 5 Mar 2015 15:33:37 -0800 (PST) Received: from atp-exchmbx2.it.nicta.com.au ([221.199.216.124] helo=atp-exchmbx1.in.nicta.com.au) by atp-mxout1.it.nicta.com.au with esmtp (Exim 4.80) (envelope-from ) id 1YTfGm-0003Oo-G6; Fri, 06 Mar 2015 10:33:32 +1100 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx2.in.nicta.com.au (221.199.216.124) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 10:33:30 +1100 Received: from blasturvion (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 10:33:29 +1100 Received: by blasturvion (sSMTP sendmail emulation); Fri, 06 Mar 2015 10:33:29 +1100 Date: Fri, 6 Mar 2015 10:33:29 +1100 From: Olivier Mehani To: Mirja =?iso-8859-15?Q?K=FChlewind?= Message-ID: <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline In-Reply-To: <54F83CA9.8040702@tik.ee.ethz.ch> X-Accept-Language: fr, en, es OpenPGP: id=4435CF6A7C8DDD9BE2DEF5F9F012A6E298C66655; preference=signencrypt; url=https://olivier.mehani.name/olivier.mehani.pgp.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-Product-Ver: SMEX-11.0.0.1251-7.500.1018-21378.003 X-TM-AS-Result: No--9.476900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: Cc: Simone Ferlin-Oliveira , taps WG Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 23:33:38 -0000 --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Mirja, all, On Thu, Mar 05, 2015 at 12:23:21PM +0100, Mirja K=C3=BChlewind wrote: > >Sections 3.2 and 3.3 in draft-03 remind us that there are > >commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They > >could be further summarised, perhaps in a dedicated session to > >=E2=80=9Cmulti-path features=E2=80=9D, abstracting what both protocols p= rovide to > >applications. It could be, for example, inside section 4 as > >subsection. > thanks for this offer. The idea of this document is to first describe all > existing protocols separately and then based on these descriptions detect > common transport service features. And, this might be again a terminology > issues, this is not about the API that is exposed to the higher layer but > rather about the actual feature that are implemented below. >=20 > Having said this, I'd like to first see a complete section (3.2) on MPTCP > before we start to writing something on this in section 4. However, I'm s= ure > you could also help to provide some text in section 3.2...? That would be > great! Yes, that was the plan. I think the API for both SCTP and MPTCP are relevant in highlighting the underlying features of the protocol, even though these APIs are not what needs to be described. The synthesis in section 4 should come at a later stage, once 3.2 (and perhaps a similar discussion in SCTP's section), have been written up. --=20 Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJU+OfJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5MzA1NjQ3NTk5QUQ1MUVBNTkxREJDRkRF OTU2NkI5RDA5NTdEMkQzAAoJEOlWa50JV9LTZtoH/RDCZDcy8KkHycDxmj2c0QKh 8ksFCHqYa4lhTpFkJs/yry/NOoaFiPNG14c6RRMrqJ3tjaZsCjIJ1858xAV/4OjU AongOvTi5DME1jlbb/6jTv3EDVTx1h6VLEpLXE4FnoN5HvBkMSfgAdbbLrOSpFIy XhKitEt/y9kWzqAuN/A3zG55i9XUVQDLqNXlSM0DWWKOgN6hgCvL/+2GXCyitwsv KuK8Wz8cNsUiCb90bLNRmkCTG391AqoPgfedb8D0tTSihT/RrtqTe2SkRtRAWkJf u/14dPHBoF7P1wjglFnB0CcR3kBbYcukGKWLNkPu9caz/FOiBBJhL1hjxWoAG5s= =cXx0 -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/-- From nobody Fri Mar 6 02:25:42 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806731A1B99 for ; Fri, 6 Mar 2015 02:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avKIzu_eVJ1P for ; Fri, 6 Mar 2015 02:25:38 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E821A00F0 for ; Fri, 6 Mar 2015 02:25:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 06690D9307; Fri, 6 Mar 2015 11:25:36 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y+gqrMscXkMW; Fri, 6 Mar 2015 11:25:35 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CAF5DD9305; Fri, 6 Mar 2015 11:25:35 +0100 (MET) Message-ID: <54F9809F.9050209@tik.ee.ethz.ch> Date: Fri, 06 Mar 2015 11:25:35 +0100 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Olivier Mehani References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> In-Reply-To: <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Simone Ferlin-Oliveira , taps WG Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 10:25:40 -0000 Hi Olivier, see below On 06.03.2015 00:33, Olivier Mehani wrote: > Hi Mirja, all, > > On Thu, Mar 05, 2015 at 12:23:21PM +0100, Mirja Khlewind wrote: >>> Sections 3.2 and 3.3 in draft-03 remind us that there are >>> commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They >>> could be further summarised, perhaps in a dedicated session to >>> multi-path features, abstracting what both protocols provide to >>> applications. It could be, for example, inside section 4 as >>> subsection. >> thanks for this offer. The idea of this document is to first describe all >> existing protocols separately and then based on these descriptions detect >> common transport service features. And, this might be again a terminology >> issues, this is not about the API that is exposed to the higher layer but >> rather about the actual feature that are implemented below. >> >> Having said this, I'd like to first see a complete section (3.2) on MPTCP >> before we start to writing something on this in section 4. However, I'm sure >> you could also help to provide some text in section 3.2...? That would be >> great! > > Yes, that was the plan. I think the API for both SCTP and MPTCP are > relevant in highlighting the underlying features of the protocol, even > though these APIs are not what needs to be described. Yep. APIs should not be discussed in section 4. However, for the protocol description in section 3, if you look at the other descriptions, there is also a subsection on the (higher layer) interface. As you say there is often a strong dependency therefore I think there is a purpose to describe the interface as well (in section 3) to have a ground truth for discussion. > > The synthesis in section 4 should come at a later stage, once 3.2 (and > perhaps a similar discussion in SCTP's section), have been written up. Yes! Mirja > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed Mar 11 03:35:15 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08771ACD40 for ; Wed, 11 Mar 2015 03:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQaqMugKb98o for ; Wed, 11 Mar 2015 03:35:11 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB331ACE51 for ; Wed, 11 Mar 2015 03:28:55 -0700 (PDT) X-AuditID: c1b4fb30-f79c86d000000fc0-b1-550018e554df Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.47.04032.5E810055; Wed, 11 Mar 2015 11:28:53 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Wed, 11 Mar 2015 11:28:53 +0100 From: Szilveszter Nadas To: "taps@ietf.org" Thread-Topic: New Version Notification for draft-mihaly-enablers-for-tlp-evolution-00.txt Thread-Index: AQHQWnltVPoFpdKPoUeUzGr9Yiio8Z0XFLyggAACijA= Date: Wed, 11 Mar 2015 10:28:52 +0000 Message-ID: References: <20150309145404.2182.93122.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje5TCYZQg54fyhZ3YhwYPZYs+ckU wBjFZZOSmpNZllqkb5fAlbFm7hzGghOSFase/2ZvYPwi0cXIySEhYCJxaeVtRghbTOLCvfVs XYxcHEICRxglFv/pZIJwFjNK7P10hB2kik3AQqJh5WY2EFtEQFni8v6NYDazgKPE5GOdzCC2 sECUxILL/UBxDqCaaIlJ7WYQ5VYSP1+eYwWxWQRUJeZvmMwCYvMK+EqseNMCdoQQ0JiHF7aA rWIEOuj7qTVMEOPFJW49mc8EcaiAxJI955khbFGJl4//sYKskhBQkpi2NQ3EZBbQlFi/Sx+i U1FiSvdDdohNghInZz5hmcAoOgvJ0FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRkV5qUWZycXF+ nl5easkmRmAkHNzy22AH48vnjocYBTgYlXh4N6z/HyLEmlhWXJl7iFGag0VJnNfO+FCIkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYEv/0ld49ekavZfShK5D3fhzkFqi22++rEn9s6umYJ /Zq3ZK7Yr4/My/e/eSet5df+dfuD6ln/D7w6sMDP56Nt3KH0dXeeHNn9yXyu/AxOt07PA7a/ FFabzTVSXCnsxTGhdWLqh7IZQhe2Z5T37Z5mfHvP59p/a/7EtJzTXB/9NWXTIq+Y3oUTlFiK MxINtZiLihMB3Z2lE2UCAAA= Archived-At: Cc: =?utf-8?B?QXR0aWxhIE1paMOhbHk=?= Subject: [Taps] FW: New Version Notification for draft-mihaly-enablers-for-tlp-evolution-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 10:35:13 -0000 RllJDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTemlsdmVzenRlciBOYWRh cyANClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTEsIDIwMTUgMTE6MjgNClRvOiB0c3Z3Z0BpZXRm Lm9yZw0KQ2M6IEF0dGlsYSBNaWjDoWx5DQpTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1taWhhbHktZW5hYmxlcnMtZm9yLXRscC1ldm9sdXRpb24tMDAudHh0 DQoNCkhpLA0KDQpXZSBjcmVhdGVkIGEgZHJhZnQgYWJvdXQgb3VyIHZpc2lvbiBob3cgdGhlIHRy YW5zcG9ydCBwcm90b2NvbCBmcmFtZXdvcmsgc2hvdWxkIGxvb2sgaW4gdGhlIGZ1dHVyZSwgd2hl biB1c2VyIHBsYW5lIGltcGxlbWVudGF0aW9ucyBhbGxvdyBtdWNoIG1vcmUgdmFyaWV0eSBhbmQg ZmFzdGVyIGV2b2x1dGlvbi4gVGhpcyByZWxhdGVzIHRvIHNldmVyYWwgb25nb2luZyBpZXRmIGFj dGl2aXRpZXMuIFdlIHdvdWxkIGJlIGhhcHB5IHRvIHByZXNlbnQgaXQsIEkgdGhpbmsgdHN2d2cg aXMgdGhlIHJpZ2h0IHBsYWNlIGZvciBpdC4gQWxzbyBkaXNjdXNzaW9uIGFuZCBjb21tZW50cyBh cmUgd2VsY29tZS4NCg0KQ2hlZXJzLA0KU3ppbHZlc3p0ZXIgYW5kIEF0dGlsYQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgTWFyY2ggMDksIDIw MTUgMTU6NTQNClRvOiBTemlsdmVzenRlciBOYWRhczsgQXR0aWxhIE1paMOhbHk7IEF0dGlsYSBN aWjDoWx5OyBTemlsdmVzenRlciBOYWRhcw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1taWhhbHktZW5hYmxlcnMtZm9yLXRscC1ldm9sdXRpb24tMDAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1paGFseS1lbmFibGVycy1mb3ItdGxwLWV2 b2x1dGlvbi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQXR0aWxh IE1paGFseSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1taWhhbHktZW5hYmxlcnMtZm9yLXRscC1ldm9sdXRpb24NClJldmlzaW9uOgkwMA0KVGl0bGU6 CQlFbmFibGVycyBmb3IgVHJhbnNwb3J0IExheWVyIFByb3RvY29sIEV2b2x1dGlvbg0KRG9jdW1l bnQgZGF0ZToJMjAxNS0wMy0wOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJMTYNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1taWhhbHktZW5hYmxlcnMtZm9yLXRscC1ldm9sdXRpb24tMDAudHh0DQpTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWloYWx5LWVu YWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1paGFseS1lbmFibGVycy1mb3ItdGxwLWV2b2x1dGlvbi0wMA0K DQoNCkFic3RyYWN0Og0KICAgSW4gdGhpcyBkb2N1bWVudCB3ZSBjb2xsZWN0ZWQgcmVxdWlyZW1l bnRzIGZvciBUTFAgZXZvbHV0aW9uLiBUaGVzZQ0KICAgcmVxdWlyZW1lbnRzIGFyZSB0aGUgY29u c2VxdWVuY2Ugb2YgcmVtb3Zpbmcgb2JzdGFjbGVzIG9mIFRMUA0KICAgZXZvbHV0aW9uLiBUaGlz IHJlc3VsdHMgaW4gYSBoaWdoZXIgdmFyaWV0eSBvZiBleHBlY3RlZCBUTFANCiAgIGltcGxlbWVu dGF0aW9ucyBhbmQgbG93ZXIgdHJ1c3QgbGV2ZWwgaW4gdGhlc2UuIENvbmZpZGVudGlhbGl0eSBv Zg0KICAgY29tbXVuaWNhdGlvbiBhbmQgc2VjdXJpdHkgaXMgbW9yZSBhbmQgbW9yZSBpbXBvcnRh bnQuIE1pZGRsZWJveGVzDQogICB3aGljaCB0b2RheSBhcmUgb25lIG9mIHRoZSBvYnN0YWNsZXMg b2YgdGhlIGV2b2x1dGlvbiBzaGFsbCBiZSB0YWtlbg0KICAgaW50byBhY2NvdW50IGFuZCBpbmNl bnRpdml6ZWQgdG8gY29vcGVyYXRlIGluIHRoZSBmdXR1cmUgbGFuZHNjYXBlLg0KICAgUmVzdWx0 aW5nIGZyb20gdGhlIHJlcXVpcmVtZW50cyB3ZSBwcm9wb3NlIGFyZWFzIGZvciBmdXJ0aGVyDQog ICBpbnZlc3RpZ2F0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Mar 11 07:26:01 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59F61ACDFE for ; Wed, 11 Mar 2015 07:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Yubjy1xRK8 for ; Wed, 11 Mar 2015 07:25:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA481ACDC2 for ; Wed, 11 Mar 2015 07:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3793; q=dns/txt; s=iport; t=1426083951; x=1427293551; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1Bgx5JVCPzAfgYTEqZmSrjmqCPNmjRCG8VD+QjqDVMQ=; b=ktixHGHciwcCfWlAfqWYORWnMbzyrC2NbIhocXrLytf+NmM5XiTNRAz4 rQabHwm2Fj96Dph8k4wLscifKDoZ2QTQnEC/FpyUYlxoHvFCT/hpQDo59 ptN8xlzIqwQ3RIYwdkuhMBm5Pq3hAqmG7N2bWD7gxIRFW14vfiHf++mSv 4=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtBQA2TwBV/4kNJK1cgwZSWgSDB8BKCoVwAoE4TQEBAQEBAXyEDwEBAQMBAQEBIEsLBQsCAQgYDR0CAiEGCyUCBA4FDogNAwkIDa0QlV4NhSgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsXgkSCKgeCaC+BFgWQG4FmgS6Ef4FKgRqDKIkhhhQjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,382,1422921600"; d="asc'?scan'208";a="131004523" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 11 Mar 2015 14:25:50 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2BEPn4l004715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 14:25:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 11 Mar 2015 09:25:49 -0500 From: "Fred Baker (fred)" To: Aaron Falk Thread-Topic: [Taps] BarBoF: How Ossified is the Protocol Stack? [HOPS] Thread-Index: AQHQXAdFbmU8wmCNIESxmxnV0W1pRA== Date: Wed, 11 Mar 2015 14:25:48 +0000 Message-ID: <7D3AA14E-FC3A-434C-A31B-C8EF03CD8F30@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.61.251] Content-Type: multipart/signed; boundary="Apple-Mail=_CF42D31F-FF4D-4541-92A6-1BDFA946A101"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] BarBoF: How Ossified is the Protocol Stack? [HOPS] X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:25:59 -0000 --Apple-Mail=_CF42D31F-FF4D-4541-92A6-1BDFA946A101 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m interested but already have an activity that evening. Will = there be some posted summary? > On Feb 25, 2015, at 10:33 AM, Aaron Falk wrote: >=20 > There has been long term and increasing interest in deploying = transport protocols with alternate dynamics and behaviors to TCP and = UDP. The IETF has standardized several new protocols including DCCP, = UDP-lite, SCTP and several changes to TCP including ECN and LEDBAT. All = of these new technologies have resulted in deployment challenges blamed = on intentional and unintentional interference by middleboxes such as = NATs and firewalls. This has lead to approaches such as building new = protocols over UDP or HTTP to make traffic look like something a = middlebox would expect. However, both these approaches have shortcomings = and a variety of ameliorating engineering approaches are being = considered [1], [2], [3]. >=20 > What is missing is a study with more than anecdotal evidence of the = nature of the problem and the portions of the network in which it = manifests. One of the best analyses to date is [4] which measures from a = very small number of locations: 49 residential, 17 enterprise, and 142 = locations in total. In the interest of getting ground-truth data about = the nature of the problem, we are organizing an informal effort starting = with a meeting (BarBoF) at the March IETF in Dallas to coordinate with = network stack, browser, and middlebox vendors, as well as network and = service operators, on collecting and reporting statistics about = middlebox impact on transport sessions. The objective is to determine a = set of measurements that can be made as a side effect of the normal = operation of the networking stack, and a reporting format that provides = some visibility into the scope and nature of middlebox impact while = addressing end-user privacy and business confidentiality concerns. >=20 > The BarBoF meeting will be Sunday evening (March 22nd). Time & = location to be announced on the mailing list [5]. >=20 > This activity is an outcome of the recent IAB workshop on Stack = Evolution in a Middlebox Internet [6]. >=20 > Please forward to anyone interested in participating. >=20 > -------- >=20 > [1] IETF Transport Services Working Group (TAPS) >=20 > [2] IAB Stack Evolution Program >=20 > [3] Session Protocol for User Datagrams (SPUD) Prototype >=20 > [4] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. = Tokuda. Is it still possible to extend tcp? In Proc. ACM IMC, 2011. >=20 > [5] Subscription link to HOPS mailing list. >=20 > [6] IAB SEMI Workshop >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_CF42D31F-FF4D-4541-92A6-1BDFA946A101 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVQBNpZ9ieig10VPpAQLkzAf+Jtcl9oHln/bxoS/n1l7Z7Zy5+RNc2qIM mypPm+y8ZO8Jf7zgUSz47WOpRz7sBhP5w+RNUOhhknmEIMsdcTxUE4MHLsFE5v7z /GJMx0nKkn7wZdkLaNxa2dIyLmIEM7ly1dQ9m0YJaE4R4b02ZyIPMp/wTlrEv4Qk LRcvK6r60KqHNfqvF9/exggwwekap4wO8qNF/BdlH15PVsYu+kXbPPRrT40Zjrkj D7iP7qsjgtNKVyC5raI2lu/PNJGKWSPMuSpduv2xHkTZkegB8Lg27dpeD0NhwB+R wvhoKp9K5wKZEmS++9UVW6bQNnmeZzlzPnFUN3MfVoz3AvPitBP2mg== =kbuM -----END PGP SIGNATURE----- --Apple-Mail=_CF42D31F-FF4D-4541-92A6-1BDFA946A101-- From nobody Wed Mar 11 07:36:04 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BDB1ACE3D for ; Wed, 11 Mar 2015 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIOt9QzHQd7L for ; Wed, 11 Mar 2015 07:35:50 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (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 512F71ACE1D for ; Wed, 11 Mar 2015 07:35:50 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hq12so3074400vcb.12 for ; Wed, 11 Mar 2015 07:35:49 -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:content-type; bh=2ZMMMoBj0As+KUYMGLdy4GC5Ebmz7w/v9Tbxy2jEcHQ=; b=h7y6QLFBxC64EdtZaukRltXERSA6y5kYBwHL272Ip0ekrIbEM1tkZvT4t4WX8kmc32 xxgujmzsJv+90Nmk7Bk1Ny4rVrSquHETyNTq2OgAiqlj90oCbVVEzoWykOxr6Wc8/0OE rE5RA6g0fNfKW+T096JUmLLG3GD9F9ld7/P1Qc3Y2ss3cWDdoC8Qzwi+ZEKPSa2O+TqI OUgLpCANHSy3/swviHYrC61ATt47FISyTvR6CYBRXncjkw1TIHd7Q4XKGELPppcpCoXI V55zQmidZEhLwhxe/sWGjpfwF+iduBcbh2Ae3GgZ5sWAiBXZEIijA3+MQQeu+V1daATo e7Ng== MIME-Version: 1.0 X-Received: by 10.52.52.136 with SMTP id t8mr43684463vdo.49.1426084549505; Wed, 11 Mar 2015 07:35:49 -0700 (PDT) Received: by 10.52.186.35 with HTTP; Wed, 11 Mar 2015 07:35:49 -0700 (PDT) In-Reply-To: <7D3AA14E-FC3A-434C-A31B-C8EF03CD8F30@cisco.com> References: <7D3AA14E-FC3A-434C-A31B-C8EF03CD8F30@cisco.com> Date: Wed, 11 Mar 2015 10:35:49 -0400 Message-ID: From: Aaron Falk To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e0115f048fe371a0511042ef1 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] BarBoF: How Ossified is the Protocol Stack? [HOPS] X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:36:02 -0000 --089e0115f048fe371a0511042ef1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yup. It'll go out to the HOPS mail list so you can find it in the archives if you aren't subscribed. --aaron On Wed, Mar 11, 2015 at 10:25 AM, Fred Baker (fred) wrote: > I=E2=80=99m interested but already have an activity that evening. Will th= ere be > some posted summary? > > > On Feb 25, 2015, at 10:33 AM, Aaron Falk wrote: > > > > There has been long term and increasing interest in deploying transport > protocols with alternate dynamics and behaviors to TCP and UDP. The IETF > has standardized several new protocols including DCCP, UDP-lite, SCTP and > several changes to TCP including ECN and LEDBAT. All of these new > technologies have resulted in deployment challenges blamed on intentional > and unintentional interference by middleboxes such as NATs and firewalls. > This has lead to approaches such as building new protocols over UDP or HT= TP > to make traffic look like something a middlebox would expect. However, bo= th > these approaches have shortcomings and a variety of ameliorating > engineering approaches are being considered [1], [2], [3]. > > > > What is missing is a study with more than anecdotal evidence of the > nature of the problem and the portions of the network in which it > manifests. One of the best analyses to date is [4] which measures from a > very small number of locations: 49 residential, 17 enterprise, and 142 > locations in total. In the interest of getting ground-truth data about th= e > nature of the problem, we are organizing an informal effort starting with= a > meeting (BarBoF) at the March IETF in Dallas to coordinate with network > stack, browser, and middlebox vendors, as well as network and service > operators, on collecting and reporting statistics about middlebox impact = on > transport sessions. The objective is to determine a set of measurements > that can be made as a side effect of the normal operation of the networki= ng > stack, and a reporting format that provides some visibility into the scop= e > and nature of middlebox impact while addressing end-user privacy and > business confidentiality concerns. > > > > The BarBoF meeting will be Sunday evening (March 22nd). Time & locatio= n > to be announced on the mailing list [5]. > > > > This activity is an outcome of the recent IAB workshop on Stack > Evolution in a Middlebox Internet [6]. > > > > Please forward to anyone interested in participating. > > > > -------- > > > > [1] IETF Transport Services Working Group (TAPS) > > > > [2] IAB Stack Evolution Program > > > > [3] Session Protocol for User Datagrams (SPUD) Prototype > > > > [4] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. > Tokuda. Is it still possible to extend tcp? In Proc. ACM IMC, 2011. > > > > [5] Subscription link to HOPS mailing list. > > > > [6] IAB SEMI Workshop > > > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > --089e0115f048fe371a0511042ef1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yup.=C2=A0 It'll go out to the HOPS mail list so you c= an find it in the archives if you aren't subscribed.

--aaron

On We= d, Mar 11, 2015 at 10:25 AM, Fred Baker (fred) <fred@cisco.com>= wrote:
I=E2=80=99m interested but alread= y have an activity that evening. Will there be some posted summary?

> On Feb 25, 2015, at 10:33 AM, Aaron Falk <aaron.falk@gmail.com> wrote:
>
> There has been long term and increasing interest in deploying transpor= t protocols with alternate dynamics and behaviors to TCP and UDP. The IETF = has standardized several new protocols including DCCP, UDP-lite, SCTP and s= everal changes to TCP including ECN and LEDBAT. All of these new technologi= es have resulted in deployment challenges blamed on intentional and uninten= tional interference by middleboxes such as NATs and firewalls. This has lea= d to approaches such as building new protocols over UDP or HTTP to make tra= ffic look like something a middlebox would expect. However, both these appr= oaches have shortcomings and a variety of ameliorating engineering approach= es are being considered [1], [2], [3].
>
> What is missing is a study with more than anecdotal evidence of the na= ture of the problem and the portions of the network in which it manifests. = One of the best analyses to date is [4] which measures from a very small nu= mber of locations: 49 residential, 17 enterprise, and 142 locations in tota= l. In the interest of getting ground-truth data about the nature of the pro= blem, we are organizing an informal effort starting with a meeting (BarBoF)= at the March IETF in Dallas to coordinate with network stack, browser, and= middlebox vendors, as well as network and service operators, on collecting= and reporting statistics about middlebox impact on transport sessions. The= objective is to determine a set of measurements that can be made as a side= effect of the normal operation of the networking stack, and a reporting fo= rmat that provides some visibility into the scope and nature of middlebox i= mpact while addressing end-user privacy and business confidentiality concer= ns.
>
> The BarBoF meeting will be Sunday evening (March 22nd).=C2=A0 Time &am= p; location to be announced on the mailing list [5].
>
> This activity is an outcome of the recent IAB workshop on Stack Evolut= ion in a Middlebox Internet [6].
>
> Please forward to anyone interested in participating.
>
> --------
>
> [1] IETF Transport Services Working Group (TAPS)
>
> [2] IAB Stack Evolution Program
>
> [3] Session Protocol for User Datagrams (SPUD) Prototype
>
> [4] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H.= Tokuda. Is it still possible to extend tcp? In Proc. ACM IMC, 2011.
>
> [5] Subscription link to HOPS mailing list.
>
> [6] IAB SEMI Workshop
>
>
> __________________= _____________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


--089e0115f048fe371a0511042ef1-- From nobody Fri Mar 13 12:47:46 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574C11A1A03 for ; Fri, 13 Mar 2015 12:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z3Z20SP9V6I for ; Fri, 13 Mar 2015 12:47:44 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (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 0EBA21A0451 for ; Fri, 13 Mar 2015 12:47:44 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so123320322iec.2 for ; Fri, 13 Mar 2015 12:47:43 -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:content-type; bh=OtFzxWGLvhHqdElN7qxA6YgGoKhJgtpxnxZdC87WREc=; b=lh/Zesr8WTP4R9/DCzl7D64ycet04taFl/NdjSNVSmWiMbKsJE7RoMwAxefLcdBwc+ oqriWdOdxGR/uF0D3RQp46bmtCeTqsfIMNTHFuDg8w16i7qLihQw3IEJczLHT9cVs5Y1 UA+0lvfsykvDsTVuICvadk9HEYqs5+Fu1l1CE00fAHQOvVZd/nbNCnHR9s3FJgWmIKCm ql0pleWu9oxzb60ck9bjG+sDrG9RW+wJcqF2vjYFqDh9TvkCAkllmTuErP3tKiC7/AGf yXwrF89T1ujnxL+/St2ZObFzPXu6tuTlTDZ3vhXw75aufL1zonYa4me8aUHOIiN3qeDl ESog== MIME-Version: 1.0 X-Received: by 10.50.39.65 with SMTP id n1mr113628700igk.37.1426276062357; Fri, 13 Mar 2015 12:47:42 -0700 (PDT) Received: by 10.64.113.196 with HTTP; Fri, 13 Mar 2015 12:47:42 -0700 (PDT) Date: Fri, 13 Mar 2015 15:47:42 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc14380c90d2051130c6d0 Archived-At: Subject: [Taps] draft TAPS agenda X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 19:47:45 -0000 --047d7bdc14380c90d2051130c6d0 Content-Type: text/plain; charset=UTF-8 Here's a coarse agenda for the TAPS meeting in Dallas: 1. Review of draft changes and badgering of volunteers - Brian Trammel 2. Two or three transport feature matrices - Gorry Fairhurst, Michael Welzl, and (hopefully) Dave Thaler 3. Applications view of transport abstractions - RTCWeb data channel services - Michael Tuexen - Multisource video / TV - Marie-Jose Montpetite Any additional topics to add? --aaron --047d7bdc14380c90d2051130c6d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's a coarse agenda for the TAPS meeting in Dallas:=

1. Review of draft changes and badgering of volunteers = - Brian Trammel

2. Two or three transport feature = matrices=C2=A0
=C2=A0 =C2=A0 - Gorry Fairhurst, Michael Welzl, an= d (hopefully) Dave Thaler

3. Applications view of = transport abstractions
=C2=A0 =C2=A0- RTCWeb data channel service= s - Michael Tuexen
=C2=A0 =C2=A0- Multisource video / TV - Marie-= Jose Montpetite

Any additional topics to add?

--aaron
--047d7bdc14380c90d2051130c6d0-- From nobody Sun Mar 15 02:07:30 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8E11A0058 for ; Sun, 15 Mar 2015 02:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 gTIbsl7NSfxD for ; Sun, 15 Mar 2015 02:07:26 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 65AEC1A001B for ; Sun, 15 Mar 2015 02:07:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D3CAB5SgVV/03T03ZbgwaBLMoJBAKBFk0BAQEBAQF9hGwjPBMhBSU3iC7JXgELAR+QCB2DAYEWBZofAYcBjRMjggIcgWQqMYJDAQEB Received: from ppp118-211-211-77.lns20.syd4.internode.on.net (HELO cancey.narf.ssji.net) ([118.211.211.77]) by ipmail06.adl6.internode.on.net with ESMTP; 15 Mar 2015 19:37:24 +1030 Received: by cancey.narf.ssji.net (sSMTP sendmail emulation); Sun, 15 Mar 2015 20:07:22 +1100 Date: Sun, 15 Mar 2015 20:07:22 +1100 From: Olivier Mehani To: taps@ietf.org Message-ID: <20150315090722.GA5406@cancey.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline X-Accept-Language: fr, en, es OpenPGP: id=4435CF6A7C8DDD9BE2DEF5F9F012A6E298C66655; preference=signencrypt; url=https://olivier.mehani.name/olivier.mehani.pgp.asc User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Ralph Holz Subject: [Taps] (D)TLS: Where shall we stop when considering features? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 09:07:28 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I noticed that draft-ietf-taps-transports-xx had a section about TLS. This makes sense as it provides an end-to-end encryption feature. However, this is not all. TLS also provides mechanisms for the authentication of endpoints (through, e.g., certificates or shared keys). This is not a feature that is usually found in transport protocols, or at least the other being reviewed. Hence my question: where shall we stop when considering transport features? Does authentication have its place there, or should we rule it out? And if we rule it out, what is the criterion for doing so? Without much thinking, I think there is value in considering authentication as a transport feature, but I'm afraid this might incur some unneeded complexity. That said, if nobody has spoken up for section 3.8, Ralph Holz (Cc'd) and I would like to volunteer to write it up. --=20 Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. --5vNYLRcllDrimb99 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJVBUvGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyQkQxRkUwMkM5ODdENDM4QTMzNkZEMkFB RENGNzJFMDZEQkMzMDU3AAoJEK3PcuBtvDBXlVwH/1f4b0PHtTW2XkpDzpqIBase Vpmx2BZ4D8fFKp2ugQZPoFd1ArIxOrwROQi0HHtArFF/Nl4cuy3BdY/VAUAr7SeO egLTrk+MX/tOTKH3731I6JTfXcF+lPnkky+W0s4nJUTora+4cGR3Tc1jokEs6TLy 9dQF5GtnHNNy3WoS/UUvAYMuu1PkZJq36fxzs9qv81h4v/2qCUjfQmRaIenX2mjJ nPNUK7LhvXFWetPE0oNzZfdSay4CYA9qqYA45c9Kd9WH46TjYTCQg+bmWFosngRM kpb/VbPnlbrO9b3z8q6iiRPmchbLaNgw217029z2t44DbZ11M8gXA1alvgtEwaE= =VvoZ -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From nobody Sun Mar 15 04:44:25 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58A61A036B for ; Sun, 15 Mar 2015 04:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ0ftg0O27_E for ; Sun, 15 Mar 2015 04:44:21 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715D61A037D for ; Sun, 15 Mar 2015 04:44:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4ABF2D9307; Sun, 15 Mar 2015 12:44:19 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k5FLoh1Z6F3p; Sun, 15 Mar 2015 12:44:19 +0100 (MET) Received: from mirjas-air.fritz.box (stgt-4d02daf5.pool.mediaWays.net [77.2.218.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D7255D9302; Sun, 15 Mar 2015 12:44:18 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <20150315090722.GA5406@cancey.fritz.box> Date: Sun, 15 Mar 2015 12:44:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4AA3E1F0-5827-4B50-AEA5-08ABECC7E274@tik.ee.ethz.ch> References: <20150315090722.GA5406@cancey.fritz.box> To: Olivier Mehani X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Ralph Holz , taps@ietf.org Subject: Re: [Taps] (D)TLS: Where shall we stop when considering features? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 11:44:23 -0000 Hi Olivier, the quick answer for now is that section 3 should describe everything = that is current in the protocol, while section 4 will later on discuss = what should be there (and what should be exposed to the higher layer). You can go for section 3.8 (incl. authentication); it=E2=80=99s not = taken yet. Thanks! However, I personally see authentication as something that can be a = transport feature as transport is end-to-end and therefore it=E2=80=99s = useful to some certainty that you speak to the right end. But you also = might have authentication on different layer (alternatively or in = addition) e.g. if you=E2=80=99d connect some information with user = account. Mirja > Am 15.03.2015 um 10:07 schrieb Olivier Mehani = : >=20 > Hi all, >=20 > I noticed that draft-ietf-taps-transports-xx had a section about TLS. > This makes sense as it provides an end-to-end encryption feature. > However, this is not all. TLS also provides mechanisms for the > authentication of endpoints (through, e.g., certificates or shared > keys). >=20 > This is not a feature that is usually found in transport protocols, or > at least the other being reviewed. Hence my question: where shall we > stop when considering transport features? Does authentication have its > place there, or should we rule it out? And if we rule it out, what is > the criterion for doing so? >=20 > Without much thinking, I think there is value in considering > authentication as a transport feature, but I'm afraid this might incur > some unneeded complexity. >=20 > That said, if nobody has spoken up for section 3.8, Ralph Holz (Cc'd) > and I would like to volunteer to write it up. >=20 > --=20 > Olivier Mehani > PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 > Confidentiality cannot be guaranteed on emails sent or received = unencrypted. > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Mar 16 04:52:41 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFA41A01F6 for ; Mon, 16 Mar 2015 04:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 wjrrnvH5oX_w for ; Mon, 16 Mar 2015 04:52:38 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 892D61A86F2 for ; Mon, 16 Mar 2015 04:52:38 -0700 (PDT) Received: by igbue6 with SMTP id ue6so38782030igb.1 for ; Mon, 16 Mar 2015 04:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=4pVoWZW89zd72bEAmw4QyLrXV1C+lsAKVT/LfzAj/2c=; b=QBeemN/WE+Lgtn8a824ql8uJ5CIhNvdDzhGaN2UhbJRexGkkCoxSOGRxcV3kOq6NbQ ZqZ6fkhd9aguUYfXqDsVgo6y1MCCsCECxAOANTPovwOB2SsIoU90Z8S2nR3fxuTi/DI8 J4D+pYwpXW3H3yrbw/s4Dr01oWguwFgh0qcek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=4pVoWZW89zd72bEAmw4QyLrXV1C+lsAKVT/LfzAj/2c=; b=OKrk6KtmlYGTlgb+QcsQ1uV4gJ43pag7EKA41dWM3+D0fwcKgjKPL/5vjNrJG75VYp FAL5m90QzSfdpx5wP1Zg2lN0okeDgxmCWv7924OVU+Zx0v5NeSnLO8LRxKEOGLouXcMb QT/E67m16dzzLKw3QSsKTDfvx/QauCwZXiZqYe7IA62tQ137jgObrC1U7C6xMHRRxfT2 0lAhrIu4A+/H5F/3K3fkCMr8l5uv91afs5peEd6Rn89k6Przqb99N+p5ooKqXr2HDAS4 pXcYImcqMDOxjWWhy2bn7GpYdZXYS0iJdPgMBtPbWyKkHoHhQfiEjg5+fJrQriIhnW0Q zPbA== X-Gm-Message-State: ALoCoQkhh2k/AdL7ryaRlKUmqj98Kv+4gFUiqUL0C3sAE+w6cFX06p74fcAJGL2F2IU+WOkfXmwHr/ymS5X/4s9VMMLlKpDXXDjX5FTvpKFvzHFLZ+xHkqw= X-Received: by 10.43.69.68 with SMTP id yb4mr65088797icb.96.1426506758037; Mon, 16 Mar 2015 04:52:38 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> <54F9809F.9050209@tik.ee.ethz.ch> In-Reply-To: <54F9809F.9050209@tik.ee.ethz.ch> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKvThym5J1vmzSMp6mC2fxE/Z4K3gH5iz5tAdDRTjMCPNu5JQG2L7kkAVTNjyebGJC50A== Date: Mon, 16 Mar 2015 12:52:37 +0100 Message-ID: <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Olivier Mehani Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: Simone Ferlin-Oliveira , taps WG Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 11:52:40 -0000 Hi Mirja, >>> >>> Having said this, I'd like to first see a complete section (3.2) on >>> MPTCP before we start to writing something on this in section 4. >>> However, I'm sure you could also help to provide some text in section >>> 3.2...? That would be great! >> >> Yes, that was the plan. I think the API for both SCTP and MPTCP are >> relevant in highlighting the underlying features of the protocol, even >> though these APIs are not what needs to be described. > >Yep. APIs should not be discussed in section 4. However, for the protocol >description in section 3, if you look at the other descriptions, there is also a >subsection on the (higher layer) interface. As you say there is often a strong >dependency therefore I think there is a purpose to describe the interface as >well (in section 3) to have a ground truth for discussion. > >> >> The synthesis in section 4 should come at a later stage, once 3.2 (and >> perhaps a similar discussion in SCTP's section), have been written up. > >Yes! > [Karen ] Do you here refer to SCTP MH or CMT SCTP ? MPTCP include concurrency aspects which, for SCTP, only significantly arise with CMT SCTP. It has previously been stated that CMT SCTP would not be in scope of taps. Is that still the assumption ? BR, Karen >Mirja > > >> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > >_______________________________________________ >Taps mailing list >Taps@ietf.org >https://www.ietf.org/mailman/listinfo/taps From nobody Mon Mar 16 06:07:24 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439521A871A for ; Mon, 16 Mar 2015 06:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqJg1ko-f3wS for ; Mon, 16 Mar 2015 06:07:20 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39121A8735 for ; Mon, 16 Mar 2015 06:07:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 69688D9304; Mon, 16 Mar 2015 14:07:18 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nXFO34K-y709; Mon, 16 Mar 2015 14:07:18 +0100 (MET) Received: from mirjas-air.fritz.box (stgt-4d02c7da.pool.mediaways.net [77.2.199.218]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id F07FFD9302; Mon, 16 Mar 2015 14:07:17 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> Date: Mon, 16 Mar 2015 14:07:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <044EBB7A-82B5-45AF-8C67-A27299C00756@tik.ee.ethz.ch> References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> <54F9809F.9050209@tik.ee.ethz.ch> <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Simone Ferlin-Oliveira , taps WG , Olivier Mehani Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:07:23 -0000 Hi Karen, section 3 should describe what currently is standardized. Am I right = that there is no RFC on CMT SCTP (yet)=E2=80=A6 and that this was/is the = reason that there was some discussion that this is out of scope? If so, = what the status of CMT SCTP? Will there be potentially be an RFC anytime = soon? However, in section 3 if there are any similarities to MPTCP in SCTP, = either in MH or CMT, these could be described in a similar way and = potentially even refer to MPTCP or the other way around. If SCTP is = described independent of MPTCP that=E2=80=99s fine as well, or = potentially even better for the start. As soon as we then start writing = section 4, we anyway to have to detect those similarities and can still = add references or adapt the wording to use the same term later on. Mirja > Am 16.03.2015 um 12:52 schrieb Karen Elisabeth Egede Nielsen = : >=20 > Hi Mirja, >=20 >>>>=20 >>>> Having said this, I'd like to first see a complete section (3.2) on >>>> MPTCP before we start to writing something on this in section 4. >>>> However, I'm sure you could also help to provide some text in = section >>>> 3.2...? That would be great! >>>=20 >>> Yes, that was the plan. I think the API for both SCTP and MPTCP are >>> relevant in highlighting the underlying features of the protocol, = even >>> though these APIs are not what needs to be described. >>=20 >> Yep. APIs should not be discussed in section 4. However, for the = protocol >> description in section 3, if you look at the other descriptions, = there is > also a >> subsection on the (higher layer) interface. As you say there is often = a > strong >> dependency therefore I think there is a purpose to describe the = interface > as >> well (in section 3) to have a ground truth for discussion. >>=20 >>>=20 >>> The synthesis in section 4 should come at a later stage, once 3.2 = (and >>> perhaps a similar discussion in SCTP's section), have been written = up. >>=20 >> Yes! >>=20 > [Karen ] Do you here refer to SCTP MH or CMT SCTP ? >=20 > MPTCP include concurrency aspects which, for SCTP, only significantly > arise with CMT SCTP. >=20 > It has previously been stated that CMT SCTP would not be in scope of = taps. > Is that still the assumption ? >=20 > BR, Karen >=20 >> Mirja >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps From nobody Mon Mar 16 06:22:12 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42161A8745 for ; Mon, 16 Mar 2015 06:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 tNQQbLxrHaAL for ; Mon, 16 Mar 2015 06:22:09 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2691A8742 for ; Mon, 16 Mar 2015 06:22:07 -0700 (PDT) Received: from [192.168.1.200] (p508F1699.dip0.t-ipconnect.de [80.143.22.153]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9AEE81C0B3E6F; Mon, 16 Mar 2015 14:22:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <044EBB7A-82B5-45AF-8C67-A27299C00756@tik.ee.ethz.ch> Date: Mon, 16 Mar 2015 14:22:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7F7DD708-75CD-4778-AAB1-96A9C76CDD68@lurchi.franken.de> References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> <54F9809F.9050209@tik.ee.ethz.ch> <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> <044EBB7A-82B5-45AF-8C67-A27299C00756@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Karen Elisabeth Egede Nielsen , Simone Ferlin-Oliveira , Olivier Mehani , taps WG Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:22:12 -0000 > On 16 Mar 2015, at 14:07, Mirja K=C3=BChlewind = wrote: >=20 > Hi Karen, >=20 > section 3 should describe what currently is standardized. Am I right = that there is no RFC on CMT SCTP (yet)=E2=80=A6 and that this was/is the = reason that there was some discussion that this is out of scope? If so, = what the status of CMT SCTP? Will there be potentially be an RFC anytime = soon? Hi Mirja, this is an interesting question. It is not yet a WG document and the = last time I asked for WG adoption, the question by the chairs was who would the consumer = of the document be? A lot of people involved in implementing this in FreeBSD, the ns-2 = and the INET simulator are already co-authors. I tried to get some support for stack vendors, but none of them wanted = to make statements about future products. If there is a chance to progress this in TSVWG as a WG document, we = would be interested, but I don't see why I should get a different answer when asking the same = question again without having a relevant list of some "consumers" of the potential RFC. Best regards Michael >=20 > However, in section 3 if there are any similarities to MPTCP in SCTP, = either in MH or CMT, these could be described in a similar way and = potentially even refer to MPTCP or the other way around. If SCTP is = described independent of MPTCP that=E2=80=99s fine as well, or = potentially even better for the start. As soon as we then start writing = section 4, we anyway to have to detect those similarities and can still = add references or adapt the wording to use the same term later on. >=20 > Mirja >=20 >=20 >=20 >> Am 16.03.2015 um 12:52 schrieb Karen Elisabeth Egede Nielsen = : >>=20 >> Hi Mirja, >>=20 >>>>>=20 >>>>> Having said this, I'd like to first see a complete section (3.2) = on >>>>> MPTCP before we start to writing something on this in section 4. >>>>> However, I'm sure you could also help to provide some text in = section >>>>> 3.2...? That would be great! >>>>=20 >>>> Yes, that was the plan. I think the API for both SCTP and MPTCP are >>>> relevant in highlighting the underlying features of the protocol, = even >>>> though these APIs are not what needs to be described. >>>=20 >>> Yep. APIs should not be discussed in section 4. However, for the = protocol >>> description in section 3, if you look at the other descriptions, = there is >> also a >>> subsection on the (higher layer) interface. As you say there is = often a >> strong >>> dependency therefore I think there is a purpose to describe the = interface >> as >>> well (in section 3) to have a ground truth for discussion. >>>=20 >>>>=20 >>>> The synthesis in section 4 should come at a later stage, once 3.2 = (and >>>> perhaps a similar discussion in SCTP's section), have been written = up. >>>=20 >>> Yes! >>>=20 >> [Karen ] Do you here refer to SCTP MH or CMT SCTP ? >>=20 >> MPTCP include concurrency aspects which, for SCTP, only significantly >> arise with CMT SCTP. >>=20 >> It has previously been stated that CMT SCTP would not be in scope of = taps. >> Is that still the assumption ? >>=20 >> BR, Karen >>=20 >>> Mirja >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Mar 16 06:42:13 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B711F1A874A for ; Mon, 16 Mar 2015 06:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJgJcvDlgZaK for ; Mon, 16 Mar 2015 06:42:10 -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 141F51A8752 for ; Mon, 16 Mar 2015 06:42:10 -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 82A481B000E1; Mon, 16 Mar 2015 13:42:25 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 16 Mar 2015 13:41:42 -0000 Message-ID: In-Reply-To: <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> <54F9809F.9050209@tik.ee.ethz.ch> <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> Date: Mon, 16 Mar 2015 13:41:42 -0000 From: gorry@erg.abdn.ac.uk To: "Karen Elisabeth Egede Nielsen" 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: Simone Ferlin-Oliveira , taps WG , =?iso-8859-1?Q?=22Mirja_K=C3=BChlewind=22?= , Olivier Mehani Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:42:11 -0000 See below > Hi Mirja, > >>>> >>>> Having said this, I'd like to first see a complete section (3.2) on >>>> MPTCP before we start to writing something on this in section 4. >>>> However, I'm sure you could also help to provide some text in section >>>> 3.2...? That would be great! >>> >>> Yes, that was the plan. I think the API for both SCTP and MPTCP are >>> relevant in highlighting the underlying features of the protocol, even >>> though these APIs are not what needs to be described. >> >>Yep. APIs should not be discussed in section 4. However, for the protocol >>description in section 3, if you look at the other descriptions, there is > also a >>subsection on the (higher layer) interface. As you say there is often a > strong >>dependency therefore I think there is a purpose to describe the interface > as >>well (in section 3) to have a ground truth for discussion. >> >>> >>> The synthesis in section 4 should come at a later stage, once 3.2 (and >>> perhaps a similar discussion in SCTP's section), have been written up. >> >>Yes! >> > [Karen ] Do you here refer to SCTP MH or CMT SCTP ? > > MPTCP include concurrency aspects which, for SCTP, only significantly > arise with CMT SCTP. > > It has previously been stated that CMT SCTP would not be in scope of taps. > Is that still the assumption ? > > BR, Karen > >>Mirja >> I think SCTP multihoming and path failover should be there. I personally think that formal discussion of SCTP/ CMT falls outside the scope of TAPS, until the IETF decides to adopt this work (that's for TSVWG sometime). However, I guess if TAPS wanted to refer to a paper on the possibility of such extensions to SCTP in the discussion section that could easily be considered. Gorry From nobody Mon Mar 16 07:05:42 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0873C1A8782 for ; Mon, 16 Mar 2015 07:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkAgxwnlJfmT for ; Mon, 16 Mar 2015 07:05:38 -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 6154F1A879B for ; Mon, 16 Mar 2015 07:05:11 -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 3BF6C1B000E1; Mon, 16 Mar 2015 14:05:26 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 16 Mar 2015 14:04:43 -0000 Message-ID: <9eb722cb685a65753d86c5367eaeabf4.squirrel@erg.abdn.ac.uk> In-Reply-To: <7F7DD708-75CD-4778-AAB1-96A9C76CDD68@lurchi.franken.de> References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> <54F9809F.9050209@tik.ee.ethz.ch> <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> <044EBB7A-82B5-45AF-8C67-A27299C00756@tik.ee.ethz.ch> <7F7DD708-75CD-4778-AAB1-96A9C76CDD68@lurchi.franken.de> Date: Mon, 16 Mar 2015 14:04:43 -0000 From: gorry@erg.abdn.ac.uk To: "Michael Tuexen" 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: Karen Elisabeth Egede Nielsen , Simone Ferlin-Oliveira , taps WG , =?iso-8859-1?Q?=22Mirja_K=C3=BChlewind=22?= , Olivier Mehani Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 14:05:41 -0000 Se below >> On 16 Mar 2015, at 14:07, Mirja Kühlewind >> wrote: >> >> Hi Karen, >> >> section 3 should describe what currently is standardized. Am I right >> that there is no RFC on CMT SCTP (yet)… and that this was/is the >> reason that there was some discussion that this is out of scope? If so, >> what the status of CMT SCTP? Will there be potentially be an RFC anytime >> soon? > Hi Mirja, > > this is an interesting question. It is not yet a WG document and the last > time I asked > for WG adoption, the question by the chairs was who would the consumer of > the document > be? A lot of people involved in implementing this in FreeBSD, the ns-2 and > the INET > simulator are already co-authors. > I tried to get some support for stack vendors, but none of them wanted to > make statements > about future products. > > If there is a chance to progress this in TSVWG as a WG document, we would > be interested, > but I don't see why I should get a different answer when asking the same > question again > without having a relevant list of some "consumers" of the potential RFC. > > Best regards > Michael > As tswg co-chair: that is more or less what I recall. Importantly: There was no decision that this was outside the charter. So, if there are developments or indications of greater maturity, then tsvwg could revisit this and revive the work - but I'd expect the same questions to be asked by the Chairs. Gorry (with tsvwg chair hat upon my head) >> >> However, in section 3 if there are any similarities to MPTCP in SCTP, >> either in MH or CMT, these could be described in a similar way and >> potentially even refer to MPTCP or the other way around. If SCTP is >> described independent of MPTCP that’s fine as well, or potentially >> even better for the start. As soon as we then start writing section 4, >> we anyway to have to detect those similarities and can still add >> references or adapt the wording to use the same term later on. >> >> Mirja >> >> >> >>> Am 16.03.2015 um 12:52 schrieb Karen Elisabeth Egede Nielsen >>> : >>> >>> Hi Mirja, >>> >>>>>> >>>>>> Having said this, I'd like to first see a complete section (3.2) on >>>>>> MPTCP before we start to writing something on this in section 4. >>>>>> However, I'm sure you could also help to provide some text in >>>>>> section >>>>>> 3.2...? That would be great! >>>>> >>>>> Yes, that was the plan. I think the API for both SCTP and MPTCP are >>>>> relevant in highlighting the underlying features of the protocol, >>>>> even >>>>> though these APIs are not what needs to be described. >>>> >>>> Yep. APIs should not be discussed in section 4. However, for the >>>> protocol >>>> description in section 3, if you look at the other descriptions, there >>>> is >>> also a >>>> subsection on the (higher layer) interface. As you say there is often >>>> a >>> strong >>>> dependency therefore I think there is a purpose to describe the >>>> interface >>> as >>>> well (in section 3) to have a ground truth for discussion. >>>> >>>>> >>>>> The synthesis in section 4 should come at a later stage, once 3.2 >>>>> (and >>>>> perhaps a similar discussion in SCTP's section), have been written >>>>> up. >>>> >>>> Yes! >>>> >>> [Karen ] Do you here refer to SCTP MH or CMT SCTP ? >>> >>> MPTCP include concurrency aspects which, for SCTP, only significantly >>> arise with CMT SCTP. >>> >>> It has previously been stated that CMT SCTP would not be in scope of >>> taps. >>> Is that still the assumption ? >>> >>> BR, Karen >>> >>>> Mirja >>>> >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>> >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Mon Mar 16 13:40:09 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8741A90E2 for ; Mon, 16 Mar 2015 13:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 qpOjJGi1vy7A for ; Mon, 16 Mar 2015 13:40:06 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 31D6A1A90E6 for ; Mon, 16 Mar 2015 13:40:03 -0700 (PDT) Received: by igbue6 with SMTP id ue6so53197027igb.1 for ; Mon, 16 Mar 2015 13:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=CNP1tcgY991YlrF+z5yxOytNnzv1QWwvp23wKf+uOAo=; b=nkU+N9PbALTSAHi+c8R9RPerdKb9YCpYHsymPriW1i2+1ea6Q2H9bC71xAYA8LjEmq 2gDpi4FaZnrcxuDtv3/lDM+0SpIWqIFzV6/wDEc/pcF90DggSp16wS6ESjyKNbdNC+Mu x8O2Lg+aEdt69GUTezavJBh4isHKGcMVzzNRE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=CNP1tcgY991YlrF+z5yxOytNnzv1QWwvp23wKf+uOAo=; b=LNJaahHRGjRQJpmNgOH3He4hAj9xfhya43UdjUI8mnNB0XBmkEe5cYbucX5KBBHjiD DO21kxGgXd4linRRcHvufnrtVaRXaw/nTYAXwoVf+oYua6cCRwFU2ONV6kmdq73W46x1 ZZFO4DL8Xd4Hux2n1MJY24UxdPFAzNSXNDaIfYDld+y/JlvfFV0OE9cCC3ULRqMmnk9O YyQgj73ObsPBVKfDj2I/ukhp+M0QxlKxkVl1E1bd+QFuP5j6/AXOEoRfide11eYEFuPV Y/x2ICGxz/L7RWppPS4Aw5GMtYuxgSfH4T6EhRezC8iyDzms5OBP1YcR0wqpe90Na82J m72w== X-Gm-Message-State: ALoCoQk4PBKXRhYA5XqBSvyeCefeHQuIbeLa9HG1NvwW7cUAxb2pS6uCxe3cKPYZ/PX58UOCe4THtuRcne2R1XjiPrudderP7r5FDhe14ECRaTC3cQR+EDU= X-Received: by 10.42.89.72 with SMTP id f8mr58750247icm.24.1426538402683; Mon, 16 Mar 2015 13:40:02 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> <54F83CA9.8040702@tik.ee.ethz.ch> <20150305233329.GB24287@blasturvion.dynhost.nicta.com.au> <54F9809F.9050209@tik.ee.ethz.ch> <7ef13c6d777e5a5f6c95737bca43e80e@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKvThym5J1vmzSMp6mC2fxE/Z4K3gH5iz5tAdDRTjMCPNu5JQG2L7kkAVTNjycB/UMiJQLyrO4YmvGaB5A= Date: Mon, 16 Mar 2015 21:40:01 +0100 Message-ID: <7f4a031db9a10124475b020a7e2c2d64@mail.gmail.com> To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: Simone Ferlin-Oliveira , taps WG , =?UTF-8?B?Ik1pcmphIEvDg8K8aGxld2luZCI=?= , Olivier Mehani Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 20:40:08 -0000 HI, See below. >-----Original Message----- >From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >Sent: Monday, March 16, 2015 2:42 PM >To: Karen Elisabeth Egede Nielsen >Cc: "Mirja K=C3=BChlewind"; Olivier Mehani; Simone Ferlin-Oliveira; taps W= G >Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps- >transports-03.txt > >See below > >> Hi Mirja, >> >>>>> >>>>> Having said this, I'd like to first see a complete section (3.2) on >>>>> MPTCP before we start to writing something on this in section 4. >>>>> However, I'm sure you could also help to provide some text in >>>>> section 3.2...? That would be great! >>>> >>>> Yes, that was the plan. I think the API for both SCTP and MPTCP are >>>> relevant in highlighting the underlying features of the protocol, >>>> even though these APIs are not what needs to be described. >>> >>>Yep. APIs should not be discussed in section 4. However, for the >>>protocol description in section 3, if you look at the other >>>descriptions, there is >> also a >>>subsection on the (higher layer) interface. As you say there is often >>>a >> strong >>>dependency therefore I think there is a purpose to describe the >>>interface >> as >>>well (in section 3) to have a ground truth for discussion. >>> >>>> >>>> The synthesis in section 4 should come at a later stage, once 3.2 >>>> (and perhaps a similar discussion in SCTP's section), have been written up. >>> >>>Yes! >>> >> [Karen ] Do you here refer to SCTP MH or CMT SCTP ? >> >> MPTCP include concurrency aspects which, for SCTP, only significantly >> arise with CMT SCTP. >> >> It has previously been stated that CMT SCTP would not be in scope of taps. >> Is that still the assumption ? >> >> BR, Karen >> >>>Mirja >>> > >I think SCTP multihoming and path failover should be there. > >I personally think that formal discussion of SCTP/ CMT falls outside the scope >of TAPS, until the IETF decides to adopt this work (that's for TSVWG >sometime). However, I guess if TAPS wanted to refer to a paper on the >possibility of such extensions to SCTP in the discussion section that could >easily be considered. > [Karen ] I would definitively support that such references be made. Provided, of course, that such becomes relevant and meaningful in the context of Multi Path discussions in taps. I agree that we still have to wait and see for when CMT-SCTP makes it to the top of things to progress in tsvwg. BR, Karen >Gorry > From nobody Mon Mar 16 14:09:54 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6786E1A90FA for ; Mon, 16 Mar 2015 14:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 1pwyMeNH32LP for ; Mon, 16 Mar 2015 14:09:51 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (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 ADFCF1A90F7 for ; Mon, 16 Mar 2015 14:09:51 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so181857614iec.1 for ; Mon, 16 Mar 2015 14:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=4waBUHKOqjxpQj9P6rSnfn/Ux1tIQDWUpBXulDZ3jJw=; b=aAo348Jx27WIkmyuORjbLXnzIaIT73+7JL+xKkFIB8ro2s6Ci8RfOmo0e5XUFFb5Bi ajS8Y7ahic3xZ8fvqqfjlV4/LIuilIdZqARhz5zXRyKnUd68sTkf3vYVAt7w33QA8Xzh lNJRMpTe6VbwUhEY367T8z+ruiwusIrAsxSEk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=4waBUHKOqjxpQj9P6rSnfn/Ux1tIQDWUpBXulDZ3jJw=; b=Sy5q+AAzuqeUP/T/tcuJ1Ozuidy9NRGo+B4Iu+fGx/lnQUWzy3jauaawYv2zMNrwOr 3Lz/evjyEyI154zvoS5BzGdw1K+2N19+CmdISZsOQXllhtS33H9p9aGNIOnfmhzSNQOM ughzobZK1B+JUfEZz2ZjvoSsNHmgIQkx3rpQTkaXJWQjqN8R7/OJ7UmXIUofP++MJsVM ra2YJOPRAlIrXv8hu32+Aofeb7meutwhGDYCBYgvb1BYCn5tvVCcA4//HH6oJnxBNPad mMCewB71tTNBkIgxXl4Y3pLUsDBTy6sS1KUNQfFnoS3RAwwYssDvDnRT9/8jeLmiwaYA ap3Q== X-Gm-Message-State: ALoCoQlGbP+SwKUdKW/LDOTExS8aws9R4YU5pZ6LmA4+rdz5YeUqJ5AnmNaiEX6OQ0AMW+RuQ4/6RwrMJALVfpmEYaLXRpkOOavU7DWq1cxIKULWzsxFjKs= X-Received: by 10.42.89.72 with SMTP id f8mr58962385icm.24.1426540191103; Mon, 16 Mar 2015 14:09:51 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150207120702.11245.33712.idtracker@ietfa.amsl.com> <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> <54D8E4C6.9040903@erg.abdn.ac.uk> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGmtw42wWVTLzBUgj5hXLcAUi5cYgHcofVgAczL2hICbS6RnJ1CL+uQ Date: Mon, 16 Mar 2015 22:09:50 +0100 Message-ID: To: Michael Tuexen , Gorry Fairhurst Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:09:53 -0000 Hi, Do we actually know what we mean by "Mode" and by the terms "dgram" and "stream" in this respect ? I personally lost track of what this meant exactly when we moved beyond TCP and UDP. Some more comments to the table - I think that the following features are missing: * reliable unordered delivery * unreliable unordered delivery BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Tuexen >Sent: Tuesday, February 10, 2015 8:06 PM >To: Gorry Fairhurst >Cc: taps WG >Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-02.txt > >> On 09 Feb 2015, at 17:48, Gorry Fairhurst wrote: >> >> >> >> This version includes my first go at a table, in section 4.1, I'm hoping this will >stimulate some input/corrections, or even perhaps alternate list of what to >see here. Please discuss, or send comments via the TAPS list. >Hi Gorry, > >maybe I didn't understand the table entries correctly, but I think the following >changes improve the description of SCTP: >https://github.com/britram/taps-transports/pull/1 > >* SCTP is message oriented, so Dgram seems to be more appropriate than >Stream. >* Bundling of DATA chunks and the Nagle algorithm is supported, so multiple > user messages can fit into a single IP packet. >* ECN support needs to be clarified. > >Best regards >Michael >> >> gorry >> >> >> >> straw On 07/02/2015 12:41, Brian Trammell wrote: >>> Greetings, all, >>> >>> We've submitted the -02 rev of the transports document, addressing >comments to date and including additional content for some of the transport >protocols. >>> >>> Markdown (kramdown-rfc2629) source and toolchain is available at >https://github.com/britram/taps-transports. Subsection authors: feel free to >send pull requests against either the markdown or XML source (we'll convert >the latter back to the former) or text to the editors via email. We'd like to get >at least one more rev of the document out before Dallas. >>> >>> Not-yet-subsection-authors who would like to contribute: there are a >couple of sections we'd like to have (HTTP(S) as a pseudotransport, and >WebSockets which removes some of the "pseudo" therefrom) that don't yet >have contributors associated; additionally, if there are transport (or transport- >like) protocols we're missing here, please send text and we'll get it integrated. >>> >>> Many thanks, best regards, >>> >>> Brian (for the editors of taps-transports). >>> >>>> Begin forwarded message: >>>> >>>> From: internet-drafts@ietf.org >>>> To: >>>> Date: 7 Feb 2015 13:07:02 CET >>>> Cc: taps@ietf.org >>>> Subject: [Taps] I-D Action: draft-ietf-taps-transports-02.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >>>> This draft is a work item of the Transport Services Working Group of the >IETF. >>>> >>>> Title : Services provided by IETF transport protocols and >congestion control mechanisms >>>> Authors : Godred Fairhurst >>>> Brian Trammell >>>> Mirja Kuehlewind >>>> Filename : draft-ietf-taps-transports-02.txt >>>> Pages : 20 >>>> Date : 2015-02-07 >>>> >>>> Abstract: >>>> This document describes services provided by existing IETF protocols >>>> and congestion control mechanisms. It is designed to help >>>> application and network stack programmers and to inform the work of >>>> the IETF TAPS Working Group. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-taps-transports-02 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-02 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>> >>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > >_______________________________________________ >Taps mailing list >Taps@ietf.org >https://www.ietf.org/mailman/listinfo/taps From nobody Mon Mar 16 15:54:19 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956821ACCF6 for ; Mon, 16 Mar 2015 15:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 CkRuqHmDbxCj for ; Mon, 16 Mar 2015 15:54:15 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 89A651ACCF3 for ; Mon, 16 Mar 2015 15:54:15 -0700 (PDT) Received: by iegc3 with SMTP id c3so187694391ieg.3 for ; Mon, 16 Mar 2015 15:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to :content-type; bh=YoCBZPo80oFq7jJpgrHn443pGtHwoj28Zd6ptEEf/tU=; b=aHk2YdmRw/VlsHNompVdNuIZSbBTQDhj9r+kw0+7Zal1Zmi9+Gaibj4MUvDIKHLf4+ M6+nFN79pc3Gv9UfOAC0fupEWepZOago5Q1B/rUVdNorIOBwNVkJbpT1PoVQ8MhtOHAR jgmdMmc2AQFuBUSNqYYkhCvn2z9rQvCflM3NQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=YoCBZPo80oFq7jJpgrHn443pGtHwoj28Zd6ptEEf/tU=; b=IxpWmthICUGYrJSgiO5uxuUl0vKzmn7zrbtkzA85yWJDYCkWHCz1RxBakZeVoltzcF /EafOcOUJNoH2liFA1l8OVZ71vYkU3HrrbYpphdISv/JJkmOkCZs1njJb1m3fJLWQoMl yjksJRCiKDsb3JrqSrj7tw1ble1LVNSyTG8Fc3WOt3rC5qsnOKg9yR9rSq3ocZy12ZFo FlyOVEu67/szm6M6+RtgCoqAp6sQvSxNFwoRy4ppB0/srRh35r/8WTiSlUpftzye2IgB 9/x9iMs5KMb3dlGrwsbROBiJ6ngvK4F8FyYKZintxLd/FVHWSfXsqWB/4ToNiF6ZQGIv AIwg== X-Gm-Message-State: ALoCoQnrD5Jcztx1m1iixGUXCom8LuPSJD8awIShVsKLB7uhhsJ6h/Ru9yIcLviELwWQzxh3NdEjQYLn67rf7g5usw5NRbzKt720UU5uiyvZ1rT8lZpkc+4= X-Received: by 10.50.122.68 with SMTP id lq4mr57673181igb.10.1426546454694; Mon, 16 Mar 2015 15:54:14 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBgPBzVpPM2De3FSCOh+0k9PpJmQA== Date: Mon, 16 Mar 2015 23:54:13 +0100 Message-ID: <177f634cc32da4f8a0362080dc2e6992@mail.gmail.com> To: taps@ietf.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 22:54:17 -0000 HI, Please accept the following "minor" comments/questions to the TCP protocol components: #1: The list include both of the followings: *ordered delivery for each byte stream * stream-oriented delivery in a single stream Wouldn't it be more fair to combine these two and say: *ordered delivery in a single stream "Each stream" seems a little too much for TCP, I think. #2: Segmentation and bundling is listed as separate components, even if bundling, for TCP, is part of the segmentation process. I suppose that is as it should be, but when speaking "Bundling" then I actually think that "Bundling delay" is a better term. Especially for TCP. To put in context: For SCTP it is actually relevant to discuss bundling and bundling delay separately as two different components. Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call that bundling), but it CAN (depending on no_delay setting) implement bundling delay or not. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- >drafts@ietf.org >Sent: Friday, February 27, 2015 1:52 PM >To: i-d-announce@ietf.org >Cc: taps@ietf.org >Subject: [Taps] I-D Action: draft-ietf-taps-transports-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Services Working Group of the IETF. > > Title : Services provided by IETF transport protocols and congestion >control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-03.txt > Pages : 25 > Date : 2015-02-27 > >Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-taps-transports-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03 > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Taps mailing list >Taps@ietf.org >https://www.ietf.org/mailman/listinfo/taps From nobody Tue Mar 17 03:09:29 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDC81A01D6 for ; Tue, 17 Mar 2015 03:09:26 -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 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 FDUtEWgGEimI for ; Tue, 17 Mar 2015 03:09:24 -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 85B291A01C6 for ; Tue, 17 Mar 2015 03:09:24 -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 1YXoR8-00023K-EH; Tue, 17 Mar 2015 11:09:22 +0100 Received: from mail-ex14.exprod.uio.no ([129.240.120.76]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YXoR6-0004YT-Rf; Tue, 17 Mar 2015 11:09:21 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex14.exprod.uio.no (2001:700:100:120::76) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 17 Mar 2015 11:09:20 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.1044.021; Tue, 17 Mar 2015 11:09:20 +0100 From: Michael Welzl To: Karen Elisabeth Egede Nielsen Thread-Topic: [Taps] I-D Action: draft-ietf-taps-transports-03.txt Thread-Index: AdBgPBzVpPM2De3FSCOh+0k9PpJmQAAVe9cA Date: Tue, 17 Mar 2015 10:09:19 +0000 Message-ID: <6105C0E5-8072-4F0A-8C61-A52DBD353997@ifi.uio.no> References: <177f634cc32da4f8a0362080dc2e6992@mail.gmail.com> In-Reply-To: <177f634cc32da4f8a0362080dc2e6992@mail.gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <669B324F4A81DF44A103929143929CFA@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 8 sum msgs/h 2 total rcpts 26466 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F860C9475E84515F7402F66755BF28E0B7F0F5D4 X-UiO-SPAM-Test: remote_host: 129.240.120.76 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 54 total 646118 max/h 441 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 10:09:27 -0000 Hi, > On 16 Mar 2015, at 23:54, Karen Elisabeth Egede Nielsen wrote: >=20 > HI, >=20 > Please accept the following "minor" comments/questions to the TCP protoco= l > components: >=20 > #1: > The list include both of the followings: >=20 > *ordered delivery for each byte stream > * stream-oriented delivery in a single stream >=20 > Wouldn't it be more fair to combine these two and say: >=20 > *ordered delivery in a single stream >=20 > "Each stream" seems a little too much for TCP, I think. >=20 > #2: > Segmentation and bundling is listed as separate components, even if > bundling, for TCP, is part of the segmentation process. > I suppose that is as it should be, but when speaking "Bundling" then I > actually think that "Bundling delay" is a better term. Especially for TCP= . >=20 > To put in context: > For SCTP it is actually relevant to discuss bundling and bundling delay > separately as two different components. > Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call that > bundling), but it CAN (depending on no_delay setting) implement bundling > delay or not. So how does bundling without delaying work? Cheers, Michael From nobody Tue Mar 17 04:26:24 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3BE1A036F for ; Tue, 17 Mar 2015 04:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 RhmkH85bIruV for ; Tue, 17 Mar 2015 04:26:17 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 1E8171A0266 for ; Tue, 17 Mar 2015 04:26:15 -0700 (PDT) Received: by igbue6 with SMTP id ue6so67715476igb.1 for ; Tue, 17 Mar 2015 04:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=W5vM+EKFP5U+kf/Ybka12cSsAd9HTPYeHjRk3d/NoGc=; b=nYONfU5Yppk0mXO9h92YWbas9ugMMmL7XiIGeZAOtyH3j2CSBzVBBgrFk8/mHI4U+t ppqJ4d5Q5YUfZ4pB0L/x8/nUXqgbVuC7hsI0NO2KxWXJ69yc4PsJZo8MxWCNheOC+fgB +RwsjhCdtb7P3CI4jrOteelJMq8pYDcROJgBE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=W5vM+EKFP5U+kf/Ybka12cSsAd9HTPYeHjRk3d/NoGc=; b=NaRivOgafucxCd4HCwsQryL17EOzVZxnWLYm7aXoRBeeoK6m+JGViS2Yn8Rbt22fvg YGCdQ+AvQEbqkQbd8pJJPsDXtAeEVvrJA2GFSTMvK+RF3QIJ2akKXoUvjlNlCQkxYqzy qZM6hLKh2bDOAKJAK+7031Y3TFHO+vNi8kkBCTalCdPTr7AxqXBXPIhzBu7+mDuCxAsF 4Dzvngo/EpDEuVQTrv+54g2By1vP1ZMj9MlpL2XX968VM9amST6vqSMJ5unJcKNbTV59 IDXr0RG+V8kK10rYiybI4y9Mo9HFT0pMjad6Ji3rc9gqdBEmmTvi+BDpNhtFma5FQOUq JjaQ== X-Gm-Message-State: ALoCoQmVUSVrhSfYInHHpQy8CMEGryISzh8Q1/BpkmaaZatbGiwrxmkCEXKJoyU2OCS/gG+4vUDkOubizFmxj1YFo8RV/HtODUhzAHgDxMmQWi8TRa7TDBM= X-Received: by 10.50.107.36 with SMTP id gz4mr118444931igb.25.1426591575237; Tue, 17 Mar 2015 04:26:15 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <177f634cc32da4f8a0362080dc2e6992@mail.gmail.com> <6105C0E5-8072-4F0A-8C61-A52DBD353997@ifi.uio.no> In-Reply-To: <6105C0E5-8072-4F0A-8C61-A52DBD353997@ifi.uio.no> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIsOPYv6IDJfmeGN6xiO1EwyYm62wIBLfQpnFjMMHA= Date: Tue, 17 Mar 2015 12:26:14 +0100 Message-ID: <605e63ae9b8740474620c9add4ea64a3@mail.gmail.com> To: Michael Welzl Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: taps@ietf.org Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 11:26:19 -0000 Hi, >-----Original Message----- >From: Michael Welzl [mailto:michawe@ifi.uio.no] >Sent: Tuesday, March 17, 2015 11:09 AM >To: Karen Elisabeth Egede Nielsen >Cc: taps@ietf.org >Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt > >Hi, > > >> On 16 Mar 2015, at 23:54, Karen Elisabeth Egede Nielsen > wrote: >> >> HI, >> >> Please accept the following "minor" comments/questions to the TCP >> protocol >> components: >> >> #1: >> The list include both of the followings: >> >> *ordered delivery for each byte stream >> * stream-oriented delivery in a single stream >> >> Wouldn't it be more fair to combine these two and say: >> >> *ordered delivery in a single stream >> >> "Each stream" seems a little too much for TCP, I think. >> >> #2: >> Segmentation and bundling is listed as separate components, even if >> bundling, for TCP, is part of the segmentation process. >> I suppose that is as it should be, but when speaking "Bundling" then I >> actually think that "Bundling delay" is a better term. Especially for TCP. >> >> To put in context: >> For SCTP it is actually relevant to discuss bundling and bundling >> delay separately as two different components. >> Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call >> that bundling), but it CAN (depending on no_delay setting) implement >> bundling delay or not. > >So how does bundling without delaying work? > [Karen ] If there are multiple messages available for transmittal in the SND buffer. E.g., 2 messages of 600 bytes would be bundled into the same SCTP packet. This of course is only in situations where there has been congestion or receiver window blocking. For TCP this "bundling" of data bytes is part of the basic segment partitioning of the data byte stream. BR, Karen >Cheers, >Michael From nobody Tue Mar 17 05:01:43 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8191A0378 for ; Tue, 17 Mar 2015 05:01:36 -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 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 PJgfoL1MHCMJ for ; Tue, 17 Mar 2015 05:01:31 -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 24D3B1A014D for ; Tue, 17 Mar 2015 05:01:30 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YXqBd-0002qB-J8; Tue, 17 Mar 2015 13:01:29 +0100 Received: from mail-ex02.exprod.uio.no ([129.240.52.5]) by mail-mx4.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YXqBc-0004tr-W1; Tue, 17 Mar 2015 13:01:29 +0100 Received: from mail-ex03.exprod.uio.no (129.240.52.6) by mail-ex02.exprod.uio.no (129.240.52.5) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 17 Mar 2015 13:01:28 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.1044.021; Tue, 17 Mar 2015 13:01:28 +0100 From: Michael Welzl To: Karen Elisabeth Egede Nielsen Thread-Topic: [Taps] I-D Action: draft-ietf-taps-transports-03.txt Thread-Index: AdBgPBzVpPM2De3FSCOh+0k9PpJmQA== Date: Tue, 17 Mar 2015 12:01:28 +0000 Message-ID: <0EF270A5-2FC2-4B05-8928-1998AFE3FBA4@ifi.uio.no> References: <177f634cc32da4f8a0362080dc2e6992@mail.gmail.com> <6105C0E5-8072-4F0A-8C61-A52DBD353997@ifi.uio.no> <605e63ae9b8740474620c9add4ea64a3@mail.gmail.com> In-Reply-To: <605e63ae9b8740474620c9add4ea64a3@mail.gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <7059A1D683257B40AA9DAEE4B84F743D@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 10 sum msgs/h 3 total rcpts 26486 max rcpts/h 44 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: D0306676C5FB22FEA2167DB8A50EC1142B0D7B5E X-UiO-SPAM-Test: remote_host: 129.240.52.5 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 646823 max/h 446 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:01:36 -0000 > On 17 Mar 2015, at 12:26, Karen Elisabeth Egede Nielsen wrote: >=20 > Hi, >=20 >> -----Original Message----- >> From: Michael Welzl [mailto:michawe@ifi.uio.no] >> Sent: Tuesday, March 17, 2015 11:09 AM >> To: Karen Elisabeth Egede Nielsen >> Cc: taps@ietf.org >> Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt >>=20 >> Hi, >>=20 >>=20 >>> On 16 Mar 2015, at 23:54, Karen Elisabeth Egede Nielsen >> wrote: >>>=20 >>> HI, >>>=20 >>> Please accept the following "minor" comments/questions to the TCP >>> protocol >>> components: >>>=20 >>> #1: >>> The list include both of the followings: >>>=20 >>> *ordered delivery for each byte stream >>> * stream-oriented delivery in a single stream >>>=20 >>> Wouldn't it be more fair to combine these two and say: >>>=20 >>> *ordered delivery in a single stream >>>=20 >>> "Each stream" seems a little too much for TCP, I think. >>>=20 >>> #2: >>> Segmentation and bundling is listed as separate components, even if >>> bundling, for TCP, is part of the segmentation process. >>> I suppose that is as it should be, but when speaking "Bundling" then I >>> actually think that "Bundling delay" is a better term. Especially for > TCP. >>>=20 >>> To put in context: >>> For SCTP it is actually relevant to discuss bundling and bundling >>> delay separately as two different components. >>> Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call >>> that bundling), but it CAN (depending on no_delay setting) implement >>> bundling delay or not. >>=20 >> So how does bundling without delaying work? >>=20 > [Karen ] > If there are multiple messages available for transmittal in the SND > buffer. E.g., > 2 messages of 600 bytes would be bundled into the same SCTP packet. > This of course is only in situations where there has been congestion or > receiver window blocking. >=20 > For TCP this "bundling" of data bytes is part of the basic segment > partitioning of the data byte stream. Ok, thanks... yes this is indeed different from "Nagle'ing"... Cheers, Michael From nobody Tue Mar 17 05:47:12 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBBD1A038D for ; Tue, 17 Mar 2015 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RgF3pJxY3X6l for ; Tue, 17 Mar 2015 05:47:08 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EB21A038B for ; Tue, 17 Mar 2015 05:47:08 -0700 (PDT) Received: from [192.168.1.200] (p508F1BCE.dip0.t-ipconnect.de [80.143.27.206]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 794C81C0B3013; Tue, 17 Mar 2015 13:47:05 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <6105C0E5-8072-4F0A-8C61-A52DBD353997@ifi.uio.no> Date: Tue, 17 Mar 2015 13:47:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3CB08F64-3C83-48FD-9C1D-A628747F48ED@lurchi.franken.de> References: <177f634cc32da4f8a0362080dc2e6992@mail.gmail.com> <6105C0E5-8072-4F0A-8C61-A52DBD353997@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Karen Elisabeth Egede Nielsen , "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:47:10 -0000 > On 17 Mar 2015, at 11:09, Michael Welzl wrote: >=20 > Hi, >=20 >=20 >> On 16 Mar 2015, at 23:54, Karen Elisabeth Egede Nielsen = wrote: >>=20 >> HI, >>=20 >> Please accept the following "minor" comments/questions to the TCP = protocol >> components: >>=20 >> #1: >> The list include both of the followings: >>=20 >> *ordered delivery for each byte stream >> * stream-oriented delivery in a single stream >>=20 >> Wouldn't it be more fair to combine these two and say: >>=20 >> *ordered delivery in a single stream >>=20 >> "Each stream" seems a little too much for TCP, I think. >>=20 >> #2: >> Segmentation and bundling is listed as separate components, even if >> bundling, for TCP, is part of the segmentation process. >> I suppose that is as it should be, but when speaking "Bundling" then = I >> actually think that "Bundling delay" is a better term. Especially for = TCP. >>=20 >> To put in context: >> For SCTP it is actually relevant to discuss bundling and bundling = delay >> separately as two different components. >> Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call = that >> bundling), but it CAN (depending on no_delay setting) implement = bundling >> delay or not. >=20 > So how does bundling without delaying work? cwnd doesn't allow you to send, a_rwnd doesn't allow you to send, you = have a send() call which allows to provide multiple user messages, ... Best regards Michael >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Fri Mar 20 03:29:50 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4852E1B2CB9 for ; Fri, 20 Mar 2015 03:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 bBaAA4kwYwsN for ; Fri, 20 Mar 2015 03:29:47 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 691C71B2CB7 for ; Fri, 20 Mar 2015 03:29:47 -0700 (PDT) Received: by iedm5 with SMTP id m5so24645158ied.3 for ; Fri, 20 Mar 2015 03:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type; bh=HnSYppFynTm+0UjSm8dJMtmM4rH1oMpS6wHT6HEYDOo=; b=Zal/ZIwKpPVkDcPzFtI+AlKw6vJgIEAS06GFc/Rxz4zv+gTMk/OEDwq7uYrNqQbs6L mvLwYmkWdg3n4halllzZWhu+IJO/EuVFkPXnOC+wStMSCA+C3t35MEirjWu33iYssCFJ WxckTdPuh30Wn/iiszzcxBJTszGogSFWE50H8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=HnSYppFynTm+0UjSm8dJMtmM4rH1oMpS6wHT6HEYDOo=; b=KShF9ILr02LtWxU93nBjcxdwEffNmIJu/3v3UWEGcAbYqvxuOgD7HOFB1Mqhjsxks5 7Aq4bpzrXCfp6zP0wxdmd9xmoY7ILkLM2AhENanfRFqueqLXjO6Rx2ZYzwk6LbWEoDwj lfvRhJcAraB/5iGZOQ0VTkLRoZBaRGvGz+PWIBM6FJom87VBMZN0KR9YA2okCk6BmGLV L/foBRFo9E9TFfiJkjzg0TVjJuQ29p966LR8UgXL8TN5HODW9lAodN5qmNtFqMsgH8z+ JSYfKe7foHhtEgnC7owcxQ0zDXmQ6GdGNF4pWTT4Kfdv++mduoLiCDEQsMB3QS6ippxS cdUw== X-Gm-Message-State: ALoCoQl9TaFzBRyv9NSXyJ17mevOpCb0go948nnoam3ocPjwGIhBlkKMCUCzXg9qiXOREvQ4iDPQkFx7ysnpCecMH+bXO3Jqx/wXno/FpfeZH5qFqlEYzOw= X-Received: by 10.50.122.68 with SMTP id lq4mr23580759igb.10.1426847386787; Fri, 20 Mar 2015 03:29:46 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150227125223.18650.57760.idtracker@ietfa.amsl.com> In-Reply-To: <20150227125223.18650.57760.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoJyvFCvT6kuTouE7K9ZHXgVZRjZx1oTnQ Date: Fri, 20 Mar 2015 11:29:45 +0100 Message-ID: <8c0ba2c17103bd5f22c0cf7cbe545c69@mail.gmail.com> To: taps@ietf.org, Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 10:29:49 -0000 HI, Please accept the following comments to the SCTP section. Generally I think that the section is extremely well written and touches on the majority of significant SCTP transport service aspects. I have some minor nits for consideration for the next update: #1: Section 1, Second paragraph: In the context of web-sockets over TCP and RTP over UDP one might refer to RTCWEB data channel usage of SCTP, but I also recognize that this may not strike the right balance towards the other more widely used services. #2: Section 1, Third paragraph: One could reformulate: for instance, SCTP offers a message-based service that does not suffer head-of-line blocking when used with multiple stream, because it can accept blocks of data out of order, --> for instance, SCTP offers a reliable ordered message-based delivery service that, when used with multiple streams, mitigates the effects of head-of-line blocking, because head-of-line blocking is confined to the individual stream. One might even also, but not sure if this is equally important, rely to that SCTP offers the service of reliable un-ordered delivery: --> for instance, SCTP offers a reliable unordered message delivery which does not suffer from head-of-line blocking as well as a reliable ordered message-based delivery service that, when used with multiple streams, mitigates the effects of head-of-line blocking, because head-of-line blocking is confined to the individual stream. #3: Section 3.3.1: Fourth paragraph. Bundling: Would it be relevant to refer to that sender side bundling delay typically is (or may be) implemented as Nagle bundling with an override timer ? Further I think that it is important to distinguish this from bundling delay from the standard bundling of immediately available messages for efficiency reasons. #4: Section 3.3.1: Fourth paragraph. PMTUD: Should the text not refer also to RFC1191 and RFC1981. Possibly as: ICMP-based PathMTU discovery [RFC1191][RFC1981] as well as Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] are supported. [RFC4821] defines a method to perform packetization layer path MTU discovery for SCTP with probe packets using the padding chunks defined the [RFC4820]. #5: Section 3.3.1: 6th paragraph: Perhaps one could elaborate: Only all ordered messages sent on the same stream are delivered at the receiver in the same order as sent by the sender. --> Only ordered messages sent on the same stream are delivered at the receiver in the same order as sent by the sender. Un-ordered messages (any stream) are delivered at the receiver in the order they arrive, conditional to message reassembly having been performed. #6: Section 3.3.1: 6th paragraph: Schedular and prioritizations of streams. I think this could be a potential very important feature for SCTP (for signaling) and that it deserves to be mentioned in its own right. What about the following change: [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and also allows to specify a scheduler for the sender side streams selection. --> [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. [I-D.ietf-tsvwg-sctp-ndata] further allows to specify different stream schedulers for the sender side selection of which streams to transmit from, thereby allowing for various priority schemes for the sender side transmittal. #8: section 3.3.1 second last paragraph: I note that native NAT traversal is not mentioned even though this is a wg document. - ? #9: Should SCTP AUTH not be described in an individual paragraph of section 3.3.1 ? #10: Section 3.3.2: Perhaps reformulate: One-to-one style sockets are similar to TCP sockets, there is a 1:1 relationship between the sockets and the SCTP associations (except for listening sockets). One-to-many style SCTP sockets are similar to unconnected UDP sockets as there is a 1:n relationship between the sockets and the SCTP associations. --> One-to-one style sockets are similar to TCP sockets, there is a 1:1 relationship between the sockets and the SCTP associations (except for listening sockets). The major difference to TCP is that the SCTP associations can span multiple local and remote addresses. One-to-many style SCTP sockets have some similarity with unconnected UDP sockets as there is a 1:n relationship between the sockets and the SCTP associations endpoints. #11: Section 3.3.3: . Perhaps one should extend the "reliable or partially reliable delivery" to "reliable, partially reliable or un-reliable delivery" . I am a little unsure about the "unordered delivery within a stream" - I know that one can read the stream that an ordered messages was received from, but if that it enough to qualify for delivery "within a" stream I am not sure. . Integrity check refers to checksum. In the TCP Transport Protocol Components list this is listed as error detection. One should use aligned semantics - I think ? . Should SCTP Auth not be mentioned ? . Is think flow control should simply be "flow control" (no reference to slow receiver). . I think the support for multiple prioritized streams should be split into two bullets: o Support for multiple concurrent streams o Support for stream scheduling prioritization . I would replace "application PDU" with "message" BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- >drafts@ietf.org >Sent: Friday, February 27, 2015 1:52 PM >To: i-d-announce@ietf.org >Cc: taps@ietf.org >Subject: [Taps] I-D Action: draft-ietf-taps-transports-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Services Working Group of the IETF. > > Title : Services provided by IETF transport protocols and congestion >control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-03.txt > Pages : 25 > Date : 2015-02-27 > >Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-taps-transports-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03 > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Taps mailing list >Taps@ietf.org >https://www.ietf.org/mailman/listinfo/taps From nobody Sat Mar 21 05:39:55 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACCC1A92DE for ; Sat, 21 Mar 2015 05:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiV1_FIy5Jpy for ; Sat, 21 Mar 2015 05:39:52 -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 597A91A92DC for ; Sat, 21 Mar 2015 05:39:50 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-ab-550d669484c8 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.D9.28835.4966D055; Sat, 21 Mar 2015 13:39:48 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.246]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Sat, 21 Mar 2015 13:39:47 +0100 From: Salvatore Loreto To: "Brian Trammell (ietf@trammell.ch)" Thread-Topic: [Taps] I-D Action: draft-ietf-taps-transports-02.txt Thread-Index: AQHQY9Qd67kPM0UrX0G20BYppHelqg== Date: Sat, 21 Mar 2015 12:39:47 +0000 Message-ID: References: <20150207120702.11245.33712.idtracker@ietfa.amsl.com> <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> In-Reply-To: <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RndKGm+owcODwhYbW96xWdyJcWDy WLLkJ5PHk/0zWQKYorhsUlJzMstSi/TtErgyDu3/z17wgaXi19UG5gbGr8xdjJwcEgImEs9b 9rFA2GISF+6tZ+ti5OIQEjjCKLH1RguUs4RRouHRJCaQKjYBM4nnD7cAdXNwiAhYSTQt1wQJ MwtIS0xaPxmsRFjASWLO2zOMILaIgLPEoaUfWSBsPYmTV/aB1bAIqEocaD/FBmLzCthLTOu5 DGYLCZRJ/Pq9nRXE5gSKr7nTzQ5iMwId9/3UGiaIXeISt57MZ4I4WkBiyZ7zUM+ISrx8/I8V wlaSWHt4OwtEvY7Egt2f2CBsa4l9p44yQtjaEssWvmaGuEFQ4uTMJywTGMVnIVkxC0n7LCTt s5C0z0LSvoCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYKwd3PLbagfjweeOhxgFOBiV eHg/ivGGCrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsfj3 3HOHLL5bPtt4+uo0LsYf+iIhr6a3z1ksnZzk5X9+Q7LdGr+1TM2/GnNn37rlZ7UuYnneGq3p dWY8Tt2z9syYnHXQ0Oip6J2SAKkyC+kN/xcccr8Teex/a86RL9r3Ft+50if8x5rte9Ts9bUX PO8uLRXkWKTpvfpKbUmyUw7Dkvy/WzksfZRYijMSDbWYi4oTAZtd71yWAgAA Archived-At: Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 12:39:53 -0000 Hi there in 03 is still not assigned so if you have not got any volunteer yet for WebSocket section I can volunteer for it! br /Salvatore > On 07 Feb 2015, at 12:41, Brian Trammell wrote: >=20 > Not-yet-subsection-authors who would like to contribute: there are a coup= le of sections we'd like to have (HTTP(S) as a pseudotransport, and WebSock= ets which removes some of the "pseudo" therefrom) that don't yet have contr= ibutors associated; additionally, if there are transport (or transport-like= ) protocols we're missing here, please send text and we'll get it integrate= d. From nobody Sat Mar 21 06:27:08 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDF91A92F1 for ; Sat, 21 Mar 2015 06:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 QI5PtR76nSP6 for ; Sat, 21 Mar 2015 06:27:06 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 E07E21A92F0 for ; Sat, 21 Mar 2015 06:27:05 -0700 (PDT) Received: by qgez102 with SMTP id z102so25179937qge.3 for ; Sat, 21 Mar 2015 06:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=wRyLcp+rJKUhtfRfZrM1Odytg/Laj3qgqO5BLQRMR5o=; b=SUrnkkUj5AtwNost+M4dfTr3lRxIwM+qQDnlB+oUitqhmqS0fmXCeskS7vhjGXg9ND oJ4jvh9VfWeDsuah+AmgSJvfG3QScx9RBOFyHB6Yf+1xz+Jdr4gncdPw3OJOh2A3WQ5X TlkCP3unA8q3mQYpqRDOROMRrbjk/LlJhEUMKv9AXBu5a6UppdaT+WruLKVr+vGoBbkM 9VhsZhM8A1ZLVRt+DrCgBKVuRKOkr7LgXZP5mRtghI8ioLq5LwR2RHNcsyHKTnWE6iqs PHqm7JHnk0C723n4MF7PFwtppp01D4McTJ1JkjPXy8wNYX4uP6GX2yzdDWh2j7NJ+zim t+Fg== MIME-Version: 1.0 X-Received: by 10.55.23.210 with SMTP id 79mr114117821qkx.72.1426944425185; Sat, 21 Mar 2015 06:27:05 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.140.84.227 with HTTP; Sat, 21 Mar 2015 06:27:05 -0700 (PDT) Date: Sat, 21 Mar 2015 14:27:05 +0100 X-Google-Sender-Auth: DcR4t_01RYAPL4MMXKUpU_lHnSo Message-ID: From: Jon Crowcroft To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a1147a66893d51e0511cc6303 Archived-At: Subject: [Taps] quic X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 13:27:07 -0000 --001a1147a66893d51e0511cc6303 Content-Type: text/plain; charset=UTF-8 standalone, if anyone wants to experiment https://github.com/devsisters/libquic --001a1147a66893d51e0511cc6303 Content-Type: text/html; charset=UTF-8
standalone, if anyone wants to experiment

--001a1147a66893d51e0511cc6303-- From nobody Sat Mar 21 15:32:23 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6A1A904B for ; Sat, 21 Mar 2015 15:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4jl-he24v4GB for ; Sat, 21 Mar 2015 15:32:19 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9AB1A902B for ; Sat, 21 Mar 2015 15:32:18 -0700 (PDT) Received: from dhcp-885f.meeting.ietf.org (dhcp-885f.meeting.ietf.org [31.133.136.95]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 505C11C104E92; Sat, 21 Mar 2015 23:32:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <8c0ba2c17103bd5f22c0cf7cbe545c69@mail.gmail.com> Date: Sat, 21 Mar 2015 17:32:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150227125223.18650.57760.idtracker@ietfa.amsl.com> <8c0ba2c17103bd5f22c0cf7cbe545c69@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: taps@ietf.org Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 22:32:22 -0000 Hi Karen, thank you very much for the review. See my comments in-line. Best regards Michael > On 20 Mar 2015, at 05:29, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI, >=20 > Please accept the following comments to the SCTP section. >=20 > Generally I think that the section is extremely well written and = touches > on the majority of > significant SCTP transport service aspects. >=20 > I have some minor nits for consideration for the next update: >=20 > #1: Section 1, Second paragraph: >=20 > In the context of web-sockets over TCP and RTP over UDP one might = refer to > RTCWEB data channel usage of SCTP, but I also recognize that this may = not > strike the right balance towards the other more widely used services. So what about: Transport services may be provided directly by these transport protocols, or layered on top of them using protocols such as WebSockets (which runs over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run over SCTP over DTLS over UDP or TCP). >=20 > #2: Section 1, Third paragraph: >=20 > One could reformulate: >=20 > for instance, SCTP offers a message-based > service that does not suffer head-of-line blocking when used with > multiple stream, because it can accept blocks of data out of order, >=20 > --> >=20 > for instance, SCTP offers a reliable ordered message-based delivery > service that, when used with multiple streams, mitigates the effects = of > head-of-line blocking, > because head-of-line blocking is confined to the individual stream. >=20 > One might even also, but not sure if this is equally important, rely = to > that SCTP offers the service of reliable un-ordered delivery: >=20 > --> >=20 > for instance, SCTP offers a reliable unordered message delivery = which > does not suffer from head-of-line blocking as well as a reliable = ordered > message-based delivery > service that, when used with multiple streams, mitigates the effects = of > head-of-line blocking, > because head-of-line blocking is confined to the individual stream. What about: SCTP offers a message-based service providing full or partial = reliability and allowing to minimize the head of line blocking due to the support of unordered and unordered message delivery within multiple streams, ... >=20 > #3: Section 3.3.1: Fourth paragraph. Bundling: >=20 > Would it be relevant to refer to that sender side bundling delay = typically > is (or may be) implemented as Nagle bundling with an override timer ? I wouldn't say that it is typically implemented with an override = timer... My point was that SCTP has specific mechanisms for supporting small = messages efficiently and also large messages. > Further I think that it is important to distinguish this from bundling > delay from the standard bundling of immediately available messages for > efficiency reasons. Hmm. The section describes the protocol. So I don't want to go into too much detail. So what about adding the following sentence: For example, this bundling may be done by delaying user messages at the = sender side similar to the Nagle algorithm used by TCP. >=20 > #4: Section 3.3.1: Fourth paragraph. PMTUD: >=20 >=20 > Should the text not refer also to RFC1191 and RFC1981. Possibly as: >=20 > ICMP-based PathMTU discovery [RFC1191][RFC1981] > as well as Packetization Layer Path MTU Discovery (PLPMTUD) = [RFC4821] > are supported. > [RFC4821] defines a method to perform packetization layer path > MTU discovery for SCTP with probe packets using the padding chunks > defined the > [RFC4820]. What about: ICMP-based path MTU discovery as specified for IPv4 in {{RFC1191}} and = for IPv6 in {{RFC1981}} as well as packetization layer path MTU discovery as = specified in {{RFC4821}} with probe packets using the padding chunks defined the = {{RFC4820}} are supported. >=20 >=20 > #5: Section 3.3.1: 6th paragraph: > Perhaps one could elaborate: >=20 > Only all ordered messages sent on the same stream are > delivered at the receiver in the same order as sent by the sender. >=20 > --> >=20 > Only ordered messages sent on the same stream are > delivered at the receiver in the same order as sent by the sender. > Un-ordered messages (any stream) are delivered at the receiver in the > order they arrive, conditional to message reassembly having been > performed. I'm not sure this is really guaranteed by the specs. I think unordered messages can be delivered in the order they arrive, but don't have to = be. So what about changing it to User messages can be sent un-ordered or ordered upon request by the = upper layer. Un-ordered messages can be delivered as soon as they are completely = received. Only all ordered messages sent on the same stream ... >=20 > #6: Section 3.3.1: 6th paragraph: Schedular and prioritizations of > streams. >=20 > I think this could be a potential very important feature for SCTP (for > signaling) and that it deserves to be mentioned in its own right. > What about the following change: >=20 > [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and > also allows to specify a scheduler for the sender side streams > selection. >=20 > --> >=20 > [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. >=20 > [I-D.ietf-tsvwg-sctp-ndata] further allows to > specify different stream schedulers for the sender side selection of > which streams to transmit from, thereby allowing for various priority > schemes for the sender side transmittal. What about {{I-D.ietf-tsvwg-sctp-ndata}} overcomes this limitation. Furthermore, {{I-D.ietf-tsvwg-sctp-ndata}} specifies multiple algorithms = for the sender side selection of which streams to send data from supporting = a variety of scheduling algorithms including priority based ones. >=20 > #8: section 3.3.1 second last paragraph: >=20 > I note that native NAT traversal is not mentioned even though this is = a wg > document. > - ? Good point. I missed that one. So what about adding at the beginning of the paragraph: {{I-D.ietf-tsvwg-ietf-tsvwg-natsupp}} defines a methods for end-hosts = and middleboxes to provide for NAT support for SCTP over IPv4. >=20 > #9: Should SCTP AUTH not be described in an individual paragraph of > section 3.3.1 ? The TCP MD-5 option is not discussed, so I thought describing SCTP-AUTH as a service might not be worth. It is used in combination with DTLS and dynamic address reconfiguration. Do you see a relevant use case for SCTP-AUTH on its own? >=20 > #10: Section 3.3.2: >=20 > Perhaps reformulate: >=20 > One-to-one style sockets are similar to TCP sockets, there is a 1:1 > relationship between the sockets and the SCTP associations (except > for listening sockets). One-to-many style SCTP sockets are similar > to unconnected UDP sockets as there is a 1:n relationship between = the > sockets and the SCTP associations. >=20 > --> >=20 > One-to-one style sockets are similar to TCP sockets, there is a 1:1 > relationship between the sockets and the SCTP associations (except > for listening sockets). The major difference to TCP is that the = SCTP > associations can span multiple local and remote addresses. > One-to-many style SCTP sockets have some similarity with > unconnected UDP sockets as there is a 1:n relationship between the > sockets and the SCTP associations endpoints. Well, multihoming-support is not related to the socket style. This is covered by an extra paragraph. >=20 > #11: Section 3.3.3: >=20 > . Perhaps one should extend the "reliable or partially reliable > delivery" to "reliable, partially reliable or un-reliable delivery" I don't use un-reliable, since I don't know what it is. What is the difference between un-reliable and partial-reliable. Bot are versions of not being reliable. > . I am a little unsure about the "unordered delivery within a > stream" - I know that one can read the stream that an ordered messages = was > received from, but if that it enough to qualify for delivery "within = a" > stream I am not sure. Well, this is my understanding: A sender selects * an outgoing stream * whether the message is sent ordered or unordered Both is presented in the API to the receiver. So I think the text is = appropriate. > . Integrity check refers to checksum. In the TCP Transport = Protocol > Components list this > is listed as error detection. One should use aligned semantics - I = think ? That is correct. Maybe Strong error detection (CRC32C) to emphasis that it is not "just" the normal checksum. > . Should SCTP Auth not be mentioned ? Depends on the point above... > . Is think flow control should simply be "flow control" (no > reference to slow receiver). Correct. > . I think the support for multiple prioritized streams should be > split into two bullets: > o Support for multiple concurrent streams > o Support for stream scheduling prioritization OK. > . I would replace "application PDU" with "message" Changed to user message. Thanks a lot for you comments. They help to improve the SCTP test = substantially! >=20 >=20 > BR, Karen >=20 >=20 >> -----Original Message----- >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, February 27, 2015 1:52 PM >> To: i-d-announce@ietf.org >> Cc: taps@ietf.org >> Subject: [Taps] I-D Action: draft-ietf-taps-transports-03.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Transport Services Working Group of = the > IETF. >>=20 >> Title : Services provided by IETF transport protocols > and congestion >> control mechanisms >> Authors : Godred Fairhurst >> Brian Trammell >> Mirja Kuehlewind >> Filename : draft-ietf-taps-transports-03.txt >> Pages : 25 >> Date : 2015-02-27 >>=20 >> Abstract: >> This document describes services provided by existing IETF protocols >> and congestion control mechanisms. It is designed to help >> application and network stack programmers and to inform the work of >> the IETF TAPS Working Group. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-taps-transports-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-03 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Sun Mar 22 07:34:31 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C497F1A9236 for ; Sun, 22 Mar 2015 07:34:30 -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 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 v8zI_Pg8BJrx for ; Sun, 22 Mar 2015 07:34:28 -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 28B071A9168 for ; Sun, 22 Mar 2015 07:34:28 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YZgxO-0002xR-PW for taps@ietf.org; Sun, 22 Mar 2015 15:34:26 +0100 Received: from [38.96.210.190] (helo=[10.1.212.173]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YZgxO-00051s-45 for taps@ietf.org; Sun, 22 Mar 2015 15:34:26 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <18E7A1D7-BF49-425C-987D-93FA01B1F374@ifi.uio.no> Date: Sun, 22 Mar 2015 09:34:23 -0500 To: taps WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 4 sum msgs/h 3 total rcpts 26722 max rcpts/h 44 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: 11A90A3DBFD88A99E403EB1635D5BFFD44B24A20 X-UiO-SPAM-Test: remote_host: 38.96.210.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 16 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Comments on draft-ietf-taps-transports-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 14:34:30 -0000 Hi, Terribly sorry for looking at this so late! I just couldn't do it = earlier. Also sorry for only "looking at it", not reading it in depth = yet! Here are some early comments (I might have more after a deeper = read): Major: - I do think that the terminology actually needs to clarify about what a = "service" is. Following the chain of dependencies here, it is found in = "Transport Service", where it says "... which provides a complete = service to an application." The reason I think we need to define this is that we should (IMO) = explicitly exclude protocol functions that can improve the performance = of the protocol *only* depending on environment characteristics but = *irrespective* of the application. For example, things like ECN, SACK = etc. shouldn't be regarded as a "service" in my opinion. As I'll say in = my presentation tomorrow: for the work we previously did, we decided to = ask, for every protocol component (adapted terminology here ;-) ): = "without knowledge about network conditions, would an application ever = have a reason to say 'no' to this?" =3D> if the answer is "no", it's = not a protocol component, because if it's purely a network optimization, = it better be implemented in the protocol and not shown to the = application. E.g., AFAIK the API of TCP does not allow the application = to turn SACK on or off. That would be pointless, right? =3D> same logic = here. Why do I bring this up? Because I saw a few components that seem to me = to fall in this category of "optimization depending on environment = conditions but otherwise irrelevant for the application": - IPv6 jumbograms in UDP. Though I don't know much about jumbograms, so = I might be very wrong here. - timestamps in DCCP - I didn't see ECN support mentioned elsewhere, but listed in the table = in 4.1. I think it also falls in this category.=20 - segmentation in TCP. Yes it's a part of what TCP does, but, repeating = my question: "without knowledge about network conditions, would an = application ever have a reason to say 'no' to this?" ... I think there's = even one more reason to remove this: isn't this an inevitable element of = stream-oriented data delivery (which is already listed)? Can you do this = without segmentation? UDP(-Lite) messes this up a bit... because it provides almost nothing = and leaves all the job available to applications, hence an application = running over UDP(-Lite) may need to be aware of almost everything, e.g. = ECN capability. Maybe the right thing to do would be to treat UDP(-Lite) = as a special case... Minor: - last para of intro: this talks about LEDBAT as if it was a protocol, = not a congestion control mechanism. - for better or worse, shouldn't "identification of urgent data" be a = part of the protocol components of TCP? Cheers, Michael From nobody Mon Mar 23 09:06:35 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7D1A8A01 for ; Mon, 23 Mar 2015 09:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw_-S6xewx7B for ; Mon, 23 Mar 2015 09:06:31 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001: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 64C2F1AC3E4 for ; Mon, 23 Mar 2015 09:06:19 -0700 (PDT) Received: by ignm3 with SMTP id m3so35450521ign.0 for ; Mon, 23 Mar 2015 09:06:19 -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:content-type; bh=5it6vBknpwArHiiFwT2bi55okCj7bOIxzqSruXpTQj0=; b=nukcMSnupv4IcbmqguKESKMeuzvEWQqMhRTlnTYDnco3iFu9CBxlCAUc+2QLX2rRZy OTryWjTW5Dw6A86RUFqrt+Rp+96JumRX7efMa/CiHU33wfwauLO3uGs3UeLZN17/RLWo yLBEnNRSlcg5GsT77b+trDfcOtIYGnK9ibbZ90j2F0xR/uFDvc9TDyNzux1JssquD1Ws 5jFfr7iBVnZOeIxllpIRSlcfjRr32hNF85Xu76UY4eNcV1FaGQnxXqQcyvKCp8ukamwP /Eb1TF9u3Hzkkx1+3p2m4J0J2lKqnWUc8I+Uq6zKg5zqZ1OYHPtZ7f6hoE3/aDHvFGGM VLrw== MIME-Version: 1.0 X-Received: by 10.50.32.7 with SMTP id e7mr15504731igi.21.1427126778925; Mon, 23 Mar 2015 09:06:18 -0700 (PDT) Received: by 10.64.113.196 with HTTP; Mon, 23 Mar 2015 09:06:18 -0700 (PDT) Date: Mon, 23 Mar 2015 12:06:18 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10cbf1b51a830511f6d875 Archived-At: Cc: Gorry Fairhurst , Michael Welzl , Michael Tuexen , Dave Thaler , Brian Trammell , Marie-Jose Montpetit Subject: [Taps] minor TAPS agenda change X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:06:33 -0000 --047d7b10cbf1b51a830511f6d875 Content-Type: text/plain; charset=UTF-8 FYI: Based on some discussion in the APPSWG, I swapped the last two topics on the agenda. I hope this doesn't pose a problem for anyone... Slides are posted. --aaron ----- Transport Services (TAPS) Working GroupMonday, March 23, 2015 1300 - 1500 CDTParisian Room 1. Chair's Slides (5 min) - Aaron Falk 2. Draft Status and badgering of volunteers (15 min) - draft-ietf-taps-transports-03 - Brian Trammel 3. Applications view of transport abstractions (30 min) - RTCWeb data channel services - Michael Tuexen - Multisource video / TV - Marie-Jose Montpetit - *Discussion* 4. Two or three transport feature matrices (45 min) - Gorry Fairhurst - Michael Welzl - Dave Thaler - *Discussion* --047d7b10cbf1b51a830511f6d875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI: Based on some discussion in the APPSWG, I swapped the= last two topics on the agenda.=C2=A0 I hope this doesn't pose a proble= m for anyone...=C2=A0 Slides are posted.

--aaron

-----

Transport Services (TAPS) Working Group

Monday, March 23, 2015 1300 - 1500 C= DT

Parisian Room<= /h3>
    =
  1. Chair's Slides (5 min)
    • Aaron Falk

  2. = Draft Status and badgering of volunteers (15 min)

  3. Applications view= of transport abstractions (30 min)
    • RTCWeb data channel services= - Michael Tuexen
    • Multisource video / TV - Marie-Jose Montpetit
    • Discussion

  4. Two or three transport feature= matrices (45 min)
    • Gorry Fairhurst
    • Michael Welzl
      • Dave Thaler
    • Discussion

--047d7b10cbf1b51a830511f6d875-- From nobody Mon Mar 23 09:39:56 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158FB1ACD5F for ; Mon, 23 Mar 2015 09:39:55 -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 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 sylzQxvmARrE for ; Mon, 23 Mar 2015 09:39:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B302D1ACD5D for ; Mon, 23 Mar 2015 09:39:53 -0700 (PDT) Received: from [75.217.45.150] (150.sub-75-217-45.myvzw.com [75.217.45.150]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t2NGZ09L005123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 09:35:08 -0700 (PDT) Message-ID: <551040B3.8050202@isi.edu> Date: Mon, 23 Mar 2015 09:34:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Welzl , taps WG References: <18E7A1D7-BF49-425C-987D-93FA01B1F374@ifi.uio.no> In-Reply-To: <18E7A1D7-BF49-425C-987D-93FA01B1F374@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: Subject: Re: [Taps] Comments on draft-ietf-taps-transports-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:39:55 -0000 On 3/22/2015 7:34 AM, Michael Welzl wrote: > Major: > - I do think that the terminology actually needs to clarify about > what a "service" is. Following the chain of dependencies here, it is found in > "Transport Service", where it says "... which provides a complete > service to an application." > > The reason I think we need to define this is that we should (IMO) > explicitly exclude protocol functions that can improve the performance > of the protocol *only* depending on environment characteristics but > *irrespective* of the application. For example, things like ECN, SACK > etc. shouldn't be regarded as a "service" in my opinion. IMO, a "service" is a coherent whole. ECN, SACK, etc. are capabilities within a service. The difference is simple: a service is the smallest set of capabilities that can be used independent of all others. Joe From nobody Mon Mar 23 11:06:50 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A8C1AD05D for ; Mon, 23 Mar 2015 11:06:48 -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 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 bV0rFVEIm8uR for ; Mon, 23 Mar 2015 11:06:46 -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 603BE1AD060 for ; Mon, 23 Mar 2015 11:06:46 -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 1Ya6kO-0004t7-8X; Mon, 23 Mar 2015 19:06:44 +0100 Received: from dhcp-8943.meeting.ietf.org ([31.133.137.67]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Ya6kN-0003b4-KM; Mon, 23 Mar 2015 19:06:44 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <551040B3.8050202@isi.edu> Date: Mon, 23 Mar 2015 13:06:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18E7A1D7-BF49-425C-987D-93FA01B1F374@ifi.uio.no> <551040B3.8050202@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 10 sum msgs/h 5 total rcpts 26784 max rcpts/h 44 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: 816B6D381D9138DF2100D72C3612D368CE43BD78 X-UiO-SPAM-Test: remote_host: 31.133.137.67 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 6 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: taps WG Subject: Re: [Taps] Comments on draft-ietf-taps-transports-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:06:48 -0000 > On 23. mar. 2015, at 11.34, Joe Touch wrote: >=20 >=20 >=20 > On 3/22/2015 7:34 AM, Michael Welzl wrote: >> Major: >> - I do think that the terminology actually needs to clarify about >> what a "service" is. Following the chain of dependencies here, it is = found in >> "Transport Service", where it says "... which provides a complete >> service to an application." >>=20 >> The reason I think we need to define this is that we should (IMO) >> explicitly exclude protocol functions that can improve the = performance >> of the protocol *only* depending on environment characteristics but >> *irrespective* of the application. For example, things like ECN, SACK >> etc. shouldn't be regarded as a "service" in my opinion. >=20 > IMO, a "service" is a coherent whole. ECN, SACK, etc. are capabilities > within a service. >=20 > The difference is simple: a service is the smallest set of = capabilities > that can be used independent of all others. I completely agree and apologize, that was slopping writing on my side: = I should have said "service component". Anyway my point was that ECN, = SACK etc. shouldn't be any of that. Cheers, Michael From nobody Mon Mar 23 11:11:57 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C131AD0B5 for ; Mon, 23 Mar 2015 11:11:56 -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 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 lTjZT-qO3IT5 for ; Mon, 23 Mar 2015 11:11:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C811AD0A3 for ; Mon, 23 Mar 2015 11:11:55 -0700 (PDT) Received: from [128.9.176.213] (c2-vpn04.isi.edu [128.9.176.213]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t2NIBI76007603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 11:11:18 -0700 (PDT) Message-ID: <55105746.2010500@isi.edu> Date: Mon, 23 Mar 2015 11:11:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Welzl References: <18E7A1D7-BF49-425C-987D-93FA01B1F374@ifi.uio.no> <551040B3.8050202@isi.edu> 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: taps WG Subject: Re: [Taps] Comments on draft-ietf-taps-transports-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:11:56 -0000 On 3/23/2015 11:06 AM, Michael Welzl wrote: > >> On 23. mar. 2015, at 11.34, Joe Touch wrote: >> >> >> >> On 3/22/2015 7:34 AM, Michael Welzl wrote: >>> Major: >>> - I do think that the terminology actually needs to clarify about >>> what a "service" is. Following the chain of dependencies here, it is found in >>> "Transport Service", where it says "... which provides a complete >>> service to an application." >>> >>> The reason I think we need to define this is that we should (IMO) >>> explicitly exclude protocol functions that can improve the performance >>> of the protocol *only* depending on environment characteristics but >>> *irrespective* of the application. For example, things like ECN, SACK >>> etc. shouldn't be regarded as a "service" in my opinion. >> >> IMO, a "service" is a coherent whole. ECN, SACK, etc. are capabilities >> within a service. >> >> The difference is simple: a service is the smallest set of capabilities >> that can be used independent of all others. > > I completely agree and apologize, that was slopping writing on my > side: I should have said "service component". Anyway my point was that > ECN, SACK etc. shouldn't be any of that. ECN and SACK are "how" a service achieves a capability, but they're not capabilities. Just like "Nagle" isn't a capability either. These items are activated to achieve a capability. The closest for Nagle would be "efficient transfer allowing delay". YMMV, and I don't have a suggestion for the others. Joe From nobody Mon Mar 23 11:22:59 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48FF1ACEEB for ; Mon, 23 Mar 2015 11:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xN5NiYNSirt for ; Mon, 23 Mar 2015 11:22:56 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEE41A0174 for ; Mon, 23 Mar 2015 11:22:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0BF14D9303; Mon, 23 Mar 2015 19:22:55 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VnGytOIThhnU; Mon, 23 Mar 2015 19:22:54 +0100 (MET) Received: from dhcp-98aa.meeting.ietf.org (dhcp-98aa.meeting.ietf.org [31.133.152.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4C133D9302; Mon, 23 Mar 2015 19:22:54 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 23 Mar 2015 13:22:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <37ED61A5-40B5-4B72-889D-AEB16AD4CD03@tik.ee.ethz.ch> References: <20150207120702.11245.33712.idtracker@ietfa.amsl.com> <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> To: Salvatore Loreto X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Brian Trammell \(ietf@trammell.ch\)" , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:22:59 -0000 Hi Salvatore, not sure Brian ever answered to this mail. We already have Dragana = Damjanovic who volunteered to help with Websocket. However, as you just = might have seen on the slides we=E2=80=99ve put your name down for = Websockets as well. Please coordinate with Dragana. Thanks! Mirja =20 > Am 21.03.2015 um 07:39 schrieb Salvatore Loreto = : >=20 > Hi there >=20 > in 03 is still not assigned > so if you have not got any volunteer yet for WebSocket section > I can volunteer for it! >=20 > br > /Salvatore >=20 >=20 >> On 07 Feb 2015, at 12:41, Brian Trammell wrote: >>=20 >> Not-yet-subsection-authors who would like to contribute: there are a = couple of sections we'd like to have (HTTP(S) as a pseudotransport, and = WebSockets which removes some of the "pseudo" therefrom) that don't yet = have contributors associated; additionally, if there are transport (or = transport-like) protocols we're missing here, please send text and we'll = get it integrated. >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps