From nobody Mon Jul 6 15:06: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 731061A049A; Mon, 6 Jul 2015 15:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pChjW7H20A3m; Mon, 6 Jul 2015 15:06:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 548371A1A98; Mon, 6 Jul 2015 15:06:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706220631.6336.219.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 15:06:31 -0700 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-06.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:06:33 -0000 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-06.txt Pages : 39 Date : 2015-07-06 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: https://tools.ietf.org/html/draft-ietf-taps-transports-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-06 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/ From nobody Wed Jul 15 02:04:03 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 9A8931A0094 for ; Wed, 15 Jul 2015 02:04:01 -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 vRw_nkr9acLg for ; Wed, 15 Jul 2015 02:03:59 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 C96011A008E for ; Wed, 15 Jul 2015 02:03:59 -0700 (PDT) Received: by igbij6 with SMTP id ij6so66272449igb.1 for ; Wed, 15 Jul 2015 02:03:59 -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=0nKAvELUGC2Wzsz8YsgLCdLO1XMZdiVLYeL+6HaZqaw=; b=frgLc69NYJiHMVPy09IHw/HGtd4bcF9dQTaYxwrUpysisuqz2RutLkqIHwqx9w52Ez KJnu1XQgo5LA8iklLvLSYIA0ZuhNUKPrkcISbjMB/mmmFkYZQBrBf/4cuMtQ2IKc9m6o YgPORxKvN72rA3LrqU0gFyFCf2h6FaOFqcr0w= 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=0nKAvELUGC2Wzsz8YsgLCdLO1XMZdiVLYeL+6HaZqaw=; b=Zyhi3hlcU+TddelecE20wsd3B/SOGSshUX+8osEgjnSe1JYYl1b6o6J07idzCcr0IX OgOIIf1wZGkXJYgenRPTKtdDH0ty1zVnKB1jUtVNaYb00evSR5Hc03vC89yPs1Js6S7x E07KMdzvabXZoEo6r3lMv6naauV3PX4ZtWR0Bf0vZklxGISdMjS6gdKn/OVDMPvo54rH AWxdTbIFgdosE9w/mrGEL22g+c1muVV2FumAaxuSNWlixJQuP8Sm/x7eLiK/hYKKDX4A qZiaW3AZ+FEG1ftXpA9bg3S3V/MeDifa0v7sSDt4vYby+ZNdLelCy6E8tJ1SdcqBEPFg o4qg== X-Gm-Message-State: ALoCoQnsI1dlV8kbEZ6MWs28M2oIv401laJnfuIQLq1PFcG2yltea5fR/FhO/AG9Vhj5tLjLWeGlyND61ZzYR8dlXqr0TLObRP2It0E5uqU6XSbInpmARpM= X-Received: by 10.50.41.8 with SMTP id b8mr24848835igl.38.1436951039303; Wed, 15 Jul 2015 02:03:59 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> In-Reply-To: <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMzp8FqXoBXDicXbg77ws60nWQywLXHxAwAlSEXMwBP4SU2gKV6VB4AmKwcTedCPsFUA== Date: Wed, 15 Jul 2015 11:03:58 +0200 Message-ID: <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: Brian Trammell , Michael Welzl , taps@ietf.org Subject: Re: [Taps] TCP components 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, 15 Jul 2015 09:04:01 -0000 HI Mirja, All Sorry for jumping late into this discussion. >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewin= d >Sent: Thursday, June 18, 2015 10:48 AM >To: Joe Touch >Cc: Brian Trammell; Michael Welzl; taps@ietf.org >Subject: Re: [Taps] TCP components > >Hi Joe, > >I believe the approach Michael is proposing is to look at existing APIs as >a >starting point; not only abstract APIs. The assumption is that someone who >implemented/designed an API, thought that it would be worth to provide a >configuration possibility to the higher layer. This assumption is more tru= e >for >SCTP than for TCP because there are quite a few different TCP >implementation that are grown over time. Quite often a new interface was >only created because a new feature was added to TCP; and to be on the safe >side we allow the user to turn it off again. > >That=E2=80=99s the reason why I prefer the approach we are/I'm taking righ= t now >(analyzing components). I think we should still describe the abstract API >of >RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, bu= t >I >personally would not and will not spend too much time analyzing other API. [Karen ] I really do not think that it makes much sense to look into outdated and deprecated APIs as specified in RFC793 and RFC4960 when we have better material available. For SCTP here specifically RFC6458. Personally I cannot support this approach. I am not saying that we need ver= y detailed APIs and therefore do not want RFC793 or RFC4960, but I want that what we do is based on the right specs (or the right defact= o implementations) not on known-to-be outdated ones. I understand that it is difficult to find out exactly what is the fundament of TAPS - sometimes it is said that it is the existing IETF specifications - which means for example that SCTP-CMT and QUIC is outside of the scope. Then in other Taps communications - e.g. TCP components - it is said that one cannot fix the congestion control aspects of TCP as there I not one CC for TCP - and "one do not know what people implements". I am not sur= e exactly what Taps should to do when the defacto standards (e.g. TCP) have superseded the actual standard. I think that it shall be on a best judgment basis and when there _are_ specs we should go with the most recent and sane ones and not with the outdated ones. BR, Karen From nobody Wed Jul 15 02:33: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 93E991A0122 for ; Wed, 15 Jul 2015 02:33:32 -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 Hi1ZXWzwlK0a for ; Wed, 15 Jul 2015 02:33:30 -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 B7F741A013B for ; Wed, 15 Jul 2015 02:33:29 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZFJ3y-0004XQ-EG; Wed, 15 Jul 2015 11:33:14 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZFJ3x-0002Iv-SA; Wed, 15 Jul 2015 11:33:14 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> Date: Wed, 15 Jul 2015 11:33:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 16 sum msgs/h 4 total rcpts 30999 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 20F52326C596DEE1A6A2539F1CCFEE4F63122465 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7417 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] TCP components 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, 15 Jul 2015 09:33:32 -0000 > On 15 Jul 2015, at 11:03, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI Mirja, All >=20 > Sorry for jumping late into this discussion. >=20 >> -----Original Message----- >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Mirja = K=C3=BChlewind >> Sent: Thursday, June 18, 2015 10:48 AM >> To: Joe Touch >> Cc: Brian Trammell; Michael Welzl; taps@ietf.org >> Subject: Re: [Taps] TCP components >>=20 >> Hi Joe, >>=20 >> I believe the approach Michael is proposing is to look at existing = APIs as >> a >> starting point; not only abstract APIs. The assumption is that = someone who >> implemented/designed an API, thought that it would be worth to = provide a >> configuration possibility to the higher layer. This assumption is = more true >> for >> SCTP than for TCP because there are quite a few different TCP >> implementation that are grown over time. Quite often a new interface = was >> only created because a new feature was added to TCP; and to be on the = safe >> side we allow the user to turn it off again. >>=20 >> That=E2=80=99s the reason why I prefer the approach we are/I'm taking = right now >> (analyzing components). I think we should still describe the abstract = API >> of >> RFC793 (and we do) as well as the SCTP API of RFC4960 in this = document, but >> I >> personally would not and will not spend too much time analyzing other = API. >=20 > [Karen ] >=20 > I really do not think that it makes much sense to look into outdated = and > deprecated APIs > as specified in RFC793 and RFC4960 when we have better material = available. > For SCTP here specifically RFC6458. > Personally I cannot support this approach. I am not saying that we = need very > detailed APIs and therefore do not want RFC793 or RFC4960, > but I want that what we do is based on the right specs (or the right = defacto > implementations) not on known-to-be outdated ones. I have been pointing at RFC6458 but was recently told (and I should have = just read the thing instead of being told, sorry :-( ) that this RFC = does not specify how SCTP's functions are supposed to be exposed to = applications using them, but describes one example implementation (in = great detail) instead. So, to identify the core functions of the protocol, RFC 4960 is probably = a more appropriate source. > I understand that it is difficult to find out exactly what is the = fundament > of TAPS - sometimes it is said that > it is the existing IETF specifications - which means for example that > SCTP-CMT and QUIC is outside of the scope. > Then in other Taps communications - e.g. TCP components - it is said = that > one cannot fix the congestion control aspects of TCP as there I not > one CC for TCP - and "one do not know what people implements". I am = not sure > exactly what Taps should to do when > the defacto standards (e.g. TCP) have superseded the actual standard. = I > think that it shall be on a best judgment basis and when there _are_ = specs > we should go with the most recent and sane ones and not with the = outdated > ones. One of the very first versions of our charter started the work off with = a document that would lay out rules for us, as a basis to make such = decisions. I venture to say that I was right to put this document there, and = whoever recommended that I should remove it was wrong :-) because = such a document would now be good to have, and I think it's easier to = first try to agree on detailed rules (a more fine-grain charter, if you = will - which protocols are in scope, how do we decide what a "service" = is, etc.) than trying to immediately agree on the actual items = themselves (SCTP-CMT: include it or not? Is the Nagle algorithm a = service or not? etc.) Cheers, Michael From nobody Wed Jul 15 03:41:00 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 9A7481A1AA9 for ; Wed, 15 Jul 2015 03:40:59 -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 RmAkbaaLamHg for ; Wed, 15 Jul 2015 03:40:58 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 77CFF1A0395 for ; Wed, 15 Jul 2015 03:40:57 -0700 (PDT) Received: by igbij6 with SMTP id ij6so67830821igb.1 for ; Wed, 15 Jul 2015 03:40:56 -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=DHfbOqzS08FwPcI0nQbZGE9VDKoL3jKf1iMIiHhgxXE=; b=1GwMbY7J0b+Ny7hSaldLgFi0L7KAgijTeZLPETwEVXq5O54w1S/xSYSBwsSCJnWgx2 MLFrqWuNARYCQ0l78xyrsX1vRZDor4IrU4vSi6Ldm2AaJEWYaLIhIp5CouFhgG8JCiUE Y5KhR9R8IeDKoUJEwqwSMFD3qRi2TaUzM9C8Q= 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=DHfbOqzS08FwPcI0nQbZGE9VDKoL3jKf1iMIiHhgxXE=; b=gEHxB4Al5992wz6dXNJOL5ZU/Z2QPToVHy/HaFZsYod1gY6murOysdEOAwtjviE/PL c7vLKG/i2kdG/NqtoYpn4DzQza2vTiPuMHuAhwZckZeSiPsaoBRGFrig1MISK53E21gD O3GD0hcogdd5bfD6xEOMzmJM3pfeKl0L+tfKB6rsZPRmNoYWC95BMfWSjOTLN32zzcU+ Fexrx70TN24eBCKZSwjC1ADG2o7rQH0kvq8Hwk6YeHRnJWJeKqPkVw7A13tAOVd/sh+T +E1PMEwpJHI24mrfUzv0ltvJwIkQP2onUWw9SvpsoWB+7RlpyqKqOpjVeoVjHKpbmSn7 rbjw== X-Gm-Message-State: ALoCoQmqjEiItAekdUoe6f1itfA3lZmEKXTfPHnNs0wlvSO/num07AMaj7ROVJ/udPar4o2gsOAbZWWUH2rDNCmt0aDmRI0hDHdgFLcbjGC0TUYhcJ8v5mw= X-Received: by 10.50.138.76 with SMTP id qo12mr9435914igb.38.1436956856649; Wed, 15 Jul 2015 03:40:56 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMzp8FqXoBXDicXbg77ws60nWQywLXHxAwAlSEXMwBP4SU2gKV6VB4AmKwcTcB5nTT9gJ3XfRNnOYkG5A= Date: Wed, 15 Jul 2015 12:40:55 +0200 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: Brian Trammell , taps@ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] TCP components 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, 15 Jul 2015 10:40:59 -0000 Hi Michael, All > >I have been pointing at RFC6458 but was recently told (and I should have >just >read the thing instead of being told, sorry :-( ) that this RFC does >not specify >how SCTP's functions are supposed to be exposed to applications using them, >but describes one example implementation (in great detail) instead. >So, to identify the core functions of the protocol, RFC 4960 is probably a >more >appropriate source. > [Karen ] I both agree and disagree with this statement. My view on this is: If looking for an abstract interface I agree that many "implementation" details of RFC6458 are unnecessary. However a significant number of abstract functions are not described in RFC4960 and for control of/API for those one need to consult either RFC6458 - or for some of the functions - the api section of the RFCs defining these abstract functions. I would not know why one should consider only the "core" services of SCTP defined by RFC4960 as some significant protocol features are only defined by auxiliary RFCs. Further there are "core" features defined in RFC4960 for which - used (!) - control functions are only exposed in RFC6458. I don't like the API parts of RFC793 as it does not so well represent the API of the defacto TCP implementations - not the (very few) I know anyway. For example both the sender side and the receiver side handling of PUSH flag, which we seem to speak much about here, is not an example of a feature where the RFC793 description well represent the implementations. Also it obviously cannot well represent newer features, like e.g. control of ECN. Then, right, ECN may not make it as something we want to expose. Not sure. I think that RFC793 and RFC4960 may be good starting points, but saying that one will not look beyond them is a misunderstanding. In my view. > >> I understand that it is difficult to find out exactly what is the >> fundament of TAPS - sometimes it is said that it is the existing IETF >> specifications - which means for example that SCTP-CMT and QUIC is >> outside of the scope. >> Then in other Taps communications - e.g. TCP components - it is said >> that one cannot fix the congestion control aspects of TCP as there I >> not one CC for TCP - and "one do not know what people implements". I >> am not sure exactly what Taps should to do when the defacto standards >> (e.g. TCP) have superseded the actual standard. I think that it shall >> be on a best judgment basis and when there _are_ specs we should go >> with the most recent and sane ones and not with the outdated ones. > >One of the very first versions of our charter started the work off with a >document that would lay out rules for us, as a basis to make such >decisions. >I venture to say that I was right to put this document there, and whoever >recommended that I should remove it was wrong :-) because such a >document would now be good to have, and I think it's easier to first try to >agree on detailed rules (a more fine-grain charter, if you will - which >protocols >are in scope, how do we decide what a "service" is, etc.) than trying to >immediately agree on the actual items themselves (SCTP-CMT: include it or >not? Is the Nagle algorithm a service or not? etc.) > [Karen ] Yes. But learning by doing has merits as well. Perhaps one now has a more qualified view on what the "rules" should be. BR, Karen >Cheers, >Michael From nobody Wed Jul 15 03:47: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 3F7A71A1ADB for ; Wed, 15 Jul 2015 03:47:53 -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 9MLNUxatoJ74 for ; Wed, 15 Jul 2015 03:47:50 -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 4ADDF1A1ADF for ; Wed, 15 Jul 2015 03:47:50 -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 1ZFKDv-0001wZ-4k; Wed, 15 Jul 2015 12:47:35 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZFKDu-0004aq-LU; Wed, 15 Jul 2015 12:47:35 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: Date: Wed, 15 Jul 2015 12:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 12 sum msgs/h 2 total rcpts 31004 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7C9BC461C21E466F1DB4771437A7C2D49F9DDC9F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7418 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] TCP components 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, 15 Jul 2015 10:47:53 -0000 > On 15 Jul 2015, at 12:40, Karen Elisabeth Egede Nielsen = wrote: >=20 > Hi Michael, All >=20 >>=20 >> I have been pointing at RFC6458 but was recently told (and I should = have >> just >> read the thing instead of being told, sorry :-( ) that this RFC = does >> not specify >> how SCTP's functions are supposed to be exposed to applications using = them, >> but describes one example implementation (in great detail) instead. >> So, to identify the core functions of the protocol, RFC 4960 is = probably a >> more >> appropriate source. >>=20 > [Karen ] I both agree and disagree with this statement. My view on = this is: >=20 > If looking for an abstract interface I agree that many = "implementation" > details of RFC6458 are unnecessary. > However a significant number of abstract functions are not described = in > RFC4960 and for control of/API for those > one need to consult either RFC6458 - or for some of the functions - = the api > section of the RFCs defining these abstract functions. >=20 > I would not know why one should consider only the "core" services of = SCTP > defined by RFC4960 > as some significant protocol features are only defined by auxiliary = RFCs. > Further there are "core" features defined in RFC4960 for which - used = (!) - > control functions are only exposed in RFC6458. Okay, sigh :( not easy, is it? > I don't like the API parts of RFC793 as it does not so well represent = the > API of the defacto TCP implementations - not the (very few) I know = anyway. > For example both the sender side and the receiver side handling of = PUSH > flag, which we seem to speak much about here, is not an example of a = feature > where the RFC793 description well represent the implementations. > Also it obviously cannot well represent newer features, like e.g. = control of > ECN. > Then, right, ECN may not make it as something we want to expose. Not = sure. >=20 > I think that RFC793 and RFC4960 may be good starting points, but = saying that > one will not look beyond them is a misunderstanding. In my view. I understand >>> I understand that it is difficult to find out exactly what is the >>> fundament of TAPS - sometimes it is said that it is the existing = IETF >>> specifications - which means for example that SCTP-CMT and QUIC is >>> outside of the scope. >>> Then in other Taps communications - e.g. TCP components - it is said >>> that one cannot fix the congestion control aspects of TCP as there I >>> not one CC for TCP - and "one do not know what people implements". I >>> am not sure exactly what Taps should to do when the defacto = standards >>> (e.g. TCP) have superseded the actual standard. I think that it = shall >>> be on a best judgment basis and when there _are_ specs we should go >>> with the most recent and sane ones and not with the outdated ones. >>=20 >> One of the very first versions of our charter started the work off = with a >> document that would lay out rules for us, as a basis to make such >> decisions. >> I venture to say that I was right to put this document there, and = whoever >> recommended that I should remove it was wrong :-) because such a >> document would now be good to have, and I think it's easier to first = try to >> agree on detailed rules (a more fine-grain charter, if you will - = which >> protocols >> are in scope, how do we decide what a "service" is, etc.) than trying = to >> immediately agree on the actual items themselves (SCTP-CMT: include = it or >> not? Is the Nagle algorithm a service or not? etc.) >>=20 > [Karen ] Yes. But learning by doing has merits as well. Perhaps one = now has > a more qualified view on what the "rules" should be. Agreed! Cheers, Michael From nobody Wed Jul 15 04:16: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 472F21A8768 for ; Wed, 15 Jul 2015 04:16: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 ah2WTtVHeoaO for ; Wed, 15 Jul 2015 04:16:47 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FA01A8709 for ; Wed, 15 Jul 2015 04:16:46 -0700 (PDT) Received: by iggp10 with SMTP id p10so118637890igg.0 for ; Wed, 15 Jul 2015 04:16:46 -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=7ir+yrmaN4bSokKRXLaoVCpCCmKfhfc7JxGVUU3ii28=; b=c7nva+25VujtPaghmputoSTtSL1eJGs3Qr2n7I7xMRguQd9yLfzXxYyNA8rpMgYiUZ FmJURvGQoPYUWEfDLQGOxPN0f49aZnUrP0RnPxft0D/uiBYE4lHA1mlFpEBVW1/n1S/2 5C+cFjJHDK5WNI89/BjC5T1um6JjHnGfYv/eI= 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=7ir+yrmaN4bSokKRXLaoVCpCCmKfhfc7JxGVUU3ii28=; b=RJ3M+xbfMWJvp5KnXxsULE+KTTZhzrsK1e9t8KeZjAiXm6Skqb9SZWU1ne+tM34k/w xrv6EJc6PE61WE9g22lTVrZPWmhkp+WXDM5nywUBBVbxDAkU0nEhNF+x/y3s1hiiXGM/ 9zRZZPBgvM2gPHgaLNOtoHzAnaVOJnfYPavSdgrqa63cEl3Q6CJvVoYQ5DITDH5LHhuO Q+7YeQo6D5gwNK18Ok5d1+fs2oI/ZlHP3Z7ouQAGglncQuP92P1Q8+mkBy/9q//n1ste MUR0tmJwJHWE2mAmszeK2t2WoyEEltHaa25dCdG6YCMwJ3vGrbdVPj1x7SwfW3+M5lwl MP5w== X-Gm-Message-State: ALoCoQk3IggczKHJrjqG3i0BhMdlbUgO2R2fth2W48iLiWt+Pq63hl4lCnv9phYWpWNb+Nd3Y23KzqcFnV+2V2VkeafFtLuqZ6tnKQiMDQlZT8j0cb1ySQQ= X-Received: by 10.50.221.107 with SMTP id qd11mr9713403igc.13.1436959006416; Wed, 15 Jul 2015 04:16:46 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> In-Reply-To: <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE86SdgORCvliHFE703NIXCziGWLQKpHUkGAiiw3coBaHzujgJBSMcpnsAtzBA= Date: Wed, 15 Jul 2015 13:16:45 +0200 Message-ID: <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> To: Michael Tuexen , Joe Touch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org Subject: Re: [Taps] TAPS Transports and ICMP 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, 15 Jul 2015 11:16:49 -0000 >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Tuexen >Sent: Thursday, June 04, 2015 9:20 PM >To: Joe Touch >Cc: Pal Martinsen (palmarti); taps@ietf.org >Subject: Re: [Taps] TAPS Transports and ICMP > >> On 04 Jun 2015, at 20:27, Joe Touch wrote: >> >> >> >> On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote: >>> >>>> On 04 Jun 2015, at 17:43, Joe Touch >>> > wrote: >>>> >>>> >>>> >>>> On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote: >>>> ... >>>>> Does it make sense for the TAPS transports draft to add ICMP? >>>> >>>> ICMP is not a transport protocol. >>> >>> Sure. And I agree. But it has the potential to influence how the variou= s >>> transport protocols behave. That interaction might be nice to have >>> described in the transports draft. >> >> Abstract APIs need to be described. These are part of that description. >> >>>> The ways in which transport protocols either terminate or pass-through >>>> ICMP messages is part of the transport protocol abstract API. >>>> >>>> E.g., for UDP and TCP see RFC1122. >>>> >>>> UDP passes all ICMP messages to the app. >>>> >>> No. Not unless the application specifically listens for it. >> >> UDP passes all ICMP messages to the app. If the app doesn't listen for >> it, that's the app's decision. >> >>> Unfortunately how to do this varies from OS to OS: >>> See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace- >01#appendix-A.2 for >>> examples. >> >> You are confusing the OS and language-dependent implementation of the >> API with the abstract API. >> >> RFC1122 requires that UDP implementations make the ICMP signals >> available to the application. It does not indicate by what mechanism. >> >>> Listening for port unreachable can be nice to avoid spamming a host or >>> application that recently crashed. Detecting fragmentation or max MTU i= s >>> also a nice feature especially VoIP applications sending video can >>> utilise to optimise their packet sizes. >> >> UDP is required to pass ALL ICMP messages to the app layer, as per RFC >1122. >> >>>> TCP passes only dest unreachable types 0, 1, and 5, time exceeded and >>>> parameter problem. All others it interprets or ignores internally and >>>> it=E2=80=99s not clear it should pass up to the app. >>> >>> That is exactly that kind of information I would find useful in the >>> transports draft. >> >> Well, yes - IMO, that's because it's part of the abstract API. >> >>> Any pitfalls with ICMP when doing SCTP? >> >> In many ways, SCTP subsumes similar requirements as TCP, but that's >> probably buried in the SCTP docs. >It is. See >https://tools.ietf.org/html/rfc4960#appendix-C > [Karen ] In this context then it is noteworthy to observe that SCTP defacto API (spec or implementations, I know) does not prescribe for that the SCTP transport passes information of received ICMP messages (any kind/type/code) up to SCTP User. Here SCTP is significantly different from UDP and TCP defacto APIs. For security reasons SCTP demands for hard reaction to receipt of protocol unreachable, but that is a protocol feature not an api issue. BR, Karen >Best regards >Michael >> >> Joe >> >> _______________________________________________ >> 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 Wed Jul 15 07:28: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 C9C141A9301 for ; Wed, 15 Jul 2015 07:28:29 -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 BvV68g21D8Um for ; Wed, 15 Jul 2015 07:28:28 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 BB1D21AC3A1 for ; Wed, 15 Jul 2015 07:28:25 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so37467208igb.0 for ; Wed, 15 Jul 2015 07:28:25 -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=0XuGwe939U2zidwASqhNhDWm8abiijbbbdb8Z+KUhHY=; b=v6aYfPkaeK+w3rKEa992y1lDX1vbqS/Xj2u71n6Lm3RC8RAJVw9ZuEBSe30B/d2PYn XdDdcGnPcL/iiCPZP0+gZGupZ+0ropqRT2l/Cs7ow0l3Wbyka7b1KJSOrNTPtKMfFNdP sJ1qRXZrxxpULByrJ4RgvNiSAtwdALDcmushI= 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=0XuGwe939U2zidwASqhNhDWm8abiijbbbdb8Z+KUhHY=; b=fUTFjlMQKsS4mxyB9VvR4PR/67X1RFMdC8jQ4/1BKoZ/aI60akZHvG1UOaYXnp78vL ykAYj1kCpl1YtUijE157bzjLRiOPKltiuWeVXRXRQKzi0326cUz8F6EbUuV/1OeLUu3Z sfUHrRvGtpBPGiALAkbeF8/3jKAATqzLaifbZwwyGb0oJNWOqLkq04mXzijUEBsLIdH5 KkWWNVH9npBRGqLZ13E0k6vYEu/hvmEdOeeziUBnw/7+ULr1NcUuGZ/QGb1L1sSyOmtf vWYCjRZcrpCwjp134C8GQgJxahnQT+JcYxqyCYfYBdZjilk2eb0O8nmRSzBjWr/8JAxa fw/Q== X-Gm-Message-State: ALoCoQmE6en25xvaTobSxiaz6CcLoCNgPoEAyzOczyNmcgORLHVKbPXyuXjBVJgS+gTrY0xqdQXLJ9CWnHs0Lg5kdUu7ayTIoV11lepUANoGiJwyjc/QvLI= X-Received: by 10.50.43.227 with SMTP id z3mr26754105igl.22.1436970505120; Wed, 15 Jul 2015 07:28:25 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150706220631.6336.219.idtracker@ietfa.amsl.com> In-Reply-To: <20150706220631.6336.219.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG/A9yO7NWA5qgnOWhDhpN5Pi0yH53/8eTA Date: Wed, 15 Jul 2015 16:28:24 +0200 Message-ID: To: internet-drafts@ietf.org, i-d-announce@ietf.org 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-06.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, 15 Jul 2015 14:28:30 -0000 Hi, Please find a very few comments to the document. Nothing major. Please use if you see fit and only then :-) Section 1: End First Paragraph: Here it is said that a transport service feature may be minimal latency. Opposed to the other features listed here, like e.g. in-order or reliable delivery, then minimal latency seems a more delicate obtainable feature; How one best obtain it within the services provided by a certain transport protocol, may depend quite heavily on the application traffic pattern (unless CPU and network resources are unlimited). Also minimal latency is not a feature which any of the protocols described in the document has within its list of features (I think) or are you thinking minimal latency and best effort transport service (like UDP) - Or are you thinking some smart protocol of the future which will deduce how to best provide a minimal latency service for a particular application flow over a specific E-to-E path ? Section 3.1.2: Not sure if this way of describing the TCP Protocol Components is the right way to do. I think that it would be nice to have the list here use Transport Service Features names and then possibly - if relevant as it is done now - describe in more detail how the TCP Component implement the Transport Service Feature. I further think that one should strive - best possibly - to use the same Transport Service Features for the different protocols when applicable. Like (some easy examples) for TCP: o Single stream-oriented transmission: The stream abstraction atop the datagram service provided by IP is implemented by dividing the stream into segments. o Flow control: Window-based flow control, with receiver-side window management and signaling of available window: Scaling the flow control window beyond 64kB requires the use of an optional feature, which has performance implications in environments where this option is not supported; this can be the case either if the receiver does not implement window scaling or if a network node on the path strips the window scaling option. o Congestion Control: Window-based congestion control reacting to loss, delay, retransmission timeout, or an explicit congestion signal (ECN): Most commonly used is a loss signal from the reliability component's retransmission mechanism. TCP reacts to a congestion signal by reducing the size of the congestion window; retransmission timeout is generally handled with a larger reaction than other signals. I am not sure if Connection oriented and Feature negotiation should be split into two features ? I am not sure if one wants something called Fast Transmission Start - or simply Fast Open - as a feature ? I am not sure what the slogan of the present bullet about Nagle should be. Also I am not so sure about the content of this section. Disabling Nagle does not always give the lowest latency and further then I think that we are missing the good side of Nagle in the present text. (the bundling of multiple stream segments into packets and its benefits) I do not think that it is relevant to describe how SACK helps reduce the latency of Fast Recovery. If so, one could also describe how it improves the congestion control handling - or ? . Is it at all relevant to consider TCP without SACK enabled ? Generally I am not so sure what the latency discussion in this section is about. It says that "the retransmission timeout defines the upper bound...". But exp back-off _is_ used in TCP, further the statement is really only true if RTO-restart is used. Should one not rather say that RTO-based loss detection reacts based on timeouts - or why does one say anything at all here ? Is it to try to describe if the protocol provides some upper bound for the latency - if so that is more provided via MAXRT ?. The RTO gives an upper bound for when to retransmit - not as such on the reliable delivery. Then on top one have the delay in the SND buffer. Generally the protocol is continuously being evolved to provide low latency loss recovery operation. Perhaps this is relevant to state ? General: I assume that once one has settled a good way of describing the TCP Components, then one will try to align the other sections. Or alternatively one go back now and try to settle the list of Abstract Transport Service Features that existing transport protocol provides - and then afterwards updates the various Transport Protocol Components sections in this doc, including the TCP one. Thanks. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- >drafts@ietf.org >Sent: Tuesday, July 07, 2015 12:07 AM >To: i-d-announce@ietf.org >Cc: taps@ietf.org >Subject: [Taps] I-D Action: draft-ietf-taps-transports-06.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-06.txt > Pages : 39 > Date : 2015-07-06 > >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: >https://tools.ietf.org/html/draft-ietf-taps-transports-06 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-06 > > >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 Wed Jul 15 07:51:21 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 E0CF01AC434 for ; Wed, 15 Jul 2015 07:51:19 -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 HZ-3KGXJ9pF3 for ; Wed, 15 Jul 2015 07:51:18 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (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 12C0D1AC41D for ; Wed, 15 Jul 2015 07:51:18 -0700 (PDT) Received: by ietj16 with SMTP id j16so35254583iet.0 for ; Wed, 15 Jul 2015 07:51:17 -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=0XuGwe939U2zidwASqhNhDWm8abiijbbbdb8Z+KUhHY=; b=smNUCuyNTzwdciKO+TE6VuIsKfz4YlBvoV9xXczq9VDfFZun+dwFcWOVwRl1FzMUZs 7JstIigjFg6Z8FaxJWc10bQ0JrguSEqPY4trTWUreZS3Fm35Flvgsu2JdHBQWfC+S7HR prvrXTmzls443tFuzg5YJfN8RXgz8g/YI3VVw= 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=0XuGwe939U2zidwASqhNhDWm8abiijbbbdb8Z+KUhHY=; b=WOOvz0khXHCMJF5pZ0UV0e68Vqyh6KziqCdzvB8QyxRksDxwli0fHLawcwGyK1iosq TVPfuC7eCS7flGQgjFnMac+V76420wfDnrdkKKTfGvZ7kz48DOvl9YIGlu5jdqnRVF6P 7qgGTR10uwqhbZUrGawQxmLddTLcAkSqOQakqrx7H2aPgozMJedB6Ud2edTuMkCbq1n4 HPCmvLD+aPZst+dDA8wRH2GCNlTS+phaJ8v/TC/2LFDStPCSSW38OCZ4zHpngWQ0/97G /JSXieFbvndzFG2lOXXRL2xk+JhFxmlRPuIRg0OYH20rK0nH6wj5FVjiMtWUnS5r0KVg nAdg== X-Gm-Message-State: ALoCoQnh2+dbQZG7et6v8svUrLVvYna8a/ApZFoIJU4JdKT9O2xzWWKQ/bcUKj+AnjwZaKUDqDyXoqtDA0os96PPeJK0ARIrJRM/bCn5Z0zlGsKeVXO6du4= X-Received: by 10.107.136.160 with SMTP id s32mr5468824ioi.174.1436971877587; Wed, 15 Jul 2015 07:51:17 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150706220631.6336.219.idtracker@ietfa.amsl.com> In-Reply-To: <20150706220631.6336.219.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG/A9yO7NWA5qgnOWhDhpN5Pi0yH54AE43A Date: Wed, 15 Jul 2015 16:51:16 +0200 Message-ID: <456cadf6d459a1c9e2c508af7b5470de@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-06.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, 15 Jul 2015 14:51:20 -0000 Hi, Please find a very few comments to the document. Nothing major. Please use if you see fit and only then :-) Section 1: End First Paragraph: Here it is said that a transport service feature may be minimal latency. Opposed to the other features listed here, like e.g. in-order or reliable delivery, then minimal latency seems a more delicate obtainable feature; How one best obtain it within the services provided by a certain transport protocol, may depend quite heavily on the application traffic pattern (unless CPU and network resources are unlimited). Also minimal latency is not a feature which any of the protocols described in the document has within its list of features (I think) or are you thinking minimal latency and best effort transport service (like UDP) - Or are you thinking some smart protocol of the future which will deduce how to best provide a minimal latency service for a particular application flow over a specific E-to-E path ? Section 3.1.2: Not sure if this way of describing the TCP Protocol Components is the right way to do. I think that it would be nice to have the list here use Transport Service Features names and then possibly - if relevant as it is done now - describe in more detail how the TCP Component implement the Transport Service Feature. I further think that one should strive - best possibly - to use the same Transport Service Features for the different protocols when applicable. Like (some easy examples) for TCP: o Single stream-oriented transmission: The stream abstraction atop the datagram service provided by IP is implemented by dividing the stream into segments. o Flow control: Window-based flow control, with receiver-side window management and signaling of available window: Scaling the flow control window beyond 64kB requires the use of an optional feature, which has performance implications in environments where this option is not supported; this can be the case either if the receiver does not implement window scaling or if a network node on the path strips the window scaling option. o Congestion Control: Window-based congestion control reacting to loss, delay, retransmission timeout, or an explicit congestion signal (ECN): Most commonly used is a loss signal from the reliability component's retransmission mechanism. TCP reacts to a congestion signal by reducing the size of the congestion window; retransmission timeout is generally handled with a larger reaction than other signals. I am not sure if Connection oriented and Feature negotiation should be split into two features ? I am not sure if one wants something called Fast Transmission Start - or simply Fast Open - as a feature ? I am not sure what the slogan of the present bullet about Nagle should be. Also I am not so sure about the content of this section. Disabling Nagle does not always give the lowest latency and further then I think that we are missing the good side of Nagle in the present text. (the bundling of multiple stream segments into packets and its benefits) I do not think that it is relevant to describe how SACK helps reduce the latency of Fast Recovery. If so, one could also describe how it improves the congestion control handling - or ? . Is it at all relevant to consider TCP without SACK enabled ? Generally I am not so sure what the latency discussion in this section is about. It says that "the retransmission timeout defines the upper bound...". But exp back-off _is_ used in TCP, further the statement is really only true if RTO-restart is used. Should one not rather say that RTO-based loss detection reacts based on timeouts - or why does one say anything at all here ? Is it to try to describe if the protocol provides some upper bound for the latency - if so that is more provided via MAXRT ?. The RTO gives an upper bound for when to retransmit - not as such on the reliable delivery. Then on top one have the delay in the SND buffer. Generally the protocol is continuously being evolved to provide low latency loss recovery operation. Perhaps this is relevant to state ? General: I assume that once one has settled a good way of describing the TCP Components, then one will try to align the other sections. Or alternatively one go back now and try to settle the list of Abstract Transport Service Features that existing transport protocol provides - and then afterwards updates the various Transport Protocol Components sections in this doc, including the TCP one. Thanks. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet- >drafts@ietf.org >Sent: Tuesday, July 07, 2015 12:07 AM >To: i-d-announce@ietf.org >Cc: taps@ietf.org >Subject: [Taps] I-D Action: draft-ietf-taps-transports-06.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-06.txt > Pages : 39 > Date : 2015-07-06 > >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: >https://tools.ietf.org/html/draft-ietf-taps-transports-06 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-06 > > >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 Wed Jul 15 11:15:20 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 5FF921ACDD7 for ; Wed, 15 Jul 2015 11:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 2stqhx0bIGof for ; Wed, 15 Jul 2015 11:15:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D431ACEB1 for ; Wed, 15 Jul 2015 11:15:18 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6FIEp3O023932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jul 2015 11:14:54 -0700 (PDT) Message-ID: <55A6A31B.3090500@isi.edu> Date: Wed, 15 Jul 2015 11:14:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Karen Elisabeth Egede Nielsen , taps@ietf.org References: <20150706220631.6336.219.idtracker@ietfa.amsl.com> <456cadf6d459a1c9e2c508af7b5470de@mail.gmail.com> In-Reply-To: <456cadf6d459a1c9e2c508af7b5470de@mail.gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.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, 15 Jul 2015 18:15:19 -0000 On 7/15/2015 7:51 AM, Karen Elisabeth Egede Nielsen wrote: > Hi, > > Please find a very few comments to the document. Nothing major. Please use > if you see fit and only then :-) > > Section 1: End First Paragraph: > > Here it is said that a transport service feature may be minimal latency. > Opposed to the other features listed here, > like e.g. in-order or reliable delivery, then minimal latency seems a more > delicate obtainable feature; How one best obtain it > within the services provided by a certain transport protocol, may depend > quite heavily on the application traffic pattern (unless CPU and network > resources are unlimited). > Also minimal latency is not a feature which any of the protocols described > in the document has within its list of features (I think) or > are you thinking minimal latency and best effort transport service (like > UDP) - Or are you thinking some smart protocol of the future which will > deduce how to best > provide a minimal latency service for a particular application flow over a > specific E-to-E path ? FWIW, UDP doesn't minimize latency; it (arguably) minimizes the latency created by the transport layer at the expense of ordered, reliable delivery and congestion control. So there are several levels of the latency issue: - minimize the latency ADDED by the transport layer - reduce the latency seen by the app (which can involve more active interaction with the network layer, anticipation, etc.) Note also that latency is not a single metric nor a meaningful standalone metric: 1. latency between two parties is a property *of a message*, i.e., it requires knowing the message size 2. latency includes both basic and higher order effects; the basic is "delay", the higher order include "jitter" etc. Many common delay-sensitive use cases are really mostly jitter sensitive. ... > I am not sure if Connection oriented and Feature negotiation should be > split into two features ? If you don't share state (i.e., what we tend to call a "connection"), what is the meaning of feature negotiation? ... > Disabling Nagle does not always give the lowest latency and further then I > think that we are missing the good side of Nagle in the present text. Nagle reduces the number of small packets at the expense of introducing transport delay. Turning it off increases the number of small packets and reduces the transport delay. Although it's theoretically possible for the larger number of packets to cause delays larger than those that Nagle aggregation would induce, in practice the Nagle delays are several orders of magnitude larger. Using byte-based congestion control, the larger number of packets would have no effect. Using packet-based congestion control, the larger number of packets would reduce latency (by opening up the window faster, keeping it open longer, etc.) unless the increased number of packets itself is the bottleneck. So the general assumption that turning off Nagle will reduce latency should be reasonable. Do you have a counterexample seen in the wild? Joe From nobody Wed Jul 15 11:18: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 638231A90BC for ; Wed, 15 Jul 2015 11:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 C05PBumiaFDc for ; Wed, 15 Jul 2015 11:18:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC52C1AD061 for ; Wed, 15 Jul 2015 11:18:25 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6FIHjur024408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jul 2015 11:17:45 -0700 (PDT) Message-ID: <55A6A3C9.3040003@isi.edu> Date: Wed, 15 Jul 2015 11:17:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Karen Elisabeth Egede Nielsen , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> In-Reply-To: <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , taps@ietf.org, Michael Welzl , touch@isi.edu Subject: Re: [Taps] TCP components 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, 15 Jul 2015 18:18:28 -0000 On 7/15/2015 2:03 AM, Karen Elisabeth Egede Nielsen wrote: > HI Mirja, All > > Sorry for jumping late into this discussion. ... > I really do not think that it makes much sense to look into outdated and > deprecated APIs > as specified in RFC793 and RFC4960 when we have better material available. What portion of RFC793's API do you consider outdated? AFAICT, it's exactly what most sockets try to support (I can't speak about SCTP, as I haven't used it much). Joe From nobody Wed Jul 15 11:24: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 BD1531B33C9 for ; Wed, 15 Jul 2015 11:24:39 -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 KTu-35dAIwhK for ; Wed, 15 Jul 2015 11:24:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6832E1B33CF for ; Wed, 15 Jul 2015 11:24:38 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6FINupa017019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jul 2015 11:23:57 -0700 (PDT) Message-ID: <55A6A53C.3010009@isi.edu> Date: Wed, 15 Jul 2015 11:23:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Karen Elisabeth Egede Nielsen , Michael Tuexen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> In-Reply-To: <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, touch@isi.edu Subject: Re: [Taps] TAPS Transports and ICMP 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, 15 Jul 2015 18:24:39 -0000 On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote: ... >>>> Any pitfalls with ICMP when doing SCTP? >>> >>> In many ways, SCTP subsumes similar requirements as TCP, but that's >>> probably buried in the SCTP docs. >> It is. See >> https://tools.ietf.org/html/rfc4960#appendix-C >> > > [Karen ] In this context then it is noteworthy to observe that SCTP defacto > API (spec or implementations, I know) > does not prescribe for that the SCTP transport passes information of > received ICMP messages (any kind/type/code) up to SCTP User. > Here SCTP is significantly different from UDP and TCP defacto APIs. > > For security reasons SCTP demands for hard reaction to receipt of protocol > unreachable, > but that is a protocol feature not an api issue. Agreed, however the other ways that SCTP doesn't pass validated ICMPs to the user seems like a mistake to me. In particular, destination unreachables can cause the SCTP connection to go into a dead state (mark the dest unreachable or increment the path error counter) without indicating anything to the user. This seems incorrect to me, given the number of other ways in which SCTP can shut down a connection (heartbeat failure, retransmission failre) and is supposed to pass that info to the user. So, IMO, this is a great example of why studying these APIs as abstractions is important and would have prevented this (IMO) oversight. Or can someone in the SCTP team explain why shutting connections down due to other reasons is a user signal but validated ICMP signals are not? Joe From nobody Thu Jul 16 00:01:16 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 BAF2A1B3683 for ; Thu, 16 Jul 2015 00:01:14 -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 uHuIRiNeL8RH for ; Thu, 16 Jul 2015 00:01:12 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782041B3681 for ; Thu, 16 Jul 2015 00:01:12 -0700 (PDT) Received: by ieik3 with SMTP id k3so50156939iei.3 for ; Thu, 16 Jul 2015 00:01:12 -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=L6iyZxJVe/H1SX5Y6dhg0Lg5ILLVGz+yY4ur7/Zo2N0=; b=zfLgq4rbRCb2AfHJ1UNdyb2F/KCt+KeBp9NCjDrmXa93ebIaoj+9vZJJWMFyvlnX9H HWWpR7JrDQXzcCnuxLI0tgzUAF1D1LMvVyT1bDmn9mXRhZCpX6g+XOpa0j014XMlwI2W QJiYJbpFavfgFea01kR+Nf3E14w1mTYWzeos4= 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=L6iyZxJVe/H1SX5Y6dhg0Lg5ILLVGz+yY4ur7/Zo2N0=; b=Spisl7uuJIfiRY2AEykC0wWpQ/1eigO8CeCB+IgwO8kPVOTcgHCq3XoJ8F3FBtSNyS j2QjuFx2K6D1VnIwJbe2EsdJtXa7tQOHkYxmDkqmvMGgb7uvLz7gTNXub2MyhU9PnDps DtLAl3igA3C8KWtjsCr/L4Lt3lKObhBsaMJFhFOBKm7RMHuyCkdvRGvnZQCm4qIEWc4H ++YvLIcPbjCylkjdhjPmdcF9RGy2clTxe7+aWlglJBkxFt4C0YIQeFH9JwEZaNkkaAOG kP/UA6WVTAKnRMrQ9JNf/wBzghGy4VbxOUq3cdfHfz6R2By/CHzOPYlL1QSkMydql8aF LQ8w== X-Gm-Message-State: ALoCoQmdoIOxaMsB9m+OIhsnjzqIly1+i4bm/0KVkNX+PJfh3D+5dgceUuD1ududpt06VIR+aJcnOkt9hwf6Bci6mDZQ0d1vkxrBaWBYWV/BLOeNRF4pU30= X-Received: by 10.50.66.167 with SMTP id g7mr2500060igt.22.1437030071932; Thu, 16 Jul 2015 00:01:11 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> In-Reply-To: <55A6A53C.3010009@isi.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE86SdgORCvliHFE703NIXCziGWLQKpHUkGAiiw3coBaHzujgJBSMcpAhGHtOcCr5vwOp6ba0uQ Date: Thu, 16 Jul 2015 09:01:10 +0200 Message-ID: To: Joe Touch , Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 07:01:14 -0000 HI Joe, I generally agree with your comments, but the situations is not necessarily as bad as you say. Please see below. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Joe Touch >Sent: Wednesday, July 15, 2015 8:24 PM >To: Karen Elisabeth Egede Nielsen; Michael Tuexen >Cc: Pal Martinsen (palmarti); taps@ietf.org; touch@isi.edu >Subject: Re: [Taps] TAPS Transports and ICMP > > > >On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote: >... >>>>> Any pitfalls with ICMP when doing SCTP? >>>> >>>> In many ways, SCTP subsumes similar requirements as TCP, but that's >>>> probably buried in the SCTP docs. >>> It is. See >>> https://tools.ietf.org/html/rfc4960#appendix-C >>> >> >> [Karen ] In this context then it is noteworthy to observe that SCTP >> defacto API (spec or implementations, I know) does not prescribe for >> that the SCTP transport passes information of received ICMP messages >> (any kind/type/code) up to SCTP User. >> Here SCTP is significantly different from UDP and TCP defacto APIs. >> >> For security reasons SCTP demands for hard reaction to receipt of >> protocol unreachable, but that is a protocol feature not an api issue. > >Agreed, however the other ways that SCTP doesn't pass validated ICMPs to >the user seems like a mistake to me. > [Karen ] I agree and we have for our SW recently discussed as to whether we should implement such notification following the UDP and TCP semantics. But at present none of our applications has the need (on why that is, see below). >In particular, destination unreachables can cause the SCTP connection to go [Karen ] MAY force. And this MAY of the RFC I (and we) believe is questionable. We believe that for an implementation to support this MAY the implementation MUST implement dormant state handling as described (right now) in the SCTP Failover draft = SCTP continues to transmit data also when the destinations are considered unreachable. (and our SCTP implementations do this). Further we think that the appropriate soft reaction to ICMP destination unreachable is to increment the path error counter, NOT to mark the destination as INACTIVE. Hopefully we will see these things be clarified in future SCTP drafts or ideally in the eventual RFC4960 revision. >into a dead state (mark the dest unreachable or increment the path error >counter) without indicating anything to the user. > [Karen ] The state is not dead if "appropriate" dormant state handling is implemented. >This seems incorrect to me, given the number of other ways in which SCTP can >shut down a connection (heartbeat failure, retransmission failre) and is >supposed to pass that info to the user. > [Karen ] I agree that when the association is closed as a direct result of receipt of ICMPs then this should be communicated to the Users. The envisaged approach (from our side) is to define a new error code for the sac_error of the SCTP_ASSOC_CHANGE (the notification of comm_LOST): sac_error: If the state was reached due to an error condition (e.g., SCTP_COMM_LOST), any relevant error information is available in this field. This corresponds to the protocol error codes defined in [RFC4960]. Right now we have the possibility to use proprietary error codes here, but we would like to go beyond that of course. For the destination error counter the information goes into the spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of destination address unreachability). PLEASE allow me to explain the abstract API in terms of a concrete one. I do understand the difference. The new thing is that the abstract transport API, which if nothing else exists in our heads and in our overall modeling, now with TAPS, may be defined as a concrete one. And I agree with everybody else that this is a good exercise and that it is doomed to (correct and) improve things substantially. >So, IMO, this is a great example of why studying these APIs as abstractions is >important and would have prevented this (IMO) oversight. [Karen ] We have studied this. But is only bringing this to the IETF now. Possibly to be addressed for RFC4960 revision. > >Or can someone in the SCTP team explain why shutting connections down >due to other reasons is a user signal but validated ICMP signals are not? [Karen ] NA. > >Joe > >_______________________________________________ >Taps mailing list >Taps@ietf.org >https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jul 16 00:27:16 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 72C091B36D2 for ; Thu, 16 Jul 2015 00:27:14 -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 YyWbxkEyYede for ; Thu, 16 Jul 2015 00:27:13 -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 3FFED1B36D0 for ; Thu, 16 Jul 2015 00:27:11 -0700 (PDT) Received: by iggf3 with SMTP id f3so7289167igg.1 for ; Thu, 16 Jul 2015 00:27:11 -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=Fc7hjLSQFUUHJPJ4Iv+mHey7zSPdvmavehcuBLR2Z28=; b=iRPUs2WAgJ3KmUSKZNOTthgyNJg0xZkStU6FaMHQqJ4EFFtpYRfXIRKjfzzRs0wO86 694ZpmQ+J8Ianj8GQy/jMbdDbmMx2rDkSAuyJi+bv+dxImlLIPmpqK5YWDfLU7+vRpkn RHdmsfL5uvC5yNnsTsiqwsPK9XSCUu3YAYPCk= 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=Fc7hjLSQFUUHJPJ4Iv+mHey7zSPdvmavehcuBLR2Z28=; b=d+EogQuBzA86XapfIXiP+OXeJNbqrT3Yysjtem8wf3t3berZyptLsBQis5RLuvhrsN fES0gtjtjzG+yVJ0ACvHtm7eJRc4iRIjm/RegFAfJ5pVZsWufoHgX5SBZANg6itNA9Oa 0gNxg8iNkwmeGh66mgsDDTDOvtP0LWgp89ntnY2dKKJzWnfDO8C/VilwJ5tD882PksiQ 7dGD/wUyN0G6wmTRGfhZI0G6La+x0gmUCGfanRos+gdCNhy0U6rXgbcV8qIVWi4M/QN4 lEm810+ZvboYMUeUqbl+TKaKKe9bSOAAVTuRgN/ewt+YTeT4KYUsP/rMq+W5/yKs7Jka IamQ== X-Gm-Message-State: ALoCoQlicTv+T+WoEWbrYtO04zarEV/iNdJ5YnICVw1XNPRdYMEBNHZWNTx5jCaUH/Hj/H8CDDhFewB36LEnkbj+W+Kkdi7/n1VTvtidp5oCMtvf79DsTio= X-Received: by 10.107.136.160 with SMTP id s32mr9925684ioi.174.1437031631491; Thu, 16 Jul 2015 00:27:11 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150706220631.6336.219.idtracker@ietfa.amsl.com> <456cadf6d459a1c9e2c508af7b5470de@mail.gmail.com> <55A6A31B.3090500@isi.edu> In-Reply-To: <55A6A31B.3090500@isi.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG/A9yO7NWA5qgnOWhDhpN5Pi0yHwGWuaxVAVccKzyd6bUoEA== Date: Thu, 16 Jul 2015 09:27:10 +0200 Message-ID: <0047fc6ff18d95970285941d02534db4@mail.gmail.com> To: Joe Touch , 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-06.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, 16 Jul 2015 07:27:14 -0000 HI Joe, > > >On 7/15/2015 7:51 AM, Karen Elisabeth Egede Nielsen wrote: >> Hi, >> >> Please find a very few comments to the document. Nothing major. Please >> use if you see fit and only then :-) >> >> Section 1: End First Paragraph: >> >> Here it is said that a transport service feature may be minimal latency. >> Opposed to the other features listed here, like e.g. in-order or >> reliable delivery, then minimal latency seems a more delicate >> obtainable feature; How one best obtain it within the services >> provided by a certain transport protocol, may depend quite heavily on >> the application traffic pattern (unless CPU and network resources are >> unlimited). >> Also minimal latency is not a feature which any of the protocols >> described in the document has within its list of features (I think) or >> are you thinking minimal latency and best effort transport service >> (like >> UDP) - Or are you thinking some smart protocol of the future which >> will deduce how to best provide a minimal latency service for a >> particular application flow over a specific E-to-E path ? > >FWIW, UDP doesn't minimize latency; it (arguably) minimizes the latency >created by the transport layer at the expense of ordered, reliable delivery and >congestion control. > [Karen ] I agree. >So there are several levels of the latency issue: > > - minimize the latency ADDED by the transport layer > - reduce the latency seen by the app > (which can involve more active interaction with the network > layer, anticipation, etc.) > >Note also that latency is not a single metric nor a meaningful standalone >metric: > > 1. latency between two parties is a property *of a message*, > i.e., it requires knowing the message size > > 2. latency includes both basic and higher order effects; > the basic is "delay", the higher order include "jitter" etc. > Many common delay-sensitive use cases are really mostly > jitter sensitive. > >... [Karen ] I agree so what do we mean in this document when we say that a transport service feature can be to provide minimal latency ? Are we thinking about Nagle OFF ? >> I am not sure if Connection oriented and Feature negotiation should >> be split into two features ? > >If you don't share state (i.e., what we tend to call a "connection"), what is the >meaning of feature negotiation? > [Karen ] Yes, but does connection oriented necessarily means that you can negotiate features ? >... >> Disabling Nagle does not always give the lowest latency and further >> then I think that we are missing the good side of Nagle in the present text. > >Nagle reduces the number of small packets at the expense of introducing >transport delay. Turning it off increases the number of small packets and >reduces the transport delay. > >Although it's theoretically possible for the larger number of packets to cause >delays larger than those that Nagle aggregation would induce, in practice the >Nagle delays are several orders of magnitude larger. > >Using byte-based congestion control, the larger number of packets would >have no effect. Using packet-based congestion control, the larger number of >packets would reduce latency (by opening up the window faster, keeping it >open longer, etc.) unless the increased number of packets itself is the >bottleneck. > >So the general assumption that turning off Nagle will reduce latency should be >reasonable. [Karen ] I agree with this as a general assumption. But when I read the paragraph in the doc it almost sounds as if turning Nagle off comes with no price. Do you have a counterexample seen in the wild? > [Karen ] Yes we have examples with NO Nagle where the number of packets then becomes the bottleneck. In the local ends (CPU) as well as in the infrastructure elements. I am not sure how much of this information I can share. I can try to find out. That is why I was saying that how to provide minimal latency may depend on the application traffic. How to solve also depends on whether it is the average latency that needs to be minimal or whether the latency for some particular application "messages" should be kept as low as possible. For SCTP we allow for that Nagle is disabled on some streams (streams with high scheduling priority) and not on others. This is done exactly for this purpose. (There is an IPR on this I have to say). BR, Karen >Joe From nobody Thu Jul 16 00:57: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 D1C5B1B372B for ; Thu, 16 Jul 2015 00:57:26 -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 0qNKIRoKcP9X for ; Thu, 16 Jul 2015 00:57:25 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 A57B91B372E for ; Thu, 16 Jul 2015 00:57:25 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so7755353igb.0 for ; Thu, 16 Jul 2015 00:57:25 -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=dL6H4YJ4HnSFxjTEZKck2e+sRgAve008Se94iGgGci4=; b=3+6sjnlcPcC1GdfoSTRx/iZthl102dpITkJIFQPnr7sbSnuMUAtU79UlT9EemX7jH7 B5I1yyAQ4FB0/NkhlgbLoYSCxINO5uzQEsCoIejZdkvVnTMSpWS6QBAmjZDc2fjbhB8o +tPTrDK2TkOmXHMOKM65jUaVkxxA97t63+/r0= 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=dL6H4YJ4HnSFxjTEZKck2e+sRgAve008Se94iGgGci4=; b=iGVRtYB4GMGEW1xevTl+R/EhZwResLvQzy241UCL3pIoiQ53R2Bd+Nq8cCQ0a1DZOa Ot3tdL8jUaFUPeQzZnxZJvxwJSErOlZI2aoNYUuYmmx9/BOEpsQsbi+/3yDxhl7kPudm F2XemUV2SStNPPwDsDjbxEZmFtQb2PUEWIEvYDBuesvX0qSo5phDjwfpGg4bYQvZEppH rXO3Sb2Juwzv31DhBD6DE56bEbe4JT6F2lbFWqYTV9rs2mEpXHVCvO+qu1aDAwV2ahDN HXzVnAa9BdA2l4VmWQKkqX7wb2rSkFZu2VFV7tAzDCqbDcnY1tnzPgo9PCR9EmZuiq9l 3kmA== X-Gm-Message-State: ALoCoQkK3VzWfHRnniQW580l7iz62Rsf/jA1BrzS5DdIYWrVwL5DWIrki021sh/NzkCuN9XfEq2djzn23VsgGGMug/yI2Ga5qyPEgr7DthESfSdTrRE0afw= X-Received: by 10.50.143.37 with SMTP id sb5mr1685176igb.13.1437033445101; Thu, 16 Jul 2015 00:57:25 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> <55A6A3C9.3040003@isi.edu> In-Reply-To: <55A6A3C9.3040003@isi.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMzp8FqXoBXDicXbg77ws60nWQywLXHxAwAlSEXMwBP4SU2gKV6VB4AmKwcTcB5nTT9gHAucYsnO1DSlA= Date: Thu, 16 Jul 2015 09:57:24 +0200 Message-ID: <9ec98209ec4b692bf9c172eec0c86711@mail.gmail.com> To: Joe Touch , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: Brian Trammell , Michael Welzl , taps@ietf.org Subject: Re: [Taps] TCP components 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, 16 Jul 2015 07:57:27 -0000 HI, I was thinking about the PUSH flag mainly. In our socket api implementation we do not allow for set of PUSH in send calls nor do we provide the PUSH flag indication upwards on the receiver side. I think that after RFC793 it has been clarified that TCP MAY allow for set of PUSH flag in send() and MAY OPTIONALLY provide this information upwards on the receiver side. I think that it would be questionable to follow RFC793 wording here on PUSH. I have no much experience with the URGENT flag - we actually don't support it, which I agree to be non-compliant. Perhaps the API parts of RFC793 is right, whereas it is only the function as such that has been clarified later. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Joe Touch >Sent: Wednesday, July 15, 2015 8:18 PM >To: Karen Elisabeth Egede Nielsen; Mirja K=C3=BChlewind >Cc: Brian Trammell; taps@ietf.org; Michael Welzl; touch@isi.edu >Subject: Re: [Taps] TCP components > > > >On 7/15/2015 2:03 AM, Karen Elisabeth Egede Nielsen wrote: >> HI Mirja, All >> >> Sorry for jumping late into this discussion. >... >> I really do not think that it makes much sense to look into outdated >> and deprecated APIs as specified in RFC793 and RFC4960 when we have >> better material available. > >What portion of RFC793's API do you consider outdated? > >AFAICT, it's exactly what most sockets try to support (I can't speak about >SCTP, as I haven't used it much). > >Joe > >_______________________________________________ >Taps mailing list >Taps@ietf.org >https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jul 16 01:49:32 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 3CC011B37AF for ; Thu, 16 Jul 2015 01:49:30 -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 XMbkyMVcrf4q for ; Thu, 16 Jul 2015 01:49:27 -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 662481B37AD for ; Thu, 16 Jul 2015 01:49:27 -0700 (PDT) Received: from [192.168.1.200] (p4FE31A5B.dip0.t-ipconnect.de [79.227.26.91]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5E4671C0B462F; Thu, 16 Jul 2015 10:49:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Tuexen In-Reply-To: Date: Thu, 16 Jul 2015 10:49:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 08:49:30 -0000 > On 16 Jul 2015, at 09:01, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI Joe, >=20 > I generally agree with your comments, but the situations is not > necessarily as bad as you say. > Please see below. >=20 > BR, Karen >=20 >> -----Original Message----- >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Wednesday, July 15, 2015 8:24 PM >> To: Karen Elisabeth Egede Nielsen; Michael Tuexen >> Cc: Pal Martinsen (palmarti); taps@ietf.org; touch@isi.edu >> Subject: Re: [Taps] TAPS Transports and ICMP >>=20 >>=20 >>=20 >> On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote: >> ... >>>>>> Any pitfalls with ICMP when doing SCTP? >>>>>=20 >>>>> In many ways, SCTP subsumes similar requirements as TCP, but = that's >>>>> probably buried in the SCTP docs. >>>> It is. See >>>> https://tools.ietf.org/html/rfc4960#appendix-C >>>>=20 >>>=20 >>> [Karen ] In this context then it is noteworthy to observe that SCTP >>> defacto API (spec or implementations, I know) does not prescribe for >>> that the SCTP transport passes information of received ICMP messages >>> (any kind/type/code) up to SCTP User. >>> Here SCTP is significantly different from UDP and TCP defacto APIs. >>>=20 >>> For security reasons SCTP demands for hard reaction to receipt of >>> protocol unreachable, but that is a protocol feature not an api = issue. >>=20 >> Agreed, however the other ways that SCTP doesn't pass validated ICMPs = to >> the user seems like a mistake to me. >>=20 > [Karen ] I agree and we have for our SW recently discussed as to = whether > we should implement such notification following > the UDP and TCP semantics. But at present none of our applications has = the > need (on why that is, see below). Hi Karen, can you elaborate what ICMP related information you provide for TCP? My understanding is that if you follow https://tools.ietf.org/html/rfc1122#section-4.2.3.9 and ignore Source Quench as specified in https://tools.ietf.org/html/rfc6633 you end up honouring Destination Unreachable (protocol unreachable, port unreachable or fragmentation needed and DF set). I guess you can handle this similar to an TCP RST in the API. Note: Not sure why "fragmentation needed and DF" SHOULD result in an abort. I would just use the information or PMTUD... I'm not sure how you expose Net unreachable, host unreachable or source route failed in the API. I think the sockets API doesn't do this. For SCTP, the port unreachable is ignored and for the protocol = unreachable it is a MUST abort. For the Net unreachable, host unreachable you might use this to indicate some soft error. However, the user is provided with the information, if requested, either about an association or path state change. Best regards Michael >=20 >> In particular, destination unreachables can cause the SCTP connection = to > go > [Karen ] MAY force. And this MAY of the RFC I (and we) believe is > questionable. We believe that > for an implementation to support this MAY the implementation MUST > implement dormant state handling as > described (right now) in the SCTP Failover draft =3D SCTP continues to > transmit data also when the destinations are considered unreachable. > (and our SCTP implementations do this). Further we think that the > appropriate soft reaction to ICMP destination unreachable is to = increment > the path error counter, > NOT to mark the destination as INACTIVE. > Hopefully we will see these things be clarified in future SCTP drafts = or > ideally in the eventual RFC4960 revision. >=20 >> into a dead state (mark the dest unreachable or increment the path = error >> counter) without indicating anything to the user. >>=20 > [Karen ] The state is not dead if "appropriate" dormant state handling = is > implemented. >=20 >> This seems incorrect to me, given the number of other ways in which = SCTP > can >> shut down a connection (heartbeat failure, retransmission failre) and = is >> supposed to pass that info to the user. >>=20 > [Karen ] I agree that when the association is closed as a direct = result > of receipt of ICMPs then this should be communicated to the Users. > The envisaged approach (from our side) is to define a new error code = for > the sac_error of the SCTP_ASSOC_CHANGE (the notification of = comm_LOST): >=20 > sac_error: If the state was reached due to an error condition = (e.g., > SCTP_COMM_LOST), any relevant error information is available in > this field. This corresponds to the protocol error codes defined > in [RFC4960]. >=20 > Right now we have the possibility to use proprietary error codes here, = but > we would like to go beyond that of course. >=20 > For the destination error counter the information goes into the = spc_error > of the SCTP_PEER_ADDR_CHANGE (the notification of destination address > unreachability). >=20 > PLEASE allow me to explain the abstract API in terms of a concrete = one. I > do understand the difference. > The new thing is that the abstract transport API, which if nothing = else > exists in our heads and in our overall modeling, now with TAPS, may be > defined as a concrete one. > And I agree with everybody else that this is a good exercise and that = it > is doomed to (correct and) improve things substantially. >=20 >> So, IMO, this is a great example of why studying these APIs as > abstractions is >> important and would have prevented this (IMO) oversight. > [Karen ] We have studied this. But is only bringing this to the IETF = now. > Possibly to be addressed for RFC4960 revision. >>=20 >> Or can someone in the SCTP team explain why shutting connections down >> due to other reasons is a user signal but validated ICMP signals are = not? > [Karen ] NA. >>=20 >> Joe >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Thu Jul 16 01:56: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 A9D871A0087 for ; Thu, 16 Jul 2015 01:56:18 -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 aeiAZSn0sP5Z for ; Thu, 16 Jul 2015 01:56:17 -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 47E741A0063 for ; Thu, 16 Jul 2015 01:56:17 -0700 (PDT) Received: from [192.168.1.200] (p4FE31A5B.dip0.t-ipconnect.de [79.227.26.91]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7C27F1C0C0BCE; Thu, 16 Jul 2015 10:56:15 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Tuexen In-Reply-To: <55A6A53C.3010009@isi.edu> Date: Thu, 16 Jul 2015 10:56:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82885842-4A90-479B-AB5E-34D8286E1A03@lurchi.franken.de> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Karen Elisabeth Egede Nielsen , "Pal Martinsen \(palmarti\)" , taps@ietf.org Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 08:56:18 -0000 > On 15 Jul 2015, at 20:23, Joe Touch wrote: >=20 >=20 >=20 > On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote: > ... >>>>> Any pitfalls with ICMP when doing SCTP? >>>>=20 >>>> In many ways, SCTP subsumes similar requirements as TCP, but that's >>>> probably buried in the SCTP docs. >>> It is. See >>> https://tools.ietf.org/html/rfc4960#appendix-C >>>=20 >>=20 >> [Karen ] In this context then it is noteworthy to observe that SCTP = defacto >> API (spec or implementations, I know) >> does not prescribe for that the SCTP transport passes information of >> received ICMP messages (any kind/type/code) up to SCTP User. >> Here SCTP is significantly different from UDP and TCP defacto APIs. >>=20 >> For security reasons SCTP demands for hard reaction to receipt of = protocol >> unreachable, >> but that is a protocol feature not an api issue. >=20 > Agreed, however the other ways that SCTP doesn't pass validated ICMPs = to > the user seems like a mistake to me. >=20 > In particular, destination unreachables can cause the SCTP connection = to > go into a dead state (mark the dest unreachable or increment the path > error counter) without indicating anything to the user. >=20 > This seems incorrect to me, given the number of other ways in which = SCTP > can shut down a connection (heartbeat failure, retransmission failre) > and is supposed to pass that info to the user. >=20 > So, IMO, this is a great example of why studying these APIs as > abstractions is important and would have prevented this (IMO) = oversight. Can you say specifically, what has been missed? My understanding is that SCTP and TCP are similar in respect to ICMP = processing with the difference that (a) SCTP ignore ICMP destination unreachable, port unreachable (b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an = ICMP destination unreachable, protocol unreachable similar to an SCTP = ABORT. The reason is that there are no legacy SCTP stacks sending ICMP = destination unreachable, port unreachable, so (a) is appropriate. (b) is for protecting hosts = that don't support SCTP. The "handle like an ABORT" includes notifying the application. The handling of ICMP Destination unreachable (host or network = unreachable) is similar to the TCP case. If there is an SCTP state change, the user will be notified if requested. Best regards Michael >=20 > Or can someone in the SCTP team explain why shutting connections down > due to other reasons is a user signal but validated ICMP signals are = not? >=20 > Joe >=20 From nobody Thu Jul 16 02:09:53 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 746861A6EE7 for ; Thu, 16 Jul 2015 02:09:51 -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 o2qZkDogq0YY for ; Thu, 16 Jul 2015 02:09:49 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 E0F501A21BC for ; Thu, 16 Jul 2015 02:09:48 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so9057202igc.0 for ; Thu, 16 Jul 2015 02:09:48 -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=7QL6NUymb5G9LsfHxRA7SHGEm2hnOSTDG/T5MWiN0B8=; b=DPFNWvVuCazx0CO2IBh704UuLlIeCj35hZgnQZZ0GsNG53neuo9xMLp5n49/Kx8Uvu NE4m9WwzxcWEBnehWpq79u+tmsraxJY8Y4qAXHb7Xgzwg5hjchrHESeenASACmxdWzwC RYDXJ95JPY+rcSZUjInnJiquziJn92Cu4IeRI= 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=7QL6NUymb5G9LsfHxRA7SHGEm2hnOSTDG/T5MWiN0B8=; b=akS+gto0tFDAptRu8X+k/YgDAvJQcm146x79NBGkrED9A8v23kPrDLiFpvXnNUMJdh zyRuljfkHJAUSJkYOO4dEapMVXQhVr0yylFemZ/BN5V9+6jDNESIKpJ/IWUg7eUWu8Pm M01aQ3cDXStEaANSmb2HSAFc9Dz/B6URx9oF4YP0fVXDbD6S+rx2F83wPA9BHkxOYetx TcRWzR5IwNzLffjqBer2b2AlonayjeUrZFYsXQZ09Gxwc3xh59zNehUrrLlrGyuRq7sv asZfNbjiMAYBfVyJafXO6Uy2rF9yUkwqvJUNEFK3B/H/Jz7gEHCdiRjyd8hXkkjvtD4y cUPg== X-Gm-Message-State: ALoCoQkeM6VbnARt8f+owYIlVr2cDa0pxZRR7Hwn5T7C474yv9Q11YFgENUlTlEC5KZyRAiyhWJVCgrcAw90lt9PTZk9slB+9CQAiiOhGkrWLaYDkcA3jpQ= X-Received: by 10.107.167.2 with SMTP id q2mr11426325ioe.109.1437037788374; Thu, 16 Jul 2015 02:09:48 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> In-Reply-To: <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE86SdgORCvliHFE703NIXCziGWLQKpHUkGAiiw3coBaHzujgJBSMcpAhGHtOcCr5vwOgHu+g0GAbkLt5OeflP6UA== Date: Thu, 16 Jul 2015 11:09:47 +0200 Message-ID: To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 09:09:51 -0000 HI Michael, >>> Agreed, however the other ways that SCTP doesn't pass validated ICMPs >>> to the user seems like a mistake to me. >>> >> [Karen ] I agree and we have for our SW recently discussed as to >> whether we should implement such notification following the UDP and >> TCP semantics. But at present none of our applications has the need >> (on why that is, see below). >Hi Karen, > >can you elaborate what ICMP related information you provide for TCP? > [Karen ] We provide information about received destination unreachable ICMPs to users via socket api. The same we do for (connected) UDP. This we could also do for SCTP, but as said we don't do it (yet). >My understanding is that if you follow >https://tools.ietf.org/html/rfc1122#section-4.2.3.9 >and ignore Source Quench as specified in >https://tools.ietf.org/html/rfc6633 >you end up honouring Destination Unreachable (protocol unreachable, port >unreachable or fragmentation needed and DF set). I guess you can handle this >similar to an TCP RST in the API. >Note: Not sure why "fragmentation needed and DF" SHOULD result in an >abort. I would just use the information or PMTUD... >I'm not sure how you expose Net unreachable, host unreachable or source >route failed in the API. I think the sockets API doesn't do this. > >For SCTP, the port unreachable is ignored and for the protocol unreachable it >is a MUST abort. For the Net unreachable, host unreachable you might use >this to indicate some soft error. [Karen ] This might (the MAY) results in hard trouble if the association is closed due to entering of dormant state. That's why we believe that this MAY reaction should be coupled with robust dormant state handling. However, the user is provided with the >information, if requested, either about an association or path state change. [Karen ] Yes, but the user is not provided with the information that the association was closed due to the receipt ICMPs. [Karen ] Yes, but even if the information is provided, then closing the association does not constitute a soft reaction. BR, Karen > >Best regards >Michael >> >>> In particular, destination unreachables can cause the SCTP connection >>> to >> go >> [Karen ] MAY force. And this MAY of the RFC I (and we) believe is >> questionable. We believe that for an implementation to support this >> MAY the implementation MUST implement dormant state handling as >> described (right now) in the SCTP Failover draft = SCTP continues to >> transmit data also when the destinations are considered unreachable. >> (and our SCTP implementations do this). Further we think that the >> appropriate soft reaction to ICMP destination unreachable is to >> increment the path error counter, NOT to mark the destination as >> INACTIVE. >> Hopefully we will see these things be clarified in future SCTP drafts >> or ideally in the eventual RFC4960 revision. >> >>> into a dead state (mark the dest unreachable or increment the path >>> error >>> counter) without indicating anything to the user. >>> >> [Karen ] The state is not dead if "appropriate" dormant state handling >> is implemented. >> >>> This seems incorrect to me, given the number of other ways in which >>> SCTP >> can >>> shut down a connection (heartbeat failure, retransmission failre) and >>> is supposed to pass that info to the user. >>> >> [Karen ] I agree that when the association is closed as a direct >> result of receipt of ICMPs then this should be communicated to the Users. >> The envisaged approach (from our side) is to define a new error code >> for the sac_error of the SCTP_ASSOC_CHANGE (the notification of >comm_LOST): >> >> sac_error: If the state was reached due to an error condition (e.g., >> SCTP_COMM_LOST), any relevant error information is available in >> this field. This corresponds to the protocol error codes defined >> in [RFC4960]. >> >> Right now we have the possibility to use proprietary error codes here, >> but we would like to go beyond that of course. >> >> For the destination error counter the information goes into the >> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >> destination address unreachability). >> >> PLEASE allow me to explain the abstract API in terms of a concrete >> one. I do understand the difference. >> The new thing is that the abstract transport API, which if nothing >> else exists in our heads and in our overall modeling, now with TAPS, >> may be defined as a concrete one. >> And I agree with everybody else that this is a good exercise and that >> it is doomed to (correct and) improve things substantially. >> >>> So, IMO, this is a great example of why studying these APIs as >> abstractions is >>> important and would have prevented this (IMO) oversight. >> [Karen ] We have studied this. But is only bringing this to the IETF now. >> Possibly to be addressed for RFC4960 revision. >>> >>> Or can someone in the SCTP team explain why shutting connections down >>> due to other reasons is a user signal but validated ICMP signals are not? >> [Karen ] NA. >>> >>> Joe >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> From nobody Thu Jul 16 02:22: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 AEDA21A8724 for ; Thu, 16 Jul 2015 02:22:55 -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 ZzpU12VaCDAg for ; Thu, 16 Jul 2015 02:22:54 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 149E51A871E for ; Thu, 16 Jul 2015 02:22:54 -0700 (PDT) Received: by iggp10 with SMTP id p10so8940181igg.0 for ; Thu, 16 Jul 2015 02:22:53 -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:cc :content-type; bh=tbQ85zcWhej3fLlK7p/JpUK4ieF++VJIVdy5k7G/cr0=; b=NGdaWRyErhvzsDFDw4kvw4cQqgUo2Tu3GMiKyShKekSxcpMyHYctJXvQDWRl/2WVEj 73iYLLpdsTWqJ8Wk7J4wGBLicS56BATQm+rYQrigFPgeykEHDMS5PVqnk3gXWYLS/kNr wo21sETGdZ0sfg/4L5aMlOlGQEG8wtr+rjIgQ= 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:cc:content-type; bh=tbQ85zcWhej3fLlK7p/JpUK4ieF++VJIVdy5k7G/cr0=; b=VZdSi6eVwcopR/0J7Ig0erSleMxT6tlT+DeUJXF7zEgwCyfTEulk6l1eF9CvujRDt5 dx1wz557R9Ojs4iJ3nohO11s7uQzupoNhWBARzZeL9HJcjxwsejkbMlWtw/+d2QVrEj3 L+QFl8fOG11S+y1Li1zG//iBEjnA3MyPqDJOXr83E3hDFpDpf9fv22M/6G5xTS0O/yaC X6wSHxXHLaUbF2Zs/TbyjYcleQIWNsdSWo6KevOKeahpzRpeeTiFVnKE8Z2Ula3Kjojz aT/fOEvZlUtFg0qCrQ7iUueIqOYp7ZcVENcSfFhK4k/Ch2rnJAuiV30SXEhvv8ZwVKRl cE1g== X-Gm-Message-State: ALoCoQkqHQoKa4bHhrY60TJocy4GuZBUoNSr4CpdqOQmtHen6mkAsuAmyLoAZKVTXD1cKcAGOnGD4PrLaYO4GBQLglayTNYAcCrIzGbfXbqWWUUhcEnRfhA= X-Received: by 10.107.167.2 with SMTP id q2mr11491524ioe.109.1437038573413; Thu, 16 Jul 2015 02:22:53 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC/qP3G6CRs7LiBSOiwXCHGIUBxIQ== Date: Thu, 16 Jul 2015 11:22:52 +0200 Message-ID: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com> To: Michael Welzl , taps WG Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: Stein Gjessing Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-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: Thu, 16 Jul 2015 09:22:55 -0000 HI, A few initial comments the definition of the transport service features as they appear from section 3 (and TAPS1): Unidirectional/bidirectional: I am not sure what this means exactly: Does it refer to that data transfer is negotiated for both directions perhaps ? But then it only applies to connection oriented transport. Does it refer to that control info is going back ? Does it refer to that messages (which ever form) are going back on the reverse network path ? Then it does not necessarily apply to SCTP MH. o non-reliable delivery: add SCTP o reliable delivery: add SCTP Suggest to rephrase o reliable and partially reliable delivery --> o partially reliable delivery: SCTP o drop notification : add SCTP o ordered delivery: add SCTP o unordered delivery: add SCTP Ideally, I think, then one would use a common term for Nagle(-like) bundling for TCP and SCTP. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Welzl >Sent: Friday, June 26, 2015 9:22 AM >To: taps WG >Cc: Stein Gjessing >Subject: [Taps] Fwd: New Version Notification for draft-gjessing-taps-minset- >00.txt > >Dear all, > >This is a very first stab at a draft addressing the charter's second item - the >minimal set of transport services that end systems should support. > >It is based on version 4 of draft-ietf-taps-transports, so the list of features / >components is not up to date - but that's not really the main point of the >document for now anyway: >it's about showing how the number of exposed services *could* be reduced. >Our hope is that, by sketching the possible destination of our journey, this >helps the current discussion of the first document. > >Cheers, >Michael > > > >> Begin forwarded message: >> >> From: >> Subject: New Version Notification for >> draft-gjessing-taps-minset-00.txt >> Date: 22 Jun 2015 14:37:43 CEST >> To: Michael Welzl , Stein Gjessing >> , Stein Gjessing , Michael Welzl >> >> Resent-From: >> >> >> A new version of I-D, draft-gjessing-taps-minset-00.txt has been >> successfully submitted by Michael Welzl and posted to the IETF >> repository. >> >> Name: draft-gjessing-taps-minset >> Revision: 00 >> Title: A Minimal Set of Transport Services for TAPS Systems >> Document date: 2015-06-22 >> Group: Individual Submission >> Pages: 10 >> URL: https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset- >00.txt >> Status: https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ >> Htmlized: https://tools.ietf.org/html/draft-gjessing-taps-minset-00 >> >> >> Abstract: >> This draft will eventually recommend a minimal set of IETF Transport >> Services offered by end systems supporting TAPS, and give guidance on >> choosing among the available mechanisms and protocols. As a starting >> point for discussion, it currently only gives an overview of some >> ways to categorize the set of transport services in the first TAPS >> document (version 4: draft-ietf-taps-transports-04), assuming that >> the eventual minimal set of transport services will be based on a >> similar form of categorization. >> >> >> >> >> 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 From nobody Thu Jul 16 02:40:39 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 5EAD41A87BA for ; Thu, 16 Jul 2015 02:40:37 -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 w99O22rvGATM for ; Thu, 16 Jul 2015 02:40:35 -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 58FFE1A8789 for ; Thu, 16 Jul 2015 02:40:35 -0700 (PDT) Received: from [192.168.1.200] (p4FE31B43.dip0.t-ipconnect.de [79.227.27.67]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 58F891C0B460E; Thu, 16 Jul 2015 11:40:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Tuexen In-Reply-To: Date: Thu, 16 Jul 2015 11:40:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 09:40:37 -0000 > On 16 Jul 2015, at 11:09, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI Michael, >=20 >>>> Agreed, however the other ways that SCTP doesn't pass validated = ICMPs >>>> to the user seems like a mistake to me. >>>>=20 >>> [Karen ] I agree and we have for our SW recently discussed as to >>> whether we should implement such notification following the UDP and >>> TCP semantics. But at present none of our applications has the need >>> (on why that is, see below). >> Hi Karen, >>=20 >> can you elaborate what ICMP related information you provide for TCP? >>=20 > [Karen ] We provide information about received destination unreachable > ICMPs to users via socket api. > The same we do for (connected) UDP. >=20 > This we could also do for SCTP, but as said we don't do it (yet). OK. FreeBSD does this. So it is not an issue with the specification, but an implementation issue. >=20 >> My understanding is that if you follow >> https://tools.ietf.org/html/rfc1122#section-4.2.3.9 >> and ignore Source Quench as specified in >> https://tools.ietf.org/html/rfc6633 >> you end up honouring Destination Unreachable (protocol unreachable, = port >> unreachable or fragmentation needed and DF set). I guess you can = handle > this >> similar to an TCP RST in the API. >> Note: Not sure why "fragmentation needed and DF" SHOULD result in an >> abort. I would just use the information or PMTUD... >> I'm not sure how you expose Net unreachable, host unreachable or = source >> route failed in the API. I think the sockets API doesn't do this. >>=20 >> For SCTP, the port unreachable is ignored and for the protocol > unreachable it >> is a MUST abort. For the Net unreachable, host unreachable you might = use >> this to indicate some soft error. >=20 > [Karen ] This might (the MAY) results in hard trouble if the = association > is closed due to entering of dormant state. > That's why we believe that this MAY reaction should be coupled with = robust > dormant state handling. I think we have to distinguish two things here: 1. When you receive an ICMP message you might increment the path error counter or change the path state. When changing the path state notify the user about it. This is about ICMP handling 2. Deal with the case that all paths are inactive, which means deal with the dormant state. This is NOT related to the ICMP handling, since it doesn't matter how you end up in the dormant state. It might make ending up there more often, but and implementation needs to deal with it anyway. >=20 > However, the user is provided with the >> information, if requested, either about an association or path state > change. > [Karen ] Yes, but the user is not provided with the information that = the > association was closed due to the receipt ICMPs. Correct. But does the application care if the peer sent an ABORT or an ICMP Destination unreachable? I don't think so. And I think both cases are signalled to the application for TCP in the same way. > [Karen ] Yes, but even if the information is provided, then closing = the > association does not constitute a soft reaction. ICMP9) of https://tools.ietf.org/html/rfc4960#appendix-C tells you that it is OK to increment the error counter or mark the destination as unreachable. It is up to you to decide what is appropriate in your implementation. However, you should not increment the association error counter, so it shouldn't be an association failure. An association failure can only occur if you move the path state to unreachable, have no reachable destinations anymore (dormant state) and have decided that this means failing the association. But again, this is related to an, in my view, suboptimal handling of the dormant state. FreeBSD doesn't fail the association in this case. Best regards Michael >=20 > BR, Karen >>=20 >> Best regards >> Michael >>>=20 >>>> In particular, destination unreachables can cause the SCTP = connection >>>> to >>> go >>> [Karen ] MAY force. And this MAY of the RFC I (and we) believe is >>> questionable. We believe that for an implementation to support this >>> MAY the implementation MUST implement dormant state handling as >>> described (right now) in the SCTP Failover draft =3D SCTP continues = to >>> transmit data also when the destinations are considered unreachable. >>> (and our SCTP implementations do this). Further we think that the >>> appropriate soft reaction to ICMP destination unreachable is to >>> increment the path error counter, NOT to mark the destination as >>> INACTIVE. >>> Hopefully we will see these things be clarified in future SCTP = drafts >>> or ideally in the eventual RFC4960 revision. >>>=20 >>>> into a dead state (mark the dest unreachable or increment the path >>>> error >>>> counter) without indicating anything to the user. >>>>=20 >>> [Karen ] The state is not dead if "appropriate" dormant state = handling >>> is implemented. >>>=20 >>>> This seems incorrect to me, given the number of other ways in which >>>> SCTP >>> can >>>> shut down a connection (heartbeat failure, retransmission failre) = and >>>> is supposed to pass that info to the user. >>>>=20 >>> [Karen ] I agree that when the association is closed as a direct >>> result of receipt of ICMPs then this should be communicated to the > Users. >>> The envisaged approach (from our side) is to define a new error code >>> for the sac_error of the SCTP_ASSOC_CHANGE (the notification of >> comm_LOST): >>>=20 >>> sac_error: If the state was reached due to an error condition = (e.g., >>> SCTP_COMM_LOST), any relevant error information is available in >>> this field. This corresponds to the protocol error codes = defined >>> in [RFC4960]. >>>=20 >>> Right now we have the possibility to use proprietary error codes = here, >>> but we would like to go beyond that of course. >>>=20 >>> For the destination error counter the information goes into the >>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >>> destination address unreachability). >>>=20 >>> PLEASE allow me to explain the abstract API in terms of a concrete >>> one. I do understand the difference. >>> The new thing is that the abstract transport API, which if nothing >>> else exists in our heads and in our overall modeling, now with TAPS, >>> may be defined as a concrete one. >>> And I agree with everybody else that this is a good exercise and = that >>> it is doomed to (correct and) improve things substantially. >>>=20 >>>> So, IMO, this is a great example of why studying these APIs as >>> abstractions is >>>> important and would have prevented this (IMO) oversight. >>> [Karen ] We have studied this. But is only bringing this to the IETF > now. >>> Possibly to be addressed for RFC4960 revision. >>>>=20 >>>> Or can someone in the SCTP team explain why shutting connections = down >>>> due to other reasons is a user signal but validated ICMP signals = are > not? >>> [Karen ] NA. >>>>=20 >>>> Joe >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >=20 From nobody Thu Jul 16 03:28: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 D6D821B3916 for ; Thu, 16 Jul 2015 03:28:06 -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 AkiXscrUBr6Q for ; Thu, 16 Jul 2015 03:28:05 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CC61B389C for ; Thu, 16 Jul 2015 03:26:09 -0700 (PDT) Received: by iggf3 with SMTP id f3so9968589igg.1 for ; Thu, 16 Jul 2015 03:26:09 -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=KS7GQ/mcJcg1D3FCvoPmjlnDER0JhR1aiSClsM6B5XA=; b=VQ3TFdph7Q3vZVPE9OcoELMx3jD/6TyGesq0i+31Jx3lzC4JLyISK1E65p4jYdThyH CQU4oLm8RdODAmB4b4lrSgOzhol6Fr+rncQ822BJSDEUXMmwusdzaZ8VHhyjUfLgQs1G W69xmTRHnagQ8mlVuK7X9l6J2WXbo2QAQ2u0Q= 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=KS7GQ/mcJcg1D3FCvoPmjlnDER0JhR1aiSClsM6B5XA=; b=QhzNN/cPJKjy2DlnD+3FAvxtOp+xTRDSBNFGquDosfezp5MRRDepGjBxyDnOWcpoTb CuPOZY2Hv10PRclQSOoqoBZ/Q18f02qrH9jssiAwv/1UH5BGaEk7nE87plaPZMRMr+EA m+RAebfb5IzEPjjjW7lrVq0KAwrWXBLd/5QYPkU3bmj/9M/ro9ga5jhtTvqwMgcvs7kg SVrC1F8AROYWdbe69efDlb5mD+aWL58BaPmOnbtOWTF97/9Xf26vPq0r6zr8xw4CBV+d n1OHzBvf8OwIvtTHQFNJZe+4orQoSIOrdYqJY5bygUtVaR8XeJpkvgpnZd4bbBKOT+a2 HaXA== X-Gm-Message-State: ALoCoQnLBgrnU9EBzWQLopngJc7qFIP7v4PJS0ekN0rlYwbsjdVqSb+0/lv7NIFQl8SqKzVljsfkpS3k8rr4kVBLO83d+iXQozGkiWFAaWPXZM5RF5Y/yQo= X-Received: by 10.107.167.2 with SMTP id q2mr11806943ioe.109.1437042369386; Thu, 16 Jul 2015 03:26:09 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> In-Reply-To: <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE86SdgORCvliHFE703NIXCziGWLQKpHUkGAiiw3coBaHzujgJBSMcpAhGHtOcCr5vwOgHu+g0GAbkLt5MCJc+oBgGuoRj/nl+8pZA= Date: Thu, 16 Jul 2015 12:26:08 +0200 Message-ID: To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 10:28:07 -0000 HI Michael, >> >> [Karen ] This might (the MAY) results in hard trouble if the >> association is closed due to entering of dormant state. >> That's why we believe that this MAY reaction should be coupled with >> robust dormant state handling. >I think we have to distinguish two things here: > [Karen ] Yes, I agree. >1. When you receive an ICMP message you might increment the path error > counter or change the path state. When changing the path state > notify the user about it. This is about ICMP handling [Karen ] Yes. But user is not notified of the receipt of ICMPs. I should perhaps tell that we have some SCTP SW versions that follow the MAY and others which ignores these destination unreachable ICMPs. 2. Deal with the case >that all paths are inactive, which means deal > with the dormant state. This is NOT related to the ICMP handling, > since it doesn't matter how you end up in the dormant state. > It might make ending up there more often, but and implementation > needs to deal with it anyway. >> >> However, the user is provided with the >>> information, if requested, either about an association or path state >> change. >> [Karen ] Yes, but the user is not provided with the information that >> the association was closed due to the receipt ICMPs. >Correct. But does the application care if the peer sent an ABORT or an ICMP >Destination unreachable? [Karen ] For TCP the socket api provides the information. Presumably this is because the application could care. For implementations that do the "suboptimal" dormant state handling and follow the MAY here, then an application would care, I think. >I don't think so. And I think both cases are signalled >to the application for TCP in the same way. >> [Karen ] Yes, but even if the information is provided, then closing >> the association does not constitute a soft reaction. >ICMP9) of https://tools.ietf.org/html/rfc4960#appendix-C tells you that it is >OK to increment the error counter or mark the destination as unreachable. It >is up to you to decide what is appropriate in your implementation. However, >you should not increment the association error counter, so it shouldn't be an >association failure. [Karen ] I agree. >An association failure can only occur if you move the path state to >unreachable, have no reachable destinations anymore (dormant state) and >have decided that this means failing the association. But again, this is related >to an, in my view, suboptimal handling of the dormant state. FreeBSD doesn't >fail the association in this case. [Karen ] I agree that this is suboptimal handling of dormant state. We also do not to this suboptimal handling. I think that one could say that RFC4960 Appendix C prescriptions for how to handle soft icmps could relate to that this can make the assocs enter dormant state fast and that dormant state implementation need to relate to this fact if the MAYs are followed. BR, Karen > >Best regards >Michael >> >> BR, Karen >>> >>> Best regards >>> Michael >>>> >>>>> In particular, destination unreachables can cause the SCTP >>>>> connection to >>>> go >>>> [Karen ] MAY force. And this MAY of the RFC I (and we) believe is >>>> questionable. We believe that for an implementation to support this >>>> MAY the implementation MUST implement dormant state handling as >>>> described (right now) in the SCTP Failover draft = SCTP continues to >>>> transmit data also when the destinations are considered unreachable. >>>> (and our SCTP implementations do this). Further we think that the >>>> appropriate soft reaction to ICMP destination unreachable is to >>>> increment the path error counter, NOT to mark the destination as >>>> INACTIVE. >>>> Hopefully we will see these things be clarified in future SCTP >>>> drafts or ideally in the eventual RFC4960 revision. >>>> >>>>> into a dead state (mark the dest unreachable or increment the path >>>>> error >>>>> counter) without indicating anything to the user. >>>>> >>>> [Karen ] The state is not dead if "appropriate" dormant state >>>> handling is implemented. >>>> >>>>> This seems incorrect to me, given the number of other ways in which >>>>> SCTP >>>> can >>>>> shut down a connection (heartbeat failure, retransmission failre) >>>>> and is supposed to pass that info to the user. >>>>> >>>> [Karen ] I agree that when the association is closed as a direct >>>> result of receipt of ICMPs then this should be communicated to the >> Users. >>>> The envisaged approach (from our side) is to define a new error code >>>> for the sac_error of the SCTP_ASSOC_CHANGE (the notification of >>> comm_LOST): >>>> >>>> sac_error: If the state was reached due to an error condition (e.g., >>>> SCTP_COMM_LOST), any relevant error information is available in >>>> this field. This corresponds to the protocol error codes defined >>>> in [RFC4960]. >>>> >>>> Right now we have the possibility to use proprietary error codes >>>> here, but we would like to go beyond that of course. >>>> >>>> For the destination error counter the information goes into the >>>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >>>> destination address unreachability). >>>> >>>> PLEASE allow me to explain the abstract API in terms of a concrete >>>> one. I do understand the difference. >>>> The new thing is that the abstract transport API, which if nothing >>>> else exists in our heads and in our overall modeling, now with TAPS, >>>> may be defined as a concrete one. >>>> And I agree with everybody else that this is a good exercise and >>>> that it is doomed to (correct and) improve things substantially. >>>> >>>>> So, IMO, this is a great example of why studying these APIs as >>>> abstractions is >>>>> important and would have prevented this (IMO) oversight. >>>> [Karen ] We have studied this. But is only bringing this to the IETF >> now. >>>> Possibly to be addressed for RFC4960 revision. >>>>> >>>>> Or can someone in the SCTP team explain why shutting connections >>>>> down due to other reasons is a user signal but validated ICMP >>>>> signals are >> not? >>>> [Karen ] NA. >>>>> >>>>> Joe >>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>> >> From nobody Thu Jul 16 03:45:37 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 7A4021B38E5 for ; Thu, 16 Jul 2015 03:45:36 -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 WldgwmSrKyZ7 for ; Thu, 16 Jul 2015 03:45:31 -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 599C51A8833 for ; Thu, 16 Jul 2015 03:45:31 -0700 (PDT) Received: from [192.168.1.200] (p4FE31B43.dip0.t-ipconnect.de [79.227.27.67]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0C42B1C0C0BCE; Thu, 16 Jul 2015 12:45:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Tuexen In-Reply-To: Date: Thu, 16 Jul 2015 12:45:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 10:45:36 -0000 > On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI Michael, >>>=20 >>> [Karen ] This might (the MAY) results in hard trouble if the >>> association is closed due to entering of dormant state. >>> That's why we believe that this MAY reaction should be coupled with >>> robust dormant state handling. >> I think we have to distinguish two things here: >>=20 > [Karen ] Yes, I agree. >=20 >> 1. When you receive an ICMP message you might increment the path = error >> counter or change the path state. When changing the path state >> notify the user about it. This is about ICMP handling > [Karen ] > Yes. But user is not notified of the receipt of ICMPs. >=20 > I should perhaps tell that we have some SCTP SW versions that follow = the > MAY and others which ignores these > destination unreachable ICMPs. >=20 > 2. Deal with the case >> that all paths are inactive, which means deal >> with the dormant state. This is NOT related to the ICMP handling, >> since it doesn't matter how you end up in the dormant state. >> It might make ending up there more often, but and implementation >> needs to deal with it anyway. >>>=20 >>> However, the user is provided with the >>>> information, if requested, either about an association or path = state >>> change. >>> [Karen ] Yes, but the user is not provided with the information that >>> the association was closed due to the receipt ICMPs. >> Correct. But does the application care if the peer sent an ABORT or = an > ICMP >> Destination unreachable? >=20 > [Karen ] For TCP the socket api provides the information. How? Isn't it the same as for SCTP? A system call returns -1 and errno is set to some value line ECONNRESET or ECONNREFUSED? I think the user can't distinguish from receiving an TCP RST. Am I missing something? > Presumably this is because the application could care. > For implementations that do the "suboptimal" dormant state handling = and > follow the MAY here, then > an application would care, I think. >=20 >> I don't think so. And I think both cases are signalled >> to the application for TCP in the same way. >>> [Karen ] Yes, but even if the information is provided, then closing >>> the association does not constitute a soft reaction. >> ICMP9) of https://tools.ietf.org/html/rfc4960#appendix-C tells you = that > it is >> OK to increment the error counter or mark the destination as = unreachable. > It >> is up to you to decide what is appropriate in your implementation. > However, >> you should not increment the association error counter, so it = shouldn't > be an >> association failure. > [Karen ] I agree. >> An association failure can only occur if you move the path state to >> unreachable, have no reachable destinations anymore (dormant state) = and >> have decided that this means failing the association. But again, this = is > related >> to an, in my view, suboptimal handling of the dormant state. FreeBSD > doesn't >> fail the association in this case. > [Karen ] I agree that this is suboptimal handling of dormant state. = We > also do not to this suboptimal handling. > I think that one could say that RFC4960 Appendix C prescriptions for = how > to handle soft icmps could relate to that this can make the assocs = enter > dormant state fast and that dormant state implementation > need to relate to this fact if the MAYs are followed. OK. Best regards Michael >=20 > BR, Karen >>=20 >> Best regards >> Michael >>>=20 >>> BR, Karen >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>>> In particular, destination unreachables can cause the SCTP >>>>>> connection to >>>>> go >>>>> [Karen ] MAY force. And this MAY of the RFC I (and we) believe is >>>>> questionable. We believe that for an implementation to support = this >>>>> MAY the implementation MUST implement dormant state handling as >>>>> described (right now) in the SCTP Failover draft =3D SCTP = continues to >>>>> transmit data also when the destinations are considered = unreachable. >>>>> (and our SCTP implementations do this). Further we think that the >>>>> appropriate soft reaction to ICMP destination unreachable is to >>>>> increment the path error counter, NOT to mark the destination as >>>>> INACTIVE. >>>>> Hopefully we will see these things be clarified in future SCTP >>>>> drafts or ideally in the eventual RFC4960 revision. >>>>>=20 >>>>>> into a dead state (mark the dest unreachable or increment the = path >>>>>> error >>>>>> counter) without indicating anything to the user. >>>>>>=20 >>>>> [Karen ] The state is not dead if "appropriate" dormant state >>>>> handling is implemented. >>>>>=20 >>>>>> This seems incorrect to me, given the number of other ways in = which >>>>>> SCTP >>>>> can >>>>>> shut down a connection (heartbeat failure, retransmission failre) >>>>>> and is supposed to pass that info to the user. >>>>>>=20 >>>>> [Karen ] I agree that when the association is closed as a direct >>>>> result of receipt of ICMPs then this should be communicated to the >>> Users. >>>>> The envisaged approach (from our side) is to define a new error = code >>>>> for the sac_error of the SCTP_ASSOC_CHANGE (the notification of >>>> comm_LOST): >>>>>=20 >>>>> sac_error: If the state was reached due to an error condition > (e.g., >>>>> SCTP_COMM_LOST), any relevant error information is available in >>>>> this field. This corresponds to the protocol error codes = defined >>>>> in [RFC4960]. >>>>>=20 >>>>> Right now we have the possibility to use proprietary error codes >>>>> here, but we would like to go beyond that of course. >>>>>=20 >>>>> For the destination error counter the information goes into the >>>>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >>>>> destination address unreachability). >>>>>=20 >>>>> PLEASE allow me to explain the abstract API in terms of a concrete >>>>> one. I do understand the difference. >>>>> The new thing is that the abstract transport API, which if nothing >>>>> else exists in our heads and in our overall modeling, now with = TAPS, >>>>> may be defined as a concrete one. >>>>> And I agree with everybody else that this is a good exercise and >>>>> that it is doomed to (correct and) improve things substantially. >>>>>=20 >>>>>> So, IMO, this is a great example of why studying these APIs as >>>>> abstractions is >>>>>> important and would have prevented this (IMO) oversight. >>>>> [Karen ] We have studied this. But is only bringing this to the = IETF >>> now. >>>>> Possibly to be addressed for RFC4960 revision. >>>>>>=20 >>>>>> Or can someone in the SCTP team explain why shutting connections >>>>>> down due to other reasons is a user signal but validated ICMP >>>>>> signals are >>> not? >>>>> [Karen ] NA. >>>>>>=20 >>>>>> Joe >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Taps mailing list >>>>>> Taps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>=20 >=20 From nobody Thu Jul 16 04:13:20 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 D9B921B39BE for ; Thu, 16 Jul 2015 04:13: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 ojHGqm9czUuE for ; Thu, 16 Jul 2015 04:13:12 -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 3F8051B39B6 for ; Thu, 16 Jul 2015 04:13:12 -0700 (PDT) Received: by ietj16 with SMTP id j16so53351767iet.0 for ; Thu, 16 Jul 2015 04:13:11 -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=lIWxjsn0gResLIPBFgFdxDzmjuYRcSF0YSnTCK1Djns=; b=wJf8vxYTA9tzCRI0tU867IxOksxWjfGJ/9B/pKq31xT8H7L7IqsOHn5O/UXKVsi2W1 O6sFpQo39HBlE9GabOAENjK0ifof7twXVoqg8O0SPA35q5TkD7mq1rDGa/IvgmlI08+Z fYq5y77dR/GTxQ5Y4cW2ge2KZXjgNYwlzmEQ0= 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=lIWxjsn0gResLIPBFgFdxDzmjuYRcSF0YSnTCK1Djns=; b=FWwBXCPYrUmX9GPGvcG8MVCY6J4Omfj3Fac0BW6qkWu2+DlXux1yE1SYGmxZPNxenZ 4gd1hSepz0SoRHhbPacpVqSc5cTPTn6oCNJcxMqUMlbSrCGz4F3xHXU5EuIRrvqmMTr4 sp/HXIDUuszuRZ8Bdn6X6+v5tYtmfVzqmRYjkm7Ho0IKKlAf5YgYgA3OqwBDT9AFn7Zh hNi/qS68IofdRa0IiQnVcQBx1hv7bmKzI+dddGcPYNJzCHLMtQzrNy6eSXleuSQCwywf if0eEriB1PpR3oKy+IXj74f9ohpXtJiEeEbJgZcd1dRerJzFFpsoBjUdrsPikZBwEOU4 u83w== X-Gm-Message-State: ALoCoQnZyT8+SbVpToyKqz7QlCGaRPhTUzAf4zTvN3xrZx9U8Rroxe97phohdD6/Otp8nmg6jyK8bH+5Fm6EoflSCL0fsBG6bRxByEhLPZXVuwuzPYEtghk= X-Received: by 10.107.167.2 with SMTP id q2mr12055173ioe.109.1437045191638; Thu, 16 Jul 2015 04:13:11 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE86SdgORCvliHFE703NIXCziGWLQKpHUkGAiiw3coBaHzujgJBSMcpAhGHtOcCr5vwOgHu+g0GAbkLt5MCJc+oBgGuoRj/Afotd2IDCJPF2J43u1uw Date: Thu, 16 Jul 2015 13:13:10 +0200 Message-ID: <6faa7a4e5858a5bb09b761c129b4814c@mail.gmail.com> To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 11:13:19 -0000 HI Michael, >-----Original Message----- >From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >Sent: Thursday, July 16, 2015 12:45 PM >To: Karen Elisabeth Egede Nielsen >Cc: Joe Touch; Pal Martinsen (palmarti); taps@ietf.org >Subject: Re: [Taps] TAPS Transports and ICMP > >> On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen > wrote: >> >> HI Michael, >>>> >>>> [Karen ] This might (the MAY) results in hard trouble if the >>>> association is closed due to entering of dormant state. >>>> That's why we believe that this MAY reaction should be coupled with >>>> robust dormant state handling. >>> I think we have to distinguish two things here: >>> >> [Karen ] Yes, I agree. >> >>> 1. When you receive an ICMP message you might increment the path >>> error counter or change the path state. When changing the path state >>> notify the user about it. This is about ICMP handling >> [Karen ] >> Yes. But user is not notified of the receipt of ICMPs. >> >> I should perhaps tell that we have some SCTP SW versions that follow >> the MAY and others which ignores these destination unreachable ICMPs. >> >> 2. Deal with the case >>> that all paths are inactive, which means deal with the dormant >>> state. This is NOT related to the ICMP handling, since it doesn't >>> matter how you end up in the dormant state. >>> It might make ending up there more often, but and implementation >>> needs to deal with it anyway. >>>> >>>> However, the user is provided with the >>>>> information, if requested, either about an association or path >>>>> state >>>> change. >>>> [Karen ] Yes, but the user is not provided with the information that >>>> the association was closed due to the receipt ICMPs. >>> Correct. But does the application care if the peer sent an ABORT or >>> an >> ICMP >>> Destination unreachable? >> >> [Karen ] For TCP the socket api provides the information. >How? Isn't it the same as for SCTP? A system call returns -1 and errno is set to >some value line ECONNRESET or ECONNREFUSED? [Karen ] TCP maps the received soft destination unreachable ICMPs to ENETUNREACH or EHOSTUNREACH pending errors on socket. Thus at least temporarily this information is available and is notified towards the user. True that when the connection is closed, the information is overwritten - unless multiple pending errors are maintained by the implementation. >I think the user can't distinguish from receiving an TCP RST. >Am I missing something? >> Presumably this is because the application could care. >> For implementations that do the "suboptimal" dormant state handling >> and follow the MAY here, then an application would care, I think. >> >>> I don't think so. And I think both cases are signalled to the >>> application for TCP in the same way. >>>> [Karen ] Yes, but even if the information is provided, then closing >>>> the association does not constitute a soft reaction. >>> ICMP9) of https://tools.ietf.org/html/rfc4960#appendix-C tells you >>> that >> it is >>> OK to increment the error counter or mark the destination as unreachable. >> It >>> is up to you to decide what is appropriate in your implementation. >> However, >>> you should not increment the association error counter, so it >>> shouldn't >> be an >>> association failure. >> [Karen ] I agree. >>> An association failure can only occur if you move the path state to >>> unreachable, have no reachable destinations anymore (dormant state) >>> and have decided that this means failing the association. But again, >>> this is >> related >>> to an, in my view, suboptimal handling of the dormant state. FreeBSD >> doesn't >>> fail the association in this case. >> [Karen ] I agree that this is suboptimal handling of dormant state. >> We also do not to this suboptimal handling. >> I think that one could say that RFC4960 Appendix C prescriptions for >> how to handle soft icmps could relate to that this can make the >> assocs enter dormant state fast and that dormant state implementation >> need to relate to this fact if the MAYs are followed. >OK. [Karen ] Thanks for understanding. BR, Karen > >Best regards >Michael >> >> BR, Karen >>> >>> Best regards >>> Michael >>>> >>>> BR, Karen >>>>> >>>>> Best regards >>>>> Michael >>>>>> >>>>>>> In particular, destination unreachables can cause the SCTP >>>>>>> connection to >>>>>> go >>>>>> [Karen ] MAY force. And this MAY of the RFC I (and we) believe is >>>>>> questionable. We believe that for an implementation to support >>>>>> this MAY the implementation MUST implement dormant state >handling >>>>>> as described (right now) in the SCTP Failover draft = SCTP >>>>>> continues to transmit data also when the destinations are considered >unreachable. >>>>>> (and our SCTP implementations do this). Further we think that the >>>>>> appropriate soft reaction to ICMP destination unreachable is to >>>>>> increment the path error counter, NOT to mark the destination as >>>>>> INACTIVE. >>>>>> Hopefully we will see these things be clarified in future SCTP >>>>>> drafts or ideally in the eventual RFC4960 revision. >>>>>> >>>>>>> into a dead state (mark the dest unreachable or increment the >>>>>>> path error >>>>>>> counter) without indicating anything to the user. >>>>>>> >>>>>> [Karen ] The state is not dead if "appropriate" dormant state >>>>>> handling is implemented. >>>>>> >>>>>>> This seems incorrect to me, given the number of other ways in >>>>>>> which SCTP >>>>>> can >>>>>>> shut down a connection (heartbeat failure, retransmission failre) >>>>>>> and is supposed to pass that info to the user. >>>>>>> >>>>>> [Karen ] I agree that when the association is closed as a direct >>>>>> result of receipt of ICMPs then this should be communicated to the >>>> Users. >>>>>> The envisaged approach (from our side) is to define a new error >>>>>> code for the sac_error of the SCTP_ASSOC_CHANGE (the notification >>>>>> of >>>>> comm_LOST): >>>>>> >>>>>> sac_error: If the state was reached due to an error condition >> (e.g., >>>>>> SCTP_COMM_LOST), any relevant error information is available in >>>>>> this field. This corresponds to the protocol error codes defined >>>>>> in [RFC4960]. >>>>>> >>>>>> Right now we have the possibility to use proprietary error codes >>>>>> here, but we would like to go beyond that of course. >>>>>> >>>>>> For the destination error counter the information goes into the >>>>>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >>>>>> destination address unreachability). >>>>>> >>>>>> PLEASE allow me to explain the abstract API in terms of a concrete >>>>>> one. I do understand the difference. >>>>>> The new thing is that the abstract transport API, which if nothing >>>>>> else exists in our heads and in our overall modeling, now with >>>>>> TAPS, may be defined as a concrete one. >>>>>> And I agree with everybody else that this is a good exercise and >>>>>> that it is doomed to (correct and) improve things substantially. >>>>>> >>>>>>> So, IMO, this is a great example of why studying these APIs as >>>>>> abstractions is >>>>>>> important and would have prevented this (IMO) oversight. >>>>>> [Karen ] We have studied this. But is only bringing this to the >>>>>> IETF >>>> now. >>>>>> Possibly to be addressed for RFC4960 revision. >>>>>>> >>>>>>> Or can someone in the SCTP team explain why shutting connections >>>>>>> down due to other reasons is a user signal but validated ICMP >>>>>>> signals are >>>> not? >>>>>> [Karen ] NA. >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Taps mailing list >>>>>>> Taps@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>> >>>> >> From nobody Thu Jul 16 04:23: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 0325B1B39E6 for ; Thu, 16 Jul 2015 04:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, 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 yIxHYZXMPfsn for ; Thu, 16 Jul 2015 04:23:20 -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 378891B39E3 for ; Thu, 16 Jul 2015 04:23:20 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZFhG2-0002Wj-F5; Thu, 16 Jul 2015 13:23:18 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1ZFhG1-0008JG-UQ; Thu, 16 Jul 2015 13:23:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com> Date: Thu, 16 Jul 2015 13:23:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 7 sum msgs/h 4 total rcpts 31027 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 11B2768CEF6352C2C43818B37E2C8BA1F6E2DD17 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 99990 minaction 1 bait 0 mail/h: 3 total 7430 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Stein Gjessing , "taps@ietf.org" Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-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: Thu, 16 Jul 2015 11:23:22 -0000 Hi, thanks! Below: > On 16 Jul 2015, at 11:22, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI, >=20 > A few initial comments the definition of the transport service = features as > they appear from section 3 (and TAPS1): >=20 > Unidirectional/bidirectional: I am not sure what this means exactly: > Does it refer to that data transfer is negotiated for both directions > perhaps ? But then it only applies to connection oriented transport. > Does it refer to that control info is going back ? > Does it refer to that messages (which ever form) are going back on the > reverse network path ? Then it does not necessarily apply to SCTP MH. Sorry for not being clear enough: it means that it's a feature that can = be used just on one side, without requiring the other side to be = involved (e.g. Nagle is just a sender-side mechanism). > o non-reliable delivery: > add SCTP >=20 > o reliable delivery: > add SCTP >=20 > Suggest to rephrase >=20 > o reliable and partially reliable delivery > --> > o partially reliable delivery: > SCTP >=20 > o drop notification : > add SCTP >=20 > o ordered delivery: > add SCTP >=20 > o unordered delivery: > add SCTP ACK, thanks > Ideally, I think, then one would use a common term for Nagle(-like) > bundling for TCP and SCTP. Agreed, we actually did that in Michael Welzl, Stefan J=C3=B6rer, Stein = Gjessing: "Towards a Protocol-Independent Internet Transport API", = FutureNet IV workshop in conjunction with of IEEE ICC 2011, 5-9 June = 2011, Kyoto, Japan, using app PDU bundling because it's more meaningful than Nagle. But here the idea was just to copy+paste the list from doc 1 (version 4) = and put things under the correct headings, as a way to show how we = *could* apply categorization methods. Cheers, Michael From nobody Thu Jul 16 04:33:17 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 2468F1B3A01 for ; Thu, 16 Jul 2015 04:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 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, J_CHICKENPOX_45=0.6, 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 rJ6WmMAcZw6m for ; Thu, 16 Jul 2015 04:33:15 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 105AE1B39FE for ; Thu, 16 Jul 2015 04:33:15 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so53654911iec.2 for ; Thu, 16 Jul 2015 04:33:14 -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=oFvNuoaRekvqz2PSeogtAGzH76z+YrYLwFGcPUhfSNY=; b=Oo/i1nGUaUTyhus+lQXvuooIrKERURdNEdizzvbQvnVigpD0S2ThNBegxCilj+28XS zs5aFx28b+/ftaI6gEvQd8ayI+oJnV1PMrhwSz66gJehxw3BRu2Kx9FI2ZKcqhDRdXBZ MBTIkxbNe7ngJtdcIcm/MgR+5GajIDUWGYVs0= 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=oFvNuoaRekvqz2PSeogtAGzH76z+YrYLwFGcPUhfSNY=; b=kk4rUQVYCRu02BOyhC39LKQ+S3MlE0yK/86KnkjswwFsDnYOAvNSD6BoEbSf5gp4h1 2sgzXJUNVH5dI51QKGIIywsW4h4N8qtLALIdmleKaHbg2z94xaKhzk6PyZWR7Wt+MuVU wkVN7iDVLdPegwxrDtGIPQH3OcRjg6dKrkhQ53qK0QQ1+Vemk5fMzlmdBBVPyxvjJ4G+ 1ANJo1bT05IKUNZX0xHlNLdPCBU4jPdL2Kyz2Ip360YK2T2XETP2vTqTeDDI0eaN4lmV h0dtr+0w98HdN+ugcecacJIJOnMwxzmQa89TC3FDNZepdEpAKyTBufLCx3RGdttTT4/V 0oQQ== X-Gm-Message-State: ALoCoQmGKdSzVEP/rTLyR7FHwbbp4Se0elMbdjuMSWk4gnKCVPaUogvt9rVkFhzEjGmb7Q/zqHDo4Wcpb8U3QhDRYybiH6YfL2/ugE3jZ5X2yBzwsKTJuqM= X-Received: by 10.107.167.2 with SMTP id q2mr12162885ioe.109.1437046394550; Thu, 16 Jul 2015 04:33:14 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEc5Xz/B23yf9Eiv4yTBTpDy7OwEgJ6rVYLnzHT3XA= Date: Thu, 16 Jul 2015 13:33:13 +0200 Message-ID: <4462808352bc6bde2e6d677d0d0e71e8@mail.gmail.com> To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: Stein Gjessing , taps@ietf.org Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-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: Thu, 16 Jul 2015 11:33:16 -0000 HI, >-----Original Message----- >From: Michael Welzl [mailto:michawe@ifi.uio.no] >Sent: Thursday, July 16, 2015 1:23 PM >To: Karen Elisabeth Egede Nielsen >Cc: taps@ietf.org; Stein Gjessing >Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt > >Hi, thanks! > >Below: > > >> On 16 Jul 2015, at 11:22, Karen Elisabeth Egede Nielsen > wrote: >> >> HI, >> >> A few initial comments the definition of the transport service >> features as they appear from section 3 (and TAPS1): >> >> Unidirectional/bidirectional: I am not sure what this means exactly: >> Does it refer to that data transfer is negotiated for both directions >> perhaps ? But then it only applies to connection oriented transport. >> Does it refer to that control info is going back ? >> Does it refer to that messages (which ever form) are going back on the >> reverse network path ? Then it does not necessarily apply to SCTP MH. > >Sorry for not being clear enough: it means that it's a feature that can be >used >just on one side, without requiring the other side to be involved (e.g. >Nagle is >just a sender-side mechanism). > [Karen ] Thanks. very precise. So we should call this single-sided or alike= . Not something that seems to have a direction or be related to how data flows. > >> o non-reliable delivery: >> add SCTP >> >> o reliable delivery: >> add SCTP >> >> Suggest to rephrase >> >> o reliable and partially reliable delivery >> --> >> o partially reliable delivery: >> SCTP >> >> o drop notification : >> add SCTP >> >> o ordered delivery: >> add SCTP >> >> o unordered delivery: >> add SCTP > >ACK, thanks > > >> Ideally, I think, then one would use a common term for Nagle(-like) >> bundling for TCP and SCTP. > >Agreed, we actually did that in Michael Welzl, Stefan J=C3=B6rer, Stein >Gjessing: >"Towards a Protocol-Independent Internet Transport API", FutureNet IV >workshop in conjunction with of IEEE ICC 2011, 5-9 June 2011, Kyoto, Japan= , >using app PDU bundling because it's more meaningful than Nagle. > [Karen ] Great. >But here the idea was just to copy+paste the list from doc 1 (version 4) >and >put things under the correct headings, as a way to show how we *could* >apply categorization methods. > [Karen ] Yes I understand that. But the write-up serves very well to help unify and clarify the terms - which I suppose is the goal :-). BR, Karen >Cheers, >Michael From nobody Thu Jul 16 06:04: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 ACC691B3ABB for ; Thu, 16 Jul 2015 06:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, SPF_HELO_PASS=-0.001, 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 KnrTuSDuIRCC for ; Thu, 16 Jul 2015 06:04:44 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CD13F1B3ABA for ; Thu, 16 Jul 2015 06:04:38 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 67DD31A03F3; Thu, 16 Jul 2015 15:04:37 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_82AA79B2-6FCD-4BCC-A318-677D9AC8B502"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: Date: Thu, 16 Jul 2015 15:04:36 +0200 Message-Id: <032C97CD-A8D3-4553-9DD1-B17E2295AC43@trammell.ch> References: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com> To: Michael Welzl X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Karen Elisabeth Egede Nielsen , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-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: Thu, 16 Jul 2015 13:04:45 -0000 --Apple-Mail=_82AA79B2-6FCD-4BCC-A318-677D9AC8B502 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Michael, ...inline... > On 16 Jul 2015, at 13:23, Michael Welzl wrote: >> Ideally, I think, then one would use a common term for Nagle(-like) >> bundling for TCP and SCTP. >=20 > Agreed, we actually did that in Michael Welzl, Stefan J=C3=B6rer, = Stein Gjessing: "Towards a Protocol-Independent Internet Transport API", = FutureNet IV workshop in conjunction with of IEEE ICC 2011, 5-9 June = 2011, Kyoto, Japan, > using app PDU bundling because it's more meaningful than Nagle. >=20 > But here the idea was just to copy+paste the list from doc 1 (version = 4) and put things under the correct headings, as a way to show how we = *could* apply categorization methods. hm, so perhaps we should have coordinated here. That list, in that = version, wasn't quite complete. In the current version it's still not = quite complete, as we're still trying to nail down how to partition the = space of features (and how to divide things that are actually features = from things that are just accidental effects of the way protocols have = evolved). There are also aspects of the interfaces (coming from the = interface discussion) we'd like to capture, on which we'd like to = discuss f2f next Thursday. Perhaps another way to approach this would be to start with a list of = features we think we want in doc 2, and to use the background from doc 1 = to fill in the gaps... Cheers, Brian > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_82AA79B2-6FCD-4BCC-A318-677D9AC8B502 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 - https://gpgtools.org iQEcBAEBCgAGBQJVp6vlAAoJENt3nsOmbNJcEmoIAKfC4ecTDCUV0Bb0ZUTKVdgk 9s5GxbBwvLV+1kQal4bBsyCAHBWnxlcUVHP4Syp5aMLy9RNA5/lvcYWBCXPHOXgD SFdSlWHl3Z8J/L1Ge1+UfH+L6FvVq3aB+HGmjRszArohdzvJZbBgJMWOhIFmlUDL 8M73WxY7TZvnyvDHLStt6FaosMzlIf8R0gJgzwuDjb3UojimBNdY5VYOMP3AdxZR cdff88hceoxMT6OPKf+gVDSydUEDpt5xDFbeNfZNdSdB/7IwDzpK2Ku7s4ZLAfh3 uviRaHtls9aaDnh/3eud0OTlkq5nH5YruGBIT282Ps5QPetFIehSK6tuvRSLkuQ= =FKjI -----END PGP SIGNATURE----- --Apple-Mail=_82AA79B2-6FCD-4BCC-A318-677D9AC8B502-- From nobody Thu Jul 16 10:49:07 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 0B54D1B2A5B for ; Thu, 16 Jul 2015 10:49:06 -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 E2oIZLPX-RLs for ; Thu, 16 Jul 2015 10:49:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AC11B2A38 for ; Thu, 16 Jul 2015 10:48:45 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6GHmW0C013201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jul 2015 10:48:33 -0700 (PDT) To: Karen Elisabeth Egede Nielsen , taps@ietf.org References: <20150706220631.6336.219.idtracker@ietfa.amsl.com> <456cadf6d459a1c9e2c508af7b5470de@mail.gmail.com> <55A6A31B.3090500@isi.edu> <0047fc6ff18d95970285941d02534db4@mail.gmail.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55A7EE70.9040308@isi.edu> Date: Thu, 16 Jul 2015 10:48:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <0047fc6ff18d95970285941d02534db4@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.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, 16 Jul 2015 17:49:06 -0000 Hi, Karen, On 7/16/2015 12:27 AM, Karen Elisabeth Egede Nielsen wrote: ... >> So there are several levels of the latency issue: >> >> - minimize the latency ADDED by the transport layer >> - reduce the latency seen by the app >> (which can involve more active interaction with the network >> layer, anticipation, etc.) >> >> Note also that latency is not a single metric nor a meaningful standalone >> metric: >> >> 1. latency between two parties is a property *of a message*, >> i.e., it requires knowing the message size >> >> 2. latency includes both basic and higher order effects; >> the basic is "delay", the higher order include "jitter" etc. >> Many common delay-sensitive use cases are really mostly >> jitter sensitive. >> >> ... > [Karen ] I agree so what do we mean in this document when we say that > a transport service feature can be to provide minimal latency ? There should probably be two levels: - minimize what you add at the transport layer - reduce even further > Are we thinking about Nagle OFF ? That is how TCP might react to a request to minimizing added latency, but I don't expect a TAPS API should expose the specific knob of "Nagle". >>> I am not sure if Connection oriented and Feature negotiation should >>> be split into two features ? >> >> If you don't share state (i.e., what we tend to call a "connection"), > what is the >> meaning of feature negotiation? >> > [Karen ] Yes, but does connection oriented necessarily means that you can > negotiate features ? Absolutely. Connection oriented means there is state that persists between messages. To be useful, that state needs to be controllable. Negotiating features *is* controlling that state. ... >> So the general assumption that turning off Nagle will reduce latency > should be >> reasonable. > [Karen ] I agree with this as a general assumption. > But when I read the paragraph in the doc it almost sounds as if turning > Nagle off comes with no price. I would think that should be clarified. > Do you have a counterexample seen in the wild? > > [Karen ] Yes we have examples with NO Nagle where the number of packets > then becomes the bottleneck. > In the local ends (CPU) as well as in the infrastructure elements. I am > not sure how much of this information I can share. > I can try to find out. That is why I was saying that how to provide > minimal latency may depend on the application traffic. Because latency depends on the sizes of the messages, it should not be a surprise that latency can't be minimized without that context. > How to solve also depends on whether it is the average latency that needs > to be minimal or whether the latency for some particular application > "messages" should be kept as low as possible. This is difficult for TCP to handle, because TCP thinks of the input stream as an ordered sequence of bytes, and the issue of latency is related to message boundaries within the TCP stream that are NOT part of the TCP API (there's no way for an application to indicate those boundaries to TCP - and no, the SEND boundaries are explicitly NOT those markers). > For SCTP we allow for that Nagle is disabled on some streams (streams with > high scheduling priority) and not on others. This is done exactly for this > purpose. Sure, but that's also why it doesn't make sense for TCP. Joe From nobody Thu Jul 16 13:29: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 BEE7D1A8991 for ; Thu, 16 Jul 2015 13:29:17 -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 ikUUw7M2Ac_5 for ; Thu, 16 Jul 2015 13:29:15 -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 F02411A88D2 for ; Thu, 16 Jul 2015 13:29:14 -0700 (PDT) Received: from [192.168.1.200] (p4FE31B43.dip0.t-ipconnect.de [79.227.27.67]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4D7181C0C0BDB; Thu, 16 Jul 2015 22:29:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Tuexen In-Reply-To: <6faa7a4e5858a5bb09b761c129b4814c@mail.gmail.com> Date: Thu, 16 Jul 2015 22:29:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84275643-6EA3-4060-AA00-31CBCEA1653A@lurchi.franken.de> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> <6faa7a4e5858a5bb09b761c129b4814c@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 20:29:17 -0000 > On 16 Jul 2015, at 13:13, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI Michael, >=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Thursday, July 16, 2015 12:45 PM >> To: Karen Elisabeth Egede Nielsen >> Cc: Joe Touch; Pal Martinsen (palmarti); taps@ietf.org >> Subject: Re: [Taps] TAPS Transports and ICMP >>=20 >>> On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen >> wrote: >>>=20 >>> HI Michael, >>>>>=20 >>>>> [Karen ] This might (the MAY) results in hard trouble if the >>>>> association is closed due to entering of dormant state. >>>>> That's why we believe that this MAY reaction should be coupled = with >>>>> robust dormant state handling. >>>> I think we have to distinguish two things here: >>>>=20 >>> [Karen ] Yes, I agree. >>>=20 >>>> 1. When you receive an ICMP message you might increment the path >>>> error counter or change the path state. When changing the path = state >>>> notify the user about it. This is about ICMP handling >>> [Karen ] >>> Yes. But user is not notified of the receipt of ICMPs. >>>=20 >>> I should perhaps tell that we have some SCTP SW versions that follow >>> the MAY and others which ignores these destination unreachable = ICMPs. >>>=20 >>> 2. Deal with the case >>>> that all paths are inactive, which means deal with the dormant >>>> state. This is NOT related to the ICMP handling, since it doesn't >>>> matter how you end up in the dormant state. >>>> It might make ending up there more often, but and implementation >>>> needs to deal with it anyway. >>>>>=20 >>>>> However, the user is provided with the >>>>>> information, if requested, either about an association or path >>>>>> state >>>>> change. >>>>> [Karen ] Yes, but the user is not provided with the information = that >>>>> the association was closed due to the receipt ICMPs. >>>> Correct. But does the application care if the peer sent an ABORT or >>>> an >>> ICMP >>>> Destination unreachable? >>>=20 >>> [Karen ] For TCP the socket api provides the information. >> How? Isn't it the same as for SCTP? A system call returns -1 and = errno is > set to >> some value line ECONNRESET or ECONNREFUSED? >=20 > [Karen ] TCP maps the received soft destination unreachable ICMPs to > ENETUNREACH or EHOSTUNREACH pending errors on socket. OK. FreeBSD provides EHOSTUNREACH instead of ETIMEDOUT for TCP. It doesn't support ENETUNREACH. I don't think we do this in SCTP... Best regards Michael > Thus at least temporarily this information is available and is = notified > towards the user. > True that when the connection is closed, the information is = overwritten - > unless multiple pending errors are maintained by the implementation. >=20 >> I think the user can't distinguish from receiving an TCP RST. >> Am I missing something? >>> Presumably this is because the application could care. >>> For implementations that do the "suboptimal" dormant state handling >>> and follow the MAY here, then an application would care, I think. >>>=20 >>>> I don't think so. And I think both cases are signalled to the >>>> application for TCP in the same way. >>>>> [Karen ] Yes, but even if the information is provided, then = closing >>>>> the association does not constitute a soft reaction. >>>> ICMP9) of https://tools.ietf.org/html/rfc4960#appendix-C tells you >>>> that >>> it is >>>> OK to increment the error counter or mark the destination as > unreachable. >>> It >>>> is up to you to decide what is appropriate in your implementation. >>> However, >>>> you should not increment the association error counter, so it >>>> shouldn't >>> be an >>>> association failure. >>> [Karen ] I agree. >>>> An association failure can only occur if you move the path state to >>>> unreachable, have no reachable destinations anymore (dormant state) >>>> and have decided that this means failing the association. But = again, >>>> this is >>> related >>>> to an, in my view, suboptimal handling of the dormant state. = FreeBSD >>> doesn't >>>> fail the association in this case. >>> [Karen ] I agree that this is suboptimal handling of dormant state. >>> We also do not to this suboptimal handling. >>> I think that one could say that RFC4960 Appendix C prescriptions for >>> how to handle soft icmps could relate to that this can make the >>> assocs enter dormant state fast and that dormant state = implementation >>> need to relate to this fact if the MAYs are followed. >> OK. > [Karen ] Thanks for understanding. >=20 > BR, Karen >>=20 >> Best regards >> Michael >>>=20 >>> BR, Karen >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> BR, Karen >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>>> In particular, destination unreachables can cause the SCTP >>>>>>>> connection to >>>>>>> go >>>>>>> [Karen ] MAY force. And this MAY of the RFC I (and we) believe = is >>>>>>> questionable. We believe that for an implementation to support >>>>>>> this MAY the implementation MUST implement dormant state >> handling >>>>>>> as described (right now) in the SCTP Failover draft =3D SCTP >>>>>>> continues to transmit data also when the destinations are > considered >> unreachable. >>>>>>> (and our SCTP implementations do this). Further we think that = the >>>>>>> appropriate soft reaction to ICMP destination unreachable is to >>>>>>> increment the path error counter, NOT to mark the destination as >>>>>>> INACTIVE. >>>>>>> Hopefully we will see these things be clarified in future SCTP >>>>>>> drafts or ideally in the eventual RFC4960 revision. >>>>>>>=20 >>>>>>>> into a dead state (mark the dest unreachable or increment the >>>>>>>> path error >>>>>>>> counter) without indicating anything to the user. >>>>>>>>=20 >>>>>>> [Karen ] The state is not dead if "appropriate" dormant state >>>>>>> handling is implemented. >>>>>>>=20 >>>>>>>> This seems incorrect to me, given the number of other ways in >>>>>>>> which SCTP >>>>>>> can >>>>>>>> shut down a connection (heartbeat failure, retransmission = failre) >>>>>>>> and is supposed to pass that info to the user. >>>>>>>>=20 >>>>>>> [Karen ] I agree that when the association is closed as a = direct >>>>>>> result of receipt of ICMPs then this should be communicated to = the >>>>> Users. >>>>>>> The envisaged approach (from our side) is to define a new error >>>>>>> code for the sac_error of the SCTP_ASSOC_CHANGE (the = notification >>>>>>> of >>>>>> comm_LOST): >>>>>>>=20 >>>>>>> sac_error: If the state was reached due to an error condition >>> (e.g., >>>>>>> SCTP_COMM_LOST), any relevant error information is available = in >>>>>>> this field. This corresponds to the protocol error codes > defined >>>>>>> in [RFC4960]. >>>>>>>=20 >>>>>>> Right now we have the possibility to use proprietary error codes >>>>>>> here, but we would like to go beyond that of course. >>>>>>>=20 >>>>>>> For the destination error counter the information goes into the >>>>>>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >>>>>>> destination address unreachability). >>>>>>>=20 >>>>>>> PLEASE allow me to explain the abstract API in terms of a = concrete >>>>>>> one. I do understand the difference. >>>>>>> The new thing is that the abstract transport API, which if = nothing >>>>>>> else exists in our heads and in our overall modeling, now with >>>>>>> TAPS, may be defined as a concrete one. >>>>>>> And I agree with everybody else that this is a good exercise and >>>>>>> that it is doomed to (correct and) improve things substantially. >>>>>>>=20 >>>>>>>> So, IMO, this is a great example of why studying these APIs as >>>>>>> abstractions is >>>>>>>> important and would have prevented this (IMO) oversight. >>>>>>> [Karen ] We have studied this. But is only bringing this to the >>>>>>> IETF >>>>> now. >>>>>>> Possibly to be addressed for RFC4960 revision. >>>>>>>>=20 >>>>>>>> Or can someone in the SCTP team explain why shutting = connections >>>>>>>> down due to other reasons is a user signal but validated ICMP >>>>>>>> signals are >>>>> not? >>>>>>> [Karen ] NA. >>>>>>>>=20 >>>>>>>> Joe >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Taps mailing list >>>>>>>> Taps@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>=20 >>>>>=20 >>>=20 >=20 From nobody Thu Jul 16 14:33: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 33CA31A0210 for ; Thu, 16 Jul 2015 14:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Hrz8r6qnGWeX for ; Thu, 16 Jul 2015 14:33:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285CB1A1A64 for ; Thu, 16 Jul 2015 14:33:24 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6GLWsFP023732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jul 2015 14:32:55 -0700 (PDT) To: Karen Elisabeth Egede Nielsen , Michael Tuexen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55A82306.4000509@isi.edu> Date: Thu, 16 Jul 2015 14:32:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, touch@isi.edu Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 21:33:40 -0000 On 7/16/2015 12:01 AM, Karen Elisabeth Egede Nielsen wrote: > HI Joe, > > I generally agree with your comments, but the situations is not > necessarily as bad as you say. > Please see below. ... >> Agreed, however the other ways that SCTP doesn't pass validated ICMPs to >> the user seems like a mistake to me. >> > [Karen ] I agree and we have for our SW recently discussed as to whether > we should implement such notification following > the UDP and TCP semantics. But at present none of our applications has the > need (on why that is, see below). IMO, the spec is what is deficient, in not requiring that this information be available to the application. It is always the application's prerogative to ignore such signals. >> In particular, destination unreachables can cause the SCTP connection to > go > [Karen ] MAY force. And this MAY of the RFC I (and we) believe is > questionable. We believe that > for an implementation to support this MAY the implementation MUST > implement dormant state handling as > described (right now) in the SCTP Failover draft = SCTP continues to > transmit data also when the destinations are considered unreachable. But the spec doesn't require that behavior. IMO, if the unreachable ends up causing the connection to close, the application should be able to figure out why. ... > [Karen ] I agree that when the association is closed as a direct result > of receipt of ICMPs then this should be communicated to the Users. > The envisaged approach (from our side) is to define a new error code for > the sac_error of the SCTP_ASSOC_CHANGE (the notification of comm_LOST): > > sac_error: If the state was reached due to an error condition (e.g., > SCTP_COMM_LOST), any relevant error information is available in > this field. This corresponds to the protocol error codes defined > in [RFC4960]. Right - the issue is that COMMUNICATION LOST as described in RFC4960, Sec 10.2, item "E", needs to include ICMP errors as a cause that generates this error message. The current description covers only lost heartbeats or aborts -- and while the ICMP could end up resulting in a lost heartbeat, that's a different type of error to report as context. Joe From nobody Thu Jul 16 14: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 448F51A0461 for ; Thu, 16 Jul 2015 14:35:14 -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 4URb6rpon19W for ; Thu, 16 Jul 2015 14:35:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BFD1A026A for ; Thu, 16 Jul 2015 14:35:13 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6GLYGRP023851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jul 2015 14:34:17 -0700 (PDT) To: Michael Tuexen , Karen Elisabeth Egede Nielsen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> From: Joe Touch Message-ID: <55A82358.8090104@isi.edu> Date: Thu, 16 Jul 2015 14:34:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> 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: "Pal Martinsen \(palmarti\)" , taps@ietf.org, touch@isi.edu Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 21:35:14 -0000 On 7/16/2015 2:40 AM, Michael Tuexen wrote: >> [Karen ] We provide information about received destination unreachable >> > ICMPs to users via socket api. >> > The same we do for (connected) UDP. >> > >> > This we could also do for SCTP, but as said we don't do it (yet). > > OK. FreeBSD does this. So it is not an issue with the specification, > but an implementation issue. IMO, it's a hole in the specification. It should be required by the specification. Yes, an implementation can exceed the specification, but that's irrelevant to the discussion here, IMO. Joe From nobody Thu Jul 16 14:36:44 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 927661A02BE for ; Thu, 16 Jul 2015 14:36:43 -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 cDXyHoJ3F3CY for ; Thu, 16 Jul 2015 14:36:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C79F1A0461 for ; Thu, 16 Jul 2015 14:36:42 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6GLZiSr024018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jul 2015 14:35:45 -0700 (PDT) To: Karen Elisabeth Egede Nielsen , Michael Tuexen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> From: Joe Touch Message-ID: <55A823B0.2080007@isi.edu> Date: Thu, 16 Jul 2015 14:35:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, touch@isi.edu Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 21:36:43 -0000 On 7/16/2015 3:26 AM, Karen Elisabeth Egede Nielsen wrote: > I think that one could say that RFC4960 Appendix C prescriptions for how > to handle soft icmps could relate to that this can make the assocs enter > dormant state fast and that dormant state implementation > need to relate to this fact if the MAYs are followed. Although that may be true for an implementation, the specification needs to cover both sides of a MAY (i.e., what happens if the MAY is followed and what happens when it is not). Joe From nobody Thu Jul 16 14: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 78EA81A1A8F for ; Thu, 16 Jul 2015 14:39:54 -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 i34rpxmnjPFI for ; Thu, 16 Jul 2015 14:39:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A201A1A8C for ; Thu, 16 Jul 2015 14:39:53 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6GLdf6c024742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jul 2015 14:39:41 -0700 (PDT) To: Michael Tuexen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <82885842-4A90-479B-AB5E-34D8286E1A03@lurchi.franken.de> From: Joe Touch Message-ID: <55A8249D.3090908@isi.edu> Date: Thu, 16 Jul 2015 14:39:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <82885842-4A90-479B-AB5E-34D8286E1A03@lurchi.franken.de> 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: Karen Elisabeth Egede Nielsen , "Pal Martinsen \(palmarti\)" , taps@ietf.org, touch@isi.edu Subject: Re: [Taps] TAPS Transports and ICMP 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, 16 Jul 2015 21:39:54 -0000 On 7/16/2015 1:56 AM, Michael Tuexen wrote: >> > So, IMO, this is a great example of why studying these APIs as >> > abstractions is important and would have prevented this (IMO) oversight. > > Can you say specifically, what has been missed? > > My understanding is that SCTP and TCP are similar in respect to ICMP processing > with the difference that > (a) SCTP ignore ICMP destination unreachable, port unreachable When it MUST ignore those signals, that's fine. > (b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an ICMP > destination unreachable, protocol unreachable similar to an SCTP ABORT. And this is the problem - when it acts on these signals, it never sends any information to the user. Further, ICMPs not otherwise defined are not required to be passed to the application, as is required for TCP. That's a HUGE problem for ICMP extensibility. > The reason is that there are no legacy SCTP stacks sending ICMP destination unreachable, > port unreachable, so (a) is appropriate. (b) is for protecting hosts that don't > support SCTP. > > The "handle like an ABORT" includes notifying the application. > > The handling of ICMP Destination unreachable (host or network unreachable) > is similar to the TCP case. If there is an SCTP state change, the user > will be notified if requested. That's not strictly required by the spec. Joe From nobody Thu Jul 16 14:51:53 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 8A77D1A1B86 for ; Thu, 16 Jul 2015 14:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 S2Fnp_QdxYg3 for ; Thu, 16 Jul 2015 14:51:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E3C1A1B84 for ; Thu, 16 Jul 2015 14:51:51 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6GLpNBl027141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jul 2015 14:51:24 -0700 (PDT) To: Karen Elisabeth Egede Nielsen , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <5a72988f46e4be6b26811213fcc4d99f@mail.gmail.com> <55A6A3C9.3040003@isi.edu> <9ec98209ec4b692bf9c172eec0c86711@mail.gmail.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55A8275B.4010907@isi.edu> Date: Thu, 16 Jul 2015 14:51:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <9ec98209ec4b692bf9c172eec0c86711@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , taps@ietf.org, Michael Welzl , touch@isi.edu Subject: Re: [Taps] TCP components 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, 16 Jul 2015 21:51:52 -0000 Hi, Karen, On 7/16/2015 12:57 AM, Karen Elisabeth Egede Nielsen wrote: >> What portion of RFC793's API do you consider outdated? .... > HI, > > I was thinking about the PUSH flag mainly. > > In our socket api implementation we do not allow for set of PUSH in send > calls nor do we provide the PUSH flag indication upwards on the receiver > side. That's consistent with RFC1122, which updates RFC793. > I think that after RFC793 it has been clarified that TCP MAY allow for set > of PUSH flag in send() and MAY OPTIONALLY provide this information upwards > on the receiver side. Yes. > I think that it would be questionable to follow RFC793 wording here on > PUSH. Sure; I was being broad in my reference back to RFC793; updates need to be chased down too, so to the extent that the updates make RFC793 outdated, you're correct. However, the bulk of RFC793's API remains in effect. Joe From nobody Thu Jul 16 15:31:03 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 8C4D41A9155 for ; Thu, 16 Jul 2015 15:31: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 LQ9ouuOqm3RV for ; Thu, 16 Jul 2015 15:30:59 -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 E61EB1A9163 for ; Thu, 16 Jul 2015 15:30:58 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so65703260ieb.1 for ; Thu, 16 Jul 2015 15:30:58 -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=Q01XjvnX1GwBB2WsZ62ScEcNO51hlxFAR5vxrrJW6dY=; b=SW/D0A9JqHuoEQlm913baVJBlxPWqhDXqz8VAQsAyQ5Gue7tIA6X2n+RWG7thHEylS BVY4zv4WebLSNvsP2y9EmNq2WfN7Rs92DMYpzk/UfHenZjthaR+IApQjE1J5qsMWh5H3 EOKUgBtbyjMUlpctyw57Npf6HrBjnZYCuFQAy5AgwnTc4z5igUZyOIrL9GmMEJ+phrXu aaD2fr7vzgqIFzPrJqcvSOcoeT4ZczY5MA+yd2UsezYTJ7MtudOAoDvH9XbRmp6Ezu7Y ZZSdlQflATDAu799IWSiz0k04VAUUGsdIBqU+H83ToAXXWpDosUJr6VVovEi3j3HpCer Ejlw== MIME-Version: 1.0 X-Received: by 10.107.7.214 with SMTP id g83mr16284303ioi.28.1437085858431; Thu, 16 Jul 2015 15:30:58 -0700 (PDT) Received: by 10.64.59.225 with HTTP; Thu, 16 Jul 2015 15:30:58 -0700 (PDT) Date: Thu, 16 Jul 2015 18:30:58 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a113f911c1a8a24051b05a030 Archived-At: Subject: [Taps] IETF-93 agenda (v.0) 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, 16 Jul 2015 22:31:01 -0000 --001a113f911c1a8a24051b05a030 Content-Type: text/plain; charset=UTF-8 Transport Services (TAPS) Working Group Thursday, July 23, 1300-1500 Karlin I/II Note: all discussion is regarding completion of draft-ietf-taps-transports-06 0. Administrivia (5 min) 1. Review of schedule for taking draft-ietf-taps-transports to working group last call this year. (5 min) 2. Review of protocols we don't have text for yet. (We're looking at you, RTP.) (5 min) Q: Are there any other missing protocols worth holding up the document? 3. Document Review (30 min) Discussion of "refactored" transport protocol components. In -06 we have redefined the components of TCP to be closer (in our opinion) to the actual interactions between each of the behaviors of the protocol. This is necessarily messier than starting from a "clean" set of features and working backward, as TCP was not designed as a composition of behaviors, rather evolving around a set of constraints. Q: Is this an acceptable approach? 4. Substantive Discussion: Features (30 min) Regardless of how we decompose the protocols, we do know enough about *some* transport service features to start writing detailed information about the features -- the discussion here will focus on draft-gjessing-taps-minset and/or section 4 of draft-ietf-taps-transports. Q: Administrative question: where is the split between these documents? Q: Primary technical question: what do we know about the features that belong in this minimum set that we can start writing? 5. Substantive Discussion: Interfaces (30 min) Discussion on interfaces/APIs and how we should consider them as input for the TAPS effort. There are three broad areas of questions about the eventual interface that TAPS will provide: (a) what are the knobs? (and who gets to turn them: app developer, user, administrator, kernel developer, etc)? (b) what are the meters (and who gets to see them)? (c) what are the patterns of interaction supported by existing interfaces? Q: Does this start work on the second document or is there something we can take from (abstract and concrete) interfaces already deployed that would inform the decomposition of transport protocols/services? --001a113f911c1a8a24051b05a030 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Transport Service= s (TAPS) Working Group
Thursday, July 23, 1300-1500=C2=A0
Karlin I/II


Note: all discussion is regard= ing completion of
draf= t-ietf-taps-transports-06


0. Administrivia (5 min)

1. Review of schedule for taking draft-ietf-= taps-transports to working
=C2=A0 =C2=A0group last call this year. =C2=A0(5 min)

2. Review of protocols we don't have text for yet. = =C2=A0(We're looking at
=C2=A0 =C2=A0you, RTP.) (5 min)

= =C2=A0 =C2=A0Q: Are there any other missing protocols worth holding up the<= /font>
=C2=A0 =C2=A0 =C2=A0 d= ocument?

3. Document Review (30 min)

=C2=A0 =C2=A0Discussion of "refactor= ed" transport protocol components.=C2=A0 In -06
=C2=A0 =C2=A0we have redefined the component= s of TCP to be closer (in our
=C2=A0 =C2=A0opinion) to the actual interactions between each of th= e behaviors
=C2=A0 =C2= =A0of the protocol. This is necessarily messier than starting from a=
=C2=A0 =C2=A0"clean&quo= t; set of features and working backward, as TCP was not
=C2=A0 =C2=A0designed as a composition of= behaviors, rather evolving around a
=C2=A0 =C2=A0set of constraints.

=C2=A0 =C2=A0Q: Is this an acceptable approach? =C2=A0
=C2=A0 =C2=A0
4. Substantive Discussion: Features (30 m= in)

<= div>=C2=A0 =C2=A0Regardless of how we d= ecompose the protocols, we do know enough
=C2=A0 =C2=A0about *some* transport service features to= start writing detailed
=C2=A0 =C2=A0d= raft-gjessing-taps-minset and/or section 4 of
=C2=A0 =C2=A0draft-ietf-taps-transports.

=C2=A0 =C2=A0Q: Administrative question: where = is the split between these
=C2=A0 =C2=A0 =C2=A0 documents?

= =C2=A0 =C2=A0Q: Primary technical question: what do we know about the featu= res
=C2=A0 =C2=A0 =C2= =A0 that belong in this minimum set that we can start writing?
=

5. Substantive Discussion: Interfaces (30 min)

=C2=A0 =C2=A0Discussion on interfaces/API= s and how we should consider them as
=C2=A0 =C2=A0input for the TAPS effort.=C2=A0 There are thre= e broad areas of
=C2= =A0 =C2=A0questions about the eventual interface that TAPS will provide: (a= )
=C2=A0 =C2=A0what ar= e the knobs? (and who gets to turn them: app developer,
=C2=A0 =C2=A0user, administrator, kernel = developer, etc)? =C2=A0(b) what are the
=C2=A0 =C2=A0meters (and who gets to see them)? =C2=A0(c)= what are the patterns of
=C2=A0 =C2=A0interaction supported by existing interfaces?
=

