Re: [rtcweb] Meaning of SHOULD support/use interleaving

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 27 October 2014 20:10 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB61A19F8 for <rtcweb@ietfa.amsl.com>; Mon, 27 Oct 2014 13:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMKOB8_kwI1y for <rtcweb@ietfa.amsl.com>; Mon, 27 Oct 2014 13:10:44 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346CD1AD40A for <rtcweb@ietf.org>; Mon, 27 Oct 2014 13:10:44 -0700 (PDT)
Received: from [192.168.1.200] (p508F0FB4.dip0.t-ipconnect.de [80.143.15.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9D4A41C1050E3; Mon, 27 Oct 2014 21:10:41 +0100 (CET)
Content-Type: text/plain; charset="windows-1256"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se>
Date: Mon, 27 Oct 2014 21:10:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de>
References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <EA00639E-2008-4BD2-88F2-27AAEE9DA213@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zUlYJl8aO1aVOyF-khT21GZ6SjQ
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 20:10:48 -0000

On 27 Oct 2014, at 21:05, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
> I am not suggesting different flavors - I am suggesting to make the usage of interleaving optional. Other SCTP features are also optional (including reliability, ordering etc).
Where are these things optional? According to
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1
an implementation MUST implement PR-SCTP and the support of the FORWARD-TSN
chunk will be negotiated similar to the NDATA chunk. I don't see a difference,
especially not if we move to MUST support NDATA.

Best regards
Michael
> 
> We CAN write/reference guidelines on when it DOES make sense to use interleaving.
> 
> Regards,
> 
> Christer
> 
> Sent from my Windows Phone
> From: Michael Tuexen
> Sent: ‎27/‎10/‎2014 21:55
> To: Christer Holmberg
> Cc: Harald Alvestrand; rtcweb@ietf.org
> Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
> 
> On 27 Oct 2014, at 19:41, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> > Hi,
> > 
> >>>>> Within the CLUE WG, we had a discussion regarding the following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt:
> >>>>> 
> >>>>> "The support for message interleaving as defined in
> >>>>>                [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used."
> >>>>> 
> >>>>> First, it is a little unclear what "the support SHOULD be used" means.
> >>>> My understanding is that SCTP implementations supporting the extension will use it.
> >>>> This is negotiated during the setup of the SCTP association.
> >>> If it's done on SCTP level, why do we need to talk about it in the data channel draft? 
> >>> 
> >>> Is there a reason why it is important to use it for data channels? If so, does it apply to data channels in general? 
> >> 
> >> NDATA was added in order to avoid head-of-line blocking on the transport (if I understand this correctly, until 
> >> this was added, sending a huge message would block the delivery of small messages on all channels until the huge message was fully delivered).
> >> 
> >> Unlike Michael, I see no reason to make this a SHOULD; I think it should be a MUST, and the older 
> >> implementations in browsers should just be called out as non-conformant.
> >> 
> >> That said, I think that data channels ought to interoperate successfully with implementations that don't support the 
> >> extension - but data channel implementations in WebRTC endpoints should be under a "MUST implement, MUST offer" ruleset.
> > 
> > First, keep in mind that I am NOT talking about WebRTC endpoints (which is one reason we shouldn't call it webrtc data channel to begin with, but that's another story...), but ANY type of endpoint that wants to use a data channel. 
> > 
> > Second, I am not talking about MUST support, but MUST use/offer.
> > 
> > Assume I have a CLUE endpoint, which will use a data channel ONLY to transport CLUE messages. CLUE messages aren't that hugeto begin with, and there will be no blocking of small messages on other channels - as there are no other channels.
> > 
> > So, why does the CLUE endpoint need to offer interleaving?
> As far as I know we don't have different flavours of data channels. At least right now.
> 
> Best regards
> Michael
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> >> Whether messages are interleaved or not depends on the stream scheduler. This is a sender side only decision. The receiver has to deal with it.
> >> It is not a MUST, since there are implementations now in use which don't support the extension.
> >> 
> >> Best regards
> >> Michael
> >>> 
> >>> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD use interleaving, even if the characteristics of the protocol wouldn't require it?
> >>> 
> >>> Regards,
> >>> 
> >>> Christer
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> rtcweb@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> > 
> > 
> > --
> > Surveillance is pervasive. Go Dark.
> > 
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > 
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >