Re: [rtcweb] Some language on "prioritization"

Harald Alvestrand <harald@alvestrand.no> Mon, 31 March 2014 17:48 UTC

Return-Path: <harald@alvestrand.no>
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 B38E21A6F0D for <rtcweb@ietfa.amsl.com>; Mon, 31 Mar 2014 10:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ggRWsMVyXpI for <rtcweb@ietfa.amsl.com>; Mon, 31 Mar 2014 10:48:19 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id E24C91A6F0C for <rtcweb@ietf.org>; Mon, 31 Mar 2014 10:48:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 41C237C50D5; Mon, 31 Mar 2014 19:48:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k-PGLtqvfva; Mon, 31 Mar 2014 19:48:14 +0200 (CEST)
Received: from [172.28.88.100] (unknown [74.125.122.49]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7D3517C50B1; Mon, 31 Mar 2014 19:48:13 +0200 (CEST)
Message-ID: <5339AA58.9070301@alvestrand.no>
Date: Mon, 31 Mar 2014 19:48:08 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Martin Thomson <martin.thomson@gmail.com>
References: <5339A120.3040909@alvestrand.no> <CABkgnnVUHUx+3wY3Dsi=UvNkUw_Es1apeMSonq7DtEg_3UKRNg@mail.gmail.com> <FBA84C78-FE8E-4FEF-8AD3-CAF24C57E512@lurchi.franken.de>
In-Reply-To: <FBA84C78-FE8E-4FEF-8AD3-CAF24C57E512@lurchi.franken.de>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rTCL5e8HmfDUaRqEzla1VdZuD50
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Some language on "prioritization"
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, 31 Mar 2014 17:48:20 -0000

On 03/31/2014 07:42 PM, Michael Tuexen wrote:
> On 31 Mar 2014, at 19:38, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On 31 March 2014 10:08, Harald Alvestrand <harald@alvestrand.no> wrote:
>>> -- TODO: Specify a relative priority scheme that makes sense with SCTP,
>>> with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies]
>>> specifies a priority policy, but it's about discarding packets, not
>>> deciding which packets to send first, and it also makes it impossible to
>>> specify time-bounded retransmission. --
>>
>> Why would SCTP need special treatment?  I can understand if there are
>> particular time-sensitive control messages that need to be given
>> higher priority, but this is all time-sensitive.
> A single transport connection (in this case an SCTP association) can
> only use a single DSCP. So it would be OK to use the same priority for
> all data channels, but things get complicated when when some data channels
> would have different priorities requiring different DSCP markings.

The SCTP protocol machine will, at some given moment in time, have
packets in its send buffers that belong to multiple data channels. Only
one of them can go on the wire first.

Which packet does it choose to send first, and why?

That's the question I'm looking for an answer to.

If the answer has an RFC number, chapter and section, I'd be very happy.
If it doesn't - perhaps we have to invent one.
Or say that it's "implementation dependent".