Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video.....adding admission control?

<> Wed, 31 July 2013 08:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91B5D21E8055; Wed, 31 Jul 2013 01:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.363
X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zx6gRZKc-jTg; Wed, 31 Jul 2013 01:28:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1829021F9E96; Wed, 31 Jul 2013 01:26:51 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 31 Jul 2013 10:26:50 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([]) by ([::1]) with mapi; Wed, 31 Jul 2013 10:26:49 +0200
Date: Wed, 31 Jul 2013 10:26:48 +0200
Thread-Topic: [tsvwg] Using intelligent dropping to improve video.....adding admission control?
Thread-Index: Ac5+myIfjYPS5jaWQ0qZ0s3PmyqMpwPKmREw
Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F501DF7476B5@HE111643.EMEA1.CDS.T-INTERNAL.COM>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, de-DE
Content-Language: de-DE
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 31 Jul 2013 02:00:04 -0700
Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video.....adding admission control?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2013 08:28:45 -0000


prior to setting up a new call, some kind of available bandwidth measurement or indication might be added. This isn't part of your draft. But an additional video stream may cause congestion on a bottleneck.

Measurement based admission control has been controversial so far. If used, the main point is to use a measurement class sharing the same queue as the traffic to be admitted, but having a higher drop probability.

- PCN is an option, but requires a new marking behaviour
 (threshold marker). End to end PCN as mentioned in another email.
- Using AF41 for admitted traffic and AF42 to perform measurements
  is an option to me, both should support ECN marking (AF42 seeing
  the higher marking and drop probability).

As marked packets indicating an issue can be interpreted by routers along a path, while packets dropped earlier elsewhere can't be, I prefer marking to dropping. I also think, it is easier to detect packet marks than delay variation measurements in routers, if it is about detecting congestion.

Take the above as an example. I used a separate thread as this isn't part of your draft an I accept if this shouldn't be discussed in the context of this draft. It fit's well to the RTCWeb QoS discussion though, I think.