=C2=A0 =C2=A0Q: Does this start work on the secon= d document or is there
=C2=A0 =C2=A0 =C2=A0 something we can take from (abstract and concrete) in= terfaces
=C2=A0 =C2=A0= =C2=A0 already deployed that would inform the decomposition of
=C2=A0 =C2=A0 =C2=A0 transport pr= otocols/services?

=


--001a113f911c1a8a24051b05a030-- From nobody Fri Jul 17 00:08:26 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 BD6AE1B2F57 for ; Fri, 17 Jul 2015 00:08:24 -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 MO9TPM8nYBRP for ; Fri, 17 Jul 2015 00:08:22 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 253241B2F83 for ; Fri, 17 Jul 2015 00:08:22 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so31377352igc.0 for ; Fri, 17 Jul 2015 00:08:21 -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=A6p0GoGBwzGL75rfxaPz89LOqFfeBzlpkiX979RYiZg=; b=nQQqLzeh2QXvj6qYXsHaryGWvmMUHZX9Nb3pYFWCJA0HJ5WOo6HAyoqK/+po8GvaIW BYyLBvNhD46puQJuaC/04KLp0tLC/oyUqvoRVMkWqiRgW+84T/JnDWIdaUaMVEAUrEbu 6PEY0stKD37MUMOl5xrj2Zy1q/5J4Jw4qvOxE= 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=A6p0GoGBwzGL75rfxaPz89LOqFfeBzlpkiX979RYiZg=; b=EtPOD+6ciK3IeOtVobSc6gEpzvM3qm4/JklCh8jUWB7n7RKG9ZMyjbnR680FhPSPcP 67bA5WMz5DDUfYWA3XBGvWBqtCGEAfJUAKHbpsEh/wk95gq7VN6Df7dgkD0O7j1/Dn0n u6LLyPnVi8R5IscHsWc39zuzJitqo5cV5n2gdqO/07iGsyRuueuQif4/PQPduh2h7zj7 LZiD1PYolD6ThhfDYluoK24Khpf+awIe1BMitiJnqakAY9Jaownt5jKHwuhhpsnI4gcv dhLEu2bGyatJGjdOwRRGhkcbyA1HSlUqCOoqQhhWBShqFqdllI1OuQTyPfOwsYEcxTq2 ciLQ== X-Gm-Message-State: ALoCoQml9A7TXQTDOxjmxGpJWeOYPRgnlADb6DQHCpt5TjLQb0QsuN7YsYybqnDrcXuMJUYHRtMgRrn1tV2CBnZWNgsTwth0KsiymEmcIGSxZ3SFnNjJtA4= X-Received: by 10.50.143.37 with SMTP id sb5mr8751338igb.13.1437116901617; Fri, 17 Jul 2015 00:08:21 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> <6faa7a4e5858a5bb09b761c129b4814c@mail.gmail.com> <84275643-6EA3-4060-AA00-31CBCEA1653A@lurchi.franken.de> In-Reply-To: <84275643-6EA3-4060-AA00-31CBCEA1653A@lurchi.franken.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE86SdgORCvliHFE703NIXCziGWLQKpHUkGAiiw3coBaHzujgJBSMcpAhGHtOcCr5vwOgHu+g0GAbkLt5MCJc+oBgGuoRj/Afotd2IDCJPF2AE4aygvAgBpameeHz99oA== Date: Fri, 17 Jul 2015 09:08:20 +0200 Message-ID: <52b8471aae0ce48df596dc667e0fdf1b@mail.gmail.com> To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: "Pal Martinsen \(palmarti\)" , taps@ietf.org, Joe Touch Subject: Re: [Taps] TAPS Transports and ICMP 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, 17 Jul 2015 07:08:24 -0000 Hi Michael, >> [Karen ] TCP maps the received soft destination unreachable ICMPs to >> ENETUNREACH or EHOSTUNREACH pending errors on socket. >OK. FreeBSD provides EHOSTUNREACH instead of ETIMEDOUT for TCP. >It doesn't support ENETUNREACH. I don't think we do this in SCTP... > [Karen ] Yes. We do this for TCP (it is from rfc1122 I think), but not for SCTP and it is not prescribed in RFC6458 or RFC4960 for SCTP. This was the point of the notification discussion. Ideally I would like to see: * Path Failure and Assoc Change Event error fields are extended with new error value to be given when change is direct results of a received ICMP - and the ICMP should then also be passed up. NICE (or NOT NICE ?): * Generally then receipt of ICMPs results in notifications (if notifications are subscribed for of course). I am not so sure about the second as the notifications fills and take resources - and this is soft ICMPs. We have first and foremost focused on the first. BR, Karen >Best regards >Michael >> Thus at least temporarily this information is available and is >> notified towards the user. >> True that when the connection is closed, the information is >> overwritten - unless multiple pending errors are maintained by the >implementation. >> >>> I think the user can't distinguish from receiving an TCP RST. >>> Am I missing something? >>>> Presumably this is because the application could care. >>>> For implementations that do the "suboptimal" dormant state handling >>>> and follow the MAY here, then an application would care, I think. >>>> >>>>> I don't think so. And I think both cases are signalled to the >>>>> application for TCP in the same way. >>>>>> [Karen ] Yes, but even if the information is provided, then >>>>>> closing the association does not constitute a soft reaction. >>>>> ICMP9) of https://tools.ietf.org/html/rfc4960#appendix-C tells you >>>>> that >>>> it is >>>>> OK to increment the error counter or mark the destination as >> unreachable. >>>> It >>>>> is up to you to decide what is appropriate in your implementation. >>>> However, >>>>> you should not increment the association error counter, so it >>>>> shouldn't >>>> be an >>>>> association failure. >>>> [Karen ] I agree. >>>>> An association failure can only occur if you move the path state to >>>>> unreachable, have no reachable destinations anymore (dormant state) >>>>> and have decided that this means failing the association. But >>>>> again, this is >>>> related >>>>> to an, in my view, suboptimal handling of the dormant state. >>>>> FreeBSD >>>> doesn't >>>>> fail the association in this case. >>>> [Karen ] I agree that this is suboptimal handling of dormant state. >>>> We also do not to this suboptimal handling. >>>> I think that one could say that RFC4960 Appendix C prescriptions for >>>> how to handle soft icmps could relate to that this can make the >>>> assocs enter dormant state fast and that dormant state >>>> implementation need to relate to this fact if the MAYs are followed. >>> OK. >> [Karen ] Thanks for understanding. >> >> BR, Karen >>> >>> Best regards >>> Michael >>>> >>>> BR, Karen >>>>> >>>>> Best regards >>>>> Michael >>>>>> >>>>>> BR, Karen >>>>>>> >>>>>>> Best regards >>>>>>> Michael >>>>>>>> >>>>>>>>> In particular, destination unreachables can cause the SCTP >>>>>>>>> connection to >>>>>>>> go >>>>>>>> [Karen ] MAY force. And this MAY of the RFC I (and we) believe >>>>>>>> is questionable. We believe that for an implementation to >>>>>>>> support this MAY the implementation MUST implement dormant >state >>> handling >>>>>>>> as described (right now) in the SCTP Failover draft = SCTP >>>>>>>> continues to transmit data also when the destinations are >> considered >>> unreachable. >>>>>>>> (and our SCTP implementations do this). Further we think that >>>>>>>> the appropriate soft reaction to ICMP destination unreachable is >>>>>>>> to increment the path error counter, NOT to mark the destination >>>>>>>> as INACTIVE. >>>>>>>> Hopefully we will see these things be clarified in future SCTP >>>>>>>> drafts or ideally in the eventual RFC4960 revision. >>>>>>>> >>>>>>>>> into a dead state (mark the dest unreachable or increment the >>>>>>>>> path error >>>>>>>>> counter) without indicating anything to the user. >>>>>>>>> >>>>>>>> [Karen ] The state is not dead if "appropriate" dormant state >>>>>>>> handling is implemented. >>>>>>>> >>>>>>>>> This seems incorrect to me, given the number of other ways in >>>>>>>>> which SCTP >>>>>>>> can >>>>>>>>> shut down a connection (heartbeat failure, retransmission >>>>>>>>> failre) and is supposed to pass that info to the user. >>>>>>>>> >>>>>>>> [Karen ] I agree that when the association is closed as a >>>>>>>> direct result of receipt of ICMPs then this should be >>>>>>>> communicated to the >>>>>> Users. >>>>>>>> The envisaged approach (from our side) is to define a new error >>>>>>>> code for the sac_error of the SCTP_ASSOC_CHANGE (the >>>>>>>> notification of >>>>>>> comm_LOST): >>>>>>>> >>>>>>>> sac_error: If the state was reached due to an error condition >>>> (e.g., >>>>>>>> SCTP_COMM_LOST), any relevant error information is available in >>>>>>>> this field. This corresponds to the protocol error codes >> defined >>>>>>>> in [RFC4960]. >>>>>>>> >>>>>>>> Right now we have the possibility to use proprietary error codes >>>>>>>> here, but we would like to go beyond that of course. >>>>>>>> >>>>>>>> For the destination error counter the information goes into the >>>>>>>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >>>>>>>> destination address unreachability). >>>>>>>> >>>>>>>> PLEASE allow me to explain the abstract API in terms of a >>>>>>>> concrete one. I do understand the difference. >>>>>>>> The new thing is that the abstract transport API, which if >>>>>>>> nothing else exists in our heads and in our overall modeling, >>>>>>>> now with TAPS, may be defined as a concrete one. >>>>>>>> And I agree with everybody else that this is a good exercise and >>>>>>>> that it is doomed to (correct and) improve things substantially. >>>>>>>> >>>>>>>>> So, IMO, this is a great example of why studying these APIs as >>>>>>>> abstractions is >>>>>>>>> important and would have prevented this (IMO) oversight. >>>>>>>> [Karen ] We have studied this. But is only bringing this to the >>>>>>>> IETF >>>>>> now. >>>>>>>> Possibly to be addressed for RFC4960 revision. >>>>>>>>> >>>>>>>>> Or can someone in the SCTP team explain why shutting >>>>>>>>> connections down due to other reasons is a user signal but >>>>>>>>> validated ICMP signals are >>>>>> not? >>>>>>>> [Karen ] NA. >>>>>>>>> >>>>>>>>> Joe >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Taps mailing list >>>>>>>>> Taps@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>> >>>>>> >>>> >> From nobody Fri Jul 17 00:17: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 85A841B3001 for ; Fri, 17 Jul 2015 00:17:39 -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 RP7nqhRcZgfU for ; Fri, 17 Jul 2015 00:17:38 -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 3A2121B2FFE for ; Fri, 17 Jul 2015 00:17:38 -0700 (PDT) Received: by iggp10 with SMTP id p10so29653375igg.0 for ; Fri, 17 Jul 2015 00:17:37 -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=T4Juheo9GYuCAEmrYilNbi1fpNL8T/VuJlXN+wix59U=; b=JSeLOQznZrbctcZNhZq+iYEEH65LKEdREvCMwx5/Q5q8WrRolPUzoVv2gqC+vjBIvC XQhCFot33vV+/8Ia3gAwwQxdw+xQZ45mvdMyN9Umu9OONbToXGWLtZ4Ti1FFJudJFt7Y NdIW28TTkLY7dOPYcmVMjy/1GfbDdLAeCco1U= 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=T4Juheo9GYuCAEmrYilNbi1fpNL8T/VuJlXN+wix59U=; b=jxN+xsA6+5PKx2CWz0PQpQe+CEs5uGup37766sUglJEI0XptuSacqx3r46mRImqOrc VQdeCCMQsvSQL9G7XkgwpKrCPDSfG3endoyocj3oOyhg4mnUyZwQ14SjXiRz4W/0puer BSAm+ciinVzQyTPxBakEshyYA9XZp3v02kxdVxq8rBMbLSZV6Lbxb06OuejuXpSubdGl j38oMScCQNiUIqDAWn8FbHsC1CMnt+gDGZw4vubClF5TItSBPuLq/xn6EhU/Iqv0nsI4 dZ1g9O1x9kiotv6OTbsikH5SMNCPFpZnX5Ws62a1l9z0/7LRoDzKC3wr++R75lIpSHcr OPtQ== X-Gm-Message-State: ALoCoQl7Gkl9knPexKvXbpg5ivulOLdXufVEz0M7NQTq7ZoYVhDhlFN2D8GjSEaexBsbGtxjTIH5/3dG8JkvFASALSI7lnnhN6+vhilVSqqqb3x3I3vKJ7U= X-Received: by 10.107.136.160 with SMTP id s32mr16924021ioi.174.1437117457572; Fri, 17 Jul 2015 00:17:37 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150706220631.6336.219.idtracker@ietfa.amsl.com> <456cadf6d459a1c9e2c508af7b5470de@mail.gmail.com> <55A6A31B.3090500@isi.edu> <0047fc6ff18d95970285941d02534db4@mail.gmail.com> <55A7EE70.9040308@isi.edu> In-Reply-To: <55A7EE70.9040308@isi.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG/A9yO7NWA5qgnOWhDhpN5Pi0yHwGWuaxVAVccKzwB4ev60gIoNK0Pncr39wA= Date: Fri, 17 Jul 2015 09:17:36 +0200 Message-ID: <19919f75ba4ebb620630739e023745de@mail.gmail.com> To: Joe Touch , 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-06.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, 17 Jul 2015 07:17:39 -0000 Hi Joe, >-----Original Message----- >From: Joe Touch [mailto:touch@isi.edu] >Sent: Thursday, July 16, 2015 7:49 PM >To: Karen Elisabeth Egede Nielsen; taps@ietf.org >Cc: touch@isi.edu >Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt > >Hi, Karen, > >On 7/16/2015 12:27 AM, Karen Elisabeth Egede Nielsen wrote: >... >>> So there are several levels of the latency issue: >>> >>> - minimize the latency ADDED by the transport layer >>> - reduce the latency seen by the app >>> (which can involve more active interaction with the network >>> layer, anticipation, etc.) >>> >>> Note also that latency is not a single metric nor a meaningful >>> standalone >>> metric: >>> >>> 1. latency between two parties is a property *of a message*, >>> i.e., it requires knowing the message size >>> >>> 2. latency includes both basic and higher order effects; >>> the basic is "delay", the higher order include "jitter" etc. >>> Many common delay-sensitive use cases are really mostly >>> jitter sensitive. >>> >>> ... >> [Karen ] I agree so what do we mean in this document when we say that >> a transport service feature can be to provide minimal latency ? > >There should probably be two levels: > > - minimize what you add at the transport layer > > - reduce even further > >> Are we thinking about Nagle OFF ? > >That is how TCP might react to a request to minimizing added latency, but I >don't expect a TAPS API should expose the specific knob of "Nagle". > >>>> I am not sure if Connection oriented and Feature negotiation should >>>> be split into two features ? >>> >>> If you don't share state (i.e., what we tend to call a "connection"), >> what is the >>> meaning of feature negotiation? >>> >> [Karen ] Yes, but does connection oriented necessarily means that you >> can negotiate features ? > >Absolutely. Connection oriented means there is state that persists between >messages. To be useful, that state needs to be controllable. >Negotiating features *is* controlling that state. > [Karen ] Yes. OK. >... >>> So the general assumption that turning off Nagle will reduce latency >> should be >>> reasonable. >> [Karen ] I agree with this as a general assumption. >> But when I read the paragraph in the doc it almost sounds as if >> turning Nagle off comes with no price. > >I would think that should be clarified. > [Karen ] Good. Perhaps a clarification also can come with enforcing the bundling aspects of the segmentation paragraph. >> Do you have a counterexample seen in the wild? >> >> [Karen ] Yes we have examples with NO Nagle where the number of >> packets then becomes the bottleneck. >> In the local ends (CPU) as well as in the infrastructure elements. I >> am not sure how much of this information I can share. >> I can try to find out. That is why I was saying that how to provide >> minimal latency may depend on the application traffic. > >Because latency depends on the sizes of the messages, it should not be a >surprise that latency can't be minimized without that context. >> How to solve also depends on whether it is the average latency that >> needs to be minimal or whether the latency for some particular >> application "messages" should be kept as low as possible. > >This is difficult for TCP to handle, because TCP thinks of the input stream >as an >ordered sequence of bytes, and the issue of latency is related to message >boundaries within the TCP stream that are NOT part of the TCP API (there's >no >way for an application to indicate those boundaries to TCP - and no, the >SEND >boundaries are explicitly NOT those markers). > [Karen ] sure. >> For SCTP we allow for that Nagle is disabled on some streams (streams >> with high scheduling priority) and not on others. This is done exactly >> for this purpose. > >Sure, but that's also why it doesn't make sense for TCP. > [Karen ] Yes and then also why Nagle off for TCP may give undesired and contra-productive results from a latency perspective. But then TCP applications may not typically have the application traffic patterns that gives these undesired latency effects of disabling Nagle. BR, Karen >Joe From nobody Fri Jul 17 07: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 3EC461B3469 for ; Fri, 17 Jul 2015 07:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, 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 ZmA0_t520t-x for ; Fri, 17 Jul 2015 07:33:38 -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 31F981B3466 for ; Fri, 17 Jul 2015 07:33:38 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZG6hj-0001D2-B1; Fri, 17 Jul 2015 16:33:35 +0200 Received: from [88.208.109.142] (helo=[192.168.11.63]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZG6hi-0003aM-KN; Fri, 17 Jul 2015 16:33:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <032C97CD-A8D3-4553-9DD1-B17E2295AC43@trammell.ch> Date: Fri, 17 Jul 2015 16:33:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BD04B53-35D1-4D95-A305-B3EF794D1ECE@ifi.uio.no> References: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com> <032C97CD-A8D3-4553-9DD1-B17E2295AC43@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 4 sum rcpts/h 17 sum msgs/h 4 total rcpts 31073 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D0AC4EACDF2A222EDEA844B8973371BBA5E5C212 X-UiO-SPAM-Test: remote_host: 88.208.109.142 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 4 total 21 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Karen Elisabeth Egede Nielsen , "taps@ietf.org" , Stein Gjessing Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-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: Fri, 17 Jul 2015 14:33:40 -0000 > On 16. jul. 2015, at 15.04, Brian Trammell wrote: >=20 > hi Michael, >=20 > ...inline... >=20 >> On 16 Jul 2015, at 13:23, Michael Welzl wrote: >=20 > >=20 >>> Ideally, I think, then one would use a common term for Nagle(-like) >>> bundling for TCP and SCTP. >>=20 >> Agreed, we actually did that in Michael Welzl, Stefan J=C3=B6rer, = Stein Gjessing: "Towards a Protocol-Independent Internet Transport API", = FutureNet IV workshop in conjunction with of IEEE ICC 2011, 5-9 June = 2011, Kyoto, Japan, >> using app PDU bundling because it's more meaningful than Nagle. >>=20 >> But here the idea was just to copy+paste the list from doc 1 (version = 4) and put things under the correct headings, as a way to show how we = *could* apply categorization methods. >=20 > hm, so perhaps we should have coordinated here. That list, in that = version, wasn't quite complete. That doesn't matter - the point of the doc was to introduce the possible = categorization and fill the "functional / non-functional" part with some = examples so it's more understandable. If this list of examples is = complete really doesn't matter. > In the current version it's still not quite complete, as we're still = trying to nail down how to partition the space of features (and how to = divide things that are actually features from things that are just = accidental effects of the way protocols have evolved). There are also = aspects of the interfaces (coming from the interface discussion) we'd = like to capture, on which we'd like to discuss f2f next Thursday. ACK, indeed... > Perhaps another way to approach this would be to start with a list of = features we think we want in doc 2, and to use the background from doc 1 = to fill in the gaps... Bad idea I think. It raises horrible memories of TAPS creation. See, I = started this off by saying that we have to do it bottom-up, by beginning = with what protocols can do, not what services apps could want. This has = disadvantages and is a compromise but it comes from looking at a history = of well above a decade of people proposing these kinds of things and = nothing coming out of it. That's because there are so many degrees of = freedom and it's practically impossible to end up agreeing on anything. My take-away from TAPS creation was that people had to share this = experience together with me: let's do it top-down - oh, really, we can't = agree - and now we're back at what I started with: bottom up. Please please please let's not do another round on this ride with doc 2! = :-) Cheers, Michael From nobody Fri Jul 17 10:28:28 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 55C0A1ACD27 for ; Fri, 17 Jul 2015 10:28:27 -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 MXmkMrXZwwUU for ; Fri, 17 Jul 2015 10:28:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3701ACD23 for ; Fri, 17 Jul 2015 10:28:26 -0700 (PDT) Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6HHRtEh028349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jul 2015 10:27:56 -0700 (PDT) To: Karen Elisabeth Egede Nielsen , taps@ietf.org References: <20150706220631.6336.219.idtracker@ietfa.amsl.com> <456cadf6d459a1c9e2c508af7b5470de@mail.gmail.com> <55A6A31B.3090500@isi.edu> <0047fc6ff18d95970285941d02534db4@mail.gmail.com> <55A7EE70.9040308@isi.edu> <19919f75ba4ebb620630739e023745de@mail.gmail.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55A93B1B.5020703@isi.edu> Date: Fri, 17 Jul 2015 10:27:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <19919f75ba4ebb620630739e023745de@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.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, 17 Jul 2015 17:28:27 -0000 Hi, Kasren, [Michael]: >>> For SCTP we allow for that Nagle is disabled on some streams (streams >>> with high scheduling priority) and not on others. This is done exactly >>> for this purpose. [Joe]: >> Sure, but that's also why it doesn't make sense for TCP. > [Karen ] Yes and then also why Nagle off for TCP may give undesired and > contra-productive results from a latency perspective. > But then TCP applications may not typically have the application traffic > patterns that gives these undesired latency effects of disabling Nagle. The one thing we should have learned about TCP is to not make assumptions about traffic patterns: - (paraphrasing) after going idle, we need to decide whether to slam CWND down or keep it open, and we need a "time since last sent"; we don't have that timer, but because TCP traffic is mostly symmetric, let's use "time since last received" (VJ88) Result: burst the entire CWND on the next HTTP request - TCP congestion control can assume infinite sources Result: good performance for elephants but bad for mice or transaction sequences (web) - TCP should not send large amounts of small packets because they create congestion, e.g., Telnet (Nagle) Result: very bad delays on protocols where multibyte messages can straddle packet boundaries, e.g., Telnet with Unicode, Web, etc. i.e., Nagle fails exactly for the kinds of uses it was intended Joe From nobody Thu Jul 23 09:11: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 D04EF1A00FA for ; Thu, 23 Jul 2015 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, WEIRD_PORT=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 b-51A7cnV6bx for ; Thu, 23 Jul 2015 09:11:39 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 99D461ACD56 for ; Thu, 23 Jul 2015 09:11:28 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so17430585igb.0 for ; Thu, 23 Jul 2015 09:11:28 -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=9SnzFehYDIPKaL9Z6B7UtgEGwGOu0yB7JYYGm67beHM=; b=p2/Xq4bc6x6uoK7PzrVnQmwQBM82bCxlzBIHiNfnGzvD0X46ep5OwBXqi+8JmuSKcA Fy3nYdp0r/frDxnrxb9N2CWb8VQ3d9j80J0BkBpjLt5ltNuwLgi7Et2L/Z/arllcE4vf kqd2E/DleR0UGP0zJHLYxsDHL8h/tdiAalcb1U9u25GydOxFlfZ2qwa3Owq2O/xo91+7 hgI+zRKVfHgDuyeWp4nfqjICwQ1LLFbA+EWeyapaDDr6zirjJQbQ9AeB7gsH65dpEDYC rQSJYfzPIf+phY43PmgF78Bfc6frUvEFQ0zD1LmK619iWE+G23Mo8xQWI9O6uyFRNi13 0WeQ== MIME-Version: 1.0 X-Received: by 10.50.60.100 with SMTP id g4mr45683347igr.41.1437667888085; Thu, 23 Jul 2015 09:11:28 -0700 (PDT) Received: by 10.64.59.225 with HTTP; Thu, 23 Jul 2015 09:11:28 -0700 (PDT) Date: Thu, 23 Jul 2015 18:11:28 +0200 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10d10bc63f6c051b8d23f7 Archived-At: Subject: [Taps] notes from IETF-93 TAPS meeting 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, 23 Jul 2015 16:11:41 -0000 --047d7b10d10bc63f6c051b8d23f7 Content-Type: text/plain; charset=UTF-8 Ken Calvert posted the notes from the meeting at the link below. Please take a look and correct any inaccuracies. It is polite to enter your name in the users list (upper-right menu) so it is clear who made what changes. http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-taps --aaron --047d7b10d10bc63f6c051b8d23f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ken Calvert posted the notes from the meeting at the link = below.=C2=A0 Please take a look and correct any inaccuracies.=C2=A0 It is p= olite to enter your name in the users list (upper-right menu) so it is clea= r who made what changes.


