From nobody Wed Apr 2 10:51:03 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BF11A033B; Wed, 2 Apr 2014 10:50:59 -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 LYh_J5obmd_1; Wed, 2 Apr 2014 10:50:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E10501A03A0; Wed, 2 Apr 2014 10:50:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402175053.4055.16525.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 10:50:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/1TIwna-kE1wQ9C8HvvnKaCnwG5E Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 17:50:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : DSCP and other packet markings for RTCWeb QoS Authors : Subha Dhesikan Dan Druta Paul Jones James Polk Filename : draft-ietf-tsvwg-rtcweb-qos-00.txt Pages : 7 Date : 2014-04-02 Abstract: Many networks, such as service provider and enterprise networks, can provide per packet treatments based on Differentiated Services Code Points (DSCP) on a per-hop basis. This document provides the recommended DSCP values for browsers to use for various classes of traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-00 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 Tue Apr 8 04:30:40 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0054D1A014F; Tue, 8 Apr 2014 04:30:37 -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 y_ixGKZD4jLW; Tue, 8 Apr 2014 04:30:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 422101A0339; Tue, 8 Apr 2014 04:30:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408113031.7710.99114.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 04:30:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/08vEy324n_fiWjz-jlp-xBx8b_U Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-prpolicies-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 11:30:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol Authors : Michael Tuexen Robin Seggelmann Randall R. Stewart Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-prpolicies-02.txt Pages : 7 Date : 2014-04-08 Abstract: This document defines policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-prpolicies-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 8 07:07:06 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648561A040A for ; Tue, 8 Apr 2014 07:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_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 WfuI0xnS8Z2I for ; Tue, 8 Apr 2014 07:06:50 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8951A03FF for ; Tue, 8 Apr 2014 07:06:43 -0700 (PDT) Received: from [192.168.1.103] (p508F1055.dip0.t-ipconnect.de [80.143.16.85]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4F3431C103E4A; Tue, 8 Apr 2014 16:06:40 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> Date: Tue, 8 Apr 2014 16:06:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> To: tsvwg WG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/QtMHG_rKqefDtyRAKalXBP6PzIo Cc: Joe Touch Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:07:00 -0000 On 07 Mar 2014, at 20:46, Michael Tuexen = wrote: Hi Joe, thank you for your review. Please find my comments in-line. Best regards Michael > WGLC comments from Joe. >=20 > Best regards > Michael >=20 > Begin forwarded message: >=20 >> From: Joe Touch >> Subject: Re: Fwd: [tsvwg] I-D Action: = draft-ietf-tsvwg-sctp-dtls-encaps-03.txt >> Date: 6 Mar 2014 23:55:24 GMT >> To: Michael Tuexen >> Cc: Gorry Fairhurst , Randall Stewart = , Randell Jesup , Salvatore Loreto = >>=20 >> Hi, Michael, >>=20 >> On 2/7/2014 7:55 AM, Michael Tuexen wrote: >>> Hi Joe, >>>=20 >>> Gorry suggested that you might be interested in reviewing the SCTP = over DTLS >>> ID, since you are interested in transport tunnels. So would it be = possible >>> for you to review the document (it is pretty short)? I would = appreciate your >>> review very much! >> ... >>>> Filename : draft-ietf-tsvwg-sctp-dtls-encaps-03.txt >>=20 >> Comments below. Feel free to post/forward as usual; please cc me if = you do, so I can track any followups if needed. >>=20 >> Joe >>=20 >> ----- >>=20 >> 1 - I'm not a fan of "stacked headers"; section 1 should have = something to say before you jump into 1.1 Agreed. Actually the abbreviations are almost useless and the = terminology can also be removed. Therefore, section 1 will only contain the overview. >>=20 >> 1.1 - This section should more clearly explain the need for DTLS = encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with = security. That's implied right now, and should be explicit. >>=20 >> Why doesn't the entirety of this document not boil down to "run SCTP = over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't that = description then mean you can then omit section 3? One of the important points of RFC 6951 is how to deal with the UDP port = numbers. These need to be handled in a specific way as described in RFC 6951. = This does not apply here. This document describes how to run SCTP over a = connections oriented protocol without providing SCTP with any information about IP = addresses and UDP port numbers. You might run DTLS over TCP or HTTP or whatever. So I added at the end of the Overview: Please note that the procedures defined in =20= for dealing with the UDP port numbers do not apply here. When using the encapsulation defined in this document, SCTP is agnostic about the protocols used below DTLS. >>=20 >> 3 - I don't understand "sent down to the DTLS layer"; RFC6951 doesn't = say "sent down to UDP". But, as noted, this section isn't needed. Replaced by: When an SCTP packet is provided to the DTLS layer, ... >>=20 >> 4 - The first sentence should be "SCTP over DTLS MUST support DTLS = v1.2 or higher [RFC6341]." T A similar comment was already made resulting in the following text: The DTLS implementation MUST be based on DTLS 1.2 [RFC6347]. The support = of future versions of DTLS is RECOMMENDED if defined. Is that acceptable? >>=20 >> The MTU discovery is already in DTLS 1.2 - no need to state, and no = need to require that particular solution (e.g., it seems OK if DTLS = updates it). I don't think DTLS 1.2 requires you to uses probe packets defined in RFC = 6520. What we want to avoid, is that user data is used as probe packets. >>=20 >> I'm not sure what the issue with probe packets is, but why is this a = MUST, rather than just the statement "Probe packets are supported using = existing DTLS extensions [RFC6520]"? Again, do you care if there are = other DTLS methods for doing this? We do care that RFC 4821 is used with probe packet not being user = messages. So RFC 6520 provides one way. Other might be possible in the future. So what about For probe packets, the extension defined in = can be used. >>=20 >> The Path MTU paragraph is already addressed in RFC6951 - why add it = here? Because RFC 6951 doesn't apply here. >>=20 >> The doc should explain why you care about disabling DTLS compression. Hmmm. It is stated: SCTP performs segmentation and reassembly based on the path MTU. If DTLS performs compression, which limit should SCTP use knowing that it fits into the packet. And if SCTP performs the path MTU discovery (as in the case of RTCWeb), than it can't detect the the message size of the outgoing packet. >>=20 >> The last sentence seems like it should be MUST NOT. No. How can you send probe packets if you can't send packets larger than the current PMTU. >>=20 >> I.e., overall, it seems like you get what you need with a simpler = first sentence, and the last two only. I don't think so. This document is independent from the UDP encaps = one... >>=20 >> 5 - same stacked header problem Right. Fixed. I added: This section describes the usage of the base protocol and the = applicability of various SCTP extensions. Since SCTP is agnostic about the protocols = being used below DTLS, explicit IP addresses MUST NOT be using in the SCTP = control chunks. As a consequence, the SCTP associations are single homed. >=20 >>=20 >> 5.1 - odd wording on first sentence. seems like you want to say "This = doc defines SCTP [RFC4960] in DTLS 1.2." I just want to make clear which specification is used for SCTP. So what = about: specifies SCTP. Is that better? >>=20 >> The issue here is, IMO, more that DTLS is connectionless *vs UDP* = (the comparison is more direct). Correct. I changed the wording to: However, the following restrictions are necessary to reflect that the = lower layer is DTLS instead of IPv4 and IPv6 and that SCTP doesn't deal with the IP addresses or the transport protocol used below DTLS: Does that address you issue? >>=20 >> I would not suggest using abbreviated terminology; you refer to = associations only in one place. Why make it hard to understand that you = mean "SCTP associations"? Agreed. Using SCTP association here. >>=20 >> The last bullet in this list is redundant; it's already covered in = SCTP over UDP. IMO you're really applying SCTP over UDP to this, so you = should refer to RFC6951 as normative and describe this as a superset of = that. Again. I don't see RFC 6951 applying here. >>=20 >> 5.2 - redundant with RFC6951 AFAICT See above. >>=20 >> 5.3 - why not put all the "no explicit addresses in band" somewhere, = and include both this and other uses of addresses as examples? Makes sense. I added corresponding text to the section introduction as = given above. >>=20 >> ----- >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 From nobody Tue Apr 8 11:48:12 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E53F1A0416 for ; Tue, 8 Apr 2014 11:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 bHEprnRSgJ51 for ; Tue, 8 Apr 2014 11:47:45 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 166081A0695 for ; Tue, 8 Apr 2014 11:47:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s38IkP8c017840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2014 11:46:26 -0700 (PDT) Message-ID: <53444401.9030905@isi.edu> Date: Tue, 08 Apr 2014 11:46:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen , tsvwg WG References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/WaloVuD3HQtlgS7m09rp6qQDl7k Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:47:57 -0000 Hi, Michael, Feedback below. Hopefully useful. On 4/8/2014 7:06 AM, Michael Tuexen wrote: > On 07 Mar 2014, at 20:46, Michael Tuexen wrote: > > Hi Joe, > > thank you for your review. Please find my comments in-line. > > Best regards > Michael > >> WGLC comments from Joe. >> >> Best regards >> Michael >> >> Begin forwarded message: >> >>> From: Joe Touch >>> Subject: Re: Fwd: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt >>> Date: 6 Mar 2014 23:55:24 GMT >>> To: Michael Tuexen >>> Cc: Gorry Fairhurst , Randall Stewart , Randell Jesup , Salvatore Loreto >>> >>> Hi, Michael, >>> >>> On 2/7/2014 7:55 AM, Michael Tuexen wrote: >>>> Hi Joe, >>>> >>>> Gorry suggested that you might be interested in reviewing the SCTP over DTLS >>>> ID, since you are interested in transport tunnels. So would it be possible >>>> for you to review the document (it is pretty short)? I would appreciate your >>>> review very much! >>> ... >>>>> Filename : draft-ietf-tsvwg-sctp-dtls-encaps-03.txt >>> >>> Comments below. Feel free to post/forward as usual; please cc me if you do, so I can track any followups if needed. >>> >>> Joe >>> >>> ----- >>> >>> 1 - I'm not a fan of "stacked headers"; section 1 should have something to say before you jump into 1.1 > Agreed. Actually the abbreviations are almost useless and the terminology can > also be removed. Therefore, section 1 will only contain the overview. >>> >>> 1.1 - This section should more clearly explain the need for DTLS encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with security. That's implied right now, and should be explicit. >>> >>> Why doesn't the entirety of this document not boil down to "run SCTP over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't that description then mean you can then omit section 3? > > One of the important points of RFC 6951 is how to deal with the UDP port numbers. The abstract of RFC 6951 seems to indicate otherwise: ...In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. There's an API for configuring the port number being used, but it doesn't seem to matter what port number is actually used (though 9899 is the default, as per Section 7). > These need to be handled in a specific way as described in RFC 6951. This does > not apply here. This document describes how to run SCTP over a connections > oriented protocol without providing SCTP with any information about IP addresses > and UDP port numbers. I can't see why Section 6.1 wouldn't apply equally well here, though. Even when you run over DTLS you still need to pick a transport port number, no? > You might run DTLS over TCP or HTTP or whatever. > So I added at the end of the Overview: > > Please note that the procedures defined in > for dealing with the UDP port numbers do not apply here. > When using the encapsulation defined in this document, SCTP is agnostic > about the protocols used below DTLS. > >>> >>> 3 - I don't understand "sent down to the DTLS layer"; RFC6951 doesn't say "sent down to UDP". But, as noted, this section isn't needed. > Replaced by: > When an SCTP packet is provided to the DTLS layer, ... OK. >>> >>> 4 - The first sentence should be "SCTP over DTLS MUST support DTLS v1.2 or higher [RFC6341]." T > A similar comment was already made resulting in the following text: > > The DTLS implementation MUST be based on DTLS 1.2 [RFC6347]. The support of future versions of DTLS is RECOMMENDED if defined. > > Is that acceptable? Yup. >>> >>> The MTU discovery is already in DTLS 1.2 - no need to state, and no need to require that particular solution (e.g., it seems OK if DTLS updates it). > > I don't think DTLS 1.2 requires you to uses probe packets defined in RFC 6520. That's correct; it doesn't -- it leaves PMTU discovery to the application (Sec 4.1.1.1). > What we want to avoid, is that user data is used as probe packets. If that's true, you need to motivate it rather than just declaring so. I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to the application - which arguably is SCTP here. If the extensions in RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they don't). And why aren't they MUST or SHOULD? (I'm disappointed -- but not surprised -- that RFC 6520 appears to have no indication of the status of the extension, e.g., MUST, SHOULD, etc., in relation to the TLS/DTLS spec) >>> >>> I'm not sure what the issue with probe packets is, but why is this a MUST, rather than just the statement "Probe packets are supported using existing DTLS extensions [RFC6520]"? Again, do you care if there are other DTLS methods for doing this? > > We do care that RFC 4821 is used with probe packet not being user messages. > So RFC 6520 provides one way. Other might be possible in the future. Then update the doc in the future; if this is standards-track (and it appears to be intended for that), you should state the MUST of 6520 and leave any future extensions for future authors of an update IMO. > So what about > For probe packets, the extension defined in can be used. MUST, IMO. >>> >>> The Path MTU paragraph is already addressed in RFC6951 - why add it here? > > Because RFC 6951 doesn't apply here. Again, I think it really does. You're just adding another layer (DTLS), but ultimately there are two layers you need to be concerned about - DTLS and UDP. >>> >>> The doc should explain why you care about disabling DTLS compression. > Hmmm. It is stated: > SCTP performs segmentation and reassembly based on the path MTU. > If DTLS performs compression, which limit should SCTP use knowing that > it fits into the packet. The uncompressed size. Note that neither PMTUD nor PLMTUD RFCs mention compression, and ROHC doesn't mention MTUD. VJ's compression mentions the interaction, but allows it. > And if SCTP performs the path MTU discovery (as in the case of RTCWeb), > than it can't detect the the message size of the outgoing packet. Sure it can; it measures from the size of the packets sent (compressed), though. >>> >>> The last sentence seems like it should be MUST NOT. > No. How can you send probe packets if you can't send packets larger than > the current PMTU. How can you do PMTU discovery if IP fragments the packets (which you mention in the next sentence)? You need to more carefully discuss how probe packets are generated and avoid outgoing fragmentation (as well as on-path fragmentation). And it would apply only to probes. That's an interaction a layer below DTLS, but you need to address it here too. >>> >>> I.e., overall, it seems like you get what you need with a simpler first sentence, and the last two only. > I don't think so. This document is independent from the UDP encaps one... I don't see how you can discuss things like MTU discovery and be independent of any transport discussion at all. >>> >>> 5 - same stacked header problem > Right. Fixed. I added: > This section describes the usage of the base protocol and the applicability > of various SCTP extensions. Since SCTP is agnostic about the protocols being > used below DTLS, explicit IP addresses MUST NOT be using in the SCTP control > chunks. As a consequence, the SCTP associations are single homed. Introductory headers shouldn't include requirements. IMO, leave that address requirement for a subsection; the header paragraph should setup the subsections only. Further, this sounds like something that ought to be mentioned in the asbtract and intro - it might severely limit the utility of the approach. >> >>> >>> 5.1 - odd wording on first sentence. seems like you want to say "This doc defines SCTP [RFC4960] in DTLS 1.2." > I just want to make clear which specification is used for SCTP. So what about: > specifies SCTP. > Is that better? Not really; maybe you wan to say: This document uses SCTP [RFC4960] with the following restrictions, which are required to reflect... >>> The issue here is, IMO, more that DTLS is connectionless *vs UDP* (the comparison is more direct). > Correct. I changed the wording to: > > However, the following restrictions are necessary to reflect that the lower layer > is DTLS instead of IPv4 and IPv6 or UDP over IP as per RFC6951 > and that SCTP doesn't deal with the IP > addresses or the transport protocol used below DTLS: IMO, it's more that it *can't* deal with addresses that far down. > Does that address you issue? >>> >>> I would not suggest using abbreviated terminology; you refer to associations only in one place. Why make it hard to understand that you mean "SCTP associations"? > Agreed. Using SCTP association here. AOK. >>> >>> The last bullet in this list is redundant; it's already covered in SCTP over UDP. IMO you're really applying SCTP over UDP to this, so you should refer to RFC6951 as normative and describe this as a superset of that. > Again. I don't see RFC 6951 applying here. See above; I think it is really relevant, and odd to present this approach as completely distinct from that RFC. >>> >>> 5.2 - redundant with RFC6951 AFAICT > See above. >>> >>> 5.3 - why not put all the "no explicit addresses in band" somewhere, and include both this and other uses of addresses as examples? > Makes sense. I added corresponding text to the section introduction as given above. Sure. Joe >>> >>> ----- >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> > From nobody Tue Apr 8 12:25:08 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D071A06F4 for ; Tue, 8 Apr 2014 12:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 utqc-D-3aJpY for ; Tue, 8 Apr 2014 12:25:05 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id C76901A01BA for ; Tue, 8 Apr 2014 12:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=839; q=dns/txt; s=iport; t=1396985105; x=1398194705; h=from:to:subject:date:message-id:mime-version; bh=ZEn7xKhHx1tnnIbXqGI+C4HcJBrwews5hF776EA4AFw=; b=nAgAaxuoMgM7WVuzGn1/wR2qTWkGSpNVnmbT3wf3nb3TdIV71QrhAe4R NYXtQJwk2Yc+jbn9iXi9MsOAcSI69bnfN0IhxB0BP6kgYkkXWsF/XV8ih vhTk1oXw6dluUIXBkppr9x1q/omNjT07ehz+es1ulMas2lAON2HwpGIah o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAKhMRFOtJV2a/2dsb2JhbABZgkJEgRLEOYEiFnSCJwEEGXIBCwECHFYfBAMBBBuHdJldsQUXjjuDXIEUBIkjoXqDMIIr X-IronPort-AV: E=Sophos; i="4.97,819,1389744000"; d="scan'208,217"; a="34061753" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 08 Apr 2014 19:25:04 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s38JP4op006508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Apr 2014 19:25:04 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 14:25:04 -0500 From: "James Polk (jmpolk)" To: "tsvwg@ietf.org" Thread-Topic: test Thread-Index: Ac9TYD3t7XihZqzTRg6ek+X7DuZdcA== Date: Tue, 8 Apr 2014 19:25:03 +0000 Message-ID: <7109A08FAC30224D9EC81057EA211D2B1084D208@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.11.38] Content-Type: multipart/alternative; boundary="_000_7109A08FAC30224D9EC81057EA211D2B1084D208xmbalnx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/8EJi_vbHCAg3lUPHU_YeJMBSXx0 Subject: [tsvwg] test X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:25:06 -0000 --_000_7109A08FAC30224D9EC81057EA211D2B1084D208xmbalnx08ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable test, please ignore --_000_7109A08FAC30224D9EC81057EA211D2B1084D208xmbalnx08ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
test, please ignore
--_000_7109A08FAC30224D9EC81057EA211D2B1084D208xmbalnx08ciscoc_-- From nobody Tue Apr 8 12:57:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1231A0711 for ; Tue, 8 Apr 2014 12:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_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 HMvZl4fO_81S for ; Tue, 8 Apr 2014 12:56:49 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E31A0736 for ; Tue, 8 Apr 2014 12:56:48 -0700 (PDT) Received: from [192.168.1.200] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CBBBA1C0B402C; Tue, 8 Apr 2014 21:56:46 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53444401.9030905@isi.edu> Date: Tue, 8 Apr 2014 21:56:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/S2dCwsDFNQu1JHcuU-6K5A5UViY Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:56:57 -0000 On 08 Apr 2014, at 20:46, Joe Touch wrote: > Hi, Michael, >=20 > Feedback below. Hopefully useful. Hi Joe, thanks for the feedback. It is very useful and will improve the = document. See my comments/response in-line. Best regards Michael >=20 > On 4/8/2014 7:06 AM, Michael Tuexen wrote: >> On 07 Mar 2014, at 20:46, Michael Tuexen = wrote: >>=20 >> Hi Joe, >>=20 >> thank you for your review. Please find my comments in-line. >>=20 >> Best regards >> Michael >>=20 >>> WGLC comments from Joe. >>>=20 >>> Best regards >>> Michael >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Joe Touch >>>> Subject: Re: Fwd: [tsvwg] I-D Action: = draft-ietf-tsvwg-sctp-dtls-encaps-03.txt >>>> Date: 6 Mar 2014 23:55:24 GMT >>>> To: Michael Tuexen >>>> Cc: Gorry Fairhurst , Randall Stewart = , Randell Jesup , Salvatore Loreto = >>>>=20 >>>> Hi, Michael, >>>>=20 >>>> On 2/7/2014 7:55 AM, Michael Tuexen wrote: >>>>> Hi Joe, >>>>>=20 >>>>> Gorry suggested that you might be interested in reviewing the SCTP = over DTLS >>>>> ID, since you are interested in transport tunnels. So would it be = possible >>>>> for you to review the document (it is pretty short)? I would = appreciate your >>>>> review very much! >>>> ... >>>>>> Filename : draft-ietf-tsvwg-sctp-dtls-encaps-03.txt >>>>=20 >>>> Comments below. Feel free to post/forward as usual; please cc me if = you do, so I can track any followups if needed. >>>>=20 >>>> Joe >>>>=20 >>>> ----- >>>>=20 >>>> 1 - I'm not a fan of "stacked headers"; section 1 should have = something to say before you jump into 1.1 >> Agreed. Actually the abbreviations are almost useless and the = terminology can >> also be removed. Therefore, section 1 will only contain the overview. >>>>=20 >>>> 1.1 - This section should more clearly explain the need for DTLS = encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with = security. That's implied right now, and should be explicit. >>>>=20 >>>> Why doesn't the entirety of this document not boil down to "run = SCTP over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't = that description then mean you can then omit section 3? > > >> One of the important points of RFC 6951 is how to deal with the UDP = port numbers. >=20 > The abstract of RFC 6951 seems to indicate otherwise: >=20 > ...In particular, it does not provide mechanisms > to determine whether UDP encapsulation is being used by the peer, = nor > the mechanisms for determining which remote UDP port number can be > used. These functions are out of scope for this document. >=20 > There's an API for configuring the port number being used, but it = doesn't seem to matter what port number is actually used (though 9899 is = the default, as per Section 7). I was not clear enough and maybe the cited text is also not very clear. Let me be more precisely: RFC 6951 does not provide a mechanism to figure out if the initiator = should use UDP encapsulation or not. And RFC 6951 does not provide a mechanism to = figure out which UDP port number to use for the initial packet. However, RFC 6951 does tell you that an SCTP stack has one local UDP = encapsulation port number and needs to store per path for each association a remote = UDP encapsulation port number. See http://tools.ietf.org/html/rfc6951#section-5.1 RFC 6951 also tells you how to update the remote encapsulation port number when a packet is received. See http://tools.ietf.org/html/rfc6951#section-5.4 Therefore the SCTP stack has to manage the UDP port numbers being used. = This is an important part of the UDP encapsulation. Since this is not used = when using DTLS, there is a major difference between the documents. >=20 >> These need to be handled in a specific way as described in RFC 6951. = This does >> not apply here. This document describes how to run SCTP over a = connections >> oriented protocol without providing SCTP with any information about = IP addresses >> and UDP port numbers. >=20 > I can't see why Section 6.1 wouldn't apply equally well here, though. = Even when you run over DTLS you still need to pick a transport port = number, no? Yes, but this is not managed by the SCTP stack. This is managed by the = DTLS layer. And I don't think DTLS can deal with UDP port number changes during the = communication as SCTP can. SCTP/UDP as described in RFC 6951 can survive that a NAT = box changes the port number mapping, SCTP/DTLS can't... >=20 >> You might run DTLS over TCP or HTTP or whatever. >> So I added at the end of the Overview: >>=20 >> Please note that the procedures defined in >> for dealing with the UDP port numbers do not apply here. >> When using the encapsulation defined in this document, SCTP is = agnostic >> about the protocols used below DTLS. >>=20 >>>>=20 >>>> 3 - I don't understand "sent down to the DTLS layer"; RFC6951 = doesn't say "sent down to UDP". But, as noted, this section isn't = needed. >> Replaced by: >> When an SCTP packet is provided to the DTLS layer, ... >=20 > OK. >=20 >>>>=20 >>>> 4 - The first sentence should be "SCTP over DTLS MUST support DTLS = v1.2 or higher [RFC6341]." T >> A similar comment was already made resulting in the following text: >>=20 >> The DTLS implementation MUST be based on DTLS 1.2 [RFC6347]. The = support of future versions of DTLS is RECOMMENDED if defined. >>=20 >> Is that acceptable? >=20 > Yup. >=20 >>>>=20 >>>> The MTU discovery is already in DTLS 1.2 - no need to state, and no = need to require that particular solution (e.g., it seems OK if DTLS = updates it). > > >> I don't think DTLS 1.2 requires you to uses probe packets defined in = RFC 6520. >=20 > That's correct; it doesn't -- it leaves PMTU discovery to the = application (Sec 4.1.1.1). Which is SCTP, in this case... One of the options allowed. So are you = suggesting just to require that SCTP the PMTU discovery and take out the option that DTLS does it? = I'm fine with that change, especially because this is exactly what RTCWeb does. >=20 >> What we want to avoid, is that user data is used as probe packets. >=20 > If that's true, you need to motivate it rather than just declaring so. OK. What about adding: User messages SHOULD NOT be used as probe packets, because during = probing this results in potential packet loss which increases due to the = necessary retransmissions the delay of the user message transfer. >=20 > I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to = the application - which arguably is SCTP here. If the extensions in RFC = 6520 are that important, why don't they UPDATE the DTLS spec? (they = don't). And why aren't they MUST or SHOULD? >=20 > (I'm disappointed -- but not surprised -- that RFC 6520 appears to = have no indication of the status of the extension, e.g., MUST, SHOULD, = etc., in relation to the TLS/DTLS spec) Again: What about just requesting SCTP to do the PMTU here? >=20 >>>>=20 >>>> I'm not sure what the issue with probe packets is, but why is this = a MUST, rather than just the statement "Probe packets are supported = using existing DTLS extensions [RFC6520]"? Again, do you care if there = are other DTLS methods for doing this? > > >> We do care that RFC 4821 is used with probe packet not being user = messages. >> So RFC 6520 provides one way. Other might be possible in the future. >=20 > Then update the doc in the future; if this is standards-track (and it = appears to be intended for that), you should state the MUST of 6520 and = leave any future extensions for future authors of an update IMO. >=20 >> So what about >> For probe packets, the extension defined in = can be used. >=20 > MUST, IMO. Hmm. This means that the current text is OK: For probe packets, the extension defined in [RFC6520] MUST be used. However, it depends on taking out the "DTLS does the PMTUD" option... >=20 >>>>=20 >>>> The Path MTU paragraph is already addressed in RFC6951 - why add it = here? > > >> Because RFC 6951 doesn't apply here. >=20 > Again, I think it really does. You're just adding another layer = (DTLS), but ultimately there are two layers you need to be concerned = about - DTLS and UDP. And as explained above: SCTP, when used over DTLS, does not deal with = UDP port numbers at all, however, SCTP, when used over UDP, does... >=20 >>>>=20 >>>> The doc should explain why you care about disabling DTLS = compression. >> Hmmm. It is stated: >> SCTP performs segmentation and reassembly based on the path MTU. >> If DTLS performs compression, which limit should SCTP use knowing = that >> it fits into the packet. >=20 > The uncompressed size. >=20 > Note that neither PMTUD nor PLMTUD RFCs mention compression, and ROHC = doesn't mention MTUD. VJ's compression mentions the interaction, but = allows it. What I don't understand: SCTP send a probe packet of size M, it gets = compressed to size m, m is the PMTU, so it makes it to the peer, and PMTUD concludes that the path MTU >=3D = M. Now SCTP fragments a user message to size M, however, this time he = compressed packet has size m' with m' > m. The packet is larger than the PMTU and this is really bad... So how can this work with compression being enabled? >=20 >> And if SCTP performs the path MTU discovery (as in the case of = RTCWeb), >> than it can't detect the the message size of the outgoing packet. >=20 > Sure it can; it measures from the size of the packets sent = (compressed), though. But this size is only known by the DTLS layer and is useless to SCTP, = since it must fragment the messages such that the compressed message would = fit. How could SCTP know? >=20 >>>>=20 >>>> The last sentence seems like it should be MUST NOT. >> No. How can you send probe packets if you can't send packets larger = than >> the current PMTU. >=20 > How can you do PMTU discovery if IP fragments the packets (which you = mention in the next sentence)? You need to more carefully discuss how = probe packets are generated and avoid outgoing fragmentation (as well as = on-path fragmentation). And it would apply only to probes. Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit. The only crucial point is that the DTLS layer allows the SCTP to do = this. This requires: * the DTLS layer to pass this information through * the lower layer of DTLS to provide a way to control the DF bit. >=20 > That's an interaction a layer below DTLS, but you need to address it = here too. Yes. The current document (not yet submitted) contains (based on a = discussion at the IETF meeting): If path MTU discovery is performed by the SCTP layer and IPv4 is used as the network layer protocol, the DTLS implementation MUST allow the DTLS user to enforce that the corresponding IPv4 packet is sent with the Don't Fragment (DF) bit set. If controlling the DF bit is not possible, for example due to implementation restrictions, a save value for the path MTU has to be used by the SCTP stack. >=20 >>>>=20 >>>> I.e., overall, it seems like you get what you need with a simpler = first sentence, and the last two only. >> I don't think so. This document is independent from the UDP encaps = one... >=20 > I don't see how you can discuss things like MTU discovery and be = independent of any transport discussion at all. >=20 >>>>=20 >>>> 5 - same stacked header problem >> Right. Fixed. I added: >> This section describes the usage of the base protocol and the = applicability >> of various SCTP extensions. Since SCTP is agnostic about the = protocols being >> used below DTLS, explicit IP addresses MUST NOT be using in the SCTP = control >> chunks. As a consequence, the SCTP associations are single homed. >=20 > Introductory headers shouldn't include requirements. IMO, leave that = address requirement for a subsection; the header paragraph should setup = the subsections only. OK. So just: This section describes the usage of the base protocol and the applicability of various SCTP extensions.=20 >=20 > Further, this sounds like something that ought to be mentioned in the = asbtract and intro - it might severely limit the utility of the = approach. OK. Added: Using encapsulation method described in this document, SCTP is agnostic about the protocols being used below DTLS, explicit IP addresses can not be used in the SCTP control chunks. As a consequence, the SCTP = associations are single homed. to the abstract and the overview contains already: Please note that the procedures defined in =20= for dealing with the UDP port numbers do not apply here. When using the encapsulation defined in this document, SCTP is agnostic about the protocols used below DTLS. >=20 >>>=20 >>>>=20 >>>> 5.1 - odd wording on first sentence. seems like you want to say = "This doc defines SCTP [RFC4960] in DTLS 1.2." >> I just want to make clear which specification is used for SCTP. So = what about: >> specifies SCTP. >> Is that better? >=20 > Not really; maybe you wan to say: >=20 > This document uses SCTP [RFC4960] with the following restrictions, = which are required to reflect... OK. So it read now: This document uses SCTP with the following restrictions, which are required to reflect that the lower layer is DTLS instead of IPv4 and IPv6 and that SCTP doesn't deal with the IP addresses or the transport protocol used below DTLS: >=20 >>>> The issue here is, IMO, more that DTLS is connectionless *vs UDP* = (the comparison is more direct). >> Correct. I changed the wording to: >>=20 >> However, the following restrictions are necessary to reflect that the = lower layer >> is DTLS instead of IPv4 and IPv6 >=20 > or UDP over IP as per RFC6951 No. RFC 6951 supports multihoming, RFC 6951 does support UDP port number = mapping changes... >=20 >> and that SCTP doesn't deal with the IP >> addresses or the transport protocol used below DTLS: >=20 > IMO, it's more that it *can't* deal with addresses that far down. It depends... At least it is not the way intended by this ID... >=20 >> Does that address you issue? >>>>=20 >>>> I would not suggest using abbreviated terminology; you refer to = associations only in one place. Why make it hard to understand that you = mean "SCTP associations"? >> Agreed. Using SCTP association here. >=20 > AOK. >=20 >>>>=20 >>>> The last bullet in this list is redundant; it's already covered in = SCTP over UDP. IMO you're really applying SCTP over UDP to this, so you = should refer to RFC6951 as normative and describe this as a superset of = that. >> Again. I don't see RFC 6951 applying here. >=20 > See above; I think it is really relevant, and odd to present this = approach as completely distinct from that RFC. I think it is important to understand the relation... Taking my = explanation above into account, do you still think this is the same? >=20 >>>>=20 >>>> 5.2 - redundant with RFC6951 AFAICT >> See above. >>>>=20 >>>> 5.3 - why not put all the "no explicit addresses in band" = somewhere, and include both this and other uses of addresses as = examples? >> Makes sense. I added corresponding text to the section introduction = as given above. >=20 > Sure. >=20 > Joe >=20 >>>>=20 >>>> ----- >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 From nobody Tue Apr 8 13:25:00 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA71A0415 for ; Tue, 8 Apr 2014 13:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 MnOa7EoZVsNU for ; Tue, 8 Apr 2014 13:24:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D9D7B1A0218 for ; Tue, 8 Apr 2014 13:24:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s38KOEpj016749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2014 13:24:14 -0700 (PDT) Message-ID: <53445AEE.9070303@isi.edu> Date: Tue, 08 Apr 2014 13:24:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> In-Reply-To: <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/-Pg_rhq7sogF2--7ph20q9k28dw Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:24:57 -0000 Following up on only the points needed... On 4/8/2014 12:56 PM, Michael Tuexen wrote: ... >>>>> 1.1 - This section should more clearly explain the need for DTLS encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with security. That's implied right now, and should be explicit. >>>>> >>>>> Why doesn't the entirety of this document not boil down to "run SCTP over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't that description then mean you can then omit section 3? >>> >>> One of the important points of RFC 6951 is how to deal with the UDP port numbers. >> >> The abstract of RFC 6951 seems to indicate otherwise: >> >> ...In particular, it does not provide mechanisms >> to determine whether UDP encapsulation is being used by the peer, nor >> the mechanisms for determining which remote UDP port number can be >> used. These functions are out of scope for this document. >> >> There's an API for configuring the port number being used, but it doesn't seem to matter what port number is actually used (though 9899 is the default, as per Section 7). > I was not clear enough and maybe the cited text is also not very clear. > Let me be more precisely: > > RFC 6951 does not provide a mechanism to figure out if the initiator should use > UDP encapsulation or not. And RFC 6951 does not provide a mechanism to figure > out which UDP port number to use for the initial packet. > > However, RFC 6951 does tell you that an SCTP stack has one local UDP encapsulation > port number and needs to store per path for each association a remote UDP encapsulation > port number. See > http://tools.ietf.org/html/rfc6951#section-5.1 > RFC 6951 also tells you how to update the remote encapsulation port > number when a packet is received. See > http://tools.ietf.org/html/rfc6951#section-5.4 > > Therefore the SCTP stack has to manage the UDP port numbers being used. This > is an important part of the UDP encapsulation. Since this is not used when > using DTLS, there is a major difference between the documents. There's a difference, but it's not what I'd consider "major" (it could easily be stated as "do that RFC, except for Sections X and Y"). >>> These need to be handled in a specific way as described in RFC 6951. This does >>> not apply here. This document describes how to run SCTP over a connections >>> oriented protocol without providing SCTP with any information about IP addresses >>> and UDP port numbers. >> >> I can't see why Section 6.1 wouldn't apply equally well here, though. Even when you run over DTLS you still need to pick a transport port number, no? > Yes, but this is not managed by the SCTP stack. This is managed by the DTLS layer. > And I don't think DTLS can deal with UDP port number changes during the communication > as SCTP can. SCTP/UDP as described in RFC 6951 can survive that a NAT box changes > the port number mapping, SCTP/DTLS can't... Fair enough, but that's just one section, and easily explained as to why it doesn't apply. ... >>>>> The MTU discovery is already in DTLS 1.2 - no need to state, and no need to require that particular solution (e.g., it seems OK if DTLS updates it). >>> >>> I don't think DTLS 1.2 requires you to uses probe packets defined in RFC 6520. >> >> That's correct; it doesn't -- it leaves PMTU discovery to the application (Sec 4.1.1.1). > > Which is SCTP, in this case... One of the options allowed. SCTP does RFC1191 only (PMTUD). > So are you suggesting just to require > that SCTP the PMTU discovery and take out the option that DTLS does it? I'm fine with that change, > especially because this is exactly what RTCWeb does. I'm wondering why you want to make a specific recommendation as to how to handle MTU discovery, e.g., to require DTLS-level PLMTUD. If you have a reason, IMO include it and justify it. >>> What we want to avoid, is that user data is used as probe packets. >> >> If that's true, you need to motivate it rather than just declaring so. > OK. What about adding: > User messages SHOULD NOT be used as probe packets, because during probing > this results in potential packet loss which increases due to the necessary > retransmissions the delay of the user message transfer. I don't see why this protocol needs to say that, esp. when RFC4821 doesn't. SCTP isn't a low-latency transport protocol anyway. >> I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to the application - which arguably is SCTP here. If the extensions in RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they don't). And why aren't they MUST or SHOULD? >> >> (I'm disappointed -- but not surprised -- that RFC 6520 appears to have no indication of the status of the extension, e.g., MUST, SHOULD, etc., in relation to the TLS/DTLS spec) > Again: What about just requesting SCTP to do the PMTU here? Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to explain why. Otherwise you're constraining your solution to TDTLS implementations that support PLMTUD - and it's not a current requirement (besides, how could you even know at the SCTP layer?) >>>>> I'm not sure what the issue with probe packets is, but why is this a MUST, rather than just the statement "Probe packets are supported using existing DTLS extensions [RFC6520]"? Again, do you care if there are other DTLS methods for doing this? >>> >>> We do care that RFC 4821 is used with probe packet not being user messages. >>> So RFC 6520 provides one way. Other might be possible in the future. >> >> Then update the doc in the future; if this is standards-track (and it appears to be intended for that), you should state the MUST of 6520 and leave any future extensions for future authors of an update IMO. >> >>> So what about >>> For probe packets, the extension defined in can be used. >> >> MUST, IMO. > Hmm. This means that the current text is OK: > For probe packets, the extension defined in [RFC6520] MUST be used. > > However, it depends on taking out the "DTLS does the PMTUD" option... That's the issue. If you really depend on DTLS support for probe packets, then MUST is fine; otherwise, it's unnecessary. >>>>> The Path MTU paragraph is already addressed in RFC6951 - why add it here? >>> >>> Because RFC 6951 doesn't apply here. >> >> Again, I think it really does. You're just adding another layer (DTLS), but ultimately there are two layers you need to be concerned about - DTLS and UDP. > And as explained above: SCTP, when used over DTLS, does not deal with UDP port numbers at all, > however, SCTP, when used over UDP, does... But again, port numbers are just one part of that other document. You could import the rest of that document by reference and exclude the port number issues. >>>>> The doc should explain why you care about disabling DTLS compression. >>> Hmmm. It is stated: >>> SCTP performs segmentation and reassembly based on the path MTU. >>> If DTLS performs compression, which limit should SCTP use knowing that >>> it fits into the packet. >> >> The uncompressed size. >> >> Note that neither PMTUD nor PLMTUD RFCs mention compression, and ROHC doesn't mention MTUD. VJ's compression mentions the interaction, but allows it. > What I don't understand: SCTP send a probe packet of size M, it gets compressed to size m, m is the PMTU, SCTP never sends probes. Either the app does, or DTLS does. > so it makes it to the peer, and PMTUD concludes that the path MTU >= M. The path MTU would be m - compression doesn't affect the fact that the path supported a message (compressed or not) of actual size m. > Now SCTP fragments a user message to size M, however, this time he compressed packet has size m' with > m' > m. The packet is larger than the PMTU and this is really bad... The packet size would be m' (the uncompressed size I was referring to above), and that's what you compare to the actual path MTU. > So how can this work with compression being enabled? See above. You measure what you see through the path, and compare it to the uncompressed size of the packet. Compression helps performance, but should not be considered as a way to increase effective path MTU. >>> And if SCTP performs the path MTU discovery (as in the case of RTCWeb), >>> than it can't detect the the message size of the outgoing packet. >> >> Sure it can; it measures from the size of the packets sent (compressed), though. > But this size is only known by the DTLS layer and is useless to SCTP, since > it must fragment the messages such that the compressed message would fit. > How could SCTP know? If that's the case, then you have problems with DTLS-layer discovery too. >>>>> The last sentence seems like it should be MUST NOT. >>> No. How can you send probe packets if you can't send packets larger than >>> the current PMTU. >> >> How can you do PMTU discovery if IP fragments the packets (which you mention in the next sentence)? You need to more carefully discuss how probe packets are generated and avoid outgoing fragmentation (as well as on-path fragmentation). And it would apply only to probes. > Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit. When SCTP runs over IP directly. It won't work when SCTP runs over UDP or SCTP over X. > The only crucial point is that the DTLS layer allows the SCTP to do this. This requires: > * the DTLS layer to pass this information through > * the lower layer of DTLS to provide a way to control the DF bit. But that doesn't appear to be a feature of DTLS AFAICT. >> That's an interaction a layer below DTLS, but you need to address it here too. > Yes. The current document (not yet submitted) contains (based on a discussion at the > IETF meeting): > > > If path MTU discovery is performed by the SCTP layer and IPv4 is used > as the network layer protocol, the DTLS implementation MUST allow the > DTLS user to enforce that the corresponding IPv4 packet is sent with > the Don't Fragment (DF) bit set. This adds a requirement to DTLS that doesn't appear to currently exist; that means this extension isn't necessarily compatible with currently compliant DTLS implementations. > ...If controlling the DF bit is not > possible, for example due to implementation restrictions, a save safe? > value for the path MTU has to be used by the SCTP stack. Presuming you mean 'safe', there's no such value AFAICT. ... >>>>> The last bullet in this list is redundant; it's already covered in SCTP over UDP. IMO you're really applying SCTP over UDP to this, so you should refer to RFC6951 as normative and describe this as a superset of that. >>> Again. I don't see RFC 6951 applying here. >> >> See above; I think it is really relevant, and odd to present this approach as completely distinct from that RFC. > I think it is important to understand the relation... Taking my explanation above into account, > do you still think this is the same? Yes. You've explained a few places that are useful to separate, but the rest is relevant. Joe From nobody Tue Apr 8 13:36:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38521A0412 for ; Tue, 8 Apr 2014 13:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.432 X-Spam-Level: X-Spam-Status: No, score=-13.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Kgrgc9qHYt98 for ; Tue, 8 Apr 2014 13:36:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1CB1A034E for ; Tue, 8 Apr 2014 13:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15; q=dns/txt; s=iport; t=1396989376; x=1398198976; h=message-id:date:to:from:subject:mime-version; bh=mfCOdbeCX77mBFY/SsE+J1XetqxL5CfcbaLfUlfpX2c=; b=hC/ooAm1uPBtjl5KYOz7gS0Kd5cKDyMRpTxFGAGsthn7tafBT0KJwe5D BfOdhgGh1Nw0xnDwParHbFF6ODT8AL7FubZGjLtXjI2QZLi9wDg226G+Z VDIFc9I4HR1tFHFqaHiBt3g2vcnGWqxShUIUf6dtX3j1REZaAtXTyXbMN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAddRFOtJV2a/2dsb2JhbABZKYJdxm8WcASCRR8CViUVHwo4BIgXmVuxCBePCYQiBIlboUKDTh8 X-IronPort-AV: E=Sophos;i="4.97,820,1389744000"; d="scan'208";a="316201266" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 08 Apr 2014 20:36:16 +0000 Received: from jmpolk-WS.cisco.com ([10.89.11.38]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s38KaFZI010281 for ; Tue, 8 Apr 2014 20:36:15 GMT Message-Id: <201404082036.s38KaFZI010281@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Apr 2014 14:37:26 -0500 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/vtjIu6sBSJ39iaeCDqXN4QU1RME Subject: [tsvwg] test X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:36:20 -0000 please ignore From nobody Tue Apr 8 14:54:23 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E891A04BA for ; Tue, 8 Apr 2014 14:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_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 vSwrEAHHSzaf for ; Tue, 8 Apr 2014 14:54:19 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF81A02A8 for ; Tue, 8 Apr 2014 14:54:18 -0700 (PDT) Received: from [192.168.1.200] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6965D1C0B402C; Tue, 8 Apr 2014 23:54:17 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53445AEE.9070303@isi.edu> Date: Tue, 8 Apr 2014 23:54:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jgrPpgaO8ROO8mdi1ZIRNO-ZrCQ Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:54:21 -0000 On 08 Apr 2014, at 22:24, Joe Touch wrote: > Following up on only the points needed... Thanks... See inline... >=20 > On 4/8/2014 12:56 PM, Michael Tuexen wrote: > ... >>>>>> 1.1 - This section should more clearly explain the need for DTLS = encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with = security. That's implied right now, and should be explicit. >>>>>>=20 >>>>>> Why doesn't the entirety of this document not boil down to "run = SCTP over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't = that description then mean you can then omit section 3? >>>>=20 >>>> One of the important points of RFC 6951 is how to deal with the UDP = port numbers. >>>=20 >>> The abstract of RFC 6951 seems to indicate otherwise: >>>=20 >>> ...In particular, it does not provide mechanisms >>> to determine whether UDP encapsulation is being used by the peer, = nor >>> the mechanisms for determining which remote UDP port number can be >>> used. These functions are out of scope for this document. >>>=20 >>> There's an API for configuring the port number being used, but it = doesn't seem to matter what port number is actually used (though 9899 is = the default, as per Section 7). >> I was not clear enough and maybe the cited text is also not very = clear. >> Let me be more precisely: >>=20 >> RFC 6951 does not provide a mechanism to figure out if the initiator = should use >> UDP encapsulation or not. And RFC 6951 does not provide a mechanism = to figure >> out which UDP port number to use for the initial packet. >>=20 >> However, RFC 6951 does tell you that an SCTP stack has one local UDP = encapsulation >> port number and needs to store per path for each association a remote = UDP encapsulation >> port number. See >> http://tools.ietf.org/html/rfc6951#section-5.1 >> RFC 6951 also tells you how to update the remote encapsulation port >> number when a packet is received. See >> http://tools.ietf.org/html/rfc6951#section-5.4 >>=20 >> Therefore the SCTP stack has to manage the UDP port numbers being = used. This >> is an important part of the UDP encapsulation. Since this is not used = when >> using DTLS, there is a major difference between the documents. >=20 > There's a difference, but it's not what I'd consider "major" (it could = easily be stated as "do that RFC, except for Sections X and Y"). Well, when implementing it, it is the major part. Adding/Removing the = the UDP header is the minor part. Without the UDP port number handling, I think there wouldn't be a real = need for an RFC, since the header manipulation is pretty obvious to do. >=20 >>>> These need to be handled in a specific way as described in RFC = 6951. This does >>>> not apply here. This document describes how to run SCTP over a = connections >>>> oriented protocol without providing SCTP with any information about = IP addresses >>>> and UDP port numbers. >>>=20 >>> I can't see why Section 6.1 wouldn't apply equally well here, = though. Even when you run over DTLS you still need to pick a transport = port number, no? >> Yes, but this is not managed by the SCTP stack. This is managed by = the DTLS layer. >> And I don't think DTLS can deal with UDP port number changes during = the communication >> as SCTP can. SCTP/UDP as described in RFC 6951 can survive that a NAT = box changes >> the port number mapping, SCTP/DTLS can't... >=20 > Fair enough, but that's just one section, and easily explained as to = why it doesn't apply. >=20 > ... >>>>>> The MTU discovery is already in DTLS 1.2 - no need to state, and = no need to require that particular solution (e.g., it seems OK if DTLS = updates it). >>>>=20 >>>> I don't think DTLS 1.2 requires you to uses probe packets defined = in RFC 6520. >>>=20 >>> That's correct; it doesn't -- it leaves PMTU discovery to the = application (Sec 4.1.1.1). > > >> Which is SCTP, in this case... One of the options allowed. >=20 > SCTP does RFC1191 only (PMTUD). That is why the text explicitly requires RFC4821 for PMTU in SCTP. >=20 >> So are you suggesting just to require >> that SCTP the PMTU discovery and take out the option that DTLS does = it? I'm fine with that change, >> especially because this is exactly what RTCWeb does. >=20 > I'm wondering why you want to make a specific recommendation as to how = to handle MTU discovery, e.g., to require DTLS-level PLMTUD. If you have = a reason, IMO include it and justify it. The text leaves it open, which layer does it. The RTCWeb spec make it = clear when used in the RTCWeb context. In general, I'm open and this is what the text currently says. However, we need a way of doing it * without relying on ICMP, since we can't verify the contents * without affecting the user data transmission with probe packet loss That is why we want an RFC4821 based algorithm. Either in DTLS or SCTP. >=20 >>>> What we want to avoid, is that user data is used as probe packets. >>>=20 >>> If that's true, you need to motivate it rather than just declaring = so. >> OK. What about adding: >> User messages SHOULD NOT be used as probe packets, because during = probing >> this results in potential packet loss which increases due to the = necessary >> retransmissions the delay of the user message transfer. >=20 > I don't see why this protocol needs to say that, esp. when RFC4821 = doesn't. SCTP isn't a low-latency transport protocol anyway. But we don't want to add timeouts just because we do PMTU discovery when = it is not needed... >=20 >>> I don't understand why it would be true, FWIW. DTLS leaves PMTUD up = to the application - which arguably is SCTP here. If the extensions in = RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they = don't). And why aren't they MUST or SHOULD? >>>=20 >>> (I'm disappointed -- but not surprised -- that RFC 6520 appears to = have no indication of the status of the extension, e.g., MUST, SHOULD, = etc., in relation to the TLS/DTLS spec) >> Again: What about just requesting SCTP to do the PMTU here? >=20 > Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to = explain why. Otherwise you're constraining your solution to TDTLS = implementations that support PLMTUD - and it's not a current requirement = (besides, how could you even know at the SCTP layer?) What are you suggesting: (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer (b) Require PLMTUD either at the SCTP layer or at the DTLS layer and let the decision be specified in the corresponding document describing the particular use case. I'm for simplicity and would vote for (a). >=20 >>>>>> I'm not sure what the issue with probe packets is, but why is = this a MUST, rather than just the statement "Probe packets are supported = using existing DTLS extensions [RFC6520]"? Again, do you care if there = are other DTLS methods for doing this? >>>>=20 >>>> We do care that RFC 4821 is used with probe packet not being user = messages. >>>> So RFC 6520 provides one way. Other might be possible in the = future. >>>=20 >>> Then update the doc in the future; if this is standards-track (and = it appears to be intended for that), you should state the MUST of 6520 = and leave any future extensions for future authors of an update IMO. >>>=20 >>>> So what about >>>> For probe packets, the extension defined in can be used. >>>=20 >>> MUST, IMO. >> Hmm. This means that the current text is OK: >> For probe packets, the extension defined in [RFC6520] MUST be used. >>=20 >> However, it depends on taking out the "DTLS does the PMTUD" option... >=20 > That's the issue. If you really depend on DTLS support for probe = packets, then MUST is fine; otherwise, it's unnecessary. We can just specify that PLMTUD is done at the SCTP layer. That would = simplify things. >=20 >>>>>> The Path MTU paragraph is already addressed in RFC6951 - why add = it here? >>>>=20 >>>> Because RFC 6951 doesn't apply here. >>>=20 >>> Again, I think it really does. You're just adding another layer = (DTLS), but ultimately there are two layers you need to be concerned = about - DTLS and UDP. >> And as explained above: SCTP, when used over DTLS, does not deal with = UDP port numbers at all, >> however, SCTP, when used over UDP, does... >=20 > But again, port numbers are just one part of that other document. You = could import the rest of that document by reference and exclude the port = number issues. For me (having both implemented) gives the impression of a similarity, = which isn't there... ICMP feedback, for example: In SCTP/UDP it might be able to process = incoming ICMP packets, since I might be able to verify the SCTP port numbers and the = verification tag. With SCTP/DTLS I can't, since the information is encrypted... >=20 >>>>>> The doc should explain why you care about disabling DTLS = compression. >>>> Hmmm. It is stated: >>>> SCTP performs segmentation and reassembly based on the path MTU. >>>> If DTLS performs compression, which limit should SCTP use knowing = that >>>> it fits into the packet. >>>=20 >>> The uncompressed size. >>>=20 >>> Note that neither PMTUD nor PLMTUD RFCs mention compression, and = ROHC doesn't mention MTUD. VJ's compression mentions the interaction, = but allows it. >> What I don't understand: SCTP send a probe packet of size M, it gets = compressed to size m, m is the PMTU, >=20 > SCTP never sends probes. Either the app does, or DTLS does. When SCTP does PLMTUD, it sends probe packets. These would be packets = containing HEARTBEAT chunks bundled with PADDING chunks (http://tools.ietf.org/html/rfc4820) >=20 >> so it makes it to the peer, and PMTUD concludes that the path MTU >=3D = M. >=20 > The path MTU would be m - compression doesn't affect the fact that the = path supported a message (compressed or not) of actual size m. >=20 >> Now SCTP fragments a user message to size M, however, this time he = compressed packet has size m' with >> m' > m. The packet is larger than the PMTU and this is really bad... >=20 > The packet size would be m' (the uncompressed size I was referring to = above), and that's what you compare to the actual path MTU. >=20 >> So how can this work with compression being enabled? >=20 > See above. You measure what you see through the path, and compare it = to the uncompressed size of the packet. Compression helps performance, = but should not be considered as a way to increase effective path MTU. But whenever SCTP sends down a packet, it is compressed. So it has no = way of finding the packet size. I think the problem is that two packet of uncompressed = sizes M' and M'' with M' > M'' can result in compressed sizes m' and m'' with m' < m''. That = is why PMTUD does work with compression. =20 >=20 >>>> And if SCTP performs the path MTU discovery (as in the case of = RTCWeb), >>>> than it can't detect the the message size of the outgoing packet. >>>=20 >>> Sure it can; it measures from the size of the packets sent = (compressed), though. >> But this size is only known by the DTLS layer and is useless to SCTP, = since >> it must fragment the messages such that the compressed message would = fit. >> How could SCTP know? >=20 > If that's the case, then you have problems with DTLS-layer discovery = too. No. The DTLS overhead is constant (if you don't use compression). So = DTLS could provide a size for which packets would fit into the PMTU. >=20 >>>>>> The last sentence seems like it should be MUST NOT. >>>> No. How can you send probe packets if you can't send packets larger = than >>>> the current PMTU. >>>=20 >>> How can you do PMTU discovery if IP fragments the packets (which you = mention in the next sentence)? You need to more carefully discuss how = probe packets are generated and avoid outgoing fragmentation (as well as = on-path fragmentation). And it would apply only to probes. >> Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit. >=20 > When SCTP runs over IP directly. It won't work when SCTP runs over UDP = or SCTP over X. It does. At least in the FreeBSD based implementation. SCTP controls the = DF bit... >=20 >> The only crucial point is that the DTLS layer allows the SCTP to do = this. This requires: >> * the DTLS layer to pass this information through >> * the lower layer of DTLS to provide a way to control the DF bit. >=20 > But that doesn't appear to be a feature of DTLS AFAICT. It is nothing the protocol has to provide, it is a feature provided by = the implementation or not... >=20 >>> That's an interaction a layer below DTLS, but you need to address it = here too. >> Yes. The current document (not yet submitted) contains (based on a = discussion at the >> IETF meeting): >>=20 >>=20 >> If path MTU discovery is performed by the SCTP layer and IPv4 is = used >> as the network layer protocol, the DTLS implementation MUST allow = the >> DTLS user to enforce that the corresponding IPv4 packet is sent = with >> the Don't Fragment (DF) bit set. >=20 > This adds a requirement to DTLS that doesn't appear to currently = exist; that means this extension isn't necessarily compatible with = currently compliant DTLS implementations. Right. However, the limiting factor is not the DTLS stack, but the UDP = interface... >=20 >> ...If controlling the DF bit is not >> possible, for example due to implementation restrictions, a save >=20 > safe? >=20 >> value for the path MTU has to be used by the SCTP stack. >=20 > Presuming you mean 'safe', there's no such value AFAICT. Formally correct. Well, RTCWeb has decided on such values: 1280 bytes = for IPv6 and 1200 bytes for IPv4 (both at the IP layer).=20 >=20 > ... >>>>>> The last bullet in this list is redundant; it's already covered = in SCTP over UDP. IMO you're really applying SCTP over UDP to this, so = you should refer to RFC6951 as normative and describe this as a superset = of that. >>>> Again. I don't see RFC 6951 applying here. >>>=20 >>> See above; I think it is really relevant, and odd to present this = approach as completely distinct from that RFC. >> I think it is important to understand the relation... Taking my = explanation above into account, >> do you still think this is the same? >=20 > Yes. You've explained a few places that are useful to separate, but = the rest is relevant. >=20 > Joe >=20 From nobody Wed Apr 9 09:56:34 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C501A03F2 for ; Wed, 9 Apr 2014 09:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 wHdX_1kuY8Zk for ; Wed, 9 Apr 2014 09:56:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 36D161A032E for ; Wed, 9 Apr 2014 09:56:31 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s39Gu1iF001596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Apr 2014 09:56:02 -0700 (PDT) Message-ID: <53457BA3.5030707@isi.edu> Date: Wed, 09 Apr 2014 09:56:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> In-Reply-To: <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/QdG9G_OQn9Oo76eDhCWOskRVbcE Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:56:33 -0000 On 4/8/2014 2:54 PM, Michael Tuexen wrote: ... >>>>>>> The MTU discovery is already in DTLS 1.2 - no need to state, and no need to require that particular solution (e.g., it seems OK if DTLS updates it). >>>>> >>>>> I don't think DTLS 1.2 requires you to uses probe packets defined in RFC 6520. >>>> >>>> That's correct; it doesn't -- it leaves PMTU discovery to the application (Sec 4.1.1.1). >>> >>> Which is SCTP, in this case... One of the options allowed. >> >> SCTP does RFC1191 only (PMTUD). > > That is why the text explicitly requires RFC4821 for PMTU in SCTP. RFC4821 talks about how SCTP *can* use the PAD chunk to do so, while avoiding retransmission if anything is lost - but I can't find anything that says that SCTP actually does this. >>> So are you suggesting just to require >>> that SCTP the PMTU discovery and take out the option that DTLS does it? I'm fine with that change, >>> especially because this is exactly what RTCWeb does. >> >> I'm wondering why you want to make a specific recommendation as to how to handle MTU discovery, e.g., to require DTLS-level PLMTUD. If you have a reason, IMO include it and justify it. > The text leaves it open, which layer does it. The RTCWeb spec make it clear when used in the RTCWeb context. > In general, I'm open and this is what the text currently says. > However, we need a way of doing it > * without relying on ICMP, since we can't verify the contents > * without affecting the user data transmission with probe packet loss > That is why we want an RFC4821 based algorithm. Either in DTLS or SCTP. There doesn't appear to be such an algorithm required in SCTP; it would be either in DTLS or the user application. If it's in DTLS, I'm not sure how SCTP would get the MTU information, though. >>>>> What we want to avoid, is that user data is used as probe packets. >>>> >>>> If that's true, you need to motivate it rather than just declaring so. >>> OK. What about adding: >>> User messages SHOULD NOT be used as probe packets, because during probing >>> this results in potential packet loss which increases due to the necessary >>> retransmissions the delay of the user message transfer. >> >> I don't see why this protocol needs to say that, esp. when RFC4821 doesn't. SCTP isn't a low-latency transport protocol anyway. > > But we don't want to add timeouts just because we do PMTU discovery when it is not needed... Timeouts are already there - they're just retransmissions in SCTP. My concern is whether/how users can know the PMTU if they aren't the ones sending the probes. >>>> I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to the application - which arguably is SCTP here. If the extensions in RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they don't). And why aren't they MUST or SHOULD? >>>> >>>> (I'm disappointed -- but not surprised -- that RFC 6520 appears to have no indication of the status of the extension, e.g., MUST, SHOULD, etc., in relation to the TLS/DTLS spec) >>> Again: What about just requesting SCTP to do the PMTU here? >> >> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to explain why. Otherwise you're constraining your solution to TDTLS implementations that support PLMTUD - and it's not a current requirement (besides, how could you even know at the SCTP layer?) > What are you suggesting: > (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer > (b) Require PLMTUD either at the SCTP layer or at the DTLS layer and let > the decision be specified in the corresponding document describing > the particular use case. > > I'm for simplicity and would vote for (a). (a) requires a standards-track RFC that indicates how this is done, which I can't find (there may be one; I don't track SCTP at that level of detail). (b) required at SCTP has the same problem (b) for DTLS has the issue of how SCTP finds out the MTU from DTLS. However you intend to handle this needs to be specific, justified, and cite an existing mechanism that's complete or you need to introduce the needed components here. ... >>>>>>> The doc should explain why you care about disabling DTLS compression. >>>>> Hmmm. It is stated: >>>>> SCTP performs segmentation and reassembly based on the path MTU. >>>>> If DTLS performs compression, which limit should SCTP use knowing that >>>>> it fits into the packet. >>>> >>>> The uncompressed size. >>>> >>>> Note that neither PMTUD nor PLMTUD RFCs mention compression, and ROHC doesn't mention MTUD. VJ's compression mentions the interaction, but allows it. >>> What I don't understand: SCTP send a probe packet of size M, it gets compressed to size m, m is the PMTU, >> >> SCTP never sends probes. Either the app does, or DTLS does. > When SCTP does PLMTUD, it sends probe packets. These would be packets containing HEARTBEAT chunks > bundled with PADDING chunks (http://tools.ietf.org/html/rfc4820) RFC4820 says that RFC4821 descibes how to use the pad chunk for PLMTUD, but there's no RFC I can locate that actually describes this as an extension to SCTP. >>> so it makes it to the peer, and PMTUD concludes that the path MTU >= M. >> >> The path MTU would be m - compression doesn't affect the fact that the path supported a message (compressed or not) of actual size m. >> >>> Now SCTP fragments a user message to size M, however, this time he compressed packet has size m' with >>> m' > m. The packet is larger than the PMTU and this is really bad... >> >> The packet size would be m' (the uncompressed size I was referring to above), and that's what you compare to the actual path MTU. >> >>> So how can this work with compression being enabled? >> >> See above. You measure what you see through the path, and compare it to the uncompressed size of the packet. Compression helps performance, but should not be considered as a way to increase effective path MTU. > But whenever SCTP sends down a packet, it is compressed. So it has no way of finding the > packet size. Isn't there a length field telling you the uncompressed size, and a length parameter to the next layer that indicates the compressed size? > I think the problem is that two packet of uncompressed sizes M' and M'' with > M' > M'' can result in compressed sizes m' and m'' with m' < m''. Yes, that's why you would want to use the compressed size as the indicator of the path MTU. > That is why > PMTUD does work with compression. Are you sure you meant that? That's what I was saying, but you seem to be saying the opposite. >>>>> And if SCTP performs the path MTU discovery (as in the case of RTCWeb), >>>>> than it can't detect the the message size of the outgoing packet. >>>> >>>> Sure it can; it measures from the size of the packets sent (compressed), though. >>> But this size is only known by the DTLS layer and is useless to SCTP, since >>> it must fragment the messages such that the compressed message would fit. >>> How could SCTP know? >> >> If that's the case, then you have problems with DTLS-layer discovery too. > No. The DTLS overhead is constant (if you don't use compression). So DTLS could > provide a size for which packets would fit into the PMTU. But DTLS packets can be fragmented at the IP layer; that's already a warning in the DTLS doc. >>>>>>> The last sentence seems like it should be MUST NOT. >>>>> No. How can you send probe packets if you can't send packets larger than >>>>> the current PMTU. >>>> >>>> How can you do PMTU discovery if IP fragments the packets (which you mention in the next sentence)? You need to more carefully discuss how probe packets are generated and avoid outgoing fragmentation (as well as on-path fragmentation). And it would apply only to probes. >>> Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit. >> >> When SCTP runs over IP directly. It won't work when SCTP runs over UDP or SCTP over X. > It does. At least in the FreeBSD based implementation. SCTP controls the DF bit... But do you have any indication this will work with another layer of indirection? I.e., SCTP->DTLS->transport->IP >>> The only crucial point is that the DTLS layer allows the SCTP to do this. This requires: >>> * the DTLS layer to pass this information through >>> * the lower layer of DTLS to provide a way to control the DF bit. >> >> But that doesn't appear to be a feature of DTLS AFAICT. > It is nothing the protocol has to provide, it is a feature provided by the > implementation or not... This may be a red-herring for this discussion, but the API provided to the next layer is absolutely part of the spec of a protocol. The IETF's position on this was incorrect (and hopefully has changed). Implementation issues are things like the argument order and specific data types (e.g., whether to use u8 or u16 for a range of 0..255).. >>>> That's an interaction a layer below DTLS, but you need to address it here too. >>> Yes. The current document (not yet submitted) contains (based on a discussion at the >>> IETF meeting): >>> >>> >>> If path MTU discovery is performed by the SCTP layer and IPv4 is used >>> as the network layer protocol, the DTLS implementation MUST allow the >>> DTLS user to enforce that the corresponding IPv4 packet is sent with >>> the Don't Fragment (DF) bit set. >> >> This adds a requirement to DTLS that doesn't appear to currently exist; that means this extension isn't necessarily compatible with currently compliant DTLS implementations. > > Right. However, the limiting factor is not the DTLS stack, but the UDP interface... Wouldn't it also be the DTLS interface (to SCTP) too? >>> ...If controlling the DF bit is not >>> possible, for example due to implementation restrictions, a save >> >> safe? >> >>> value for the path MTU has to be used by the SCTP stack. >> >> Presuming you mean 'safe', there's no such value AFAICT. > > Formally correct. Well, RTCWeb has decided on such values: 1280 bytes for IPv6 > and 1200 bytes for IPv4 (both at the IP layer). You should refer to those then, IMO. Joe From nobody Wed Apr 9 12:13:23 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBF21A02F4 for ; Wed, 9 Apr 2014 12:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_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 qAaLOSTOuK4B for ; Wed, 9 Apr 2014 12:13:17 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 83E021A0443 for ; Wed, 9 Apr 2014 12:13:16 -0700 (PDT) Received: from [192.168.1.103] (p508F23E9.dip0.t-ipconnect.de [80.143.35.233]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DE9401C104641; Wed, 9 Apr 2014 21:13:14 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53457BA3.5030707@isi.edu> Date: Wed, 9 Apr 2014 21:13:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ucGUFSYH9DseB2vkK3LhQ7dityA Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:13:20 -0000 On 09 Apr 2014, at 18:56, Joe Touch wrote: >=20 >=20 > On 4/8/2014 2:54 PM, Michael Tuexen wrote: > ... >>>>>>>> The MTU discovery is already in DTLS 1.2 - no need to state, = and no need to require that particular solution (e.g., it seems OK if = DTLS updates it). >>>>>>=20 >>>>>> I don't think DTLS 1.2 requires you to uses probe packets defined = in RFC 6520. >>>>>=20 >>>>> That's correct; it doesn't -- it leaves PMTU discovery to the = application (Sec 4.1.1.1). >>>>=20 >>>> Which is SCTP, in this case... One of the options allowed. >>>=20 >>> SCTP does RFC1191 only (PMTUD). > > >> That is why the text explicitly requires RFC4821 for PMTU in SCTP. >=20 > RFC4821 talks about how SCTP *can* use the PAD chunk to do so, while = avoiding retransmission if anything is lost - but I can't find anything = that says that SCTP actually does this. I read http://tools.ietf.org/html/rfc4821#section-10.2 in way that is describes a method for doing PLMTUD with probe packets. = It used the term RECOMMENDED, so it is more strict than *can*. Or am I missing something? >=20 >>>> So are you suggesting just to require >>>> that SCTP the PMTU discovery and take out the option that DTLS does = it? I'm fine with that change, >>>> especially because this is exactly what RTCWeb does. >>>=20 >>> I'm wondering why you want to make a specific recommendation as to = how to handle MTU discovery, e.g., to require DTLS-level PLMTUD. If you = have a reason, IMO include it and justify it. >> The text leaves it open, which layer does it. The RTCWeb spec make it = clear when used in the RTCWeb context. >> In general, I'm open and this is what the text currently says. >> However, we need a way of doing it >> * without relying on ICMP, since we can't verify the contents >> * without affecting the user data transmission with probe packet loss >> That is why we want an RFC4821 based algorithm. Either in DTLS or = SCTP. >=20 > There doesn't appear to be such an algorithm required in SCTP; it = would be either in DTLS or the user application. In my view RFC 4821 describes such an algorithm. That is why I'm = requiring support of this method. >=20 > If it's in DTLS, I'm not sure how SCTP would get the MTU information, = though. >=20 >>>>>> What we want to avoid, is that user data is used as probe = packets. >>>>>=20 >>>>> If that's true, you need to motivate it rather than just declaring = so. >>>> OK. What about adding: >>>> User messages SHOULD NOT be used as probe packets, because during = probing >>>> this results in potential packet loss which increases due to the = necessary >>>> retransmissions the delay of the user message transfer. >>>=20 >>> I don't see why this protocol needs to say that, esp. when RFC4821 = doesn't. SCTP isn't a low-latency transport protocol anyway. > > >> But we don't want to add timeouts just because we do PMTU discovery = when it is not needed... >=20 > Timeouts are already there - they're just retransmissions in SCTP. Yes. >=20 > My concern is whether/how users can know the PMTU if they aren't the = ones sending the probes. Because the probes are sent by SCTP as described in RFC 4821. RFC 4820 = defined the probes: http://tools.ietf.org/html/rfc4820 >=20 >>>>> I don't understand why it would be true, FWIW. DTLS leaves PMTUD = up to the application - which arguably is SCTP here. If the extensions = in RFC 6520 are that important, why don't they UPDATE the DTLS spec? = (they don't). And why aren't they MUST or SHOULD? >>>>>=20 >>>>> (I'm disappointed -- but not surprised -- that RFC 6520 appears to = have no indication of the status of the extension, e.g., MUST, SHOULD, = etc., in relation to the TLS/DTLS spec) >>>> Again: What about just requesting SCTP to do the PMTU here? >>>=20 >>> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to = explain why. Otherwise you're constraining your solution to TDTLS = implementations that support PLMTUD - and it's not a current requirement = (besides, how could you even know at the SCTP layer?) >> What are you suggesting: >> (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer >> (b) Require PLMTUD either at the SCTP layer or at the DTLS layer and = let >> the decision be specified in the corresponding document = describing >> the particular use case. >>=20 >> I'm for simplicity and would vote for (a). >=20 > (a) requires a standards-track RFC that indicates how this is done, = which I can't find (there may be one; I don't track SCTP at that level = of detail). What am I missing: I think RFC4821 describes such an algorithm and it is = standards track. We have only to require that the SCTP implementation support the = mechanism described in RFC4821. >=20 > (b) required at SCTP has the same problem >=20 > (b) for DTLS has the issue of how SCTP finds out the MTU from DTLS. There can be an API for requesting the MTU minus the DTLS relevant = overhead... >=20 > However you intend to handle this needs to be specific, justified, and = cite an existing mechanism that's complete or you need to introduce the = needed components here. Why is 4821 not enough? >=20 > ... >>>>>>>> The doc should explain why you care about disabling DTLS = compression. >>>>>> Hmmm. It is stated: >>>>>> SCTP performs segmentation and reassembly based on the path MTU. >>>>>> If DTLS performs compression, which limit should SCTP use knowing = that >>>>>> it fits into the packet. >>>>>=20 >>>>> The uncompressed size. >>>>>=20 >>>>> Note that neither PMTUD nor PLMTUD RFCs mention compression, and = ROHC doesn't mention MTUD. VJ's compression mentions the interaction, = but allows it. >>>> What I don't understand: SCTP send a probe packet of size M, it = gets compressed to size m, m is the PMTU, >>>=20 >>> SCTP never sends probes. Either the app does, or DTLS does. >> When SCTP does PLMTUD, it sends probe packets. These would be packets = containing HEARTBEAT chunks >> bundled with PADDING chunks (http://tools.ietf.org/html/rfc4820) >=20 > RFC4820 says that RFC4821 descibes how to use the pad chunk for = PLMTUD, but there's no RFC I can locate that actually describes this as = an extension to SCTP. For my understanding, this is done in http://tools.ietf.org/html/rfc4821#section-10.2 >=20 >>>> so it makes it to the peer, and PMTUD concludes that the path MTU = >=3D M. >>>=20 >>> The path MTU would be m - compression doesn't affect the fact that = the path supported a message (compressed or not) of actual size m. >>>=20 >>>> Now SCTP fragments a user message to size M, however, this time he = compressed packet has size m' with >>>> m' > m. The packet is larger than the PMTU and this is really = bad... >>>=20 >>> The packet size would be m' (the uncompressed size I was referring = to above), and that's what you compare to the actual path MTU. >>>=20 >>>> So how can this work with compression being enabled? >>>=20 >>> See above. You measure what you see through the path, and compare it = to the uncompressed size of the packet. Compression helps performance, = but should not be considered as a way to increase effective path MTU. >> But whenever SCTP sends down a packet, it is compressed. So it has no = way of finding the >> packet size. >=20 > Isn't there a length field telling you the uncompressed size, and a = length parameter to the next layer that indicates the compressed size? >=20 >> I think the problem is that two packet of uncompressed sizes M' and = M'' with >> M' > M'' can result in compressed sizes m' and m'' with m' < m''. >=20 > Yes, that's why you would want to use the compressed size as the = indicator of the path MTU. OK. But does SCTP know what size it needs to use as the fragmentation = limit such that after compression of that fragment it does fit? >=20 >> That is why >> PMTUD does work with compression. >=20 > Are you sure you meant that? That's what I was saying, but you seem to = be saying the opposite. Yes, sorry. Mistake on my side. I meant that is why PLMTUD does not work = with compression. >=20 >>>>>> And if SCTP performs the path MTU discovery (as in the case of = RTCWeb), >>>>>> than it can't detect the the message size of the outgoing packet. >>>>>=20 >>>>> Sure it can; it measures from the size of the packets sent = (compressed), though. >>>> But this size is only known by the DTLS layer and is useless to = SCTP, since >>>> it must fragment the messages such that the compressed message = would fit. >>>> How could SCTP know? >>>=20 >>> If that's the case, then you have problems with DTLS-layer discovery = too. >> No. The DTLS overhead is constant (if you don't use compression). So = DTLS could >> provide a size for which packets would fit into the PMTU. >=20 > But DTLS packets can be fragmented at the IP layer; that's already a = warning in the DTLS doc. We want to avoid IP level fragmentation. That is why we want to do = PLPMTUD. >=20 >>>>>>>> The last sentence seems like it should be MUST NOT. >>>>>> No. How can you send probe packets if you can't send packets = larger than >>>>>> the current PMTU. >>>>>=20 >>>>> How can you do PMTU discovery if IP fragments the packets (which = you mention in the next sentence)? You need to more carefully discuss = how probe packets are generated and avoid outgoing fragmentation (as = well as on-path fragmentation). And it would apply only to probes. >>>> Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit. >>>=20 >>> When SCTP runs over IP directly. It won't work when SCTP runs over = UDP or SCTP over X. >> It does. At least in the FreeBSD based implementation. SCTP controls = the DF bit... >=20 > But do you have any indication this will work with another layer of = indirection? I.e., SCTP->DTLS->transport->IP Depends on the OS. Some OSes allow to control the DF bit others don't. = Getting this through DTLS is simple to implement... >=20 >>>> The only crucial point is that the DTLS layer allows the SCTP to do = this. This requires: >>>> * the DTLS layer to pass this information through >>>> * the lower layer of DTLS to provide a way to control the DF bit. >>>=20 >>> But that doesn't appear to be a feature of DTLS AFAICT. >> It is nothing the protocol has to provide, it is a feature provided = by the >> implementation or not... >=20 > This may be a red-herring for this discussion, but the API provided to = the next layer is absolutely part of the spec of a protocol. The IETF's = position on this was incorrect (and hopefully has changed). I really appreciate that API are becoming important... Having worked for = a long time on the socket API for SCTP. However, there is currently no API specified for DTLS... >=20 > Implementation issues are things like the argument order and specific = data types (e.g., whether to use u8 or u16 for a range of 0..255).. >=20 >>>>> That's an interaction a layer below DTLS, but you need to address = it here too. >>>> Yes. The current document (not yet submitted) contains (based on a = discussion at the >>>> IETF meeting): >>>>=20 >>>>=20 >>>> If path MTU discovery is performed by the SCTP layer and IPv4 is = used >>>> as the network layer protocol, the DTLS implementation MUST = allow the >>>> DTLS user to enforce that the corresponding IPv4 packet is sent = with >>>> the Don't Fragment (DF) bit set. >>>=20 >>> This adds a requirement to DTLS that doesn't appear to currently = exist; that means this extension isn't necessarily compatible with = currently compliant DTLS implementations. > > >> Right. However, the limiting factor is not the DTLS stack, but the = UDP interface... >=20 > Wouldn't it also be the DTLS interface (to SCTP) too? That can simply be changed by the people implementing this stack, since = it is in userland. Accessing the UDP stack (without special privileges) requires OS = support. This can't be changed that simple by people using this stack. >=20 >>>> ...If controlling the DF bit is not >>>> possible, for example due to implementation restrictions, a = save >>>=20 >>> safe? >>>=20 >>>> value for the path MTU has to be used by the SCTP stack. >>>=20 >>> Presuming you mean 'safe', there's no such value AFAICT. > > >> Formally correct. Well, RTCWeb has decided on such values: 1280 bytes = for IPv6 >> and 1200 bytes for IPv4 (both at the IP layer). >=20 > You should refer to those then, IMO. I can... No problem, but I think the value for IPv4 might be dependent = on the usage. The 1200 bytes comes from the RTCWeb WG, and are stated in that = specification. Best regards Michael >=20 > Joe >=20 From nobody Wed Apr 9 14:36:47 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5161A026E for ; Wed, 9 Apr 2014 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 g7qERSUCX7NG for ; Wed, 9 Apr 2014 14:36:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 273431A00EC for ; Wed, 9 Apr 2014 14:36:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s39LaFoo007164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Apr 2014 14:36:16 -0700 (PDT) Message-ID: <5345BD4F.5070007@isi.edu> Date: Wed, 09 Apr 2014 14:36:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/h-J4GqQML741Gu_ej-6bIE-Uwq8 Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:36:43 -0000 Hi, Martin, On 4/9/2014 12:13 PM, Michael Tuexen wrote: ... >>>> SCTP does RFC1191 only (PMTUD). >>> >>> That is why the text explicitly requires RFC4821 for PMTU in SCTP. >> >> RFC4821 talks about how SCTP *can* use the PAD chunk to do so, while avoiding retransmission if anything is lost - but I can't find anything that says that SCTP actually does this. > I read > http://tools.ietf.org/html/rfc4821#section-10.2 > in way that is describes a method for doing PLMTUD with probe packets. It used the term RECOMMENDED, so > it is more strict than *can*. Or am I missing something? RFC4821 doesn't update SCTP -- it doesn't update anything. I read that as "if SCTP generates probes, it SHOULD generate them using the PAD chunk attached to a min-len HB", and, later, "it MAY" do something like TCP does. It doesn't mandate that SCTP do probes at all - or PLMTUD at all - though. ... >> My concern is whether/how users can know the PMTU if they aren't the ones sending the probes. > > Because the probes are sent by SCTP as described in RFC 4821. RFC 4820 defined the probes: > http://tools.ietf.org/html/rfc4820 That means that SCTP knows the PMTU, so it can send data fragmented to conform to the path; that doesn't mean the user ever knows it. SCTP goes to lengths to bundle multiple user messages into one chunk or to split chunks across messages. FWIW, 4820 doesn't update SCTP either; this is more like "if you do probes, this is the mechanism by which to do it". >> >>>>>> I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to the application - which arguably is SCTP here. If the extensions in RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they don't). And why aren't they MUST or SHOULD? >>>>>> >>>>>> (I'm disappointed -- but not surprised -- that RFC 6520 appears to have no indication of the status of the extension, e.g., MUST, SHOULD, etc., in relation to the TLS/DTLS spec) >>>>> Again: What about just requesting SCTP to do the PMTU here? >>>> >>>> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to explain why. Otherwise you're constraining your solution to TDTLS implementations that support PLMTUD - and it's not a current requirement (besides, how could you even know at the SCTP layer?) >>> What are you suggesting: >>> (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer >>> (b) Require PLMTUD either at the SCTP layer or at the DTLS layer and let >>> the decision be specified in the corresponding document describing >>> the particular use case. >>> >>> I'm for simplicity and would vote for (a). >> >> (a) requires a standards-track RFC that indicates how this is done, which I can't find (there may be one; I don't track SCTP at that level of detail). > > What am I missing: I think RFC4821 describes such an algorithm and it is standards track. It talks about how SCTP should generate probes; it doesn't provide the rest of what would be needed to update SCTP. > We have only to require that the SCTP implementation support the mechanism described in > RFC4821. AFAICT, that description alone would not be sufficient. At a minimum, it fails to describe how SCTP would indicate the PMTU to the user (which SCTP doesn't otherwise do, AFAICT). ... >>> I think the problem is that two packet of uncompressed sizes M' and M'' with >>> M' > M'' can result in compressed sizes m' and m'' with m' < m''. >> >> Yes, that's why you would want to use the compressed size as the indicator of the path MTU. > > OK. But does SCTP know what size it needs to use as the fragmentation limit such that > after compression of that fragment it does fit? That's where thinking about compression gets into trouble with PMTUs. Think of it this way: - the PMTU is the size of message the net supports - compression makes transmission more efficient - compression IS NEVER a way to get a larger single message across a net than the PMTU can support THat's why SCTP doesn't need to know what size to use as a frag limit so that "after compression" it will fit; if it doesn't fit *before* compression, it doesn't fit. >> >>> That is why >>> PMTUD does work with compression. >> >> Are you sure you meant that? That's what I was saying, but you seem to be saying the opposite. > > Yes, sorry. Mistake on my side. I meant that is why PLMTUD does not work with compression. It can; there's nothing about that in the PLMTUD doc. ... >> But do you have any indication this will work with another layer of indirection? I.e., SCTP->DTLS->transport->IP > > Depends on the OS. Some OSes allow to control the DF bit others don't. Getting this through DTLS > is simple to implement... It's not an implementation issue; it's a protocol issue. If it's not a service provided by the protocol (in its logical API), then it might not exist, and thus you can't rely on it. ... > I really appreciate that API are becoming important... Having worked for a long time on the socket API for SCTP. > However, there is currently no API specified for DTLS... Hmm. That may render this entire document irrelevant then; you can't know what you're building SCTP to run over in that case. Joe From nobody Thu Apr 10 11:26:42 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CF81A029C for ; Thu, 10 Apr 2014 11:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 u4rHfg_e3hVk for ; Thu, 10 Apr 2014 11:26:37 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id C96A61A01F2 for ; Thu, 10 Apr 2014 11:26:36 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3AIQZgV005655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Apr 2014 14:26:35 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s3AIQZgV005655 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1397154395; bh=OTsTwHlZAagxadKcpWcJgnvZJCM=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rieWJqpL+JCrYRAsTPFkvmv9N9HipLqboD1qvDRGDZgslcbL229VRZp6wo+wcUypy JPEciouN+PE6FRfCOAinHQ4bUfApbSWtX1Ic4tjk/26YHy0Ok3QK4i6gavfadkbUfJ QrVg0Jka8XsmbVPfFaVFo21a/B39WM6XjxvBs1+s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s3AIQZgV005655 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Thu, 10 Apr 2014 14:26:19 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3AIQIm3016548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Apr 2014 14:26:19 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Thu, 10 Apr 2014 14:26:18 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Thu, 10 Apr 2014 14:26:18 -0400 Thread-Topic: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling over Foo (with)in IP networks (TOFOO) Thread-Index: Ac9U32QHwhNjz5LpSLilyrJHcbNvKwACusDQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C1D1968@MX15A.corp.emc.com> References: <20140410170359.12268.41197.idtracker@ietfa.amsl.com> In-Reply-To: <20140410170359.12268.41197.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/dFXFI_Rr22Iy4_LrV8UiZg3s9Fg Subject: [tsvwg] FW: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling over Foo (with)in IP networks (TOFOO) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 18:26:41 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYtQW5ub3VuY2UgW21haWx0bzpp ZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJRVRGIFNlY3JldGFy aWF0DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTAsIDIwMTQgMTowNCBQTQ0KVG86IElFVEYgQW5u b3VuY2VtZW50IExpc3QNCkNjOiBtbHMuaWV0ZkBnbWFpbC5jb207IHRvZm9vQGlldGYub3JnDQpT dWJqZWN0OiBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDogVG9mb28gLS0gRGlzY3Vzc2lvbiBsaXN0 IGZvciBUdW5uZWxpbmcgb3ZlciBGb28gKHdpdGgpaW4gSVAgbmV0d29ya3MgKFRPRk9PKQ0KDQpB IG5ldyBJRVRGIG5vbi13b3JraW5nIGdyb3VwIGVtYWlsIGxpc3QgaGFzIGJlZW4gY3JlYXRlZC4N Cg0KTGlzdCBhZGRyZXNzOiB0b2Zvb0BpZXRmLm9yZw0KQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3RvZm9vLw0KVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RvZm9vDQoNClB1cnBvc2U6IA0KDQpUdW5uZWxpbmcg ZGF0YSBhY3Jvc3MgSVAtYmFzZWQgbmV0d29ya3MgY2FuIHVzZSBhIHZhcmlldHkgb2YgZXhpc3Rp bmcgZW5jYXBzdWxhdGlvbiBzY2hlbWVzLCBzdWNoIGFzLCBHUkUgW1JGQzI3ODRdLCBJUC1pbi1J UCBbUkZDMjAwM10gYW5kIElQc2VjIHR1bm5lbHMgW1JGQzQzMDFdIG9yIHByb3Bvc2VkIGVuY2Fw c3VsYXRpb24gc2NoZW1lcyB0aGF0IGFyZSBiYXNlZCBvbiBjYXJyeWluZyB0cmFmZmljIG92ZXIg VURQLiANClRoZSBkZW1hbmQgZm9yIHVzaW5nIHR1bm5lbHMgaW4gZGF0YSBjZW50ZXJzIGFuZCBh Y3Jvc3MgdGhlIEludGVybmV0IGlzIGluY3JlYXNpbmcgYWxzbyBkdWUgdG8gbmV0d29yayB2aXJ0 dWFsaXphdGlvbi4gDQpBIG51bWJlciBvZiBrbm93biBpc3N1ZXMgaGF2ZSBiZWVuIHJhaXNlZCBh cm91bmQgdXNpbmcgdHVubmVscywgZGlzY3Vzc2lvbnMgYWJvdXQgYXBwbGljYWJpbGl0eSBvZiB0 aGVzZSBpc3N1ZXMgYXJlIG9uZ29pbmcgYW5kIGEgbnVtYmVyIG9mIHNvbHV0aW9ucyB0byBjb3Bl IHdpdGgsIGZvciBpbnN0YW5jZSwgY29uZ2VzdGlvbiBjb250cm9sIG9yIGNvbmdlc3Rpb24gY29u dHJvbCBzZW5zaXRpdml0eSwgYXJlIGJlaW5nIGRpc2N1c3NlZC4gDQpUaGUgaW50ZW50aW9uIG9m IHRoaXMgbGlzdCBpcyB0byBicmluZyB0b2dldGhlciB0dW5uZWwgcHJvdG9jb2wgZGVzaWduZXJz L2ltcGxlbWVudGVycywgbmV0d29yayBvcGVyYXRvcnMsIGFuZCB0aGUgZGlmZmVyZW50IGFyZWFz IGluIHRoZSBJRVRGIHRvIGRpc2N1c3MgdGhlIHdheXMgZm9yd2FyZC4NCg0KRm9yIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24sIHBsZWFzZSBjb250YWN0IHRoZSBsaXN0IGFkbWluaXN0cmF0b3JzLg0K DQoNCg== From nobody Thu Apr 17 13:55:05 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADFE1A0130 for ; Thu, 17 Apr 2014 13:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_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 BE52foxc8QcO for ; Thu, 17 Apr 2014 13:54:50 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id EA2BF1A0109 for ; Thu, 17 Apr 2014 13:54:49 -0700 (PDT) Received: from [192.168.1.200] (p508F3AD4.dip0.t-ipconnect.de [80.143.58.212]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7FEC11C10465A; Thu, 17 Apr 2014 22:54:44 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5345BD4F.5070007@isi.edu> Date: Thu, 17 Apr 2014 22:54:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> <5345BD4F.5070007@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ckS2D6BzbchEWt4Y2zsP-MLBeyc Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:54:56 -0000 On 09 Apr 2014, at 23:36, Joe Touch wrote: > Hi, Martin, >=20 > On 4/9/2014 12:13 PM, Michael Tuexen wrote: > ... >>>>> SCTP does RFC1191 only (PMTUD). >>>>=20 >>>> That is why the text explicitly requires RFC4821 for PMTU in SCTP. >>>=20 >>> RFC4821 talks about how SCTP *can* use the PAD chunk to do so, while = avoiding retransmission if anything is lost - but I can't find anything = that says that SCTP actually does this. >> I read >> http://tools.ietf.org/html/rfc4821#section-10.2 >> in way that is describes a method for doing PLMTUD with probe = packets. It used the term RECOMMENDED, so >> it is more strict than *can*. Or am I missing something? >=20 > RFC4821 doesn't update SCTP -- it doesn't update anything. Right. >=20 > I read that as "if SCTP generates probes, it SHOULD generate them = using the PAD chunk attached to a min-len HB", and, later, "it MAY" do = something like TCP does. >=20 > It doesn't mandate that SCTP do probes at all - or PLMTUD at all - = though. That is why we write in this document that when you run SCTP over DTLS as defined in this document, you MUST use the PLMTUD. So this document mandates what to do, it refers to other specs how to do it, but the other documents don't mandate it. Isn't that a valid way of doing it? >=20 > ... >>> My concern is whether/how users can know the PMTU if they aren't the = ones sending the probes. > > >> Because the probes are sent by SCTP as described in RFC 4821. RFC = 4820 defined the probes: >> http://tools.ietf.org/html/rfc4820 >=20 > That means that SCTP knows the PMTU, so it can send data fragmented to = conform to the path; that doesn't mean the user ever knows it. SCTP goes = to lengths to bundle multiple user messages into one chunk or to split = chunks across messages. The user of SCTP doesn't need to know. SCTP fragments the user messages. >=20 > FWIW, 4820 doesn't update SCTP either; this is more like "if you do = probes, this is the mechanism by which to do it". Correct. I want the SCTP/DTLS to mandate that this is the way you need = to do it (in this case). >=20 >=20 >>>=20 >>>>>>> I don't understand why it would be true, FWIW. DTLS leaves PMTUD = up to the application - which arguably is SCTP here. If the extensions = in RFC 6520 are that important, why don't they UPDATE the DTLS spec? = (they don't). And why aren't they MUST or SHOULD? >>>>>>>=20 >>>>>>> (I'm disappointed -- but not surprised -- that RFC 6520 appears = to have no indication of the status of the extension, e.g., MUST, = SHOULD, etc., in relation to the TLS/DTLS spec) >>>>>> Again: What about just requesting SCTP to do the PMTU here? >>>>>=20 >>>>> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to = explain why. Otherwise you're constraining your solution to TDTLS = implementations that support PLMTUD - and it's not a current requirement = (besides, how could you even know at the SCTP layer?) >>>> What are you suggesting: >>>> (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer >>>> (b) Require PLMTUD either at the SCTP layer or at the DTLS layer = and let >>>> the decision be specified in the corresponding document = describing >>>> the particular use case. >>>>=20 >>>> I'm for simplicity and would vote for (a). >>>=20 >>> (a) requires a standards-track RFC that indicates how this is done, = which I can't find (there may be one; I don't track SCTP at that level = of detail). > > >> What am I missing: I think RFC4821 describes such an algorithm and it = is standards track. >=20 > It talks about how SCTP should generate probes; it doesn't provide the = rest of what would be needed to update SCTP. >=20 >> We have only to require that the SCTP implementation support the = mechanism described in >> RFC4821. >=20 > AFAICT, that description alone would not be sufficient. At a minimum, = it fails to describe how SCTP would indicate the PMTU to the user (which = SCTP doesn't otherwise do, AFAICT). Normally the user is not interested in it, since SCTP does fragmentation = and reassembly. However, if the user wants to know it, it can use http://tools.ietf.org/html/rfc6458#section-8.2.2 >=20 > ... >>>> I think the problem is that two packet of uncompressed sizes M' and = M'' with >>>> M' > M'' can result in compressed sizes m' and m'' with m' < m''. >>>=20 >>> Yes, that's why you would want to use the compressed size as the = indicator of the path MTU. > > >> OK. But does SCTP know what size it needs to use as the fragmentation = limit such that >> after compression of that fragment it does fit? >=20 > That's where thinking about compression gets into trouble with PMTUs. >=20 > Think of it this way: >=20 > - the PMTU is the size of message the net supports >=20 > - compression makes transmission more efficient >=20 > - compression IS NEVER a way to get a larger single > message across a net than the PMTU can support >=20 > THat's why SCTP doesn't need to know what size to use as a frag limit = so that "after compression" it will fit; if it doesn't fit *before* = compression, it doesn't fit. What I don't understand: * A compressed message can be larger than the original uncompressed. So = it won't fit. * If SCTP sends the probe packets, doesn't this mean that the probe = packets must bypass compression? >=20 >>>=20 >>>> That is why >>>> PMTUD does work with compression. >>>=20 >>> Are you sure you meant that? That's what I was saying, but you seem = to be saying the opposite. > > >> Yes, sorry. Mistake on my side. I meant that is why PLMTUD does not = work with compression. >=20 > It can; there's nothing about that in the PLMTUD doc. >=20 > ... >>> But do you have any indication this will work with another layer of = indirection? I.e., SCTP->DTLS->transport->IP > > >> Depends on the OS. Some OSes allow to control the DF bit others = don't. Getting this through DTLS >> is simple to implement... >=20 > It's not an implementation issue; it's a protocol issue. If it's not a = service provided by the protocol (in its logical API), then it might not = exist, and thus you can't rely on it. >=20 > ... >> I really appreciate that API are becoming important... Having worked = for a long time on the socket API for SCTP. >> However, there is currently no API specified for DTLS... >=20 > Hmm. That may render this entire document irrelevant then; you can't = know what you're building SCTP to run over in that case. I don't think we can define a DTLS API in TSVWG... At least this is not = in the scope of this document. Best regards Michael >=20 > Joe >=20 From nobody Thu Apr 17 16:21:08 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CDD1A0110 for ; Thu, 17 Apr 2014 16:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 G9MMvYI2Qk35 for ; Thu, 17 Apr 2014 16:20:58 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 09B011A019D for ; Thu, 17 Apr 2014 16:20:58 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3HNKbdt014560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Apr 2014 16:20:38 -0700 (PDT) Message-ID: <535061C5.3030206@isi.edu> Date: Thu, 17 Apr 2014 16:20:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> <5345BD4F.5070007@isi.edu> <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> In-Reply-To: <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/bbOB70D18sm6iTU6s8iHJ6_v_iY Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 23:21:03 -0000 Hi, Michael, On 4/17/2014 1:54 PM, Michael Tuexen wrote: > On 09 Apr 2014, at 23:36, Joe Touch wrote: > >> Hi, Martin, >> >> On 4/9/2014 12:13 PM, Michael Tuexen wrote: >> ... >>>>>> SCTP does RFC1191 only (PMTUD). >>>>> >>>>> That is why the text explicitly requires RFC4821 for PMTU in SCTP. >>>> >>>> RFC4821 talks about how SCTP *can* use the PAD chunk to do so, while avoiding retransmission if anything is lost - but I can't find anything that says that SCTP actually does this. >>> I read >>> http://tools.ietf.org/html/rfc4821#section-10.2 >>> in way that is describes a method for doing PLMTUD with probe packets. It used the term RECOMMENDED, so >>> it is more strict than *can*. Or am I missing something? >> >> RFC4821 doesn't update SCTP -- it doesn't update anything. > > Right. >> >> I read that as "if SCTP generates probes, it SHOULD generate them using the PAD chunk attached to a min-len HB", and, later, "it MAY" do something like TCP does. >> >> It doesn't mandate that SCTP do probes at all - or PLMTUD at all - though. > > That is why we write in this document that when you run SCTP over DTLS > as defined in this document, you MUST use the PLMTUD. At the DTLS layer. > So this document > mandates what to do, it refers to other specs how to do it, but the > other documents don't mandate it. > Isn't that a valid way of doing it? The way you describe it in Sec 4 is (emphasis mine): If path MTU discovery is performed by the *DTLS* layer, the method described in [RFC4821] MUST be used. But RFC4821 doesn't talk about DTLS. That's what's confusing me. It only talks about SCTP, and gives two methods - one using pads and one at the user level (like TCP). For probe packets, the extension defined in [RFC6520] MUST be used. Now you're back to talking about DTLS. I think what you might want to say is that: If path MTU discovery is performed by the DTLS layer, the method described in [RFC4821] as for SCTP using a PAD in the extension described in [RFC6520] MUST be used. --- If path MTU discovery is performed by the *SCTP* layer and IPv4 is used as the network layer protocol, the DTLS implementation MUST allow the DTLS user to enforce that the corresponding IPv4 packet is sent with the DF bit set. Now I don't know where to do discovery - in DTLS or SCTP. That's not a mandate; that's two alternatives. >> ... >>>> My concern is whether/how users can know the PMTU if they aren't the ones sending the probes. >>> >>> Because the probes are sent by SCTP as described in RFC 4821. RFC 4820 defined the probes: >>> http://tools.ietf.org/html/rfc4820 >> >> That means that SCTP knows the PMTU, so it can send data >> fragmented to conform to the path; that doesn't mean the user ever >> knows it. SCTP goes to lengths to bundle multiple user messages >> into one chunk or to split chunks across messages. > > The user of SCTP doesn't need to know. SCTP fragments the user messages. OK; I think I have it now. I was thrown off by Section 4. >> FWIW, 4820 doesn't update SCTP either; this is more like "if you do probes, this is the mechanism by which to do it". > > Correct. I want the SCTP/DTLS to mandate that this is the way you need to do it (in this case). See above; there's ambiguity that needs to be resolved. >>>>>>>> I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to the application - which arguably is SCTP here. If the extensions in RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they don't). And why aren't they MUST or SHOULD? >>>>>>>> >>>>>>>> (I'm disappointed -- but not surprised -- that RFC 6520 appears to have no indication of the status of the extension, e.g., MUST, SHOULD, etc., in relation to the TLS/DTLS spec) >>>>>>> Again: What about just requesting SCTP to do the PMTU here? >>>>>> >>>>>> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to explain why. Otherwise you're constraining your solution to TDTLS implementations that support PLMTUD - and it's not a current requirement (besides, how could you even know at the SCTP layer?) >>>>> What are you suggesting: >>>>> (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer >>>>> (b) Require PLMTUD either at the SCTP layer or at the DTLS layer and let >>>>> the decision be specified in the corresponding document describing >>>>> the particular use case. >>>>> >>>>> I'm for simplicity and would vote for (a). >>>> >>>> (a) requires a standards-track RFC that indicates how this is done, which I can't find (there may be one; I don't track SCTP at that level of detail). >>> >>> What am I missing: I think RFC4821 describes such an algorithm and it is standards track. >> >> It talks about how SCTP should generate probes; it doesn't provide the rest of what would be needed to update SCTP. >> >>> We have only to require that the SCTP implementation support the mechanism described in >>> RFC4821. >> >> AFAICT, that description alone would not be sufficient. At a minimum, it fails to describe how SCTP would indicate the PMTU to the user (which SCTP doesn't otherwise do, AFAICT). > > Normally the user is not interested in it, since SCTP does fragmentation and reassembly. > However, if the user wants to know it, it can use > http://tools.ietf.org/html/rfc6458#section-8.2.2 Right - I was confused by Sec 4. >> ... >>>>> I think the problem is that two packet of uncompressed sizes M' and M'' with >>>>> M' > M'' can result in compressed sizes m' and m'' with m' < m''. >>>> >>>> Yes, that's why you would want to use the compressed size as the indicator of the path MTU. >>> >>> OK. But does SCTP know what size it needs to use as the fragmentation limit such that >>> after compression of that fragment it does fit? >> >> That's where thinking about compression gets into trouble with PMTUs. >> >> Think of it this way: >> >> - the PMTU is the size of message the net supports >> >> - compression makes transmission more efficient >> >> - compression IS NEVER a way to get a larger single >> message across a net than the PMTU can support >> >> THat's why SCTP doesn't need to know what size to use as a frag limit so that "after compression" it will fit; if it doesn't fit *before* compression, it doesn't fit. > > What I don't understand: > * A compressed message can be larger than the original uncompressed. So it won't fit. Then your compression is broken. A compressed message should never be larger than uncompressed - ever. > * If SCTP sends the probe packets, doesn't this mean that the probe packets > must bypass compression? At the SCTP layer; SCTP can't force lower layers to bypass compression. However, again, I was confused by Sec 4. >>>>> That is why >>>>> PMTUD does work with compression. >>>> >>>> Are you sure you meant that? That's what I was saying, but you seem to be saying the opposite. >>> >>> Yes, sorry. Mistake on my side. I meant that is why PLMTUD does not work with compression. >> >> It can; there's nothing about that in the PLMTUD doc. >> >> ... >>>> But do you have any indication this will work with another layer of indirection? I.e., SCTP->DTLS->transport->IP >>> >>> Depends on the OS. Some OSes allow to control the DF bit others don't. Getting this through DTLS >>> is simple to implement... >> >> It's not an implementation issue; it's a protocol issue. If it's not a service provided by the protocol (in its logical API), then it might not exist, and thus you can't rely on it. >> >> ... >>> I really appreciate that API are becoming important... Having worked for a long time on the socket API for SCTP. >>> However, there is currently no API specified for DTLS... >> >> Hmm. That may render this entire document irrelevant then; you can't know what you're building SCTP to run over in that case. > > I don't think we can define a DTLS API in TSVWG... At least this is not in the scope > of this document. Sure, but then you're stuck with SCTP only assuming it can interact with DTLS as if it were a DTLS user. DTLS users can't set DF. Joe From nobody Fri Apr 18 04:39:29 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC9E1A010D for ; Fri, 18 Apr 2014 04:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_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 XAcCLi7tcG8d for ; Fri, 18 Apr 2014 04:39:20 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 36AD71A017D for ; Fri, 18 Apr 2014 04:39:19 -0700 (PDT) Received: from [192.168.1.200] (p508F2359.dip0.t-ipconnect.de [80.143.35.89]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 621A81C104652; Fri, 18 Apr 2014 13:39:13 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <535061C5.3030206@isi.edu> Date: Fri, 18 Apr 2014 13:39:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C98A0A7-4727-4B53-A78B-186AEAAF15D1@lurchi.franken.de> References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> <5345BD4F.5070007@isi.edu> <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> <535061C5.3030206@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/XBNHBeG6GTEpASIYRGyuEYtlN-w Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 11:39:25 -0000 On 18 Apr 2014, at 01:20, Joe Touch wrote: > Hi, Michael, >=20 > On 4/17/2014 1:54 PM, Michael Tuexen wrote: >> On 09 Apr 2014, at 23:36, Joe Touch wrote: >>=20 >>> Hi, Martin, >>>=20 >>> On 4/9/2014 12:13 PM, Michael Tuexen wrote: >>> ... >>>>>>> SCTP does RFC1191 only (PMTUD). >>>>>>=20 >>>>>> That is why the text explicitly requires RFC4821 for PMTU in = SCTP. >>>>>=20 >>>>> RFC4821 talks about how SCTP *can* use the PAD chunk to do so, = while avoiding retransmission if anything is lost - but I can't find = anything that says that SCTP actually does this. >>>> I read >>>> http://tools.ietf.org/html/rfc4821#section-10.2 >>>> in way that is describes a method for doing PLMTUD with probe = packets. It used the term RECOMMENDED, so >>>> it is more strict than *can*. Or am I missing something? >>>=20 >>> RFC4821 doesn't update SCTP -- it doesn't update anything. > > >> Right. >>>=20 >>> I read that as "if SCTP generates probes, it SHOULD generate them = using the PAD chunk attached to a min-len HB", and, later, "it MAY" do = something like TCP does. >>>=20 >>> It doesn't mandate that SCTP do probes at all - or PLMTUD at all - = though. > > >> That is why we write in this document that when you run SCTP over = DTLS >> as defined in this document, you MUST use the PLMTUD. >=20 > At the DTLS layer. Either at the DTLS layer or at the SCTP layer. >=20 >> So this document >> mandates what to do, it refers to other specs how to do it, but the >> other documents don't mandate it. >> Isn't that a valid way of doing it? >=20 > The way you describe it in Sec 4 is (emphasis mine): >=20 > If path MTU discovery is performed by the *DTLS* layer, the method > described in [RFC4821] MUST be used. >=20 > But RFC4821 doesn't talk about DTLS. That's what's confusing me. It = only talks about SCTP, and gives two methods - one using pads and one at = the user level (like TCP). >=20 > For probe packets, the > extension defined in [RFC6520] MUST be used. >=20 > Now you're back to talking about DTLS. Have a look at https://tools.ietf.org/html/rfc4821#section-10.4 Since DTLS is running on top of UDP, it qualifies as an application in the sense of that section, I think. In the second paragraph it talks about packets similar to SCTP HB plus PAD. This is exactly what is described in https://tools.ietf.org/html/rfc6520#section-4 >=20 > I think what you might want to say is that: >=20 > If path MTU discovery is performed by the DTLS layer, the method > described in [RFC4821] as for SCTP using a PAD in the extension > described in [RFC6520] MUST be used. OK. I'm fine with that text. >=20 > --- >=20 > If path MTU discovery is performed by the *SCTP* layer and IPv4 is = used > as the network layer protocol, the DTLS implementation MUST allow = the > DTLS user to enforce that the corresponding IPv4 packet is sent with > the DF bit set. >=20 > Now I don't know where to do discovery - in DTLS or SCTP. That's not a = mandate; that's two alternatives. Since it is "performed by the SCTP layer", SCTP is sending the probe = packets. It usea the ones defined in http://tools.ietf.org/html/rfc4820. However, the = requirement for the DTLS layer is to expose the control of the DF bit. Any suggestion how to make that clearer? >=20 >>> ... >>>>> My concern is whether/how users can know the PMTU if they aren't = the ones sending the probes. >>>>=20 >>>> Because the probes are sent by SCTP as described in RFC 4821. RFC = 4820 defined the probes: >>>> http://tools.ietf.org/html/rfc4820 >>>=20 >>> That means that SCTP knows the PMTU, so it can send data >>> fragmented to conform to the path; that doesn't mean the user ever >>> knows it. SCTP goes to lengths to bundle multiple user messages >>> into one chunk or to split chunks across messages. >>=20 >> The user of SCTP doesn't need to know. SCTP fragments the user = messages. >=20 > OK; I think I have it now. I was thrown off by Section 4. >=20 >>> FWIW, 4820 doesn't update SCTP either; this is more like "if you do = probes, this is the mechanism by which to do it". > > >> Correct. I want the SCTP/DTLS to mandate that this is the way you = need to do it (in this case). >=20 > See above; there's ambiguity that needs to be resolved. >=20 >>>>>>>>> I don't understand why it would be true, FWIW. DTLS leaves = PMTUD up to the application - which arguably is SCTP here. If the = extensions in RFC 6520 are that important, why don't they UPDATE the = DTLS spec? (they don't). And why aren't they MUST or SHOULD? >>>>>>>>>=20 >>>>>>>>> (I'm disappointed -- but not surprised -- that RFC 6520 = appears to have no indication of the status of the extension, e.g., = MUST, SHOULD, etc., in relation to the TLS/DTLS spec) >>>>>>>> Again: What about just requesting SCTP to do the PMTU here? >>>>>>>=20 >>>>>>> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need = to explain why. Otherwise you're constraining your solution to TDTLS = implementations that support PLMTUD - and it's not a current requirement = (besides, how could you even know at the SCTP layer?) >>>>>> What are you suggesting: >>>>>> (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer >>>>>> (b) Require PLMTUD either at the SCTP layer or at the DTLS layer = and let >>>>>> the decision be specified in the corresponding document = describing >>>>>> the particular use case. >>>>>>=20 >>>>>> I'm for simplicity and would vote for (a). >>>>>=20 >>>>> (a) requires a standards-track RFC that indicates how this is = done, which I can't find (there may be one; I don't track SCTP at that = level of detail). >>>>=20 >>>> What am I missing: I think RFC4821 describes such an algorithm and = it is standards track. >>>=20 >>> It talks about how SCTP should generate probes; it doesn't provide = the rest of what would be needed to update SCTP. >>>=20 >>>> We have only to require that the SCTP implementation support the = mechanism described in >>>> RFC4821. >>>=20 >>> AFAICT, that description alone would not be sufficient. At a = minimum, it fails to describe how SCTP would indicate the PMTU to the = user (which SCTP doesn't otherwise do, AFAICT). > > >> Normally the user is not interested in it, since SCTP does = fragmentation and reassembly. >> However, if the user wants to know it, it can use >> http://tools.ietf.org/html/rfc6458#section-8.2.2 >=20 > Right - I was confused by Sec 4. >=20 >>> ... >>>>>> I think the problem is that two packet of uncompressed sizes M' = and M'' with >>>>>> M' > M'' can result in compressed sizes m' and m'' with m' < m''. >>>>>=20 >>>>> Yes, that's why you would want to use the compressed size as the = indicator of the path MTU. >>>>=20 >>>> OK. But does SCTP know what size it needs to use as the = fragmentation limit such that >>>> after compression of that fragment it does fit? >>>=20 >>> That's where thinking about compression gets into trouble with = PMTUs. >>>=20 >>> Think of it this way: >>>=20 >>> - the PMTU is the size of message the net supports >>>=20 >>> - compression makes transmission more efficient >>>=20 >>> - compression IS NEVER a way to get a larger single >>> message across a net than the PMTU can support >>>=20 >>> THat's why SCTP doesn't need to know what size to use as a frag = limit so that "after compression" it will fit; if it doesn't fit = *before* compression, it doesn't fit. > > >> What I don't understand: >> * A compressed message can be larger than the original uncompressed. = So it won't fit. >=20 > Then your compression is broken. A compressed message should never be = larger than uncompressed - ever. Really? If you present some random data, the compression won't give you = anything (there is no redundancy). Some compression algorithms add an overhead. So the = compressed message would be larger. Or am I wrong? >=20 >> * If SCTP sends the probe packets, doesn't this mean that the probe = packets >> must bypass compression? >=20 > At the SCTP layer; SCTP can't force lower layers to bypass = compression. Correct. So assume SCTP send probe packets and the padding is constant data. So = it is highly compressible. Wouldn't SCTP then conclude that you can send a large = message without fragmentation? If SCTP takes that as the PMTU, it would fragment user = messages for that boundary, compression might not be as efficient and you would need = IP fragmentation. >=20 > However, again, I was confused by Sec 4. >=20 >>>>>> That is why >>>>>> PMTUD does work with compression. >>>>>=20 >>>>> Are you sure you meant that? That's what I was saying, but you = seem to be saying the opposite. >>>>=20 >>>> Yes, sorry. Mistake on my side. I meant that is why PLMTUD does not = work with compression. >>>=20 >>> It can; there's nothing about that in the PLMTUD doc. >>>=20 >>> ... >>>>> But do you have any indication this will work with another layer = of indirection? I.e., SCTP->DTLS->transport->IP >>>>=20 >>>> Depends on the OS. Some OSes allow to control the DF bit others = don't. Getting this through DTLS >>>> is simple to implement... >>>=20 >>> It's not an implementation issue; it's a protocol issue. If it's not = a service provided by the protocol (in its logical API), then it might = not exist, and thus you can't rely on it. >>>=20 >>> ... >>>> I really appreciate that API are becoming important... Having = worked for a long time on the socket API for SCTP. >>>> However, there is currently no API specified for DTLS... >>>=20 >>> Hmm. That may render this entire document irrelevant then; you can't = know what you're building SCTP to run over in that case. > > >> I don't think we can define a DTLS API in TSVWG... At least this is = not in the scope >> of this document. >=20 > Sure, but then you're stuck with SCTP only assuming it can interact = with DTLS as if it were a DTLS user. DTLS users can't set DF. Why? It depends on the implementation of DTLS... Best regards Michael >=20 > Joe >=20 From nobody Fri Apr 18 09:36:34 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6362C1A0423 for ; Fri, 18 Apr 2014 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 m5E9ANpqixuE for ; Fri, 18 Apr 2014 09:36:30 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4D11A041E for ; Fri, 18 Apr 2014 09:36:30 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3IGZpti020754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 Apr 2014 09:35:55 -0700 (PDT) Message-ID: <53515469.3010703@isi.edu> Date: Fri, 18 Apr 2014 09:35:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> <5345BD4F.5070007@isi.edu> <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> <535061C5.3030206@isi.edu> <6C98A0A7-4727-4B53-A78B-186AEAAF15D1@lurchi.franken.de> In-Reply-To: <6C98A0A7-4727-4B53-A78B-186AEAAF15D1@lurchi.franken.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/zh4Ozqa6ePqSG0L2JyL4tjv6QuY Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:36:32 -0000 Cutting down a bit... On 4/18/2014 4:39 AM, Michael Tuexen wrote: ... >>> That is why we write in this document that when you run SCTP over DTLS >>> as defined in this document, you MUST use the PLMTUD. >> >> At the DTLS layer. > > Either at the DTLS layer or at the SCTP layer. How would an implementer know what to do per se? If they built this using userland SCTP, which they could AFAICT, they might not know. IMO, that means you should say something more like: - if you know, it can be at either layer - one layer MUST do it >>> So this document >>> mandates what to do, it refers to other specs how to do it, but the >>> other documents don't mandate it. >>> Isn't that a valid way of doing it? >> >> The way you describe it in Sec 4 is (emphasis mine): >> >> If path MTU discovery is performed by the *DTLS* layer, the method >> described in [RFC4821] MUST be used. >> >> But RFC4821 doesn't talk about DTLS. That's what's confusing me. It only talks about SCTP, and gives two methods - one using pads and one at the user level (like TCP). >> >> For probe packets, the >> extension defined in [RFC6520] MUST be used. >> >> Now you're back to talking about DTLS. > > Have a look at > https://tools.ietf.org/html/rfc4821#section-10.4 > Since DTLS is running on top of UDP, it qualifies as an > application in the sense of that section, I think. > In the second paragraph it talks about packets similar > to SCTP HB plus PAD. This is exactly what is described in > https://tools.ietf.org/html/rfc6520#section-4 That's far too vague to qualify as a "method" that you can tie to a MUST, IMO. I would expect that your doc ought to give the needed details, "inspired" by 4821. >> I think what you might want to say is that: >> >> If path MTU discovery is performed by the DTLS layer, the method >> described in [RFC4821] as for SCTP using a PAD in the extension >> described in [RFC6520] MUST be used. > > OK. I'm fine with that text. You might need a little more (not sure; I'll let the SCTP folks decide). I just don't know if that's enough detail to qualify as a standards requirement. >> --- >> >> If path MTU discovery is performed by the *SCTP* layer and IPv4 is used >> as the network layer protocol, the DTLS implementation MUST allow the >> DTLS user to enforce that the corresponding IPv4 packet is sent with >> the DF bit set. >> >> Now I don't know where to do discovery - in DTLS or SCTP. That's not a mandate; that's two alternatives. > > Since it is "performed by the SCTP layer", SCTP is sending the probe packets. It usea > the ones defined in http://tools.ietf.org/html/rfc4820. However, the requirement for > the DTLS layer is to expose the control of the DF bit. > Any suggestion how to make that clearer? As noted above: a) say "do X or Y, but you MUST do one of these" b) give the details a little more of how to do things in either case. ... >>> What I don't understand: >>> * A compressed message can be larger than the original uncompressed. So it won't fit. >> >> Then your compression is broken. A compressed message should never be larger than uncompressed - ever. > > Really? If you present some random data, the compression won't give you anything (there > is no redundancy). Some compression algorithms add an overhead. So the compressed message would > be larger. Or am I wrong? That's a really bad compression algorithm. A reasonable one should leave things alone (with no overhead) if it can't make things better. >>> * If SCTP sends the probe packets, doesn't this mean that the probe packets >>> must bypass compression? >> >> At the SCTP layer; SCTP can't force lower layers to bypass compression. > > Correct. > So assume SCTP send probe packets and the padding is constant data. So it is highly > compressible. Wouldn't SCTP then conclude that you can send a large message without > fragmentation? If SCTP takes that as the PMTU, it would fragment user messages for > that boundary, compression might not be as efficient and you would need IP fragmentation. PMTUD is supposed to tell you when a segment of a given size at a given layer *can get there*. If it gets there, then the MTU is valid. E.g., PMTUD won't tell you that ATM has 53-byte cells with 48-byte payloads either. ... >>> I don't think we can define a DTLS API in TSVWG... At least this is not in the scope >>> of this document. >> >> Sure, but then you're stuck with SCTP only assuming it can >> interact with DTLS as if it were a DTLS user. DTLS users can't set DF. > > Why? It depends on the implementation of DTLS... Then you can't require it in a standards doc. Joe From nobody Mon Apr 21 14:34:15 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987491A02A0 for ; Mon, 21 Apr 2014 14:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 6JHqyl1FUBjg for ; Mon, 21 Apr 2014 14:34:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 52DE11A0216 for ; Mon, 21 Apr 2014 14:34:12 -0700 (PDT) Received: from BLUPR02MB359.namprd02.prod.outlook.com (10.141.77.148) by BLUPR02MB360.namprd02.prod.outlook.com (10.141.77.152) with Microsoft SMTP Server (TLS) id 15.0.921.12; Mon, 21 Apr 2014 21:34:06 +0000 Received: from BLUPR02MB359.namprd02.prod.outlook.com ([10.141.77.148]) by BLUPR02MB359.namprd02.prod.outlook.com ([10.141.77.148]) with mapi id 15.00.0921.000; Mon, 21 Apr 2014 21:34:06 +0000 From: Michael Thornburgh To: "tsvwg@ietf.org" Thread-Topic: feedback request: draft-thornburgh-rtmfp-flash Thread-Index: Ac9dqU3+CdsveOucSe6LFY6UlsuYcg== Date: Mon, 21 Apr 2014 21:34:05 +0000 Message-ID: <1a06e61cada14a898169c53419607ec4@BLUPR02MB359.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.19.4] x-forefront-prvs: 0188D66E61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(377424004)(189002)(199002)(86362001)(76482001)(85852003)(83072002)(15975445006)(76576001)(81342001)(33646001)(87936001)(46102001)(81542001)(99286001)(4396001)(83322001)(66066001)(79102001)(80022001)(77982001)(99396002)(2656002)(20776003)(50986999)(15202345003)(77096999)(74316001)(92566001)(54356999)(80976001)(19580395003)(74662001)(74502001)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB360; H:BLUPR02MB359.namprd02.prod.outlook.com; FPR:AD5875FF.ACF0CD95.B5E13F47.DCEA9171.2033E; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/s2ll2gc6AsINy2xt0dzZPSTLnIw Subject: [tsvwg] feedback request: draft-thornburgh-rtmfp-flash X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:34:14 -0000 hi TSV Working Group folks. i briefly presented "Adobe's Secure Real-Time Media Flow Protocol" (RTMFP) = to this working group at IETF 86 in Orlando, and notified this mailing list= , soliciting feedback on the specification I-D to help improve it. i recei= ved invaluable feedback from the community, and when the specification was = published as RFC 7016, it was very much improved from the initial draft due= in large part to the community review it received. RTMFP is a general purpose endpoint-to-endpoint transport protocol designed= for real-time and P2P communication. it is deployed widely in the Interne= t as part of Adobe Flash and other software. i have submitted a new companion I-D, "Adobe's RTMFP Profile for Flash Comm= unication", that describes how RTMFP (the generic protocol) is used to tran= sport the video, audio, and data messages of real-time and P2P communicatio= ns in Flash, including the concrete RFC 7016 "Cryptography Profile" for Fla= sh. this new specification illustrates a practical application of RTMFP, w= hich can also help folks understand how to apply RTMFP's capabilities to us= e cases other than Flash communication. we will eventually be submitting this specification to the Independent Subm= ission Editorial Board for publication as an Informational RFC. to that en= d i am soliciting feedback, comments, and reviews of this I-D to help us im= prove its quality, readability, implementability, etc. --- Name: draft-thornburgh-rtmfp-flash Revision: 00 Title: Adobe's RTMFP Profile for Flash Communication Document date: 2014-04-14 Group: Individual Submission Pages: 45 URL: http://www.ietf.org/internet-drafts/draft-thornburgh-rtmfp-= flash-00.txt Status: https://datatracker.ietf.org/doc/draft-thornburgh-rtmfp-fla= sh/ Htmlized: http://tools.ietf.org/html/draft-thornburgh-rtmfp-flash-00 IPR: https://datatracker.ietf.org/ipr/2345/ Abstract: This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication. --- thank you. -michael thornburgh From nobody Tue Apr 22 08:10:04 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CBD1A064B for ; Tue, 22 Apr 2014 08:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 A-HG3dIpRnT9 for ; Tue, 22 Apr 2014 08:10:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id E8D041A063A for ; Tue, 22 Apr 2014 08:09:46 -0700 (PDT) Received: from BLUPR07MB593.namprd07.prod.outlook.com (10.141.206.141) by BLUPR07MB594.namprd07.prod.outlook.com (10.141.206.146) with Microsoft SMTP Server (TLS) id 15.0.918.8; Tue, 22 Apr 2014 15:09:38 +0000 Received: from BLUPR07MB593.namprd07.prod.outlook.com ([10.141.206.141]) by BLUPR07MB593.namprd07.prod.outlook.com ([10.141.206.141]) with mapi id 15.00.0918.000; Tue, 22 Apr 2014 15:09:38 +0000 From: "Bradner, Scott" To: "tsvwg@ietf.org" Thread-Topic: Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over PCN Domains Thread-Index: AQHPXjzguG2pscojD065tH44tp2tPg== Date: Tue, 22 Apr 2014 15:09:38 +0000 Message-ID: <785FC019-5394-476E-B266-80108F12C580@harvard.edu> References: <201404142019.s3EKJQJZ000761@alln-core-7.cisco.com> In-Reply-To: <201404142019.s3EKJQJZ000761@alln-core-7.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.103.229.199] x-forefront-prvs: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(37854004)(189002)(199002)(92726001)(83716003)(20776003)(81342001)(36756003)(2656002)(81542001)(99396002)(76482001)(82746002)(86362001)(46102001)(80022001)(87936001)(4396001)(92566001)(85852003)(74662001)(31966008)(33656001)(83322001)(54356999)(80976001)(76176999)(74502001)(50986999)(83072002)(77096999)(75432001)(99286001)(66066001)(79102001)(77982001)(100906001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR07MB594; H:BLUPR07MB593.namprd07.prod.outlook.com; FPR:3B1A58DC.1594A7E6.636D0DB8.D8E99278.200EE; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: harvard.edu does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <99AA1ECE6CC62F47B16579DBEE7C1667@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/AQa3gKZ6Lan8VVYWw3nCoMIvyZY Subject: [tsvwg] Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over PCN Domains X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 15:10:02 -0000 sorry for the delay I have reviewed Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over= PCN Domains (draft-ietf-tsvwg-rsvp-pcn-08). It took a while because of the changes but the resulting document makes sen= se to me, both relative to the original PCN architecture=20 and in the absolute, so I think this is ready to proceed. Scott From nobody Tue Apr 22 14:44:45 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246751A0282 for ; Tue, 22 Apr 2014 14:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 p9yRwFXjRG1Y for ; Tue, 22 Apr 2014 14:44:37 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 293691A027C for ; Tue, 22 Apr 2014 14:44:37 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3MLiVZp004718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Apr 2014 17:44:31 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s3MLiVZp004718 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1398203071; bh=tbc3/GrOSmybJGauL4+Fjx3iC4U=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nVyaH+RLspWRQg5CjUu49e7NNjbb+4AuOPzd8DPSAFtz2Lv5fBaNPOR51MJNxQMz/ MxSzyUyhvSk7PR8xMsdSnFxu5q8F4fZmZUgxcCK6DMOElpSFW/1OtEklyJHNT5cACe aUgLZmJhBLNf/jB/zS/4YWOZkceYf9T6Ij8l0LuE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s3MLiVZp004718 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Tue, 22 Apr 2014 17:44:15 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3MLiEce004384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Apr 2014 17:44:15 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Tue, 22 Apr 2014 17:44:11 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Tue, 22 Apr 2014 17:43:54 -0400 Thread-Topic: WG Action: Formed DiffServ Applied to Real-time Transports (dart) Thread-Index: Ac9bRjHapB9e9BasTAiZjwr3xq+g6wDLbUgw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C2EC8F0@MX15A.corp.emc.com> References: <20140418203825.19855.70363.idtracker@ietfa.amsl.com> In-Reply-To: <20140418203825.19855.70363.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/VL1EvvzPSGTbGwq7HJ8qfVul4TA Subject: [tsvwg] FW: WG Action: Formed DiffServ Applied to Real-time Transports (dart) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 21:44:41 -0000 -----Original Message----- From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Th= e IESG Sent: Friday, April 18, 2014 4:38 PM To: IETF-Announce Cc: dart WG Subject: WG Action: Formed DiffServ Applied to Real-time Transports (dart) A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information please contact the Area Directors or the WG Chair. DiffServ Applied to Real-time Transports (dart) ------------------------------------------------ Current Status: Proposed WG Chairs: Ben Campbell Technical advisors: Martin Stiemerling Assigned Area Director: Richard Barnes Mailing list Address: dart@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dart Archive: http://www.ietf.org/mail-archive/web/dart/ Charter: Differentiated Services (DiffServ) and DiffServ code points (DSCP) can be used in some situations to provide quality of service (QoS). Packets with different markings can be reordered, which can cause poor interaction with a transport protocol that is sensitive to reordering. When RTP streams or other real-time media (sub-)flows are used with different DSCP values with the same transport 5-tuple, there may be transport protocol interactions. There are also environments where the DSCP markings are removed or remarked. This WG will write a document that explains the limitations that exist with DiffServ when used with RTP in general as well in the specific RTCWeb cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Milestones: Aug 2014 - Send Informational draft to IESG on DiffServ usage consideration From rdohm321@gmail.com Tue Apr 22 09:58:24 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8881A0698 for ; Tue, 22 Apr 2014 09:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFxkBbVqRJ0t for ; Tue, 22 Apr 2014 09:58:24 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2A1A0697 for ; Tue, 22 Apr 2014 09:58:23 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so5311923qae.33 for ; Tue, 22 Apr 2014 09:58:18 -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=mH+7jEvSbQk/6Q7sDhO2CjQrRGvV5QmB+CHlk9RG/EU=; b=xhhP2SueW6792JMI8pheF7IsFGY+2hilDE3rsJueMbfQYsVYLw+v5FngkLhZwLh+di PHGfbRmuEp1Qw6zWjlqlpMvjpUVJpBViIyrRGZDx1DHFD7AWlLZ5g9cVxwH6ltgYCL2I vu4Tk0labCMC2VkfQJ50aFD+05M6IC8991+jdPi5dz0jFvhsGYT8wLaZXCfO61ZCPZbx 1gr0LXQZgBtxxedof31aaE/HNQNV6Jv4SXYdDn2MEothkg+vQC42LYLmTRo0/fOqEmqD wc/XWOxoCvWw1GLV2oJ4v+zBt4O2QH4zMLQcGnwp2NDd/b4e6CnyUOePkn8XdeAqiWxh 0fNA== MIME-Version: 1.0 X-Received: by 10.229.192.7 with SMTP id do7mr50156776qcb.1.1398185898120; Tue, 22 Apr 2014 09:58:18 -0700 (PDT) Received: by 10.96.178.168 with HTTP; Tue, 22 Apr 2014 09:58:18 -0700 (PDT) Date: Tue, 22 Apr 2014 18:58:18 +0200 Message-ID: From: Randolph To: linux-sctp@vger.kernel.org Content-Type: multipart/alternative; boundary=001a11337d4ac9b82304f7a48512 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/aYQJZPw_sFKpUQoXCvQenhZxJcM X-Mailman-Approved-At: Wed, 23 Apr 2014 08:02:19 -0700 Subject: [tsvwg] SCTP implementation into an Instant Messenger with File Transfer X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 17:00:18 -0000 --001a11337d4ac9b82304f7a48512 Content-Type: text/plain; charset=UTF-8 Dear SCTP Community, SCTP has been implemented into an Instant Messenger with File Transfer. Binaries are available for windows, a compile info for Linux and several other operating systems is also given (c++ / Qt). Please test it and if you like, describe your research. The used library spot-on is an evaluation project and please post improvement requests there. For the implementation see the homepage of the Chat-App: http://goldbug.sf.net - an extended gui is provided by the library too for more detailed tests. Regards --001a11337d4ac9b82304f7a48512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear SCTP Community,

SCTP ha= s been implemented into an Instant Messenger with File Transfer.
= Binaries are available for windows, a compile info for Linux and several ot= her operating systems is also given (c++ / Qt).

Please test it=C2=A0and if you like,=C2=A0describe your= research. The used library spot-on is an evaluation=C2=A0project and pleas= e post improvement requests there.

For the impleme= ntation see the homepage of the Chat-App:
http://goldbug.sf.net=C2=A0 - an= extended=C2=A0gui is provided by the library too for more detailed tests.<= /div>

Regards
--001a11337d4ac9b82304f7a48512-- From nobody Thu Apr 24 06:13:47 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56A81A01B3 for ; Thu, 24 Apr 2014 06:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 ULvtwfphi8bJ for ; Thu, 24 Apr 2014 06:13:41 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B26411A0192 for ; Thu, 24 Apr 2014 06:13:41 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so2152347yho.32 for ; Thu, 24 Apr 2014 06:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xAsGJFsrAXl2D6p4Vxsm6+kU/bK5VfBJQ5OvmXREPHg=; b=rd6gwUj8UzQUR6l8WVeuMxRDWMugsCNaqrnWd3eEto2xTLD6pn5NATG92oCvFzjJgh K4qKvTOypf1LYK6O602fe0skZfeagVlU/0NGXNPjKx8NzoATowwcuVaACPhPwBREY5GW c5pizFHxKZZI4362r7ZEWDSn0HpU80VLfIgvZQYCl5fN3+ipOMM+GbGBZh028jaEksO5 peaRZXuRVltmV7GWNOXCtoxFOsCXv3UEiXZxXmgDsz7MUECoRRdQcO2/Q3TlwVOpsPRg k7EzuH+nFBi+VL7TrRsmMlAARjbHvxJatiLglepjUr8sRHcuZnEVpmRN0BmZxuhKo00T DawA== X-Received: by 10.236.220.72 with SMTP id n68mr2340795yhp.102.1398345215638; Thu, 24 Apr 2014 06:13:35 -0700 (PDT) Received: from [10.83.33.122] ([166.205.66.93]) by mx.google.com with ESMTPSA id g65sm7478565yhm.28.2014.04.24.06.13.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 06:13:34 -0700 (PDT) References: <201404142019.s3EKJQJZ000761@alln-core-7.cisco.com> <785FC019-5394-476E-B266-80108F12C580@harvard.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <785FC019-5394-476E-B266-80108F12C580@harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D167) From: bhargava.anurag@gmail.com Date: Thu, 24 Apr 2014 09:13:33 -0400 To: "Bradner, Scott" Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Ho2TOl2x4_bx-RHV007J0x0oFH0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over PCN Domains X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 13:13:43 -0000 T Sent from my iPhone > On Apr 22, 2014, at 11:09 AM, "Bradner, Scott" wrote: >=20 > sorry for the delay >=20 > I have reviewed Generic Aggregated RSVP for IPv4 and IPv6 Reservations Ove= r PCN Domains (draft-ietf-tsvwg-rsvp-pcn-08). >=20 > It took a while because of the changes but the resulting document makes se= nse to me, both relative to the original PCN architecture=20 > and in the absolute, so I think this is ready to proceed. >=20 > Scott >=20 >=20 From nobody Thu Apr 24 06:14:38 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E171A0192 for ; Thu, 24 Apr 2014 06:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 DFLihh62yDRG for ; Thu, 24 Apr 2014 06:14:31 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA71A01B3 for ; Thu, 24 Apr 2014 06:14:31 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so2137026yho.4 for ; Thu, 24 Apr 2014 06:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7MgO2ar/GzaqF9FY4CHE00MtS0LGzDAHlE4RWBEFdV0=; b=npqvdvBrdND6HhLlLjAGTLu88FchXisMAaRm6xqL4w6TdtsqDbtmW+5twMzTe1knQx xJB3gW/xgSaiAZ91Ge7neVRhEPX2HZC34JtiMfUTOYVmv+KurPKa/70GDM5K6HghPjaT jUb90pJbvj+Lk42aoFVLz2nufC6LurzFN/7/qWPaI8r5qczdB0ST9gGYrBQcQJcO25WG 3oO5ywH92Hx7Gj0VpzoXxwzPKwrp/yHpVS0lLr+NEWwbmDVyyoIrzLahE+LFxI3OJ8ZC Tw5TdtcrZSOiz+vtxWXBXAIb/BAHyiN5S1ppkR22vd3iWU/TSfNQbRU96uknjaeRtpw8 mCSQ== X-Received: by 10.236.63.103 with SMTP id z67mr2410678yhc.2.1398345265022; Thu, 24 Apr 2014 06:14:25 -0700 (PDT) Received: from [10.83.33.122] ([166.205.66.93]) by mx.google.com with ESMTPSA id 24sm7488325yhb.19.2014.04.24.06.14.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 06:14:24 -0700 (PDT) References: <201404142019.s3EKJQJZ000761@alln-core-7.cisco.com> <785FC019-5394-476E-B266-80108F12C580@harvard.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <785FC019-5394-476E-B266-80108F12C580@harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <989FAB66-EE3F-4947-A4D4-DC80FFC811FF@gmail.com> X-Mailer: iPhone Mail (11D167) From: bhargava.anurag@gmail.com Date: Thu, 24 Apr 2014 09:14:22 -0400 To: "Bradner, Scott" Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/JnSFxKFvaNO8bRWGcqao_71NsiE Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over PCN Domains X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 13:14:34 -0000 Thx Scott and chairs. Br, Anurag Sent from my iPhone > On Apr 22, 2014, at 11:09 AM, "Bradner, Scott" wrote: >=20 > sorry for the delay >=20 > I have reviewed Generic Aggregated RSVP for IPv4 and IPv6 Reservations Ove= r PCN Domains (draft-ietf-tsvwg-rsvp-pcn-08). >=20 > It took a while because of the changes but the resulting document makes se= nse to me, both relative to the original PCN architecture=20 > and in the absolute, so I think this is ready to proceed. >=20 > Scott >=20 >=20