--aaron

=

--047d7b10d10bc63f6c051b8d23f7-- From nobody Thu Jul 23 09:33:00 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 D65F41A1A79; Thu, 23 Jul 2015 09:32:55 -0700 (PDT) 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 KDj13FwQyl7F; Thu, 23 Jul 2015 09:32:54 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6721A2130; Thu, 23 Jul 2015 09:32:45 -0700 (PDT) Received: from dhcp-b12e.meeting.ietf.org (dhcp-b12e.meeting.ietf.org [31.133.177.46]) by trammell.ch (Postfix) with ESMTPSA id C7FDE1A035E; Thu, 23 Jul 2015 18:32:14 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 23 Jul 2015 18:32:13 +0200 Message-Id: To: IAB SEMI Workshop , spud@ietf.org, taps WG , hops@ietf.org, tsv-area@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Stackevo , IAB IAB Subject: [Taps] New open IAB list to discuss stack evolution issues 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, 23 Jul 2015 16:32:56 -0000 --Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've heard a bit of confusion about the plethora of mailing lists on = which to discuss efforts to evolve the stack in and around the transport = layer, and we've decided to fix the confusion by creating another list. = :) The stackevo-discuss@iab.org list has been created for discussion any = and all aspects of evolution of the IP protocol stack. List membership = is open; please join at = https://www.iab.org/mailman/listinfo/stackevo-discuss Thanks, cheers, Brian Trammell (IAB IP Stack Evolution Program Lead) --Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8 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 - https://gpgtools.org iQEcBAEBCgAGBQJVsRcNAAoJENt3nsOmbNJcTVIH/iepa3ml9ulR2p+AEZovAh/1 lbfheo0Y9Pa3LJu1LdybNJV05ae5pC/XThoirkUfAR6/0DvGjfLD3Msiyd/xCm/+ Ydf4Vw2yhaBtt6PkztO7O/3LXA1T25EvxI2SDhIt/o/9aH86v9e89MbmiZAIKPyn +3GE5rjg2XXZdmB+kzseYBgQHNBjK09JxDDJkcDnw25E8Vyqhq4jG951Q1KaEYm2 Q8ffrXDoeLSvcyCWHczWsF8HDLSwbdYpgaeUdVqhYskCbckE9zDJPlf7nItkXHtS w6jEGi0fhnfhpb60ZhA7d3IE8Aq3y9Ityv6fpWn+mGGj08vIKuFzBdihrjyv6/g= =GssY -----END PGP SIGNATURE----- --Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8--