From nobody Fri Oct 2 08:36:17 2015 Return-Path: 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 B81791B2C31; Fri, 2 Oct 2015 08:36:16 -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 5qzUL5B1I5BU; Fri, 2 Oct 2015 08:36:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0291B2C2A; Fri, 2 Oct 2015 08:36:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151002153614.5600.72208.idtracker@ietfa.amsl.com> Date: Fri, 02 Oct 2015 08:36:14 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-constraints-registry-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 02 Oct 2015 15:36:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : IANA Registry for RTCWeb Constrainable Properties Author : Daniel C. Burnett Filename : draft-ietf-rtcweb-constraints-registry-03.txt Pages : 5 Date : 2015-10-02 Abstract: Specifications in W3C's Media Capture Task Force and WebRTC Working Group have need of a registry in which to maintain a list of constrainable properties for HTML media and other constrainable objects. This document defines this registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-constraints-registry/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-constraints-registry-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-constraints-registry-03 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 Oct 6 05:47:01 2015 Return-Path: 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 7DC401B405D for ; Tue, 6 Oct 2015 05:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, 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 kXk0_iKbGonF for ; Tue, 6 Oct 2015 05:46:58 -0700 (PDT) Received: from smtp97.ord1c.emailsrvr.com (smtp97.ord1c.emailsrvr.com [108.166.43.97]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03551B4060 for ; Tue, 6 Oct 2015 05:46:58 -0700 (PDT) Received: from smtp13.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp13.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id F0AB938028F for ; Tue, 6 Oct 2015 08:46:57 -0400 (EDT) Received: by smtp13.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9EAFF38021C for ; Tue, 6 Oct 2015 08:46:57 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.32.239] ([UNAVAILABLE]. [128.107.241.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Tue, 06 Oct 2015 12:46:57 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <20151002153614.5600.72208.idtracker@ietfa.amsl.com> Date: Mon, 5 Oct 2015 15:15:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151002153614.5600.72208.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-constraints-registry-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 06 Oct 2015 12:46:59 -0000 FWIW =E2=80=A6 I reviewed this and it looks reasonable to me.=20 Cullen From nobody Tue Oct 13 15:02:21 2015 Return-Path: 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 89E7B1A1A15 for ; Tue, 13 Oct 2015 15:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJdIcZzvViiQ for ; Tue, 13 Oct 2015 15:02:18 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623B61A1A13 for ; Tue, 13 Oct 2015 15:02:18 -0700 (PDT) Received: by qkfm62 with SMTP id m62so13089555qkf.1 for ; Tue, 13 Oct 2015 15:02:17 -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=qcFrk0PX6OMiUlPLaJfv4lIF3xB5wZ8Oy5RBkm6sx/w=; b=Mt1ZxGPNFsy410wYu1VQAsxJcWBLeFwR+d8ncKumf3REOpGof8Ghcy4ke+MAcBSYu6 mEfuORLMN9Vvdcoh82OymVDzz6nJjYlkayqIuXkDqhKW/E8KaIMgzE+IGaDhMjqqWts/ /wOCv5DNG+n23jJ+N9d4WghOYEPCepMUOdf1IxI8Sx7wORSjCGmNpIFwqxE72IvNZAJJ 4pt4SoSED/IeiOsODY/fFfjUfjYIXacun8aeslBkul2qCacs4cup7oRpJmoSECXjgNVM OLHeMUpyAc2eLyyOHSUaJFt6OwA0Q5xYcYI3E/T5DsGr3xSTltexxQCYzTLmFnJ69llP +Keg== MIME-Version: 1.0 X-Received: by 10.55.50.211 with SMTP id y202mr42384203qky.86.1444773737438; Tue, 13 Oct 2015 15:02:17 -0700 (PDT) Received: by 10.55.50.2 with HTTP; Tue, 13 Oct 2015 15:02:17 -0700 (PDT) Date: Tue, 13 Oct 2015 15:02:17 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1149021e66bf830522039973 Archived-At: Subject: [rtcweb] Finalized agenda timing for IETF 94 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 13 Oct 2015 22:02:19 -0000 --001a1149021e66bf830522039973 Content-Type: text/plain; charset=UTF-8 While the IETF agenda is always subject to tweaking, it's now pretty set. Our sessions are 9:00 to 11:30, Tuesday November 3, 2015 and 15:20 to 17:20 Thursday November 5, 2015 (Despite it being Guy Fawkes day, we'd appreciate no fireworks!). Please send agenda request to the chairs or the list, thanks, Ted --001a1149021e66bf830522039973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While the IETF agenda is always subject to tweak= ing, it's now pretty set.=C2=A0 Our sessions are 9:00 to 11:30, Tuesday= November 3, 2015 and 15:20 to 17:20 =20 =20 =20 =20 Thursday November 5, 2015 (Despite it being Guy Fawkes day, = we'd appreciate no fireworks!).

Please send agen= da request to the chairs or the list,

thanks,
Ted
--001a1149021e66bf830522039973-- From nobody Thu Oct 15 11:28:01 2015 Return-Path: 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 B93591AD094 for ; Thu, 15 Oct 2015 11:28:00 -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_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 fqaQ9ld_RPgf for ; Thu, 15 Oct 2015 11:27:59 -0700 (PDT) Received: from smtp113.ord1c.emailsrvr.com (smtp113.ord1c.emailsrvr.com [108.166.43.113]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F511AD06A for ; Thu, 15 Oct 2015 11:27:59 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BC25138087B; Thu, 15 Oct 2015 14:27:58 -0400 (EDT) Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1C5063805A7; Thu, 15 Oct 2015 14:27:57 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 15 Oct 2015 18:27:58 GMT From: Cullen Jennings Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2015 12:27:56 -0600 Message-Id: <0CCCDCD4-2A7D-4CFF-9A87-6F085B7784CF@iii.ca> To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Sean Turner , Ted Hardie Subject: [rtcweb] Draft RTCWeb Agenda IETF94 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 15 Oct 2015 18:28:00 -0000 Draft agenda v1 9:00-11:30 Tuesday Morning session I JSEP, JSEP, JSEP (sung to the tune of Marcia, Marcia, Marcia) - 2 hours=20= Candidate gather procedures and privacy - 30 min=20 15:20-17:20 Thursday Afternoon session II Review MMUSIC simulcast - 30 min=20 Security drafts SecDir comments - 60 min Other agenda requests =E2=80=A6. 30 min=20 Thanks, Cullen, Ted, and Sean From nobody Thu Oct 15 13:58:06 2015 Return-Path: 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 E87841A1B64 for ; Thu, 15 Oct 2015 13:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZnyLwTgqvDY for ; Thu, 15 Oct 2015 13:58:02 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477D51A010C for ; Thu, 15 Oct 2015 13:58:02 -0700 (PDT) Received: by vkex70 with SMTP id x70so50090772vke.3 for ; Thu, 15 Oct 2015 13:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E968RiFtWBmZLn2zuCkRWYmRz4WUM+NPgSV3WI6dZxw=; b=Xp1rBjFp5OWlxn4IUb15dFEczFJ11XqplNgvm3t3V6uGxYwpSsrx+PL/EXScswEzHG ak43jMn7NTYYEu1k+IOc4N34ssfWeTLJCSpq41OFCXl29f6FGR81rj/jQArcjI5WB5h8 J2ZeoJ5E1Bk6VeOfetiCbZ0BJCdGfUCmx0jAh8uCklOBy2qxtaX2swpxo4VVRrUgfNhv eqczXGgbwfWUGq+kZFlQSBW6ZBxs4j8jRBngBSaemqZAJHwQqon/FPVa41Yt91Qzpr5C 8wzzeGBGzvhtIEe8abOmvGoswOF8+ZWW8ExA1YVNkV9wKrR3mG+obdPJLfY/qVIweDXn 9ohw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E968RiFtWBmZLn2zuCkRWYmRz4WUM+NPgSV3WI6dZxw=; b=CwnwFPI3xnrBb/4VtPE9kIh0uIS6GowqgYWYM4uG18MyGEHrl2g0TCrf1SUQr3vm5m O01WPbJYuHbKfDFT0d+6sDsVLmlsJoXtEmw6capD/jcSvo7QjDM5DBWYEUwVYPbWW9+M DcT41mesOUR3ecSDk87qeAiA5ztgWtf/I4/jJOSMs0oah95/fejy+vhvFJHCETdHgS4K Lj172eW80dbcqaIACEKqxDcr9k7WyOkCb3o0znGpbfz8K4jbfeyeSu0rzGBOLUrZhjC6 jmVisDZImbhEngaoPZl5dAuJ2rA/z42is7fQZOe8xdyXoOqbomRfb0zNoKILDIPv0T+Q GTjw== X-Gm-Message-State: ALoCoQnavoKiyYfYlc7gPmvqEbvz21IjcPACufkjvNX9UCq5w6wBELqrzEXDwNSS287RfhxdVKHz X-Received: by 10.31.185.12 with SMTP id j12mr6970638vkf.98.1444942681305; Thu, 15 Oct 2015 13:58:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.201 with HTTP; Thu, 15 Oct 2015 13:57:41 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Thu, 15 Oct 2015 13:57:41 -0700 Message-ID: To: Ted Hardie , "Mo Zanaty (mzanaty)" , Jonathan Lennox , Bernard Aboba Content-Type: multipart/alternative; boundary=001a1143a66a3dbed705222aefe0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minutes review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 15 Oct 2015 20:58:04 -0000 --001a1143a66a3dbed705222aefe0 Content-Type: text/plain; charset=UTF-8 I went back and reviewed the recording on this today. The highlights that I captured. - regarding use of session-multiplexed FEC (as opposed to ssrc-multiplexed), Jonathan mentioned that my proposal of 'must-reject' for BUNDLE is probably inappropriate, and instead should say something along the lines of 'must reject if it does not support session-multiplexed FEC'. - regarding use of protection of multiple streams with a single FEC stream, Bernard noted that for 1.0, leaving this out of scope is fine (i.e. not in rtcweb-fec), but work should still proceed to figure out a mechanism for this in the actual flexfec doc. - Mo Zanaty thought it might be possible to do something in the 1.0 timeframe to allow for multiple stream protection, such as having a single FEC flow in a m= line that protected multiple primary flows, and offered to write up a proposal. If anyone else has any notes on this, please let me know. I plan to do an update on this document to address the first two points. We can discuss the third at IETF 94 if a proposal materializes. On Thu, Aug 6, 2015 at 4:20 PM, Ted Hardie wrote: > Howdy, > > The draft minutes are available for review here: > > https://www.ietf.org/proceedings/93/minutes/minutes-93-rtcweb > > There is a section of discussion related to the FEC presentation which did > not get minuted, and if folks have notes on that, they would be appreciated > (the audio in the meetecho recording is a valuable resource, but additional > notes welcome). > > thanks, > > Ted > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1143a66a3dbed705222aefe0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I went back and reviewed the recording on this today. The = highlights that I captured.

- regarding use of session-multipl= exed FEC (as opposed to ssrc-multiplexed), Jonathan mentioned that my propo= sal of 'must-reject' for BUNDLE is probably inappropriate, and inst= ead should say something along the lines of 'must reject if it does not= support session-multiplexed FEC'.
- regarding use of protect= ion of multiple streams with a single FEC stream, Bernard noted that for 1.= 0, leaving this out of scope is fine (i.e. not in rtcweb-fec), but work sho= uld still proceed to figure out a mechanism for this in the actual flexfec = doc.
- Mo Zanaty thought it might be possible to do something in = the 1.0 timeframe to allow for multiple stream protection, such as having a= single FEC flow in a m=3D line that protected multiple primary flows, and = offered to write up a proposal.

If anyone else has= any notes on this, please let me know.

I plan to = do an update on this document to address the first two points. We can discu= ss the third at IETF 94 if a proposal materializes.

On Thu, Aug 6, 2015 at 4= :20 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Howdy,

The draft minutes are available for review here:

https://www.ietf.org/proceedings/93/minutes/minutes-93-rtcweb
There is a section of discussion related to the FEC prese= ntation which did not get minuted, and if folks have notes on that, they wo= uld be appreciated (the audio in the meetecho recording is a valuable resou= rce, but additional notes welcome).

thanks,

<= /div>
Ted

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--001a1143a66a3dbed705222aefe0-- From nobody Thu Oct 15 17:05:14 2015 Return-Path: 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 2DF561A89C7 for ; Thu, 15 Oct 2015 17:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd-eYs75jim5 for ; Thu, 15 Oct 2015 17:05:11 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D211A89F5 for ; Thu, 15 Oct 2015 17:05:09 -0700 (PDT) Received: by vkex70 with SMTP id x70so52341803vke.3 for ; Thu, 15 Oct 2015 17:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zIvvSNI5ceQrtrM5i8SuTBNanTRxzM4VqBUrfaSW7lg=; b=LIpJgm5DPh7ICqJbiDJ04axUN2u3LsnEJBF+tA6oMsIY5nEZ0bKXC6mQXfkzTbM3ZA lhPvyPUDsARruym0MAfgTs9apqN4HLZqEv5Ili/nR6JG3vB5n63G+fxXBgjEasITw02L 6xfDhL62gVqapxPA58jjSohe/5uiXiUgahGspAqMUMR8O+NG9KMjNrXSgySCCICqyVKb tJEQXANGuWNlE7PnQehqD2Y7DrMWyh2CFQ2xcnhqHppM1dmRhuwkrlPzejSQphQzpavE R09WTkBUZc6BhS3nwof7OPiINXJl12HcuptHnZ2Nf0GpBE0MU48+N35nqCsTaGNEBy6O 6oSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zIvvSNI5ceQrtrM5i8SuTBNanTRxzM4VqBUrfaSW7lg=; b=K0wF5D1AIC1NwU3UhHCwXMZ2Y4r+4/IJ87Qy8F0CejNFgZJGEqnP4210wY3HpKSg3Q +Mk+QZ0LJVXmAoep122hmwwczMYR7tn5a3uNLPuZB7Xq+xH51sSJO3OTjmUm1wHHmLgU FiX4Kt82AXlA40wbj8GPhTJSwUezHR48hShJr1SF+REABqPIqkvRQfbsbt4w0T4DLW+Y taCUwgj1EvbEEhSlgFUXes88BmUgq0Im96eVAkT7C056BRP5o2NAP0AJki9i43qHiI8o haWl5bN50IdZ5FbRGpfaOtngFnKvES/MXZfhJ4S+NAqzLgMyJfZ4T4DQIXVFKXcnAbYP Z15Q== X-Gm-Message-State: ALoCoQnajaV57D8e6D/Ef9N57KgDVUAqnLV45CdEuh5RYo9eWr1oO6vu2Je3c80nyItyCXpl2XNd X-Received: by 10.31.5.144 with SMTP id 138mr8108976vkf.62.1444953908723; Thu, 15 Oct 2015 17:05:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.201 with HTTP; Thu, 15 Oct 2015 17:04:49 -0700 (PDT) In-Reply-To: <1ccfb213094a482db2472117f6f1dffe@NASANEXM01C.na.qualcomm.com> References: <1ccfb213094a482db2472117f6f1dffe@NASANEXM01C.na.qualcomm.com> From: Justin Uberti Date: Thu, 15 Oct 2015 17:04:49 -0700 Message-ID: To: "Mandyam, Giridhar" Content-Type: multipart/alternative; boundary=001a1143ef6272a2af05222d8ce5 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , Bernard Aboba Subject: Re: [rtcweb] Minutes review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 16 Oct 2015 00:05:13 -0000 --001a1143ef6272a2af05222d8ce5 Content-Type: text/plain; charset=UTF-8 The real complication here is how we signal the FEC information, e.g. what m= section does it get attached to, and what happens if that m= section happens to disappear later. My expectation is that we will have to essentially define a way for a m= section to have no primary stream but only a repair flow, and then that repair flow can repair any SSRC in the same RTP session using flexfec. If we are careful, we could do this without exploding unified plan or freaking out existing WebRTC endpoints. On Thu, Oct 15, 2015 at 3:36 PM, Mandyam, Giridhar wrote: > Regarding the 3rd item, I intended > https://tools.ietf.org/html/draft-mandyam-rtcweb-fecframebundledssrc-00 > to be the starting point for this. I think we need to resolve whether such > a proposal would be better handled in the context of FLEX FEC ( > https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-00 ). > I believe Mo mentioned this possibility after my presentation, but he can > confirm. > > > > BTW, it looks like FLEX FEC has expired (but it also looks like > draft-ietf-rtcweb-fec has expired as well). > > > > -Giri > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Justin > Uberti > *Sent:* Thursday, October 15, 2015 1:58 PM > *To:* Ted Hardie; Mo Zanaty (mzanaty); Jonathan Lennox; Bernard Aboba > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Minutes review > > > > I went back and reviewed the recording on this today. The highlights that > I captured. > > > > - regarding use of session-multiplexed FEC (as opposed to > ssrc-multiplexed), Jonathan mentioned that my proposal of 'must-reject' for > BUNDLE is probably inappropriate, and instead should say something along > the lines of 'must reject if it does not support session-multiplexed FEC'. > > - regarding use of protection of multiple streams with a single FEC > stream, Bernard noted that for 1.0, leaving this out of scope is fine (i.e. > not in rtcweb-fec), but work should still proceed to figure out a mechanism > for this in the actual flexfec doc. > > - Mo Zanaty thought it might be possible to do something in the 1.0 > timeframe to allow for multiple stream protection, such as having a single > FEC flow in a m= line that protected multiple primary flows, and offered to > write up a proposal. > > > > If anyone else has any notes on this, please let me know. > > > > I plan to do an update on this document to address the first two points. > We can discuss the third at IETF 94 if a proposal materializes. > > > > On Thu, Aug 6, 2015 at 4:20 PM, Ted Hardie wrote: > > Howdy, > > The draft minutes are available for review here: > > https://www.ietf.org/proceedings/93/minutes/minutes-93-rtcweb > > There is a section of discussion related to the FEC presentation which did > not get minuted, and if folks have notes on that, they would be appreciated > (the audio in the meetecho recording is a valuable resource, but additional > notes welcome). > > thanks, > > Ted > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --001a1143ef6272a2af05222d8ce5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The real complication here is how we signal the FEC inform= ation, e.g. what m=3D section does it get attached to, and what happens if = that m=3D section happens to disappear later.

My expecta= tion is that we will have to essentially define a way for a m=3D section to= have no primary stream but only a repair flow, and then that repair flow c= an repair any SSRC in the same RTP session using flexfec. If we are careful= , we could do this without exploding unified plan or freaking out existing = WebRTC endpoints.

On Thu, Oct 15, 2015 at 3:36 PM, Mandyam, Giridhar <man= dyam@qti.qualcomm.com> wrote:

Regarding the 3rd item, I = intended https://tools.ietf.org/html/draft-mandyam-rtcweb-fecframebundledssrc-00= to be the starting point for this.=C2=A0 I think we need to resolve whethe= r such a proposal would be better handled in the context of FLEX FEC (https://tools.ietf.org/html/draft-ietf-payload-flexible= -fec-scheme-00 ).=C2=A0 I believe Mo mentioned this possibility after my presentation, bu= t he can confirm.

=C2=A0

BTW, it looks like FLEX FEC has expir= ed (but it also looks like draft-ietf-rtcweb-fec has expired as well).

=C2=A0

-Giri

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, October 15, 2015 1:58 PM
To: Ted Hardie; Mo Zanaty (mzanaty); Jonathan Lennox; Bernard Aboba<= br> Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Minutes review

=C2=A0

I went back and reviewed the recording on this today= . The highlights that I captured.

=C2=A0

- regarding use of session-multiplexed FEC (as oppos= ed to ssrc-multiplexed), Jonathan mentioned that my proposal of 'must-r= eject' for BUNDLE is probably inappropriate, and instead should say som= ething along the lines of 'must reject if it does not support session-multiplexed FEC'.

- regarding use of protection of multiple streams wi= th a single FEC stream, Bernard noted that for 1.0, leaving this out of sco= pe is fine (i.e. not in rtcweb-fec), but work should still proceed to figur= e out a mechanism for this in the actual flexfec doc.

- Mo Zanaty thought it might be possible to do somet= hing in the 1.0 timeframe to allow for multiple stream protection, such as = having a single FEC flow in a m=3D line that protected multiple primary flo= ws, and offered to write up a proposal.

=C2=A0

If anyone else has any notes on this, please let me = know.

=C2=A0

I plan to do an update on this document to address t= he first two points. We can discuss the third at IETF 94 if a proposal mate= rializes.

=C2=A0

On Thu, Aug 6, 2015 at 4:20 PM, Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

Howdy,

The draft minutes are available for re= view here:

https://www.ietf.org/proceedings/93/minutes/minutes-93-rtc= web

There is a section of discussion relat= ed to the FEC presentation which did not get minuted, and if folks have not= es on that, they would be appreciated (the audio in the meetecho recording is a valuable resource, but additional notes wel= come).

thanks,

Ted


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

=C2=A0


--001a1143ef6272a2af05222d8ce5-- From nobody Sat Oct 17 20:37:31 2015 Return-Path: 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 3379F1A889C for ; Sat, 17 Oct 2015 20:37:30 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_HEX=1.122] 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 4W3FwdZErjjG for ; Sat, 17 Oct 2015 20:37:28 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457FC1A889F for ; Sat, 17 Oct 2015 20:37:28 -0700 (PDT) Received: by oiad129 with SMTP id d129so20560482oia.0 for ; Sat, 17 Oct 2015 20:37:27 -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=CnVLBdpN9SAkEtEIHXQILcaoJ2fOcBA+pVVBBTma+KQ=; b=kzl/lG0DqcgfCkqv15vI1NkEj4XTc0iVwg2yySNvj37386JBtbgK3NhZaj791d5nAJ 6UWUjZ6WrQk4oo0TgRcmSijW2IZgo8ebuH4v0oxqTlw5QymhbvJVXBIkDWHNOGoqFAKn 3Bbe30fTkhU0iEIqz/2QPwrd0vsgzDuScSkTAq1ValbWAbIzkAOKYBb37dpwfAko9REr TwmwSPTc9Tb83MH2Z5izbCp1GbP3i5CPeYnwayzkI1EukDZzQGslxq6wYBed2a6dnbXN ioRov29hNHXKOIMHx6nHqfaVuzNTBqh/S3hFsx1oYSNg6VOAwBq8eo8y26/g3Haovwjw lDwg== MIME-Version: 1.0 X-Received: by 10.202.73.73 with SMTP id w70mr5315794oia.94.1445139447740; Sat, 17 Oct 2015 20:37:27 -0700 (PDT) Received: by 10.202.202.216 with HTTP; Sat, 17 Oct 2015 20:37:27 -0700 (PDT) Date: Sun, 18 Oct 2015 11:37:27 +0800 Message-ID: From: Alexandre GOUAILLARD To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113dec466f00f7052258bffc Archived-At: Subject: [rtcweb] special webrtc meet up during IETF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 18 Oct 2015 03:37:30 -0000 --001a113dec466f00f7052258bffc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, NTT and a few other Japanese companies (infocomm, ..) have been the sponsors of a growing and fascinatingly creative webRTC dev community in Japan. This year in February, their 2 days webrtc-Japan conference was a great success and a place to witness not only the solutions from the big companies, but also the demos and lighting talks from many local hackers (ever herd of the tchin~~ machine?). The next one will be in Feb 2016 and the speaker/sponsor list is still open ;-) However, the great work of the Japanese dev community is usually less visible form the US, mainly because of a language barrier. The conferences and experts of the webrtc also rarely happen to be in Japan all together. To take the opportunity of having both W3C and IETF in Japan this fall, not one but two meet ups have been organized: - a w3c dev meetup in sapporo (here ) - a Tokyo webrtc meet up close to the IETF meeting location (here ) The tokyo meet up organizers will start with an intro of the tokyo webrtc dev scene, and most of the following talks are made either by japanese, or by companies that just joined w3c/ietf and will provide feedback about their use for the first time. That should be interesting for everyone, A map to guide you from the IETF location to the meeting is provided (map ), and the Japanese sessions will be translated in english. I hope to have made you curious/excited/interested enough to see you all at he meet up. Do not hesitate to forward that e-mail to other groups's members that could be interested in joining. Alex, for yoshimasa isake, and yusuke naka, organizers. --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- President - CoSMo Software Consulting, Singapore ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --001a113dec466f00f7052258bffc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

NTT and a few othe= r Japanese companies (infocomm, ..) have been the sponsors of a growing and= fascinatingly creative webRTC dev community in Japan.=C2=A0

=
This year in February, their 2 days webrtc-Japan conference was a great success and a plac= e to witness not only the solutions from the big companies, but also the de= mos and lighting talks from many local hackers (ever herd of the tchin~~ ma= chine?). The next one will be in= Feb 2016 and the speaker/sponsor list is still open ;-)

However, the great work of the Japanese dev community is usually les= s visible form the US, mainly because of a language barrier. The conference= s and experts of the webrtc also rarely happen to be in Japan all together.=

To take the opportunity of having both W3C and IE= TF in Japan this fall, not one but two meet ups have been organized:
<= div>- a w3c dev meetup in sapporo (here)
- a Tokyo webrtc meet up clo= se to the IETF meeting location (here)

The toky= o meet up organizers will start with an intro of the tokyo webrtc dev scene= , and most of the following talks are made either by japanese, or by compan= ies that just joined w3c/ietf and will provide feedback about their use for= the first time. That should be interesting for everyone,=C2=A0
<= br>
A map to guide you from the IETF location to the meeting is p= rovided (map), and the Japanese sessions will be translated in englis= h.

I hope to have made you curious/excited/interes= ted enough to see you all at he meet up. Do not hesitate to forward that e-= mail to other groups's members that could be interested in joining.

Alex, for yoshimasa isake, and yusuke naka, organizer= s.

--
Alex. Gouaillard, PhD, PhD, MBA
--------------= ----------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
----------= --------------------------------------------------------------------------<= /div>

--001a113dec466f00f7052258bffc-- From nobody Sun Oct 18 21:27:26 2015 Return-Path: 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 694C11A1A6F; Sun, 18 Oct 2015 21:27:23 -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 QpcFz9CtZco8; Sun, 18 Oct 2015 21:27:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC0C1A1A4F; Sun, 18 Oct 2015 21:27:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019042722.3070.80202.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 21:27:22 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 19 Oct 2015 04:27:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-02.txt Pages : 8 Date : 2015-10-18 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-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 Sun Oct 18 22:18:19 2015 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 496761A0098; Sun, 18 Oct 2015 22:18:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019051816.7520.46968.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 22:18:16 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 19 Oct 2015 05:18:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-12.txt Pages : 80 Date : 2015-10-18 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-12 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 Mon Oct 19 12:48:21 2015 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BFC1A8AC2; Mon, 19 Oct 2015 12:48:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019194803.19372.81732.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 12:48:03 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 19 Oct 2015 19:48:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-10.txt Pages : 16 Date : 2015-10-19 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-10 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 Mon Oct 19 15:58:17 2015 Return-Path: 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 12E5C1B2E53; Mon, 19 Oct 2015 15:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 6glsQj2paUuN; Mon, 19 Oct 2015 15:58:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 7F65B1B2E52; Mon, 19 Oct 2015 15:57:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BDC1A187E28; Mon, 19 Oct 2015 15:57:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151019225727.BDC1A187E28@rfc-editor.org> Date: Mon, 19 Oct 2015 15:57:27 -0700 (PDT) Archived-At: Cc: rtcweb@ietf.org, rfc-editor@rfc-editor.org Subject: [rtcweb] RFC 7675 on Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 19 Oct 2015 22:58:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7675 Title: Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness Author: M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson Status: Standards Track Stream: IETF Date: October 2015 Mailbox: muthu.arul@gmail.com, dwing@cisco.com, rmohanr@cisco.com, tireddy@cisco.com, martin.thomson@gmail.com Pages: 10 Characters: 22346 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rtcweb-stun-consent-freshness-16.txt URL: https://www.rfc-editor.org/info/rfc7675 DOI: http://dx.doi.org/10.17487/RFC7675 To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. This document is a product of the Real-Time Communication in WEB-browsers Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Oct 19 17:03:29 2015 Return-Path: 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 C1DC81AC3CE for ; Mon, 19 Oct 2015 17:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br_9KicFKrlp for ; Mon, 19 Oct 2015 17:03:26 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82EB21B2F09 for ; Mon, 19 Oct 2015 17:03:26 -0700 (PDT) Received: by vkat63 with SMTP id t63so758512vka.1 for ; Mon, 19 Oct 2015 17:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=wx3nC4xSzbsEROnOo4emp/yd/8FMNt9fBMOVvCVOwMA=; b=cJD0OV6+rPXutjWBZwwedUP/i1+tGZsn8UFUOI3kI2J8U5g3zdqj4xRtMhlqrwF7BQ vfgbk8jw0eV9sE8Jcb0ayOTdP7wBa+2QNTpiVTe/4tOjVLPZjDX/VLd/YGJSskL3wS3S xLYMtFBQraM8I824VphfsYTd/olBAeGfMHOCmSub8JQbdi3m5fP4o/FZBniONBjqUh3c aDN0+rKUaacxk8QFV975twPURLRt+530Jo+m4RJ3dCgW5Xv89Qy4zWuNiS/HhAqOJ29H 8VPLWDP8hqRVAVUx7FeGUkbmMk1lOwK44o4x7s9am2tl054BtKDFisJZIDYjUt624z61 8+/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=wx3nC4xSzbsEROnOo4emp/yd/8FMNt9fBMOVvCVOwMA=; b=i61KWFYyvkoeiMLgSoPOMphvbr8J4yueisCt9odu8e+Ry16vUUh81SS8vxB131Gxm+ k3DDwBxB2FaTIpZvB+2tkzFxssfXApVnutu3hq7lngkNMSgISx1V2rvnc0n9l3BE2vSs Uy/7DMqdOCXHBkKkP6xi+NaAwSsZcDfzGhFoICJucoRqocn2HqvhuIwX1WJisupAKKiy rZPGj4Tgfwzsg9qwVooCXM4Fl+Qfp+hMgwpOVfo9WZPQECY5/oKihcpmIpRA9t79T3hu ctiFdFU0C4ti+r5n1LIn3NrEt2lhgH1eW8virlX+DiHXUIK+RnmEDuXBrxeQo8YBJxZG pT+A== X-Gm-Message-State: ALoCoQlCF4KflaRzG9BH8iTdPsk4XOLiPb86QwZkFOlqB3BakvM/KI3G4KcfFBkQvyZDAef1lBT+ X-Received: by 10.31.6.20 with SMTP id 20mr117759vkg.158.1445299405564; Mon, 19 Oct 2015 17:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.201 with HTTP; Mon, 19 Oct 2015 17:03:06 -0700 (PDT) In-Reply-To: References: <20151019235727.20397.15249.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 19 Oct 2015 17:03:06 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1143d7caa9ef0705227dfdb9 Archived-At: Subject: [rtcweb] Fwd: New Version Notification for draft-shieh-rtcweb-ip-handling-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 20 Oct 2015 00:03:27 -0000 --001a1143d7caa9ef0705227dfdb9 Content-Type: text/plain; charset=UTF-8 FYI - A rough initial attempt to document the recommended IP handling logic for WebRTC apps. A new version of I-D, draft-shieh-rtcweb-ip-handling-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Name: draft-shieh-rtcweb-ip-handling Revision: 00 Title: WebRTC IP Address Handling Recommendations Document date: 2015-10-19 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-shieh-rtcweb-ip-handling-00.txt Status: https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling/ Htmlized: https://tools.ietf.org/html/draft-shieh-rtcweb-ip-handling-00 Abstract: This document provides best practices for how IP addresses should be handled by WebRTC applications. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a1143d7caa9ef0705227dfdb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI - A rough initial attempt to document the recommended= IP handling logic for WebRTC apps.

A new version of I-D, draft-shieh-rtcweb-ip-handling-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-shieh-rtcweb-ip-handlin= g
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WebRTC IP Address Handling Recomme= ndations
Document date:=C2=A0 2015-10-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-shieh-rtcweb= -ip-handling-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-shieh-rtcweb-ip-handling-00


Abstract:
=C2=A0 =C2=A0This document provides best practices for how IP addresses sho= uld be
=C2=A0 =C2=A0handled by WebRTC applications.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a1143d7caa9ef0705227dfdb9-- From nobody Wed Oct 21 07:18:11 2015 Return-Path: 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 4ED7D1A88C6 for ; Wed, 21 Oct 2015 07:18:10 -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 A8tRUTW5cLQ2 for ; Wed, 21 Oct 2015 07:18:09 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id E0CD11A1B60 for ; Wed, 21 Oct 2015 07:18:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2843E7C0AF4 for ; Wed, 21 Oct 2015 16:18:08 +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 uRaR08PhJLBi for ; Wed, 21 Oct 2015 16:18:07 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:2cac:97a8:89fe:113e] (unknown [IPv6:2001:470:de0a:1:2cac:97a8:89fe:113e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4EC6E7C0AF0 for ; Wed, 21 Oct 2015 16:18:07 +0200 (CEST) References: <20151019194803.19372.9807.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" From: Harald Alvestrand X-Forwarded-Message-Id: <20151019194803.19372.9807.idtracker@ietfa.amsl.com> Message-ID: <56279E9E.1080802@alvestrand.no> Date: Wed, 21 Oct 2015 16:18:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151019194803.19372.9807.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-transports-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2015 14:18:10 -0000 New version published - only significant change is a re-layout of the "prioritization" chapter. There should be no change in technical content. Harald -------- Videresendt melding -------- Emne: New Version Notification for draft-ietf-rtcweb-transports-10.txt Dato: Mon, 19 Oct 2015 12:48:03 -0700 Fra: internet-drafts@ietf.org Til: Harald Alvestrand , Harald T. Alvestrand A new version of I-D, draft-ietf-rtcweb-transports-10.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Name: draft-ietf-rtcweb-transports Revision: 10 Title: Transports for WebRTC Document date: 2015-10-19 Group: rtcweb Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-rtcweb-transports-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ Htmlized: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-10 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Oct 21 08:51:42 2015 Return-Path: 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 D30201AD0BB; Wed, 21 Oct 2015 08:51:40 -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 bycEVOQBBNTi; Wed, 21 Oct 2015 08:51:38 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8CF1AD0B9; Wed, 21 Oct 2015 08:51:38 -0700 (PDT) Received: by obctp1 with SMTP id tp1so17992782obc.2; Wed, 21 Oct 2015 08:51:38 -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 :content-transfer-encoding; bh=RdRPJehdyTlUpA6l0gPiD0oeXh7TftgzvdJvbMrTUoY=; b=F+Say6ZcI9a0hPSmiOXaext3FdsbbRWdgULw6mzfghY53hJ6V7dCi8tvvaUpypa/Qp j7WI7dXx386BVL8hFBLzf3Yqy4I3yBcGXFsM8U9wb+oviopQSJtJJTk2XNr4qmftd0Gg s1hUM/0Jc20OYwBSmc6MLRS1IWZJ7NzS4nqOK2CdU6zBrZvAFT+k7BhxmSPf2b2Ha1vd DlzK/QhF0WofE+rlq/FYKta/QYugC08JY4bH+IIoXCalHRm9VfdNbnuictVp7p+F4Dcl xSZ2k6/J3wGQYFCx3OKqxho7/duq4+2Mum4FWwDfSHFjcpp0YpRdRi4nqJBmiCCIUKL3 Mn+g== MIME-Version: 1.0 X-Received: by 10.182.18.103 with SMTP id v7mr6765602obd.73.1445442697996; Wed, 21 Oct 2015 08:51:37 -0700 (PDT) Received: by 10.202.108.212 with HTTP; Wed, 21 Oct 2015 08:51:37 -0700 (PDT) Date: Wed, 21 Oct 2015 17:51:37 +0200 Message-ID: From: Dave Taht To: "rtcweb@ietf.org" , "rmcat@ietf.org" , "aqm@ietf.org" , cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2015 15:51:41 -0000 I unsubscribed from rmcat and rtcweb groups a while back after I got overloaded, and appear.in started working so well, (for both ipv6 and ipv4! I use it all day long now!), to focus on finishing up the new "cake" qdisc/shaper/aqm/QoS system, among other things. http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical Cake is now entering the testlab, and among other things, it has support for the diffserv markings discussed in the related, now concluded dart wg, but in ways somewhat different from that imagined there. We have not got any good code in our testbeds yet to test videoconferencing behavior, and we could use some, although it does look like we can drive firefox with some remote control stuff with a fixed video playback now.... Five questions: 1) Has anyone implemented or tested putting voice and video on two different 5-tuples in any running code out there? 2) How about diffserv markings in general? Do any browsers or webrtc capable software support what was discussed way back when? 3) Were diffserv marking changes eventually allowed on the same 5-tuple? 4) Did the ECN support that was originally in one draft or another ever make it into any running code? (yea, apple plans to turn on ecn universally in their next OS!) 5) What else did I miss in the past year I should know about? Feel free to contact me off list if these have already been discussed. I have totally lost track of the relevant drafts. Sincerely, Dave T=C3=A4ht I just lost five years of my life to making the edge of the internet, and, wifi better. And, now... the FCC wants to make my work illegal for ordinary people to install. https://www.gofundme.com/savewifi From nobody Wed Oct 21 09:11:03 2015 Return-Path: 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 462781A92DD; Wed, 21 Oct 2015 09:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 C9XqxtLzoDUa; Wed, 21 Oct 2015 09:10:58 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 528351B29E3; Wed, 21 Oct 2015 09:10:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 393E47C0B0B; Wed, 21 Oct 2015 18:10:57 +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 03NT44YPHYyX; Wed, 21 Oct 2015 18:10:54 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:2cac:97a8:89fe:113e] (unknown [IPv6:2001:470:de0a:1:2cac:97a8:89fe:113e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 17AD77C0B06; Wed, 21 Oct 2015 18:10:54 +0200 (CEST) To: Dave Taht , "rtcweb@ietf.org" , "rmcat@ietf.org" , "aqm@ietf.org" , cake@lists.bufferbloat.net References: From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <5627B90D.8070106@alvestrand.no> Date: Wed, 21 Oct 2015 18:10:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2015 16:11:01 -0000 Den 21. okt. 2015 17:51, skrev Dave Taht: > I unsubscribed from rmcat and rtcweb groups a while back after I got > overloaded, and appear.in started working so well, (for both ipv6 and > ipv4! I use it all day long now!), to focus on finishing up the new > "cake" qdisc/shaper/aqm/QoS system, among other things. > > http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical > > Cake is now entering the testlab, and among other things, it has > support for the diffserv markings discussed in the related, now > concluded dart wg, but in ways somewhat different from that imagined > there. We have not got any good code in our testbeds yet to test > videoconferencing behavior, and we could use some, although it does > look like we can drive firefox with some remote control stuff with a > fixed video playback now.... > > Five questions: > > 1) Has anyone implemented or tested putting voice and video on two > different 5-tuples in any running code out there? All VC systems I know of except WebRTC-based ones do it, AFAIK. It's putting them on the same that's unusual. > 2) How about diffserv markings in general? Do any browsers or webrtc > capable software support what was discussed way back when? I know Hangouts did something like that internally, on the controlled network. But not according to spec. > 3) Were diffserv marking changes eventually allowed on the same 5-tuple? Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table. > 4) Did the ECN support that was originally in one draft or another > ever make it into any running code? I don't know. I think we lost it from the docs. > (yea, apple plans to turn on ecn universally in their next OS!) > > 5) What else did I miss in the past year I should know about? For TCP and SCTP congestion controllers, we're back to one DSCP marking per flow, and resetting the congestion control state if DSCP marking changes. > > Feel free to contact me off list if these have already been discussed. > I have totally lost track of the relevant drafts. They're not finished still :-) > > Sincerely, > > Dave Täht > I just lost five years of my life to making the edge > of the internet, and, wifi better. > And, now... the FCC wants to make my work illegal > for ordinary people to install. > https://www.gofundme.com/savewifi > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Oct 22 00:49:35 2015 Return-Path: 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 E922E1B2B1C; Thu, 22 Oct 2015 00:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 U2aXfOvvnVhn; Thu, 22 Oct 2015 00:49:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5EF1B2B1A; Thu, 22 Oct 2015 00:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35360; q=dns/txt; s=iport; t=1445500172; x=1446709772; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MrfXA4FWcPQsgu8ff/zp9ykdv/4yoD6alkLNpyO+aw0=; b=OsWFmdq4CGBBuFRN5WBtRWZqudAqB4rpC3degt4lMD4uIvS43XjwUQP1 muFD+UBcwbTwSylZJsiPTWyDpc9iVakmaXV1o/OJqmBG8JoeGycawhxh3 MJ+/HgAJzB8WX9AKSduQp22SZC/wt6FG3gZP2A7KmI1rZnitCEF78PENo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBQCtlChW/4MNJK1YBoJpTVRvBr4igVYDFwEJgkOCb0oCHIEeOhIBAQEBAQEBgQqELwEBBAEBASArIAUGEAIBCDgBBgMCAgIlCxQRAgQOBRkEBIgPDbFSkwIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhneCEIJuhEo/BAcJgmAxgRQFlioBhRiIBYIgmgMBKAM4ghEdgVVyhT2BBgEBAQ X-IronPort-AV: E=Sophos; i="5.20,181,1444694400"; d="scan'208,217"; a="43727555" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Oct 2015 07:49:17 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9M7nG3d014350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 07:49:16 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 02:48:56 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 02:48:56 -0500 From: "Pal Martinsen (palmarti)" To: Dave Taht Thread-Topic: [rtcweb] Catching up on diffserv markings Thread-Index: AQHRDBhhKLAKR0e6806JMGmCoYGOXJ52cb+AgAEGK4A= Date: Thu, 22 Oct 2015 07:48:56 +0000 Message-ID: <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> References: <5627B90D.8070106@alvestrand.no> In-Reply-To: <5627B90D.8070106@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.64.11] Content-Type: multipart/alternative; boundary="_000_43B59C2F4B644318833904903AF2A6ACciscocom_" MIME-Version: 1.0 Archived-At: Cc: "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , "aqm@ietf.org" Subject: Re: [rtcweb] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 22 Oct 2015 07:49:34 -0000 --_000_43B59C2F4B644318833904903AF2A6ACciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAyMSBPY3QgMjAxNSwgYXQgMTg6MTAsIEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2 ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+PiB3cm90ZToNCg0KRGVuIDIx LiBva3QuIDIwMTUgMTc6NTEsIHNrcmV2IERhdmUgVGFodDoNCkkgdW5zdWJzY3JpYmVkIGZyb20g cm1jYXQgYW5kIHJ0Y3dlYiBncm91cHMgYSB3aGlsZSBiYWNrIGFmdGVyIEkgZ290DQpvdmVybG9h ZGVkLCBhbmQgYXBwZWFyLmluIHN0YXJ0ZWQgd29ya2luZyBzbyB3ZWxsLCAoZm9yIGJvdGggaXB2 NiBhbmQNCmlwdjQhIEkgdXNlIGl0IGFsbCBkYXkgbG9uZyBub3chKSwgdG8gZm9jdXMgb24gZmlu aXNoaW5nIHVwIHRoZSBuZXcNCiJjYWtlIiBxZGlzYy9zaGFwZXIvYXFtL1FvUyBzeXN0ZW0sIGFt b25nIG90aGVyIHRoaW5ncy4NCg0KaHR0cDovL3d3dy5idWZmZXJibG9hdC5uZXQvcHJvamVjdHMv Y29kZWwvd2lraS9DYWtlVGVjaG5pY2FsDQoNCkNha2UgaXMgbm93IGVudGVyaW5nIHRoZSB0ZXN0 bGFiLCBhbmQgYW1vbmcgb3RoZXIgdGhpbmdzLCBpdCBoYXMNCnN1cHBvcnQgZm9yIHRoZSBkaWZm c2VydiBtYXJraW5ncyBkaXNjdXNzZWQgaW4gdGhlIHJlbGF0ZWQsIG5vdw0KY29uY2x1ZGVkIGRh cnQgd2csIGJ1dCBpbiB3YXlzIHNvbWV3aGF0IGRpZmZlcmVudCBmcm9tIHRoYXQgaW1hZ2luZWQN CnRoZXJlLiBXZSBoYXZlIG5vdCBnb3QgYW55IGdvb2QgY29kZSBpbiBvdXIgdGVzdGJlZHMgeWV0 IHRvIHRlc3QNCnZpZGVvY29uZmVyZW5jaW5nIGJlaGF2aW9yLCBhbmQgd2UgY291bGQgdXNlIHNv bWUsIGFsdGhvdWdoIGl0IGRvZXMNCmxvb2sgbGlrZSB3ZSBjYW4gZHJpdmUgZmlyZWZveCB3aXRo IHNvbWUgcmVtb3RlIGNvbnRyb2wgc3R1ZmYgd2l0aCBhDQpmaXhlZCB2aWRlbyBwbGF5YmFjayBu b3cuLi4uDQoNCkZpdmUgcXVlc3Rpb25zOg0KDQoxKSBIYXMgYW55b25lIGltcGxlbWVudGVkIG9y IHRlc3RlZCBwdXR0aW5nIHZvaWNlIGFuZCB2aWRlbyBvbiB0d28NCmRpZmZlcmVudCA1LXR1cGxl cyBpbiBhbnkgcnVubmluZyBjb2RlIG91dCB0aGVyZT8NCg0KQWxsIFZDIHN5c3RlbXMgSSBrbm93 IG9mIGV4Y2VwdCBXZWJSVEMtYmFzZWQgb25lcyBkbyBpdCwgQUZBSUsuDQpJdOKAmXMgcHV0dGlu ZyB0aGVtIG9uIHRoZSBzYW1lIHRoYXQncyB1bnVzdWFsLg0KDQpUaGF0IHNvdW5kcyBsaWtlIHRo ZSB3b3JsZCBJIGFtIGxpdmluZyBpbiBhcyB3ZWxsLg0KDQoNCjIpIEhvdyBhYm91dCBkaWZmc2Vy diBtYXJraW5ncyBpbiBnZW5lcmFsPyBEbyBhbnkgYnJvd3NlcnMgb3Igd2VicnRjDQpjYXBhYmxl IHNvZnR3YXJlIHN1cHBvcnQgd2hhdCB3YXMgZGlzY3Vzc2VkIHdheSBiYWNrIHdoZW4/DQoNCkkg a25vdyBIYW5nb3V0cyBkaWQgc29tZXRoaW5nIGxpa2UgdGhhdCBpbnRlcm5hbGx5LCBvbiB0aGUg Y29udHJvbGxlZA0KbmV0d29yay4gQnV0IG5vdCBhY2NvcmRpbmcgdG8gc3BlYy4NCg0KMykgV2Vy ZSBkaWZmc2VydiBtYXJraW5nIGNoYW5nZXMgZXZlbnR1YWxseSBhbGxvd2VkIG9uIHRoZSBzYW1l IDUtdHVwbGU/DQoNClllcywgd2l0aCBjYXZlYXRzLiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1x b3MgaGFzIHRoZSB0YWJsZS4NCg0KNCkgRGlkIHRoZSBFQ04gc3VwcG9ydCB0aGF0IHdhcyBvcmln aW5hbGx5IGluIG9uZSBkcmFmdCBvciBhbm90aGVyDQpldmVyIG1ha2UgaXQgaW50byBhbnkgcnVu bmluZyBjb2RlPw0KDQpJIGRvbid0IGtub3cuIEkgdGhpbmsgd2UgbG9zdCBpdCBmcm9tIHRoZSBk b2NzLg0KDQooeWVhLCBhcHBsZSBwbGFucyB0byB0dXJuIG9uIGVjbiB1bml2ZXJzYWxseSBpbiB0 aGVpciBuZXh0IE9TISkNCg0KU28gaG93IHdvdWxkIEVDTiB3b3JrIG9uIFVEUD8gSSBkbyBub3Qg dGhpbmsgdGhlIG5lY2Vzc2FyeSBiaXRzIGZyb20gdGhlIElQIGhlYWRlciBhcmUgYXZhaWxhYmxl IGZvciB0aGUgYXBwbGljYXRpb24gdG8gZG8gYW55dGhpbmcuIEkgZG8gdGhpbmsgTGludXggc3Vw cG9ydHMgdGhpcywgaGF2ZSBub3QgdGVzdGVkLg0KDQpBbmQgd2hhdCBhYm91dCB0aGUgbmV0d29y aywgd291bGQgaXQgc3VwcG9ydCBVRFAgd2hlbiBzZXR0aW5nIHRoZSBFQ04gYml0cz8gUHJvYmFi bHkgYSBjb25maWd1cmF0aW9uIHJlbGF0ZWQgcHJvYmxlbSBpZiBub3Qgc3VwcG9ydGVkLg0KDQo1 KSAgV2hhdCBlbHNlIGRpZCBJIG1pc3MgaW4gdGhlIHBhc3QgeWVhciBJIHNob3VsZCBrbm93IGFi b3V0Pw0KDQpGb3IgVENQIGFuZCBTQ1RQIGNvbmdlc3Rpb24gY29udHJvbGxlcnMsIHdlJ3JlIGJh Y2sgdG8gb25lIERTQ1AgbWFya2luZw0KcGVyIGZsb3csIGFuZCByZXNldHRpbmcgdGhlIGNvbmdl c3Rpb24gY29udHJvbCBzdGF0ZSBpZiBEU0NQIG1hcmtpbmcNCmNoYW5nZXMuDQoNCg0KVGhlcmUg aXMgYSBuZXcgSUNFIHdnLiBJdCB3YXMgY3JlYXRlZCBzbyDigJxuZXR3b3JrIHBlb3BsZeKAnSBj b3VsZCBwYXJ0aWNpcGF0ZSB3aXRob3V0IHRoZSBvdmVyaGVhZCBvZiBsaXN0ZW5pbmcgdG8gdGhl IFNEUCByZWxhdGVkIGRpc2N1c3Npb25zLiAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93 Zy9pY2UvY2hhcnRlci8pDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KRmVlbCBmcmVlIHRvIGNvbnRh Y3QgbWUgb2ZmIGxpc3QgaWYgdGhlc2UgaGF2ZSBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkLg0KSSBo YXZlIHRvdGFsbHkgbG9zdCB0cmFjayBvZiB0aGUgcmVsZXZhbnQgZHJhZnRzLg0KDQpUaGV5J3Jl IG5vdCBmaW5pc2hlZCBzdGlsbCA6LSkNCg0KDQpTaW5jZXJlbHksDQoNCkRhdmUgVMOkaHQNCkkg anVzdCBsb3N0IGZpdmUgeWVhcnMgb2YgbXkgbGlmZSB0byBtYWtpbmcgdGhlIGVkZ2UNCm9mIHRo ZSBpbnRlcm5ldCwgYW5kLCB3aWZpIGJldHRlci4NCkFuZCwgbm93Li4uIHRoZSBGQ0Mgd2FudHMg dG8gbWFrZSBteSB3b3JrIGlsbGVnYWwNCmZvciBvcmRpbmFyeSBwZW9wbGUgdG8gaW5zdGFsbC4N Cmh0dHBzOi8vd3d3LmdvZnVuZG1lLmNvbS9zYXZld2lmaQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2Vi QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3 ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_43B59C2F4B644318833904903AF2A6ACciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <029B1644B9945D44AC500E5FDE060086@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyMSBP Y3QgMjAxNSwgYXQgMTg6MTAsIEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86 aGFyYWxkQGFsdmVzdHJhbmQubm8iIGNsYXNzPSIiPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RGVuDQogMjEuIG9r dC4gMjAxNSAxNzo1MSwgc2tyZXYgRGF2ZSBUYWh0Ojwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQpJIHVuc3Vic2NyaWJlZCBmcm9t IHJtY2F0IGFuZCBydGN3ZWIgZ3JvdXBzIGEgd2hpbGUgYmFjayBhZnRlciBJIGdvdDxiciBjbGFz cz0iIj4NCm92ZXJsb2FkZWQsIGFuZCBhcHBlYXIuaW4gc3RhcnRlZCB3b3JraW5nIHNvIHdlbGws IChmb3IgYm90aCBpcHY2IGFuZDxiciBjbGFzcz0iIj4NCmlwdjQhIEkgdXNlIGl0IGFsbCBkYXkg bG9uZyBub3chKSwgdG8gZm9jdXMgb24gZmluaXNoaW5nIHVwIHRoZSBuZXc8YnIgY2xhc3M9IiI+ DQomcXVvdDtjYWtlJnF1b3Q7IHFkaXNjL3NoYXBlci9hcW0vUW9TIHN5c3RlbSwgYW1vbmcgb3Ro ZXIgdGhpbmdzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly93 d3cuYnVmZmVyYmxvYXQubmV0L3Byb2plY3RzL2NvZGVsL3dpa2kvQ2FrZVRlY2huaWNhbCIgY2xh c3M9IiI+aHR0cDovL3d3dy5idWZmZXJibG9hdC5uZXQvcHJvamVjdHMvY29kZWwvd2lraS9DYWtl VGVjaG5pY2FsPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNha2UgaXMgbm93IGVu dGVyaW5nIHRoZSB0ZXN0bGFiLCBhbmQgYW1vbmcgb3RoZXIgdGhpbmdzLCBpdCBoYXM8YnIgY2xh c3M9IiI+DQpzdXBwb3J0IGZvciB0aGUgZGlmZnNlcnYgbWFya2luZ3MgZGlzY3Vzc2VkIGluIHRo ZSByZWxhdGVkLCBub3c8YnIgY2xhc3M9IiI+DQpjb25jbHVkZWQgZGFydCB3ZywgYnV0IGluIHdh eXMgc29tZXdoYXQgZGlmZmVyZW50IGZyb20gdGhhdCBpbWFnaW5lZDxiciBjbGFzcz0iIj4NCnRo ZXJlLiBXZSBoYXZlIG5vdCBnb3QgYW55IGdvb2QgY29kZSBpbiBvdXIgdGVzdGJlZHMgeWV0IHRv IHRlc3Q8YnIgY2xhc3M9IiI+DQp2aWRlb2NvbmZlcmVuY2luZyBiZWhhdmlvciwgYW5kIHdlIGNv dWxkIHVzZSBzb21lLCBhbHRob3VnaCBpdCBkb2VzPGJyIGNsYXNzPSIiPg0KbG9vayBsaWtlIHdl IGNhbiBkcml2ZSBmaXJlZm94IHdpdGggc29tZSByZW1vdGUgY29udHJvbCBzdHVmZiB3aXRoIGE8 YnIgY2xhc3M9IiI+DQpmaXhlZCB2aWRlbyBwbGF5YmFjayBub3cuLi4uPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KRml2ZSBxdWVzdGlvbnM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KMSkgSGFzIGFueW9uZSBpbXBsZW1lbnRlZCBvciB0ZXN0ZWQgcHV0dGluZyB2b2ljZSBhbmQg dmlkZW8gb24gdHdvPGJyIGNsYXNzPSIiPg0KZGlmZmVyZW50IDUtdHVwbGVzIGluIGFueSBydW5u aW5nIGNvZGUgb3V0IHRoZXJlPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPkFsbA0KIFZDIHN5c3RlbXMgSSBrbm93IG9mIGV4Y2VwdCBXZWJSVEMtYmFz ZWQgb25lcyBkbyBpdCwgQUZBSUsuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkl04oCZcw0K IHB1dHRpbmcgdGhlbSBvbiB0aGUgc2FtZSB0aGF0J3MgdW51c3VhbC48L3NwYW4+PGJyIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj5U aGF0IHNvdW5kcyBsaWtlIHRoZSB3b3JsZCBJIGFtIGxpdmluZyBpbiBhcyB3ZWxsLjwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQoyKSBIb3cgYWJv dXQgZGlmZnNlcnYgbWFya2luZ3MgaW4gZ2VuZXJhbD8gRG8gYW55IGJyb3dzZXJzIG9yIHdlYnJ0 YzxiciBjbGFzcz0iIj4NCmNhcGFibGUgc29mdHdhcmUgc3VwcG9ydCB3aGF0IHdhcyBkaXNjdXNz ZWQgd2F5IGJhY2sgd2hlbj88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5JDQoga25vdyBIYW5nb3V0cyBkaWQgc29tZXRoaW5nIGxpa2UgdGhhdCBpbnRl cm5hbGx5LCBvbiB0aGUgY29udHJvbGxlZDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5uZXR3 b3JrLg0KIEJ1dCBub3QgYWNjb3JkaW5nIHRvIHNwZWMuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KMykgV2VyZSBkaWZmc2VydiBtYXJraW5nIGNo YW5nZXMgZXZlbnR1YWxseSBhbGxvd2VkIG9uIHRoZSBzYW1lIDUtdHVwbGU/PGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+WWVzLA0KIHdpdGggY2F2ZWF0 cy4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIGhhcyB0aGUgdGFibGUuPC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KNCkgRGlkIHRoZSBFQ04g c3VwcG9ydCB0aGF0IHdhcyBvcmlnaW5hbGx5IGluIG9uZSBkcmFmdCBvciBhbm90aGVyPGJyIGNs YXNzPSIiPg0KZXZlciBtYWtlIGl0IGludG8gYW55IHJ1bm5pbmcgY29kZT88YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsg ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogZG9uJ3Qga25vdy4gSSB0 aGluayB3ZSBsb3N0IGl0IGZyb20gdGhlIGRvY3MuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KKHllYSwgYXBwbGUgcGxhbnMgdG8gdHVybiBvbiBlY24gdW5pdmVyc2FsbHkg aW4gdGhlaXIgbmV4dCBPUyEpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PlNvIGhvdyB3b3VsZCBFQ04gd29yayBv biBVRFA/IEkgZG8gbm90IHRoaW5rIHRoZSBuZWNlc3NhcnkgYml0cyBmcm9tIHRoZSBJUCBoZWFk ZXIgYXJlIGF2YWlsYWJsZSBmb3IgdGhlIGFwcGxpY2F0aW9uIHRvIGRvIGFueXRoaW5nLiBJIGRv IHRoaW5rIExpbnV4IHN1cHBvcnRzIHRoaXMsIGhhdmUgbm90IHRlc3RlZC48L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkFuZCB3aGF0IGFib3V0IHRoZSBuZXR3b3JrLCB3 b3VsZCBpdCBzdXBwb3J0IFVEUCB3aGVuIHNldHRpbmcgdGhlIEVDTiBiaXRzPyBQcm9iYWJseSBh IGNvbmZpZ3VyYXRpb24gcmVsYXRlZCBwcm9ibGVtIGlmIG5vdCBzdXBwb3J0ZWQuPC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjUpICZuYnNwO1doYXQgZWxzZSBkaWQgSSBt aXNzIGluIHRoZSBwYXN0IHllYXIgSSBzaG91bGQga25vdyBhYm91dD88YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Gb3INCiBUQ1AgYW5kIFNDVFAgY29u Z2VzdGlvbiBjb250cm9sbGVycywgd2UncmUgYmFjayB0byBvbmUgRFNDUCBtYXJraW5nPC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPnBlcg0KIGZsb3csIGFuZCByZXNldHRpbmcgdGhlIGNvbmdl c3Rpb24gY29udHJvbCBzdGF0ZSBpZiBEU0NQIG1hcmtpbmc8L3NwYW4+PGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+Y2hhbmdlcy48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoZXJl IGlzIGEgbmV3IElDRSB3Zy4gSXQgd2FzIGNyZWF0ZWQgc28g4oCcbmV0d29yayBwZW9wbGXigJ0g Y291bGQgcGFydGljaXBhdGUgd2l0aG91dCB0aGUgb3ZlcmhlYWQgb2YgbGlzdGVuaW5nIHRvIHRo ZSBTRFAgcmVsYXRlZCBkaXNjdXNzaW9ucy4gKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvd2cvaWNlL2NoYXJ0ZXIvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL3dnL2ljZS9jaGFydGVyLzwvYT4pPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj4uLS48L2Rpdj4NCjxkaXY+UMOlbC1FcmlrPC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGZWVsIGZyZWUgdG8gY29udGFjdCBtZSBvZmYgbGlz dCBpZiB0aGVzZSBoYXZlIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQuPGJyIGNsYXNzPSIiPg0KSSBo YXZlIHRvdGFsbHkgbG9zdCB0cmFjayBvZiB0aGUgcmVsZXZhbnQgZHJhZnRzLjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRoZXkncmUNCiBub3QgZmlu aXNoZWQgc3RpbGwgOi0pPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2luY2VyZWx5LDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkRhdmUgVMOkaHQ8YnIgY2xhc3M9IiI+DQpJIGp1c3QgbG9zdCBmaXZlIHllYXJz IG9mIG15IGxpZmUgdG8gbWFraW5nIHRoZSBlZGdlPGJyIGNsYXNzPSIiPg0Kb2YgdGhlIGludGVy bmV0LCBhbmQsIHdpZmkgYmV0dGVyLjxiciBjbGFzcz0iIj4NCkFuZCwgbm93Li4uIHRoZSBGQ0Mg d2FudHMgdG8gbWFrZSBteSB3b3JrIGlsbGVnYWw8YnIgY2xhc3M9IiI+DQpmb3Igb3JkaW5hcnkg cGVvcGxlIHRvIGluc3RhbGwuPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29m dW5kbWUuY29tL3NhdmV3aWZpIiBjbGFzcz0iIj5odHRwczovL3d3dy5nb2Z1bmRtZS5jb20vc2F2 ZXdpZmk8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KcnRjd2ViQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5ydGN3ZWINCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3Jn IiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9y ZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_43B59C2F4B644318833904903AF2A6ACciscocom_-- From nobody Thu Oct 22 02:14:24 2015 Return-Path: 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 2F7BB1A0113; Thu, 22 Oct 2015 02:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 PZiOqECNznmv; Thu, 22 Oct 2015 02:14:18 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BB71A0119; Thu, 22 Oct 2015 02:14:18 -0700 (PDT) Received: from [79.78.84.166] (port=51678 helo=[192.168.0.3]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZpBwo-0002p1-Pu; Thu, 22 Oct 2015 10:14:13 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_9E65B11C-6074-44B2-8374-7A7ACD657975" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Colin Perkins In-Reply-To: <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> Date: Thu, 22 Oct 2015 10:13:33 +0100 Message-Id: <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> To: "Pal Martinsen (palmarti)" X-Mailer: Apple Mail (2.2104) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , "aqm@ietf.org" Subject: Re: [rtcweb] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 22 Oct 2015 09:14:21 -0000 --Apple-Mail=_9E65B11C-6074-44B2-8374-7A7ACD657975 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) = wrote: >=20 >=20 >> On 21 Oct 2015, at 18:10, Harald Alvestrand > wrote: >>=20 >> Den 21. okt. 2015 17:51, skrev Dave Taht: >>> I unsubscribed from rmcat and rtcweb groups a while back after I got >>> overloaded, and appear.in started working so well, (for both ipv6 = and >>> ipv4! I use it all day long now!), to focus on finishing up the new >>> "cake" qdisc/shaper/aqm/QoS system, among other things. >>>=20 >>> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical = >>>=20 >>> Cake is now entering the testlab, and among other things, it has >>> support for the diffserv markings discussed in the related, now >>> concluded dart wg, but in ways somewhat different from that imagined >>> there. We have not got any good code in our testbeds yet to test >>> videoconferencing behavior, and we could use some, although it does >>> look like we can drive firefox with some remote control stuff with a >>> fixed video playback now.... >>>=20 >>> Five questions: >>>=20 >>> 1) Has anyone implemented or tested putting voice and video on two >>> different 5-tuples in any running code out there? >>=20 >> All VC systems I know of except WebRTC-based ones do it, AFAIK. >> It=E2=80=99s putting them on the same that's unusual. >>=20 > That sounds like the world I am living in as well. >=20 >=20 >>> 2) How about diffserv markings in general? Do any browsers or webrtc >>> capable software support what was discussed way back when? >>=20 >> I know Hangouts did something like that internally, on the controlled >> network. But not according to spec. >>=20 >>> 3) Were diffserv marking changes eventually allowed on the same = 5-tuple? >>=20 >> Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table. >>=20 >>> 4) Did the ECN support that was originally in one draft or another >>> ever make it into any running code? >>=20 >> I don't know. I think we lost it from the docs. >>=20 >>> (yea, apple plans to turn on ecn universally in their next OS!) >>>=20 > So how would ECN work on UDP? I do not think the necessary bits from = the IP header are available for the application to do anything. I do = think Linux supports this, have not tested. >=20 > And what about the network, would it support UDP when setting the ECN = bits? Probably a configuration related problem if not supported. RFC 6679 describes how to use ECN with RTP on UDP, although as you say = there are implementation difficulties on some platforms. I=E2=80=99m not = sure whether there are implementations.=20 >>> 5) What else did I miss in the past year I should know about? >>=20 >> For TCP and SCTP congestion controllers, we're back to one DSCP = marking >> per flow, and resetting the congestion control state if DSCP marking >> changes. >>=20 >=20 > There is a new ICE wg. It was created so =E2=80=9Cnetwork people=E2=80=9D= could participate without the overhead of listening to the SDP related = discussions. (https://datatracker.ietf.org/wg/ice/charter/ = ) >=20 > .-. > P=C3=A5l-Erik >=20 >>>=20 >>> Feel free to contact me off list if these have already been = discussed. >>> I have totally lost track of the relevant drafts. >>=20 >> They're not finished still :-) >>=20 >>>=20 >>> Sincerely, >>>=20 >>> Dave T=C3=A4ht >>> I just lost five years of my life to making the edge >>> of the internet, and, wifi better. >>> And, now... the FCC wants to make my work illegal >>> for ordinary people to install. >>> https://www.gofundme.com/savewifi = >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >> _______________________________________________ >> 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 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_9E65B11C-6074-44B2-8374-7A7ACD657975 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) <palmarti@cisco.com> = wrote:


On 21 Oct 2015, at 18:10, Harald Alvestrand <harald@alvestrand.no> wrote:

Den 21. okt. 2015 17:51, skrev Dave Taht:
I unsubscribed from rmcat and rtcweb groups a while back after I got
overloaded, and appear.in started working so well, (for both ipv6 and
ipv4! I use it all day long now!), to focus on finishing up the new
"cake" qdisc/shaper/aqm/QoS system, among other things.

http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical

Cake is now entering the testlab, and among other things, it has
support for the diffserv markings discussed in the related, now
concluded dart wg, but in ways somewhat different from that imagined
there. We have not got any good code in our testbeds yet to test
videoconferencing behavior, and we could use some, although it does
look like we can drive firefox with some remote control stuff with a
fixed video playback now....

Five questions:

1) Has anyone implemented or tested putting voice and video on two
different 5-tuples in any running code out there?

All VC systems I know of except WebRTC-based ones do it, AFAIK.
It=E2=80=99s putting them on the same that's unusual.

That sounds like the world I am living in as well.


2) How about diffserv markings in general? Do any browsers or webrtc
capable software support what was discussed way back when?

I know Hangouts did something like that internally, on the = controlled
network. But not according to spec.

3) Were diffserv marking changes eventually allowed on the same = 5-tuple?

Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table.

4) Did the ECN support that was originally in one draft or another
ever make it into any running code?

I don't know. I think we lost it from the docs.

(yea, apple plans to turn on ecn universally in their next OS!)

So how would ECN work on UDP? I do not think the = necessary bits from the IP header are available for the application to = do anything. I do think Linux supports this, have not tested.

And what about the network, would it support UDP when = setting the ECN bits? Probably a configuration related problem if not = supported.



5)  What else did I miss in the past year I should know about?

For TCP and SCTP congestion controllers, we're back to one DSCP = marking
per flow, and resetting the congestion control state if DSCP = marking
changes.


There is a new ICE wg. It was created so =E2=80=9Cnetwork people=E2=80=9D = could participate without the overhead of listening to the SDP related = discussions. (https://datatracker.ietf.org/wg/ice/charter/)

.-.
P=C3=A5l-Erik


Feel free to contact me off list if these have already been = discussed.
I have totally lost track of the relevant drafts.

They're not finished still :-)


Sincerely,

Dave T=C3=A4ht
I just lost five years of my life to making the edge
of the internet, and, wifi better.
And, now... the FCC wants to make my work illegal
for ordinary people to install.
https://www.gofundme.com/savewifi

_______________________________________________
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

_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_9E65B11C-6074-44B2-8374-7A7ACD657975-- From nobody Thu Oct 22 12:55:22 2015 Return-Path: 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 1710D1B3EC1 for ; Thu, 22 Oct 2015 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miOiTPFtm8Bv for ; Thu, 22 Oct 2015 12:55:18 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7295E1B3EC5 for ; Thu, 22 Oct 2015 12:55:18 -0700 (PDT) Received: by vkex70 with SMTP id x70so52621009vke.3 for ; Thu, 22 Oct 2015 12:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wNTrOP9OOMSOBq9exn3VE6a7U4zq5E80THMcHJFomiQ=; b=joBVww/qoW/cf6Y7Rk0RmjYBo5AC++dLZlFI1YF6DhK7iLsslQDC+dTdOQGLSj1FIP 4KPXnwZGoBPkIZfMyNYcZZKd9ujkQfgwSQsbdmQuMCEo8E6+FEq6fwaa9ZOM0jvk0eV1 3Ubkh6vAyQJdZma3DK8AIJtDYfxVykIYyMZCdtztihdnpUOWM+vaUQWHHgGYZI1YsClZ /UQNv5AAAbmvo3Do4IFQmJpGC326Kca9k2OINjEUG/TEIhG8T6gabekGmJkUa5twTSWu ItK/pufVk8Br6+4W8+DBe7XpgFrKCQ4sabr0ctNXttoQ3f4r4uYvryFBEOtNOi/swI3+ T5Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wNTrOP9OOMSOBq9exn3VE6a7U4zq5E80THMcHJFomiQ=; b=io4SWiYuVLus4A3ZaiPa2wp0MnG22wOYgd290OLIkYBZO/ixZUc9FIudy1ksDv9l7K fGudARvB47G8sUyjAa/qKnzhXY2QzQTuQx7M0uFql+KB6LiMHCNjZjhxaE8MOkp/6TJ4 2AolSQBIavgS089oGYjUH/WnHsEcr4s37yL5A+8EKahakX6Tkt14iT6pCirj6/qybXKL +1q20m3su2d77OCcNU4Zali3X1anHyEt7rekA17XjiLYCGuc9DSny+8ZUMsd2qoCz/Zl pvAhN7UCG/si/qk1TfnXK3AT+zP7tpu3w6LqTK9RxajdD2KNOfgsvPjMfLSroYquI0NK /HyA== X-Gm-Message-State: ALoCoQlS8yM+d5KE+2rORdt0dNyKtIiw6yTmeFcT+l9CfU6Ks5TH4hCN55O0F5SreL0i0UIyR9DE X-Received: by 10.31.49.22 with SMTP id x22mr9717959vkx.60.1445543717498; Thu, 22 Oct 2015 12:55:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.201 with HTTP; Thu, 22 Oct 2015 12:54:57 -0700 (PDT) In-Reply-To: <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> From: Justin Uberti Date: Thu, 22 Oct 2015 12:54:57 -0700 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a11440790ca2f400522b6dfd6 Archived-At: Cc: "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , "aqm@ietf.org" Subject: Re: [rtcweb] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 22 Oct 2015 19:55:21 -0000 --001a11440790ca2f400522b6dfd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At present I'm not aware of any widely-deployed OS where an app can read the received ECN markings. iOS9 added support for this within the kernel, and it's used for TCP, but not exposed to userspace. There is an open Radar bug asking for this info to be exposed to userspace. FWIW, Chrome supports setting the DSCP markings if you set a magic parameter. But it's not on by default, mainly because we've never done the auditing necessary to ensure this doesn't randomly break in various dimly-lit parts of the internet. On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins wrote: > On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) > wrote: > > > On 21 Oct 2015, at 18:10, Harald Alvestrand wrote: > > Den 21. okt. 2015 17:51, skrev Dave Taht: > > I unsubscribed from rmcat and rtcweb groups a while back after I got > overloaded, and appear.in started working so well, (for both ipv6 and > ipv4! I use it all day long now!), to focus on finishing up the new > "cake" qdisc/shaper/aqm/QoS system, among other things. > > http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical > > Cake is now entering the testlab, and among other things, it has > support for the diffserv markings discussed in the related, now > concluded dart wg, but in ways somewhat different from that imagined > there. We have not got any good code in our testbeds yet to test > videoconferencing behavior, and we could use some, although it does > look like we can drive firefox with some remote control stuff with a > fixed video playback now.... > > Five questions: > > 1) Has anyone implemented or tested putting voice and video on two > different 5-tuples in any running code out there? > > > All VC systems I know of except WebRTC-based ones do it, AFAIK. > It=E2=80=99s putting them on the same that's unusual. > > That sounds like the world I am living in as well. > > > 2) How about diffserv markings in general? Do any browsers or webrtc > capable software support what was discussed way back when? > > > I know Hangouts did something like that internally, on the controlled > network. But not according to spec. > > 3) Were diffserv marking changes eventually allowed on the same 5-tuple? > > > Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table. > > 4) Did the ECN support that was originally in one draft or another > ever make it into any running code? > > > I don't know. I think we lost it from the docs. > > (yea, apple plans to turn on ecn universally in their next OS!) > > So how would ECN work on UDP? I do not think the necessary bits from the > IP header are available for the application to do anything. I do think > Linux supports this, have not tested. > > And what about the network, would it support UDP when setting the ECN > bits? Probably a configuration related problem if not supported. > > > RFC 6679 describes how to use ECN with RTP on UDP, although as you say > there are implementation difficulties on some platforms. I=E2=80=99m not = sure > whether there are implementations. > > > 5) What else did I miss in the past year I should know about? > > > For TCP and SCTP congestion controllers, we're back to one DSCP marking > per flow, and resetting the congestion control state if DSCP marking > changes. > > > There is a new ICE wg. It was created so =E2=80=9Cnetwork people=E2=80=9D= could > participate without the overhead of listening to the SDP related > discussions. (https://datatracker.ietf.org/wg/ice/charter/) > > .-. > P=C3=A5l-Erik > > > Feel free to contact me off list if these have already been discussed. > I have totally lost track of the relevant drafts. > > > They're not finished still :-) > > > Sincerely, > > Dave T=C3=A4ht > I just lost five years of my life to making the edge > of the internet, and, wifi better. > And, now... the FCC wants to make my work illegal > for ordinary people to install. > https://www.gofundme.com/savewifi > > _______________________________________________ > 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 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a11440790ca2f400522b6dfd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At present I'm not aware of any widely-deployed OS whe= re an app can read the received ECN markings.=C2=A0

iOS9= added support for this within the kernel, and it's used for TCP, but n= ot exposed to userspace. There is an open Radar bug asking for this info to= be exposed to userspace.

FWIW, Chrome supports se= tting the DSCP markings if you set a magic parameter. But it's not on b= y default, mainly because we've never done the auditing necessary to en= sure this doesn't randomly break in various dimly-lit parts of the inte= rnet.

= On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins <csp@csperkins.org><= /span> wrote:
On 22 O= ct 2015, at 08:48, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:


On 21 Oct 2015, at 18:10, Harald Alvestrand <harald@alvestrand.no> wrote:
Den 21. okt. 2015 17:51, skrev Dave Taht:
I unsubscribed from rmcat and rtcweb groups a while back after I got
overloaded, and appear.in started working so well, (for both ipv6 and
ipv4! I use it all day long now!), to focus on finishing up the new
"cake" qdisc/shaper/aqm/QoS system, among other things.

http://www.bufferbloat.net/projects/codel/wiki/CakeTechnica= l

Cake is now entering the testlab, and among other things, it has
support for the diffserv markings discussed in the related, now
concluded dart wg, but in ways somewhat different from that imagined
there. We have not got any good code in our testbeds yet to test
videoconferencing behavior, and we could use some, although it does
look like we can drive firefox with some remote control stuff with a
fixed video playback now....

Five questions:

1) Has anyone implemented or tested putting voice and video on two
different 5-tuples in any running code out there?

All VC systems I know of except WebRTC-based ones do it, AFAIK.
It=E2=80=99s putting them on the same that's unusual.

That sounds like the world I am living in as well.


2) How about diffserv markings in general? Do any browsers or webrtc
capable software support what was discussed way back when?

I know Hangouts did something like that internally, on the controlled=
network. But not according to spec.

3) Were diffserv marking changes eventually allowed on the same 5-tuple?

Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table.

4) Did the ECN support that was originally in one draft or another
ever make it into any running code?

I don't know. I think we lost it from the docs.

(yea, apple plans to turn on ecn universally in their next OS!)

So how would ECN work on UDP? I do not think the necessary bits from t= he IP header are available for the application to do anything. I do think L= inux supports this, have not tested.

And what about the network, would it support UDP when setting the ECN = bits? Probably a configuration related problem if not supported.

RFC 6679 describe= s how to use ECN with RTP on UDP, although as you say there are implementat= ion difficulties on some platforms. I=E2=80=99m not sure whether there are = implementations.=C2=A0


5) =C2=A0What else did I miss in the past year I should know about?

For TCP and SCTP congestion controllers, we're back to one DSCP marking
per flow, and resetting the congestion control state if DSCP marking changes.


There is a new ICE wg. It was created so =E2=80=9Cnetwork people=E2=80=9D c= ould participate without the overhead of listening to the SDP related discu= ssions. (https://datatracker.ietf.org/wg/ice/charter/)

.-.
P=C3=A5l-Erik


Feel free to contact me off list if these have already been discussed.
I have totally lost track of the relevant drafts.

They're not finished still :-)


Sincerely,

Dave T=C3=A4ht
I just lost five years of my life to making the edge
of the internet, and, wifi better.
And, now... the FCC wants to make my work illegal
for ordinary people to install.
https://www= .gofundme.com/savewifi

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


________________________= _______________________
rtcweb mailing list
rtcweb@ietf.o= rg
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb



--=C2=A0
Colin= Perkins





--001a11440790ca2f400522b6dfd6-- From nobody Fri Oct 23 01:34:28 2015 Return-Path: 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 7CAF51B3329 for ; Fri, 23 Oct 2015 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.222 X-Spam-Level: X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, 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 UnZ4oAfSKBe4 for ; Fri, 23 Oct 2015 01:34:24 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC421B3322 for ; Fri, 23 Oct 2015 01:34:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 833DF7C0B32 for ; Fri, 23 Oct 2015 10:34:22 +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 f324vASDtYMS for ; Fri, 23 Oct 2015 10:34:20 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:78f8:6c3f:c382:dab8] (unknown [IPv6:2001:470:de0a:1:78f8:6c3f:c382:dab8]) by mork.alvestrand.no (Postfix) with ESMTPSA id A97667C0B2A for ; Fri, 23 Oct 2015 10:34:20 +0200 (CEST) To: rtcweb@ietf.org References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <5629F10B.6050503@alvestrand.no> Date: Fri, 23 Oct 2015 10:34:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Oct 2015 08:34:26 -0000 ECN markings are just a byte in the IP header. The brutal way to do this is to get your packets as raw packets, and doing UDP processing yourself. The less brutal way on Linux is to use setsockopt(IP_RECVTOS) ("since Linux 2.2" according to "man 7 ip"). There's a 2012 FreeBSD code example from Michael Tuexen here: http://lists.freebsd.org/pipermail/freebsd-net/2012-June/032519.html (Linux and FreeBSD may not count as "widely deployed" on the desktop, but Linux wrapped up as Android is a fairly frequent player in the mobile space.) Den 22. okt. 2015 21:54, skrev Justin Uberti: > At present I'm not aware of any widely-deployed OS where an app can read > the received ECN markings. > > iOS9 added support for this within the kernel, and it's used for TCP, > but not exposed to userspace. There is an open Radar bug asking for this > info to be exposed to userspace. > > FWIW, Chrome supports setting the DSCP markings if you set a magic > parameter. But it's not on by default, mainly because we've never done > the auditing necessary to ensure this doesn't randomly break in various > dimly-lit parts of the internet. > > On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins > wrote: > >> On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) >> > wrote: >> >> >>> On 21 Oct 2015, at 18:10, Harald Alvestrand >> > wrote: >>> >>> Den 21. okt. 2015 17:51, skrev Dave Taht: >>>> I unsubscribed from rmcat and rtcweb groups a while back after I got >>>> overloaded, and appear.in started working so >>>> well, (for both ipv6 and >>>> ipv4! I use it all day long now!), to focus on finishing up the new >>>> "cake" qdisc/shaper/aqm/QoS system, among other things. >>>> >>>> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical >>>> >>>> Cake is now entering the testlab, and among other things, it has >>>> support for the diffserv markings discussed in the related, now >>>> concluded dart wg, but in ways somewhat different from that imagined >>>> there. We have not got any good code in our testbeds yet to test >>>> videoconferencing behavior, and we could use some, although it does >>>> look like we can drive firefox with some remote control stuff with a >>>> fixed video playback now.... >>>> >>>> Five questions: >>>> >>>> 1) Has anyone implemented or tested putting voice and video on two >>>> different 5-tuples in any running code out there? >>> >>> All VC systems I know of except WebRTC-based ones do it, AFAIK. >>> It’s putting them on the same that's unusual. >>> >> That sounds like the world I am living in as well. >> >> >>>> 2) How about diffserv markings in general? Do any browsers or webrtc >>>> capable software support what was discussed way back when? >>> >>> I know Hangouts did something like that internally, on the controlled >>> network. But not according to spec. >>> >>>> 3) Were diffserv marking changes eventually allowed on the same >>>> 5-tuple? >>> >>> Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table. >>> >>>> 4) Did the ECN support that was originally in one draft or another >>>> ever make it into any running code? >>> >>> I don't know. I think we lost it from the docs. >>> >>>> (yea, apple plans to turn on ecn universally in their next OS!) >>>> >> So how would ECN work on UDP? I do not think the necessary bits >> from the IP header are available for the application to do >> anything. I do think Linux supports this, have not tested. >> >> And what about the network, would it support UDP when setting the >> ECN bits? Probably a configuration related problem if not supported. > > RFC 6679 describes how to use ECN with RTP on UDP, although as you > say there are implementation difficulties on some platforms. I’m not > sure whether there are implementations. > > >>>> 5) What else did I miss in the past year I should know about? >>> >>> For TCP and SCTP congestion controllers, we're back to one DSCP >>> marking >>> per flow, and resetting the congestion control state if DSCP marking >>> changes. >>> >> >> There is a new ICE wg. It was created so “network people” could >> participate without the overhead of listening to the SDP related >> discussions. (https://datatracker.ietf.org/wg/ice/charter/) >> >> .-. >> Pål-Erik >> >>>> >>>> Feel free to contact me off list if these have already been >>>> discussed. >>>> I have totally lost track of the relevant drafts. >>> >>> They're not finished still :-) >>> >>>> >>>> Sincerely, >>>> >>>> Dave Täht >>>> I just lost five years of my life to making the edge >>>> of the internet, and, wifi better. >>>> And, now... the FCC wants to make my work illegal >>>> for ordinary people to install. >>>> https://www.gofundme.com/savewifi >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Oct 23 01:40:40 2015 Return-Path: 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 A7CDB1B3344; Fri, 23 Oct 2015 01:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 SY2EnnvTZGr9; Fri, 23 Oct 2015 01:40:32 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274631B3337; Fri, 23 Oct 2015 01:40:30 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-e5-5629f27c1c6e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.FF.27359.C72F9265; Fri, 23 Oct 2015 10:40:29 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.167]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Fri, 23 Oct 2015 10:40:28 +0200 From: Ingemar Johansson S To: Colin Perkins , "Pal Martinsen (palmarti)" , Dave Taht Thread-Topic: ECN support for UDP (was RE: [rmcat] [rtcweb] Catching up on diffserv markings) Thread-Index: AdENa5mK943I69uaQMma3cH7eCfP0w== Date: Fri, 23 Oct 2015 08:40:26 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3A@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3AESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM+JvjW7tJ80wg/lRFmv2SVpM/bqS1WL5 yxOMFns2nmSxeH99JYvF6psf2CzW/mtnd2D3mPJ7I6vHtPv32Tx2zrrL7rFkyU8mj+0XzzAF sEZx2aSk5mSWpRbp2yVwZexetYqp4Ns7xopdU1cxNjBeeMHYxcjJISFgIrH09zRmCFtM4sK9 9WwgtpDAUUaJW6/0uhi5gOwljBKLDu9iAkmwCdhIrDz0HaxZRKBSYk3/TSaQImaBR4wSS/f9 A+sWFoiSWLd7CVARB1BRvMT925YQ9XoS/VMeg4VZBFQldh1NBDF5BXwlfp4VBKlgFJCVuP/9 HguIzSwgLnHryXwmiNMEJJbsOQ91pqjEy8f/WCFsRYn2pw2MEPX5EjMOLQOL8woISpyc+YRl AqPwLCSjZiEpm4WkbBbQFcwCmhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxUm66 kZFealFmcnFxfp5eXmrJJkZgJB7c8ttgB+PL546HGAU4GJV4eBdM0QwTYk0sK67MPcQowcGs JMK7+z1QiDclsbIqtSg/vqg0J7X4EKM0B4uSOG8z04NQIYH0xJLU7NTUgtQimCwTB6dUA+Ns V62LYc3rjV546Qba3PH79cluaZPni6PLmoxzT937JM3T8DTDXWrvlpT6SXOvLdxlpPnz0fOa 5ZqFAnamXr9dlu8P2nX77smZh05obhAoYHiRbnmykcM6fM0vw6/z7rjm+H6u/8To1CfKrx/m 8NBYRp6pr0T01zovvgre0idn/CafmzfF5KgSS3FGoqEWc1FxIgAX0RZRwAIAAA== Archived-At: Cc: "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , Ingemar Johansson S , "rtcweb@ietf.org" , "aqm@ietf.org" Subject: [rtcweb] ECN support for UDP (was RE: [rmcat] Catching up on diffserv markings) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Oct 2015 08:40:35 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3AESESSMB205erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBmb2xsb3d1cCBvbiB0aGUgRUNOIGRpc2N1c3Npb24gOg0KDQpDb25nZXN0aW9uIGNvbnRyb2wg d2lzZSAoUk1DQVQpIGJvdGggTkFEQSBhbmQgU0NSZUFNIHN1cHBvcnQgRUNOIGluIHRoZSBzcGVj aWZpY2F0aW9uLiBJbiBhZGRpdGlvbiBNVFNJICgzR1BQIFNBNCkgc3VwcG9ydCBFQ04gaW4gdGhl IHNwZWNpZmljYXRpb24uDQpJbiBTQ1JlQU0sIHRoZSBzdXBwb3J0IGlzIG5vdCBmdWxseSBpbXBs ZW1lbnRlZCBpbiBydW5uaW5nIGNvZGUgYnV0IGhlIGZlZWRiYWNrIGlzIGluIHBsYWNlIGFuZCB0 aGUgYWRkaXRpb25hbCBhbW91bnQgb2YgY29kZSBuZWVkZWQgdG8gZ2V0IEVDTiBzdXBwb3J0IGlz IHZlcnkgc21hbGwuIFRoZSBsYXRlc3Qgc3BlY2lmaWNhdGlvbiBob3dldmVyIGV4cGxhaW5zIHRo ZSBFQ04gc3VwcG9ydCwgdGhlIGJlaGF2aW9yIGlzIHZlcnkgc2ltaWxhciB0byBSRkMzMTY4IGFz IFNDUmVBTSBpcyBhIHNlbGYtY2xvY2tlZCBwcm90b2NvbC4NClRoZSBjdXJyZW50IHNuYWcgaXMg dGhhdCB0aGUgc29ja2V0cyBuZWVkIHRvIGJlIG1vZGlmaWVkIHRvIGdpdmUgYWNjZXNzIHRvIHRo ZSB0d28gRUNOIGJpdHMuIE1vcmUgc3BlY2lmaWNhbGx5LCB3aGF0IGlzIG5lZWRlZCBpcyB0byBi ZSBhYmxlIHRvIHNldCB0aGUgdHdvIEVDTiBiaXRzIGFuZCB0byByZWFkIHRoZSBzYW1lIHR3byBF Q04gYml0cyBpbiB0aGUgSVAgaGVhZGVyLCB0aGlzIGlzIGFsc28gc3RhdGVkIGluIHNlY3Rpb24g OSBpbiBSRkM2Njc5IC4gSGVyZSBJIGJlbGlldmUgdGhhdCBvbmUgY2FuIGVhc2lseSBzcGVuZCBt b3JlIHRpbWUgZGlzY3Vzc2luZyB0aGUgZ29vZCBhbmQgYmFkIHNpZGVzIG9mIGFkZGluZyBFQ04g c3VwcG9ydCB0byB0aGUgc29ja2V0IGludGVyZmFjZSB0aGFuIGl0IGFjdHVhbGx5IHRha2VzIHRv IGltcGxlbWVudCBpdCDimLogLg0KDQpOZXR3b3JrIHdpc2UsIEkgZ3Vlc3MgdGhlIHN1cHBvcnQg Zm9yIEVDTiBmb3IgVURQIGlzIGEgbWF0dGVyIG9mIGNvbmZpZ3VyYXRpb24sIGJ1dCBpZiBvbmUg bG9vayBmcm9tIHN0cmljdCByYWRpbyAoTFRFKSBwZXJzcGVjdGl2ZSBpdCBkb2VzIG5vdCByZWFs bHkgbWF0dGVyIGlmIGl0IGlzIFVEUCBvciBUQ1Agb3ZlciBJUCwgaXQgaXMgdHJlYXRlZCB0aGUg c2FtZSwgdGh1cyB0aGUgc3RyYXRlZ3kgZm9yIEVDTiBtYXJraW5nIHNob3VsZCBiZSB0aGUgc2Ft ZSBhbmQgc2hvdWxkIHByZWZlcmFibHkgZm9sbG93IHRoZSBndWlkZWxpbmVzIGluIFJGQzc1Njcu DQoNCi9JbmdlbWFyDQoNCg0KRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3Blcmtp bnMub3JnXQ0KU2VudDogZGVuIDIyIG9rdG9iZXIgMjAxNSAxMToxNA0KVG86IFBhbCBNYXJ0aW5z ZW4gKHBhbG1hcnRpKQ0KQ2M6IGNha2VAbGlzdHMuYnVmZmVyYmxvYXQubmV0OyBybWNhdEBpZXRm Lm9yZzsgcnRjd2ViQGlldGYub3JnOyBEYXZlIFRhaHQ7IGFxbUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtybWNhdF0gW3J0Y3dlYl0gQ2F0Y2hpbmcgdXAgb24gZGlmZnNlcnYgbWFya2luZ3MNCg0K T24gMjIgT2N0IDIwMTUsIGF0IDA4OjQ4LCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgPHBhbG1h cnRpQGNpc2NvLmNvbTxtYWlsdG86cGFsbWFydGlAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KT24g MjEgT2N0IDIwMTUsIGF0IDE4OjEwLCBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJh bmQubm88bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj4gd3JvdGU6DQoNCkRlbiAyMS4gb2t0 LiAyMDE1IDE3OjUxLCBza3JldiBEYXZlIFRhaHQ6DQoNCkkgdW5zdWJzY3JpYmVkIGZyb20gcm1j YXQgYW5kIHJ0Y3dlYiBncm91cHMgYSB3aGlsZSBiYWNrIGFmdGVyIEkgZ290DQpvdmVybG9hZGVk LCBhbmQgYXBwZWFyLmluIHN0YXJ0ZWQgd29ya2luZyBzbyB3ZWxsLCAoZm9yIGJvdGggaXB2NiBh bmQNCmlwdjQhIEkgdXNlIGl0IGFsbCBkYXkgbG9uZyBub3chKSwgdG8gZm9jdXMgb24gZmluaXNo aW5nIHVwIHRoZSBuZXcNCiJjYWtlIiBxZGlzYy9zaGFwZXIvYXFtL1FvUyBzeXN0ZW0sIGFtb25n IG90aGVyIHRoaW5ncy4NCg0KaHR0cDovL3d3dy5idWZmZXJibG9hdC5uZXQvcHJvamVjdHMvY29k ZWwvd2lraS9DYWtlVGVjaG5pY2FsDQoNCkNha2UgaXMgbm93IGVudGVyaW5nIHRoZSB0ZXN0bGFi LCBhbmQgYW1vbmcgb3RoZXIgdGhpbmdzLCBpdCBoYXMNCnN1cHBvcnQgZm9yIHRoZSBkaWZmc2Vy diBtYXJraW5ncyBkaXNjdXNzZWQgaW4gdGhlIHJlbGF0ZWQsIG5vdw0KY29uY2x1ZGVkIGRhcnQg d2csIGJ1dCBpbiB3YXlzIHNvbWV3aGF0IGRpZmZlcmVudCBmcm9tIHRoYXQgaW1hZ2luZWQNCnRo ZXJlLiBXZSBoYXZlIG5vdCBnb3QgYW55IGdvb2QgY29kZSBpbiBvdXIgdGVzdGJlZHMgeWV0IHRv IHRlc3QNCnZpZGVvY29uZmVyZW5jaW5nIGJlaGF2aW9yLCBhbmQgd2UgY291bGQgdXNlIHNvbWUs IGFsdGhvdWdoIGl0IGRvZXMNCmxvb2sgbGlrZSB3ZSBjYW4gZHJpdmUgZmlyZWZveCB3aXRoIHNv bWUgcmVtb3RlIGNvbnRyb2wgc3R1ZmYgd2l0aCBhDQpmaXhlZCB2aWRlbyBwbGF5YmFjayBub3cu Li4uDQoNCkZpdmUgcXVlc3Rpb25zOg0KDQoxKSBIYXMgYW55b25lIGltcGxlbWVudGVkIG9yIHRl c3RlZCBwdXR0aW5nIHZvaWNlIGFuZCB2aWRlbyBvbiB0d28NCmRpZmZlcmVudCA1LXR1cGxlcyBp biBhbnkgcnVubmluZyBjb2RlIG91dCB0aGVyZT8NCg0KQWxsIFZDIHN5c3RlbXMgSSBrbm93IG9m IGV4Y2VwdCBXZWJSVEMtYmFzZWQgb25lcyBkbyBpdCwgQUZBSUsuDQpJdOKAmXMgcHV0dGluZyB0 aGVtIG9uIHRoZSBzYW1lIHRoYXQncyB1bnVzdWFsLg0KDQpUaGF0IHNvdW5kcyBsaWtlIHRoZSB3 b3JsZCBJIGFtIGxpdmluZyBpbiBhcyB3ZWxsLg0KDQoNCg0KMikgSG93IGFib3V0IGRpZmZzZXJ2 IG1hcmtpbmdzIGluIGdlbmVyYWw/IERvIGFueSBicm93c2VycyBvciB3ZWJydGMNCmNhcGFibGUg c29mdHdhcmUgc3VwcG9ydCB3aGF0IHdhcyBkaXNjdXNzZWQgd2F5IGJhY2sgd2hlbj8NCg0KSSBr bm93IEhhbmdvdXRzIGRpZCBzb21ldGhpbmcgbGlrZSB0aGF0IGludGVybmFsbHksIG9uIHRoZSBj b250cm9sbGVkDQpuZXR3b3JrLiBCdXQgbm90IGFjY29yZGluZyB0byBzcGVjLg0KDQoNCjMpIFdl cmUgZGlmZnNlcnYgbWFya2luZyBjaGFuZ2VzIGV2ZW50dWFsbHkgYWxsb3dlZCBvbiB0aGUgc2Ft ZSA1LXR1cGxlPw0KDQpZZXMsIHdpdGggY2F2ZWF0cy4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWIt cW9zIGhhcyB0aGUgdGFibGUuDQoNCg0KNCkgRGlkIHRoZSBFQ04gc3VwcG9ydCB0aGF0IHdhcyBv cmlnaW5hbGx5IGluIG9uZSBkcmFmdCBvciBhbm90aGVyDQpldmVyIG1ha2UgaXQgaW50byBhbnkg cnVubmluZyBjb2RlPw0KDQpJIGRvbid0IGtub3cuIEkgdGhpbmsgd2UgbG9zdCBpdCBmcm9tIHRo ZSBkb2NzLg0KKHllYSwgYXBwbGUgcGxhbnMgdG8gdHVybiBvbiBlY24gdW5pdmVyc2FsbHkgaW4g dGhlaXIgbmV4dCBPUyEpDQpTbyBob3cgd291bGQgRUNOIHdvcmsgb24gVURQPyBJIGRvIG5vdCB0 aGluayB0aGUgbmVjZXNzYXJ5IGJpdHMgZnJvbSB0aGUgSVAgaGVhZGVyIGFyZSBhdmFpbGFibGUg Zm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkbyBhbnl0aGluZy4gSSBkbyB0aGluayBMaW51eCBzdXBw b3J0cyB0aGlzLCBoYXZlIG5vdCB0ZXN0ZWQuDQoNCkFuZCB3aGF0IGFib3V0IHRoZSBuZXR3b3Jr LCB3b3VsZCBpdCBzdXBwb3J0IFVEUCB3aGVuIHNldHRpbmcgdGhlIEVDTiBiaXRzPyBQcm9iYWJs eSBhIGNvbmZpZ3VyYXRpb24gcmVsYXRlZCBwcm9ibGVtIGlmIG5vdCBzdXBwb3J0ZWQuDQoNClJG QyA2Njc5IGRlc2NyaWJlcyBob3cgdG8gdXNlIEVDTiB3aXRoIFJUUCBvbiBVRFAsIGFsdGhvdWdo IGFzIHlvdSBzYXkgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9uIGRpZmZpY3VsdGllcyBvbiBzb21l IHBsYXRmb3Jtcy4gSeKAmW0gbm90IHN1cmUgd2hldGhlciB0aGVyZSBhcmUgaW1wbGVtZW50YXRp b25zLg0KDQoNCg0KNSkgIFdoYXQgZWxzZSBkaWQgSSBtaXNzIGluIHRoZSBwYXN0IHllYXIgSSBz aG91bGQga25vdyBhYm91dD8NCg0KRm9yIFRDUCBhbmQgU0NUUCBjb25nZXN0aW9uIGNvbnRyb2xs ZXJzLCB3ZSdyZSBiYWNrIHRvIG9uZSBEU0NQIG1hcmtpbmcNCnBlciBmbG93LCBhbmQgcmVzZXR0 aW5nIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgc3RhdGUgaWYgRFNDUCBtYXJraW5nDQpjaGFuZ2Vz Lg0KDQoNClRoZXJlIGlzIGEgbmV3IElDRSB3Zy4gSXQgd2FzIGNyZWF0ZWQgc28g4oCcbmV0d29y ayBwZW9wbGXigJ0gY291bGQgcGFydGljaXBhdGUgd2l0aG91dCB0aGUgb3ZlcmhlYWQgb2YgbGlz dGVuaW5nIHRvIHRoZSBTRFAgcmVsYXRlZCBkaXNjdXNzaW9ucy4gKGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvd2cvaWNlL2NoYXJ0ZXIvKQ0KDQouLS4NClDDpWwtRXJpaw0KDQoNCg0KRmVl bCBmcmVlIHRvIGNvbnRhY3QgbWUgb2ZmIGxpc3QgaWYgdGhlc2UgaGF2ZSBhbHJlYWR5IGJlZW4g ZGlzY3Vzc2VkLg0KSSBoYXZlIHRvdGFsbHkgbG9zdCB0cmFjayBvZiB0aGUgcmVsZXZhbnQgZHJh ZnRzLg0KDQpUaGV5J3JlIG5vdCBmaW5pc2hlZCBzdGlsbCA6LSkNCg0KDQoNClNpbmNlcmVseSwN Cg0KRGF2ZSBUw6RodA0KSSBqdXN0IGxvc3QgZml2ZSB5ZWFycyBvZiBteSBsaWZlIHRvIG1ha2lu ZyB0aGUgZWRnZQ0Kb2YgdGhlIGludGVybmV0LCBhbmQsIHdpZmkgYmV0dGVyLg0KQW5kLCBub3cu Li4gdGhlIEZDQyB3YW50cyB0byBtYWtlIG15IHdvcmsgaWxsZWdhbA0KZm9yIG9yZGluYXJ5IHBl b3BsZSB0byBpbnN0YWxsLg0KaHR0cHM6Ly93d3cuZ29mdW5kbWUuY29tL3NhdmV3aWZpDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5v cmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViDQoNCg0KLS0NCkNvbGluIFBlcmtpbnMNCmh0dHBzOi8vY3NwZXJraW5z Lm9yZy8NCg0KDQoNCg== --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3AESESSMB205erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTHVjaWRhIFNhbnMgVHlwZXdyaXRlciI7DQoJcGFub3NlLTE6MiAxMSA1IDkg MyA1IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBw bGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlNWIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkEgZm9sbG93dXAgb24gdGhlIEVDTiBkaXNjdXNzaW9uIDo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uZ2VzdGlvbiBjb250cm9sIHdpc2UgKFJNQ0FUKSBib3Ro IE5BREEgYW5kIFNDUmVBTSBzdXBwb3J0IEVDTiBpbiB0aGUgc3BlY2lmaWNhdGlvbi4gSW4gYWRk aXRpb24gTVRTSSAoM0dQUCBTQTQpIHN1cHBvcnQgRUNOIGluIHRoZSBzcGVjaWZpY2F0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gU0NSZUFNLCB0aGUg c3VwcG9ydCBpcyBub3QgZnVsbHkgaW1wbGVtZW50ZWQgaW4gcnVubmluZyBjb2RlIGJ1dCBoZSBm ZWVkYmFjayBpcyBpbiBwbGFjZSBhbmQgdGhlIGFkZGl0aW9uYWwgYW1vdW50IG9mIGNvZGUgbmVl ZGVkIHRvIGdldCBFQ04NCiBzdXBwb3J0IGlzIHZlcnkgc21hbGwuIFRoZSBsYXRlc3Qgc3BlY2lm aWNhdGlvbiBob3dldmVyIGV4cGxhaW5zIHRoZSBFQ04gc3VwcG9ydCwgdGhlIGJlaGF2aW9yIGlz IHZlcnkgc2ltaWxhciB0byBSRkMzMTY4IGFzIFNDUmVBTSBpcyBhIHNlbGYtY2xvY2tlZCBwcm90 b2NvbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGN1 cnJlbnQgc25hZyBpcyB0aGF0IHRoZSBzb2NrZXRzIG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8gZ2l2 ZSBhY2Nlc3MgdG8gdGhlIHR3byBFQ04gYml0cy4gTW9yZSBzcGVjaWZpY2FsbHksIHdoYXQgaXMg bmVlZGVkIGlzIHRvIGJlIGFibGUgdG8NCiBzZXQgdGhlIHR3byBFQ04gYml0cyBhbmQgdG8gcmVh ZCB0aGUgc2FtZSB0d28gRUNOIGJpdHMgaW4gdGhlIElQIGhlYWRlciwgdGhpcyBpcyBhbHNvIHN0 YXRlZCBpbiBzZWN0aW9uIDkgaW4gUkZDNjY3OSAuIEhlcmUgSSBiZWxpZXZlIHRoYXQgb25lIGNh biBlYXNpbHkgc3BlbmQgbW9yZSB0aW1lIGRpc2N1c3NpbmcgdGhlIGdvb2QgYW5kIGJhZCBzaWRl cyBvZiBhZGRpbmcgRUNOIHN1cHBvcnQgdG8gdGhlIHNvY2tldCBpbnRlcmZhY2UgdGhhbiBpdA0K IGFjdHVhbGx5IHRha2VzIHRvIGltcGxlbWVudCBpdCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEIj5KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+IC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TmV0d29y ayB3aXNlLCBJIGd1ZXNzIHRoZSBzdXBwb3J0IGZvciBFQ04gZm9yIFVEUCBpcyBhIG1hdHRlciBv ZiBjb25maWd1cmF0aW9uLCBidXQgaWYgb25lIGxvb2sgZnJvbSBzdHJpY3QgcmFkaW8gKExURSkg cGVyc3BlY3RpdmUgaXQgZG9lcyBub3QNCiByZWFsbHkgbWF0dGVyIGlmIGl0IGlzIFVEUCBvciBU Q1Agb3ZlciBJUCwgaXQgaXMgdHJlYXRlZCB0aGUgc2FtZSwgdGh1cyB0aGUgc3RyYXRlZ3kgZm9y IEVDTiBtYXJraW5nIHNob3VsZCBiZSB0aGUgc2FtZSBhbmQgc2hvdWxkIHByZWZlcmFibHkgZm9s bG93IHRoZSBndWlkZWxpbmVzIGluIFJGQzc1NjcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDb2xpbiBQZXJraW5zIFtt YWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDIyIG9rdG9i ZXIgMjAxNSAxMToxNDxicj4NCjxiPlRvOjwvYj4gUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpPGJy Pg0KPGI+Q2M6PC9iPiBjYWtlQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldDsgcm1jYXRAaWV0Zi5vcmc7 IHJ0Y3dlYkBpZXRmLm9yZzsgRGF2ZSBUYWh0OyBhcW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtybWNhdF0gW3J0Y3dlYl0gQ2F0Y2hpbmcgdXAgb24gZGlmZnNlcnYgbWFya2lu Z3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gMjIgT2N0IDIwMTUsIGF0IDA4OjQ4LCBQYWwgTWFydGluc2VuIChwYWxtYXJ0 aSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20iPnBhbG1hcnRpQGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gMjEgT2N0IDIwMTUsIGF0IDE4OjEwLCBIYXJhbGQgQWx2ZXN0cmFuZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vIj5oYXJhbGRAYWx2ZXN0cmFu ZC5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZW4gMjEuIG9rdC4gMjAxNSAxNzo1MSwg c2tyZXYgRGF2ZSBUYWh0OjxiciBzdHlsZT0ib3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0 O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHVuc3Vic2NyaWJlZCBmcm9tIHJtY2F0 IGFuZCBydGN3ZWIgZ3JvdXBzIGEgd2hpbGUgYmFjayBhZnRlciBJIGdvdDxicj4NCm92ZXJsb2Fk ZWQsIGFuZCBhcHBlYXIuaW4gc3RhcnRlZCB3b3JraW5nIHNvIHdlbGwsIChmb3IgYm90aCBpcHY2 IGFuZDxicj4NCmlwdjQhIEkgdXNlIGl0IGFsbCBkYXkgbG9uZyBub3chKSwgdG8gZm9jdXMgb24g ZmluaXNoaW5nIHVwIHRoZSBuZXc8YnI+DQomcXVvdDtjYWtlJnF1b3Q7IHFkaXNjL3NoYXBlci9h cW0vUW9TIHN5c3RlbSwgYW1vbmcgb3RoZXIgdGhpbmdzLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0 dHA6Ly93d3cuYnVmZmVyYmxvYXQubmV0L3Byb2plY3RzL2NvZGVsL3dpa2kvQ2FrZVRlY2huaWNh bCI+aHR0cDovL3d3dy5idWZmZXJibG9hdC5uZXQvcHJvamVjdHMvY29kZWwvd2lraS9DYWtlVGVj aG5pY2FsPC9hPjxicj4NCjxicj4NCkNha2UgaXMgbm93IGVudGVyaW5nIHRoZSB0ZXN0bGFiLCBh bmQgYW1vbmcgb3RoZXIgdGhpbmdzLCBpdCBoYXM8YnI+DQpzdXBwb3J0IGZvciB0aGUgZGlmZnNl cnYgbWFya2luZ3MgZGlzY3Vzc2VkIGluIHRoZSByZWxhdGVkLCBub3c8YnI+DQpjb25jbHVkZWQg ZGFydCB3ZywgYnV0IGluIHdheXMgc29tZXdoYXQgZGlmZmVyZW50IGZyb20gdGhhdCBpbWFnaW5l ZDxicj4NCnRoZXJlLiBXZSBoYXZlIG5vdCBnb3QgYW55IGdvb2QgY29kZSBpbiBvdXIgdGVzdGJl ZHMgeWV0IHRvIHRlc3Q8YnI+DQp2aWRlb2NvbmZlcmVuY2luZyBiZWhhdmlvciwgYW5kIHdlIGNv dWxkIHVzZSBzb21lLCBhbHRob3VnaCBpdCBkb2VzPGJyPg0KbG9vayBsaWtlIHdlIGNhbiBkcml2 ZSBmaXJlZm94IHdpdGggc29tZSByZW1vdGUgY29udHJvbCBzdHVmZiB3aXRoIGE8YnI+DQpmaXhl ZCB2aWRlbyBwbGF5YmFjayBub3cuLi4uPGJyPg0KPGJyPg0KRml2ZSBxdWVzdGlvbnM6PGJyPg0K PGJyPg0KMSkgSGFzIGFueW9uZSBpbXBsZW1lbnRlZCBvciB0ZXN0ZWQgcHV0dGluZyB2b2ljZSBh bmQgdmlkZW8gb24gdHdvPGJyPg0KZGlmZmVyZW50IDUtdHVwbGVzIGluIGFueSBydW5uaW5nIGNv ZGUgb3V0IHRoZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkFsbCBWQyBzeXN0ZW1zIEkga25v dyBvZiBleGNlcHQgV2ViUlRDLWJhc2VkIG9uZXMgZG8gaXQsIEFGQUlLLjxicj4NCkl04oCZcyBw dXR0aW5nIHRoZW0gb24gdGhlIHNhbWUgdGhhdCdzIHVudXN1YWwuPGJyIHN0eWxlPSJvcnBoYW5z OiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YXQgc291bmRzIGxpa2UgdGhlIHdvcmxkIEkgYW0gbGl2aW5nIGluIGFzIHdlbGwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIpIEhvdyBh Ym91dCBkaWZmc2VydiBtYXJraW5ncyBpbiBnZW5lcmFsPyBEbyBhbnkgYnJvd3NlcnMgb3Igd2Vi cnRjPGJyPg0KY2FwYWJsZSBzb2Z0d2FyZSBzdXBwb3J0IHdoYXQgd2FzIGRpc2N1c3NlZCB3YXkg YmFjayB3aGVuPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkkga25vdyBI YW5nb3V0cyBkaWQgc29tZXRoaW5nIGxpa2UgdGhhdCBpbnRlcm5hbGx5LCBvbiB0aGUgY29udHJv bGxlZDxicj4NCm5ldHdvcmsuIEJ1dCBub3QgYWNjb3JkaW5nIHRvIHNwZWMuPGJyPg0KPGJyIHN0 eWxlPSJvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjMpIFdlcmUgZGlmZnNlcnYgbWFya2luZyBjaGFuZ2VzIGV2ZW50dWFsbHkgYWxs b3dlZCBvbiB0aGUgc2FtZSA1LXR1cGxlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NClllcywgd2l0 aCBjYXZlYXRzLiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MgaGFzIHRoZSB0YWJsZS48YnI+ DQo8YnIgc3R5bGU9Im9ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+NCkgRGlkIHRoZSBFQ04gc3VwcG9ydCB0aGF0IHdhcyBvcmlnaW5h bGx5IGluIG9uZSBkcmFmdCBvciBhbm90aGVyPGJyPg0KZXZlciBtYWtlIGl0IGludG8gYW55IHJ1 bm5pbmcgY29kZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCkkgZG9uJ3Qga25vdy4gSSB0aGluayB3ZSBsb3N0IGl0IGZyb20gdGhlIGRvY3MuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv cmQtc3BhY2luZzowcHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4oeWVhLCBhcHBsZSBwbGFu cyB0byB0dXJuIG9uIGVjbiB1bml2ZXJzYWxseSBpbiB0aGVpciBuZXh0IE9TISk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBob3cgd291bGQgRUNOIHdvcmsgb24gVURQPyBJIGRv IG5vdCB0aGluayB0aGUgbmVjZXNzYXJ5IGJpdHMgZnJvbSB0aGUgSVAgaGVhZGVyIGFyZSBhdmFp bGFibGUgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkbyBhbnl0aGluZy4gSSBkbyB0aGluayBMaW51 eCBzdXBwb3J0cyB0aGlzLCBoYXZlIG5vdCB0ZXN0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB3aGF0IGFib3V0IHRoZSBuZXR3b3Jr LCB3b3VsZCBpdCBzdXBwb3J0IFVEUCB3aGVuIHNldHRpbmcgdGhlIEVDTiBiaXRzPyBQcm9iYWJs eSBhIGNvbmZpZ3VyYXRpb24gcmVsYXRlZCBwcm9ibGVtIGlmIG5vdCBzdXBwb3J0ZWQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyA2Njc5IGRlc2NyaWJlcyBob3cgdG8g dXNlIEVDTiB3aXRoIFJUUCBvbiBVRFAsIGFsdGhvdWdoIGFzIHlvdSBzYXkgdGhlcmUgYXJlIGlt cGxlbWVudGF0aW9uIGRpZmZpY3VsdGllcyBvbiBzb21lIHBsYXRmb3Jtcy4gSeKAmW0gbm90IHN1 cmUgd2hldGhlciB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij41KSAmbmJzcDtXaGF0IGVsc2UgZGlkIEkg bWlzcyBpbiB0aGUgcGFzdCB5ZWFyIEkgc2hvdWxkIGtub3cgYWJvdXQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KRm9yIFRDUCBhbmQgU0NUUCBjb25nZXN0aW9uIGNvbnRy b2xsZXJzLCB3ZSdyZSBiYWNrIHRvIG9uZSBEU0NQIG1hcmtpbmc8YnI+DQpwZXIgZmxvdywgYW5k IHJlc2V0dGluZyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIHN0YXRlIGlmIERTQ1AgbWFya2luZzxi cj4NCmNoYW5nZXMuPGJyIHN0eWxlPSJvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhIG5ldyBJQ0Ugd2cuIEl0IHdhcyBjcmVh dGVkIHNvIOKAnG5ldHdvcmsgcGVvcGxl4oCdIGNvdWxkIHBhcnRpY2lwYXRlIHdpdGhvdXQgdGhl IG92ZXJoZWFkIG9mIGxpc3RlbmluZyB0byB0aGUgU0RQIHJlbGF0ZWQgZGlzY3Vzc2lvbnMuICg8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2ljZS9jaGFydGVyLyI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9pY2UvY2hhcnRlci88L2E+KTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4uLS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlDDpWwtRXJpazxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCkZlZWwgZnJlZSB0byBjb250YWN0IG1lIG9mZiBsaXN0IGlmIHRoZXNlIGhhdmUgYWxy ZWFkeSBiZWVuIGRpc2N1c3NlZC48YnI+DQpJIGhhdmUgdG90YWxseSBsb3N0IHRyYWNrIG9mIHRo ZSByZWxldmFudCBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K VGhleSdyZSBub3QgZmluaXNoZWQgc3RpbGwgOi0pPGJyPg0KPGJyIHN0eWxlPSJvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KU2luY2VyZWx5LDxicj4NCjxicj4NCkRhdmUg VMOkaHQ8YnI+DQpJIGp1c3QgbG9zdCBmaXZlIHllYXJzIG9mIG15IGxpZmUgdG8gbWFraW5nIHRo ZSBlZGdlPGJyPg0Kb2YgdGhlIGludGVybmV0LCBhbmQsIHdpZmkgYmV0dGVyLjxicj4NCkFuZCwg bm93Li4uIHRoZSBGQ0Mgd2FudHMgdG8gbWFrZSBteSB3b3JrIGlsbGVnYWw8YnI+DQpmb3Igb3Jk aW5hcnkgcGVvcGxlIHRvIGluc3RhbGwuPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29mdW5k bWUuY29tL3NhdmV3aWZpIj5odHRwczovL3d3dy5nb2Z1bmRtZS5jb20vc2F2ZXdpZmk8L2E+PGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxp c3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7THVjaWRhIFNhbnMgVHlwZXdyaXRlciZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXImcXVv dDs7Y29sb3I6YmxhY2siPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXImcXVvdDs7Y29sb3I6YmxhY2siPkNvbGluIFBlcmtpbnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIFNhbnMgVHlwZXdyaXRlciZx dW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cHM6 Ly9jc3BlcmtpbnMub3JnLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7THVj aWRhIFNhbnMgVHlwZXdyaXRlciZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3AESESSMB205erics_-- From nobody Fri Oct 23 10:46:36 2015 Return-Path: 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 434A51A88D6 for ; Fri, 23 Oct 2015 10:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.6 X-Spam-Level: ** X-Spam-Status: No, score=2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QZrdpt5_-P0 for ; Fri, 23 Oct 2015 10:46:33 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB0D1A88D0 for ; Fri, 23 Oct 2015 10:46:32 -0700 (PDT) Received: by vkex70 with SMTP id x70so67958269vke.3 for ; Fri, 23 Oct 2015 10:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mIp/KbhCL4XnmdAgQAFCgKPL7RBqWYu5PKxEkf1frQg=; b=dO6DyOE4KAUCS39SS8qzwDAhege4zxpGEBsvQpIyBDisWLg/q4u+anu/J3b30FI4M9 NFceJ5foVsnTlKbAAjV/9lstJhC0RcAZcF5Rb7+oPhOkX3vgYRrM5vJH1mv6H9s4Jdjw FugB+3bwMxWTq/OW0hqCVcaILuA/bXkQ79es1qYo0JuGCK1vOXX9xuMI42ak4ug1lnvm rWZkzNTkEMjaKr/8EZf3gaBQu72Yy0rtcn/Q9go1VwQx0iwQA8EFyxfNUsfOWLVTKBJh oOyZ0jRbIUW898QCDjhZ00DlncY/ZhjoUwl3NbW+PmNlQlnDYrcxBDe+9u4WdWihyqce ZJgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mIp/KbhCL4XnmdAgQAFCgKPL7RBqWYu5PKxEkf1frQg=; b=MF7E0cIRnSNB7iW2f6epUVBAgLkQ36C7Xj3FzfDSS4F6KY/rwwEszc31u8iiwkhEWH 68k7kdMNPL9U1TJ7DuC1r/4p9+84meFYQDa9w//OyEzhu2pOEIsY44IGHpM4Scg8Dwel UK90Fz6EauRrIMXl8OYDgy34M0aOfPlfqapiqKaKyK7uvEoLeslToOoELYo9VvAQtUvC OVg0nAozyY5RdqNIuleIkqY7sxtngvoQUrTRnwMQfOF2iZAFr9qm0JB6zY89tPcbtXd2 w8j0P0PBer9dS1I7GwVIkY4xDfFil2GvQgVy6/ZXj9/spFBPf1newRMa8myscxoySyhm 3hiQ== X-Gm-Message-State: ALoCoQnI8mB9i1/42jA4nO7WKbRWQy9b32WXzjQOfwCuYJ2sKd0+DfkRAzJeYJO0KCPxsqxQzlMI X-Received: by 10.31.41.149 with SMTP id p143mr14168903vkp.4.1445622391812; Fri, 23 Oct 2015 10:46:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.201 with HTTP; Fri, 23 Oct 2015 10:46:12 -0700 (PDT) In-Reply-To: <5629F10B.6050503@alvestrand.no> References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> <5629F10B.6050503@alvestrand.no> From: Justin Uberti Date: Fri, 23 Oct 2015 10:46:12 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113ee6a42507720522c93181 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Oct 2015 17:46:36 -0000 --001a113ee6a42507720522c93181 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right; I checked and while IP_RECVTOS isn't exposed to Java, I think you can setsockopt/recvmsg to get the ECN data when writing to the Android NDK. On Fri, Oct 23, 2015 at 1:34 AM, Harald Alvestrand wrote: > ECN markings are just a byte in the IP header. > > The brutal way to do this is to get your packets as raw packets, and > doing UDP processing yourself. > > The less brutal way on Linux is to use setsockopt(IP_RECVTOS) ("since > Linux 2.2" according to "man 7 ip"). There's a 2012 FreeBSD code example > from Michael Tuexen here: > > http://lists.freebsd.org/pipermail/freebsd-net/2012-June/032519.html > > (Linux and FreeBSD may not count as "widely deployed" on the desktop, > but Linux wrapped up as Android is a fairly frequent player in the > mobile space.) > > Den 22. okt. 2015 21:54, skrev Justin Uberti: > > At present I'm not aware of any widely-deployed OS where an app can rea= d > > the received ECN markings. > > > > iOS9 added support for this within the kernel, and it's used for TCP, > > but not exposed to userspace. There is an open Radar bug asking for thi= s > > info to be exposed to userspace. > > > > FWIW, Chrome supports setting the DSCP markings if you set a magic > > parameter. But it's not on by default, mainly because we've never done > > the auditing necessary to ensure this doesn't randomly break in various > > dimly-lit parts of the internet. > > > > On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins > > wrote: > > > >> On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) > >> > wrote: > >> > >> > >>> On 21 Oct 2015, at 18:10, Harald Alvestrand >>> > wrote: > >>> > >>> Den 21. okt. 2015 17:51, skrev Dave Taht: > >>>> I unsubscribed from rmcat and rtcweb groups a while back after I > got > >>>> overloaded, and appear.in started working so > >>>> well, (for both ipv6 and > >>>> ipv4! I use it all day long now!), to focus on finishing up the > new > >>>> "cake" qdisc/shaper/aqm/QoS system, among other things. > >>>> > >>>> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical > >>>> > >>>> Cake is now entering the testlab, and among other things, it has > >>>> support for the diffserv markings discussed in the related, now > >>>> concluded dart wg, but in ways somewhat different from that > imagined > >>>> there. We have not got any good code in our testbeds yet to test > >>>> videoconferencing behavior, and we could use some, although it > does > >>>> look like we can drive firefox with some remote control stuff > with a > >>>> fixed video playback now.... > >>>> > >>>> Five questions: > >>>> > >>>> 1) Has anyone implemented or tested putting voice and video on t= wo > >>>> different 5-tuples in any running code out there? > >>> > >>> All VC systems I know of except WebRTC-based ones do it, AFAIK. > >>> It=E2=80=99s putting them on the same that's unusual. > >>> > >> That sounds like the world I am living in as well. > >> > >> > >>>> 2) How about diffserv markings in general? Do any browsers or > webrtc > >>>> capable software support what was discussed way back when? > >>> > >>> I know Hangouts did something like that internally, on the > controlled > >>> network. But not according to spec. > >>> > >>>> 3) Were diffserv marking changes eventually allowed on the same > >>>> 5-tuple? > >>> > >>> Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table. > >>> > >>>> 4) Did the ECN support that was originally in one draft or anoth= er > >>>> ever make it into any running code? > >>> > >>> I don't know. I think we lost it from the docs. > >>> > >>>> (yea, apple plans to turn on ecn universally in their next OS!) > >>>> > >> So how would ECN work on UDP? I do not think the necessary bits > >> from the IP header are available for the application to do > >> anything. I do think Linux supports this, have not tested. > >> > >> And what about the network, would it support UDP when setting the > >> ECN bits? Probably a configuration related problem if not supporte= d. > > > > RFC 6679 describes how to use ECN with RTP on UDP, although as you > > say there are implementation difficulties on some platforms. I=E2= =80=99m not > > sure whether there are implementations. > > > > > >>>> 5) What else did I miss in the past year I should know about? > >>> > >>> For TCP and SCTP congestion controllers, we're back to one DSCP > >>> marking > >>> per flow, and resetting the congestion control state if DSCP > marking > >>> changes. > >>> > >> > >> There is a new ICE wg. It was created so =E2=80=9Cnetwork people= =E2=80=9D could > >> participate without the overhead of listening to the SDP related > >> discussions. (https://datatracker.ietf.org/wg/ice/charter/) > >> > >> .-. > >> P=C3=A5l-Erik > >> > >>>> > >>>> Feel free to contact me off list if these have already been > >>>> discussed. > >>>> I have totally lost track of the relevant drafts. > >>> > >>> They're not finished still :-) > >>> > >>>> > >>>> Sincerely, > >>>> > >>>> Dave T=C3=A4ht > >>>> I just lost five years of my life to making the edge > >>>> of the internet, and, wifi better. > >>>> And, now... the FCC wants to make my work illegal > >>>> for ordinary people to install. > >>>> https://www.gofundme.com/savewifi > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > -- > > Colin Perkins > > https://csperkins.org/ > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > --001a113ee6a42507720522c93181 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right; I checked and while IP_RECVTOS isn't exposed to= Java, I think you can setsockopt/recvmsg to get the ECN data when writing = to the Android NDK.

On Fri, Oct 23, 2015 at 1:34 AM, Harald Alvestrand = <harald@alvest= rand.no> wrote:
ECN marking= s are just a byte in the IP header.

The brutal way to do this is to get your packets as raw packets, and
doing UDP processing yourself.

The less brutal way on Linux is to use setsockopt(IP_RECVTOS) ("since<= br> Linux 2.2" according to "man 7 ip"). There's a 2012 Free= BSD code example
from Michael Tuexen here:

http://lists.freebsd.org/piperma= il/freebsd-net/2012-June/032519.html

(Linux and FreeBSD may not count as "widely deployed" on the desk= top,
but Linux wrapped up as Android is a fairly frequent player in the
mobile space.)

Den 22. okt. 2015 21:54, skrev Justin Uberti:
> At present I'm not aware of any widely-deployed OS where an app ca= n read
> the received ECN markings.
>
> iOS9 added support for this within the kernel, and it's used for T= CP,
> but not exposed to userspace. There is an open Radar bug asking for th= is
> info to be exposed to userspace.
>
> FWIW, Chrome supports setting the DSCP markings if you set a magic
> parameter. But it's not on by default, mainly because we've ne= ver done
> the auditing necessary to ensure this doesn't randomly break in va= rious
> dimly-lit parts of the internet.
>
> On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins <csp@csperkins.org
> <mailto:csp@csperkins.org>> wrote:
>
>>=C2=A0 =C2=A0 =C2=A0On 22 Oct 2015, at 08:48, Pal Martinsen (palmar= ti)
>>=C2=A0 =C2=A0 =C2=A0<palmarti@cisco.com <mailto:palmarti@cisco.com>> wrote:
>>
>>
>>>=C2=A0 =C2=A0 =C2=A0On 21 Oct 2015, at 18:10, Harald Alvestrand= <harald@alvestrand.no
>>>=C2=A0 =C2=A0 =C2=A0<mailto:harald@alvestrand.no>> wrote: >>>
>>>=C2=A0 =C2=A0 =C2=A0Den 21. okt. 2015 17:51, skrev Dave Taht: >>>>=C2=A0 =C2=A0 =C2=A0I unsubscribed from rmcat and rtcweb gr= oups a while back after I got
>>>>=C2=A0 =C2=A0 =C2=A0overloaded, and appear.in <http://appear.in= > started working so
>>>>=C2=A0 =C2=A0 =C2=A0well, (for both = ipv6 and
>>>>=C2=A0 =C2=A0 =C2=A0ipv4! I use it all day long now!), to f= ocus on finishing up the new
>>>>=C2=A0 =C2=A0 =C2=A0"cake" qdisc/shaper/aqm/QoS s= ystem, among other things.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0http= ://www.bufferbloat.net/projects/codel/wiki/CakeTechnical
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Cake is now entering the testlab, and a= mong other things, it has
>>>>=C2=A0 =C2=A0 =C2=A0support for the diffserv markings discu= ssed in the related, now
>>>>=C2=A0 =C2=A0 =C2=A0concluded dart wg, but in ways somewhat= different from that imagined
>>>>=C2=A0 =C2=A0 =C2=A0there. We have not got any good code in= our testbeds yet to test
>>>>=C2=A0 =C2=A0 =C2=A0videoconferencing behavior, and we coul= d use some, although it does
>>>>=C2=A0 =C2=A0 =C2=A0look like we can drive firefox with som= e remote control stuff with a
>>>>=C2=A0 =C2=A0 =C2=A0fixed video playback now....
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Five questions:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A01) Has anyone implemented or tested put= ting voice and video on two
>>>>=C2=A0 =C2=A0 =C2=A0different 5-tuples in any running code = out there?
>>>
>>>=C2=A0 =C2=A0 =C2=A0All VC systems I know of except WebRTC-base= d ones do it, AFAIK.
>>>=C2=A0 =C2=A0 =C2=A0It=E2=80=99s putting them on the same that&= #39;s unusual.
>>>
>>=C2=A0 =C2=A0 =C2=A0That sounds like the world I am living in as we= ll.
>>
>>
>>>>=C2=A0 =C2=A0 =C2=A02) How about diffserv markings in gener= al? Do any browsers or webrtc
>>>>=C2=A0 =C2=A0 =C2=A0capable software support what was discu= ssed way back when?
>>>
>>>=C2=A0 =C2=A0 =C2=A0I know Hangouts did something like that int= ernally, on the controlled
>>>=C2=A0 =C2=A0 =C2=A0network. But not according to spec.
>>>
>>>>=C2=A0 =C2=A0 =C2=A03) Were diffserv marking changes eventu= ally allowed on the same
>>>>=C2=A0 =C2=A0 =C2=A05-tuple?
>>>
>>>=C2=A0 =C2=A0 =C2=A0Yes, with caveats. draft-ietf-tsvwg-rtcweb-= qos has the table.
>>>
>>>>=C2=A0 =C2=A0 =C2=A04) Did the ECN support that was origina= lly in one draft or another
>>>>=C2=A0 =C2=A0 =C2=A0ever make it into any running code?
>>>
>>>=C2=A0 =C2=A0 =C2=A0I don't know. I think we lost it from t= he docs.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0(yea, apple plans to turn on ecn univer= sally in their next OS!)
>>>>
>>=C2=A0 =C2=A0 =C2=A0So how would ECN work on UDP? I do not think th= e necessary bits
>>=C2=A0 =C2=A0 =C2=A0from the IP header are available for the applic= ation to do
>>=C2=A0 =C2=A0 =C2=A0anything. I do think Linux supports this, have = not tested.
>>
>>=C2=A0 =C2=A0 =C2=A0And what about the network, would it support UD= P when setting the
>>=C2=A0 =C2=A0 =C2=A0ECN bits? Probably a configuration related prob= lem if not supported.
>
>=C2=A0 =C2=A0 =C2=A0RFC 6679 describes how to use ECN with RTP on UDP, = although as you
>=C2=A0 =C2=A0 =C2=A0say there are implementation difficulties on some p= latforms. I=E2=80=99m not
>=C2=A0 =C2=A0 =C2=A0sure whether there are implementations.
>
>
>>>>=C2=A0 =C2=A0 =C2=A05)=C2=A0 What else did I miss in the pa= st year I should know about?
>>>
>>>=C2=A0 =C2=A0 =C2=A0For TCP and SCTP congestion controllers, we= 're back to one DSCP
>>>=C2=A0 =C2=A0 =C2=A0marking
>>>=C2=A0 =C2=A0 =C2=A0per flow, and resetting the congestion cont= rol state if DSCP marking
>>>=C2=A0 =C2=A0 =C2=A0changes.
>>>
>>
>>=C2=A0 =C2=A0 =C2=A0There is a new ICE wg. It was created so =E2=80= =9Cnetwork people=E2=80=9D could
>>=C2=A0 =C2=A0 =C2=A0participate without the overhead of listening t= o the SDP related
>>=C2=A0 =C2=A0 =C2=A0discussions. (https://datatr= acker.ietf.org/wg/ice/charter/)
>>
>>=C2=A0 =C2=A0 =C2=A0.-.
>>=C2=A0 =C2=A0 =C2=A0P=C3=A5l-Erik
>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Feel free to contact me off list if the= se have already been
>>>>=C2=A0 =C2=A0 =C2=A0discussed.
>>>>=C2=A0 =C2=A0 =C2=A0I have totally lost track of the releva= nt drafts.
>>>
>>>=C2=A0 =C2=A0 =C2=A0They're not finished still :-)
>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Sincerely,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Dave T=C3=A4ht
>>>>=C2=A0 =C2=A0 =C2=A0I just lost five years of my life to ma= king the edge
>>>>=C2=A0 =C2=A0 =C2=A0of the internet, and, wifi better.
>>>>=C2=A0 =C2=A0 =C2=A0And, now... the FCC wants to make my wo= rk illegal
>>>>=C2=A0 =C2=A0 =C2=A0for ordinary people to install.
>>>>=C2=A0 =C2=A0 =C2=A0https://www.gofundme.com/savewi= fi
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0_______________________________________= ________
>>>>=C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>>>>=C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <mailto:r= tcweb@ietf.org>
>>>>=C2=A0 =C2=A0 =C2=A0htt= ps://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0___________________________________________= ____
>>>=C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>>>=C2=A0 =C2=A0 =C2=A0r= tcweb@ietf.org <mailto:rtcweb@iet= f.org>
>>>=C2=A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/rtcweb
>>
>>=C2=A0 =C2=A0 =C2=A0_______________________________________________=
>>=C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>>=C2=A0 =C2=A0 =C2=A0rtcwe= b@ietf.org <mailto:rtcweb@ietf.or= g>
>>=C2=A0 =C2=A0 =C2=A0ht= tps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Colin Perkins
>=C2=A0 =C2=A0 =C2=A0https://csperkins.org/
>
>
>
>
>
>
>
> _______________________= ________________________
> 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

--001a113ee6a42507720522c93181-- From nobody Tue Oct 27 09:16:41 2015 Return-Path: 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 839C51A92A9 for ; Tue, 27 Oct 2015 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUzlZoIzbDz5 for ; Tue, 27 Oct 2015 09:16:38 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B591A92B2 for ; Tue, 27 Oct 2015 09:16:37 -0700 (PDT) Received: by vkgs66 with SMTP id s66so63768362vkg.1 for ; Tue, 27 Oct 2015 09:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PcgnF2x4GVmXSsm8zJIWXm3CZSEmspb8BIhXcwmAY1Y=; b=jqmxJYW93f2Y+LA3gDaMibxuobRPw0xbm/pbS5d344oFvaNnTlKCUa9EN4TYeWVBgp FEzWcjrColTqtJtJrNR6j45ECAodqGK+dR6mgXe5ya7mk9n6RIJU/fkIA8Tg+ez+l6D9 tfHA79gjECAA32LSiqaKRQmhCL6EwhP3CKpOvqMKhpVFd1zj/lyGWS650DAJLy1Ehwsq brcTcu7KjCvz4/5WCbbMj9Zmnu8JrzEMZ/LwfLJlN8NIeLOJQZJnY493/bXInxj2ftI+ lJBJH/gO1V/iZyvEkYU1sVis6K1zEqGrklzUyxSKIrYa41uOjBDpCq5E01VSRBib19aa /3CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PcgnF2x4GVmXSsm8zJIWXm3CZSEmspb8BIhXcwmAY1Y=; b=kRuEdxofhs/OxLcwC+8eA3gqZug+N+stH4DHPerSOjWdOgO3XNJWinWi3gSuKjVVQy GLOWTa5iQlwyZ4oMCW556NgXDgh18MYNjJOvC0CFtO1CV1bjN6q4hyXvu3RbJYOHf4Kz fTS0KcZzkhgfWDc072JY6QkyzeDtXKorje9VvBEbpUkOOHH+n3MnChuRJOg7REsPAKjq cZvVHV7A62g3wbetGg3LcU57p3uJop+4FwXgOiozfvt7aOSabcxWbqmmgWqx4491kbuZ zGMGgicdDCFCMZvktlCPlXExl4B4TKX06dpuq5tR+EPgeU0XUtlns6UwxBjABnh7vwYF baqg== X-Gm-Message-State: ALoCoQmDjTeVjOScaglFAeRRWRKo7a2ioDqH0KgSCJqPoEl2D4zCSB05pFbdv+Yi/JXe0DnRwNas X-Received: by 10.31.185.6 with SMTP id j6mr24048465vkf.98.1445962596837; Tue, 27 Oct 2015 09:16:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.201 with HTTP; Tue, 27 Oct 2015 09:16:17 -0700 (PDT) In-Reply-To: <7AE5EAF1-4177-466F-AEFA-3198F03F24B7@gmx.de> References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> <7AE5EAF1-4177-466F-AEFA-3198F03F24B7@gmx.de> From: Justin Uberti Date: Tue, 27 Oct 2015 09:16:17 -0700 Message-ID: To: Sebastian Moeller Content-Type: multipart/alternative; boundary=001a113bf89ef1c75e05231866c5 Archived-At: Cc: "aqm@ietf.org" , "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [Cake] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 27 Oct 2015 16:16:39 -0000 --001a113bf89ef1c75e05231866c5 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 27, 2015 at 1:06 AM, Sebastian Moeller wrote: > Hi Justin, > > > On Oct 22, 2015, at 21:54 , Justin Uberti wrote: > > > At present I'm not aware of any widely-deployed OS where an app can read > the received ECN markings. > > > > iOS9 added support for this within the kernel, and it's used for TCP, > but not exposed to userspace. There is an open Radar bug asking for this > info to be exposed to userspace. > > > > FWIW, Chrome supports setting the DSCP markings if you set a magic > parameter. But it's not on by default, mainly because we've never done the > auditing necessary to ensure this doesn't randomly break in various > dimly-lit parts of the internet. > > Slightly related question, is this DSCP marking capability > restricted to webrtc packets or is there a way to make chrome use > (arbitrary) DSCP marks for all its packets? For exercising different > priority banding schemes such an option would be perfect (say to test > whether a aqm+qos system will allow snappy browsing even with heavy > download/upload/bittorrent traffic in other priority bands; this test is > especially interesting if all traffic sources can reside on the same host, > as this is a quite common set-up in home networks, one computer that does > everything concurrently and where the users still want a decent browsing > experience). > The option that currently exists only works for WebRTC packets. --001a113bf89ef1c75e05231866c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 27, 2015 at 1:06 AM, Sebastian Moeller &l= t;moeller0@gmx.de&= gt; wrote:
Hi Justin,


On Oct 22, 2015, at 21:54 , Justin Uberti <juberti@google.com> wrote:

> At present I'm not aware of any widely-deployed OS where an app ca= n read the received ECN markings.
>
> iOS9 added support for this within the kernel, and it's used for T= CP, but not exposed to userspace. There is an open Radar bug asking for thi= s info to be exposed to userspace.
>
> FWIW, Chrome supports setting the DSCP markings if you set a magic par= ameter. But it's not on by default, mainly because we've never done= the auditing necessary to ensure this doesn't randomly break in variou= s dimly-lit parts of the internet.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Slightly related question, is this DSCP = marking capability restricted to webrtc packets or is there a way to make c= hrome use (arbitrary) DSCP marks for all its packets? For exercising differ= ent priority banding schemes such an option would be perfect (say to test w= hether a aqm+qos system will allow snappy browsing even with heavy download= /upload/bittorrent traffic in other priority bands; this test is especially= interesting if all traffic sources can reside on the same host, as this is= a quite common set-up in home networks, one computer that does everything = concurrently and where the users still want a decent browsing experience).<= br>

The option that currently exists only w= orks for WebRTC packets.=C2=A0
--001a113bf89ef1c75e05231866c5-- From nobody Sat Oct 31 17:13:23 2015 Return-Path: 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 AAFC51B3F1C; Thu, 22 Oct 2015 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-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 4gef_hlkv2Dt; Thu, 22 Oct 2015 13:02:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E344E1B3F14; Thu, 22 Oct 2015 13:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WYEAcIVfeWE8rkYTK9LbfZLthrVtt0TD81Oi8/LzdTg=; b=HcYU2vgmlhhTCaGaP0+840uDjNjdREoodLYG+qtSsJDzDvvNsRfPXasetgmXhXclH0QPlYcQS1ElwSRe6vYfTXrSndK0p3L3ekocvDnCntoKPPgdbcsNRfmrbZh4bh4KXToM2EH2VLNfGUVTg04VeFLmuwyRida6HoJjT87JooY= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 20:02:21 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 20:02:21 +0000 From: Christian Huitema To: Colin Perkins , "Pal Martinsen (palmarti)" Thread-Topic: [aqm] [rtcweb] Catching up on diffserv markings Thread-Index: AQHRDKoPSPTr9bvTB0K0qipM6TL7n5536tog Date: Thu, 22 Oct 2015 20:02:21 +0000 Message-ID: References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> In-Reply-To: <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.192.202] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:50DYgRZkE01NxTVS6rrFSlvDqm5vz6k+wBhpuuq5IZfM10uJ7D2crgxasFZl+Y5yXuO0EE6lsMBeo4XZ4Y7i/k+2wnYOuMmzZWL6YZZZkpAka0BN9AaA2RuUAJqzLCTbYsIwNKPg0/nBlrf9cit0Ug==; 24:8XimeykfPYntSzk0xd9nGIfubEL/Vs+8fbctFEuM6un//dLhr26VY+CUVCRbZShvnX9EKYRMBpq+3j1c37OyDELZ/JagsPTPS6Y36QpVgQQ=; 20:EfVWGBNLYpnOalFvdj5yvIuHaOWxXtZE8lcdgLNRplBpqedULYk7KYCg65ex2U81UO67Dxk6mpqJ1oGb/xcxsQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026)(61426024)(61427024); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(24454002)(377454003)(86612001)(99286002)(122556002)(97736004)(10290500002)(8990500004)(5003600100002)(10090500001)(77096005)(5007970100001)(102836002)(15975445007)(76576001)(2950100001)(2900100001)(106356001)(66066001)(92566002)(40100003)(87936001)(86362001)(106116001)(5002640100001)(5001770100001)(5004730100002)(81156007)(10400500002)(101416001)(33656002)(76176999)(50986999)(5001960100002)(189998001)(54356999)(93886004)(19580405001)(74316001)(5008740100001)(5005710100001)(105586002)(5001920100001)(19580395003)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 20:02:21.7058 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 17:13:19 -0700 Cc: "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , "aqm@ietf.org" Subject: Re: [rtcweb] [aqm] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 22 Oct 2015 20:02:33 -0000 T24gVGh1cnNkYXksIE9jdG9iZXIgMjIsIDIwMTUgMjoxNCBBTSwgQ29saW4gUGVya2lucyB3cm90 ZToNCj4gT24gMjIgT2N0IDIwMTUsIGF0IDA4OjQ4LCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkg PHBhbG1hcnRpQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBPbiAyMSBPY3QgMjAxNSwgYXQgMTg6MTAs IEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4gd3JvdGU6DQo+Pj4gRGVu IDIxLiBva3QuIDIwMTUgMTc6NTEsIHNrcmV2IERhdmUgVGFodDoNCj4gLi4uDQo+Pj4gRml2ZSBx dWVzdGlvbnM6DQo+Pj4NCj4+PiAxKSBIYXMgYW55b25lIGltcGxlbWVudGVkIG9yIHRlc3RlZCBw dXR0aW5nIHZvaWNlIGFuZCB2aWRlbyBvbiB0d28NCj4+PiBkaWZmZXJlbnQgNS10dXBsZXMgaW4g YW55IHJ1bm5pbmcgY29kZSBvdXQgdGhlcmU/IA0KPj4NCj4+IEFsbCBWQyBzeXN0ZW1zIEkga25v dyBvZiBleGNlcHQgV2ViUlRDLWJhc2VkIG9uZXMgZG8gaXQsIEFGQUlLLiANCj4+IEl04oCZcyBw dXR0aW5nIHRoZW0gb24gdGhlIHNhbWUgdGhhdCdzIHVudXN1YWwuDQo+DQo+IFRoYXQgc291bmRz IGxpa2UgdGhlIHdvcmxkIEkgYW0gbGl2aW5nIGluIGFzIHdlbGwuDQoNClNldmVyYWwgcG9ydHMg aXMgY29tbW9uLCBidXQgeW91IGhhdmUgdG8gY29uc2lkZXIgcHJpb3JpdHkgaXNzdWVzLiBJbiBh IHZpZGVvIGNvbmZlcmVuY2UsIHlvdSB3YW50IHZvaWNlIGFuZCB2aWRlbyB0byBiZSBpbiBzeW5j LCBzbyB0aGUgdXNlciBzZWVzIHRoZSBsaXBzIG1vdmluZyBhdCB0aGUgc2FtZSB0aW1lIGFzIHRo ZSBjb3JyZXNwb25kaW5nIHNvdW5kIGlzIGhlYXJkLiBJbiBmYWN0LCB5b3Ugd2FudCB0byBzZWUg dGhlIGxpcCBtb3Zpbmcgc2xpZ2h0bHkgYmVmb3JlIHlvdSBoZWFyIHRoZSBzb3VuZC4gSWYgdm9p Y2UgYXJyaXZlcyBiZWZvcmUgdmlkZW8sIG1hbnkgc3lzdGVtcyB3aWxsIGRlbGF5IHRoZSBwbGF5 YmFjayBpbiBvcmRlciB0byBhY2hpZXZlIGxpcCBzeW5jaHJvbml6YXRpb24uIFRoZXJlIGlzIG5v dCBhIHdob2xlIGxvdCB0byBiZSBnYWluZWQgYnkgc2VuZGluZyByZWFsLXRpbWUgdm9pY2UgImZh c3RlciIgdGhhbiAidmlkZW8uIg0KDQpEYXZlIGRpZCBub3QgYXNrIHRoZSBxdWVzdGlvbiwgYnV0 IHRoZSBDYWtlIGRvY3VtZW50IGFsc28gbWVudGlvbnMgcGxhY2luZyBnYW1lIHRyYWZmaWMgaW4g dGhlIHZvaWNlIHByaW9yaXR5IGNsYXNzLiBOb3RlIHRoYXQgWGJveCBPbmUsIHRoZSBnYW1lIHRy YWZmaWMgaXMgZW5jcnlwdGVkIHdpdGggSVBTRUMsIGVpdGhlciBuYXRpdmVseSBvdmVyIElQdjYs IG9yIG9mdGVuIHR1bm5lbGVkIG92ZXIgYSBzaW5nbGUgVURQIHBvcnQgZm9yIElQdjQgKGh0dHA6 Ly93d3cubmFub2cub3JnL3NpdGVzL2RlZmF1bHQvZmlsZXMvd2VkLmdlbmVyYWwucGFsbWVyLnhi b3hfLjQ3LnBkZikuIA0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0KDQo= From nobody Sat Oct 31 17:13:25 2015 Return-Path: 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 0DF331A00FE; Fri, 23 Oct 2015 06:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 hx7V-xAZulgW; Fri, 23 Oct 2015 06:29:54 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24181A00F6; Fri, 23 Oct 2015 06:29:53 -0700 (PDT) Received: by lffz202 with SMTP id z202so83711915lff.3; Fri, 23 Oct 2015 06:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sY3IU0oAcWi6s0OlknWBP8EQgbdC4LmXFKtuQX/54ps=; b=vVconhNWXh0bBxZ2keCfMBFoZ8DZd2a79ANoKrn9NsXLx5g7Xa3S0EjQUOlWqC5c+r d85uS5xBqEDs3xUmNnvL+7DITclL9XAVslc02X0e1qBIjHymkXFEAP1WPO5d5V5Anqpa sCZHjJ8+T+OxDrQFsqRUiTbNBYRG0GpYPDeZc2DtuTAoggEtcjruaZS9YBYYoJNR9gYZ rINjsVse5twlqJIgPWelhshhhNTWFf9tQ6ak8UGxqyDPPBTi3B9USXPAlcN5PTEsVov+ xZKb0tlG9cz6QQ7ydMGr1I+/NDWam+YxPLXYKzuN1P6QwMTuZbaJeyhWlFrUd0zFwQ5I bkFg== X-Received: by 10.25.208.141 with SMTP id h135mr7469155lfg.81.1445606992178; Fri, 23 Oct 2015 06:29:52 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-20-216.bb.dnainternet.fi. [87.95.20.216]) by smtp.gmail.com with ESMTPSA id o137sm3305922lfe.31.2015.10.23.06.29.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Oct 2015 06:29:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jonathan Morton In-Reply-To: Date: Fri, 23 Oct 2015 16:29:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> To: Justin Uberti X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 17:13:19 -0700 Cc: "aqm@ietf.org" , "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [Cake] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Oct 2015 13:29:55 -0000 > On 22 Oct, 2015, at 22:54, Justin Uberti wrote: >=20 > At present I'm not aware of any widely-deployed OS where an app can = read the received ECN markings.=20 I have personally verified that this is possible (for UDP) on Linux - we = were investigating the feasibility of adding ECN to uTP (ie. = BitTorrent). The code looks horrid, but what raw sockets code = doesn=E2=80=99t? - Jonathan Morton From nobody Sat Oct 31 17:13:26 2015 Return-Path: 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 E197D1A0108; Fri, 23 Oct 2015 06:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNY_dJ-Hrzeu; Fri, 23 Oct 2015 06:31:58 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974201A00F9; Fri, 23 Oct 2015 06:31:56 -0700 (PDT) Received: by pasz6 with SMTP id z6so118774325pas.2; Fri, 23 Oct 2015 06:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0QKXTZo3L/X2O67++UN6W4oD2Lv0zQbbE4dFJ6mR1sY=; b=fTVFMxteusyU0OnJoAyr2aGyDH5sF8aN/drVXkrAGS/q70aMHaTxJf4sRy+V5QjBl9 GYz/bmYg6Za+TKoOa9/MDYevMDUSR+/1GRtzAx3DPtbzFOKypX7IYz6/5LmPKC4+v0i/ Y3juvFO7hGGm3JF2VYO/0xSD7Aedn9V+xnyyfA2ED5jwyFyLNt5AGg1KqcG3pEKTCWJq 8XPJm6zDqO22A/XEfJbkL67oN5O5NYknXqkC4WAXzdfPGUjdCky4VvrFNtjDrMYmXNAl BYA9j+vBa+gcR2h+o1/c7VFLdu6w0+iFN6dLQBr3QbkPoPNoMyeBuTCuQWcA5HvZGnd5 wuzQ== MIME-Version: 1.0 X-Received: by 10.68.182.161 with SMTP id ef1mr5236114pbc.79.1445607116230; Fri, 23 Oct 2015 06:31:56 -0700 (PDT) Received: by 10.66.23.38 with HTTP; Fri, 23 Oct 2015 06:31:56 -0700 (PDT) In-Reply-To: References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> Date: Fri, 23 Oct 2015 17:31:56 +0400 Message-ID: From: Loganaden Velvindron To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0160bf50a5dac80522c5a29a Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 17:13:19 -0700 Cc: "aqm@ietf.org" , "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [Cake] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Oct 2015 13:32:00 -0000 --089e0160bf50a5dac80522c5a29a Content-Type: text/plain; charset=UTF-8 On Thu, Oct 22, 2015 at 11:54 PM, Justin Uberti wrote: > At present I'm not aware of any widely-deployed OS where an app can read > the received ECN markings. > > iOS9 added support for this within the kernel, and it's used for TCP, but > not exposed to userspace. There is an open Radar bug asking for this info > to be exposed to userspace. > > FWIW, Chrome supports setting the DSCP markings if you set a magic > parameter. But it's not on by default, mainly because we've never done the > auditing necessary to ensure this doesn't randomly break in various > dimly-lit parts of the internet. > > > dimly-lit ? You mean regions like Africa ? --089e0160bf50a5dac80522c5a29a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 22, 2015 at 11:54 PM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
At = present I'm not aware of any widely-deployed OS where an app can read t= he received ECN markings.=C2=A0

iOS9 added support for t= his within the kernel, and it's used for TCP, but not exposed to usersp= ace. There is an open Radar bug asking for this info to be exposed to users= pace.

FWIW, Chrome supports setting the DSCP marki= ngs if you set a magic parameter. But it's not on by default, mainly be= cause we've never done the auditing necessary to ensure this doesn'= t randomly break in various dimly-lit parts of the internet.


dimly-lit= ? You mean regions like Africa ?

=C2=A0
--089e0160bf50a5dac80522c5a29a-- From nobody Sat Oct 31 17:13:28 2015 Return-Path: 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 8006E1A0104; Fri, 23 Oct 2015 06:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 cKY_Vt6pSZlw; Fri, 23 Oct 2015 06:32:30 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F308A1A00F5; Fri, 23 Oct 2015 06:32:27 -0700 (PDT) Received: by lfbn126 with SMTP id n126so49193486lfb.2; Fri, 23 Oct 2015 06:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3gjUNHQDUH3yLDFB3z11m6JH7VW5SUjWLoudeJuvFpg=; b=tcqOzQ3BVE8g+8LAhj4UuZjU95c32mXGc4CvgJAG648P2cQmeQc42tj8Pd/DOlXXBy zNCXEPE2qtJaV1/gCn9V275bToFoENoxu01942yjuv9bwPzccnyHbLgE5uEo4EzulDB/ VQvC9sSib+udn0VXJz96VrivuKmKiV4ACady9Y3lhzh0xZyf+FLIpjtRrKbg0CZJ679K 97X4b0OQDFIa00vVcBKnjm/NxD1io76KwLVGe4626vlZegTzuaZQZhlA7xL4FcHwgtj3 xlIRPYkZW38uM7yTit/UfqTemHN2SxmnVvd9si6K2/BGZmGKB/Dx/tdo8ywa2W0hxSj4 Yh7w== X-Received: by 10.112.141.7 with SMTP id rk7mr10658965lbb.82.1445607146234; Fri, 23 Oct 2015 06:32:26 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-20-216.bb.dnainternet.fi. [87.95.20.216]) by smtp.gmail.com with ESMTPSA id ut10sm3255918lbc.31.2015.10.23.06.32.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Oct 2015 06:32:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jonathan Morton In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3A@ESESSMB205.ericsson.se> Date: Fri, 23 Oct 2015 16:31:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81564C0D7D4D2A4B9A86C8C7404A13DA34C0AE3A@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 17:13:19 -0700 Cc: "aqm@ietf.org" , "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [aqm] ECN support for UDP (was RE: [rmcat] Catching up on diffserv markings) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Oct 2015 13:32:31 -0000 > On 23 Oct, 2015, at 11:40, Ingemar Johansson S = wrote: >=20 > Network wise, I guess the support for ECN for UDP is a matter of = configuration, but if one look from strict radio (LTE) perspective it = does not really matter if it is UDP or TCP over IP, it is treated the = same, thus the strategy for ECN marking should be the same and should = preferably follow the guidelines in RFC7567. All the Linux qdiscs I=E2=80=99m aware of that support ECN are agnostic = to the transport layer in this respect. If ECN capability is advertised = in a packet=E2=80=99s IP header, it=E2=80=99s eligible for ECN CE = marking. - Jonathan Morton From nobody Sat Oct 31 17:13:29 2015 Return-Path: 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 EA06C1ACC7F; Tue, 27 Oct 2015 10:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 P1MtkS5uZftr; Tue, 27 Oct 2015 10:05:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A211A8A95; Tue, 27 Oct 2015 10:05:06 -0700 (PDT) Received: from u-089-d065.biologie.uni-tuebingen.de ([134.2.89.65]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MPppG-1ZuzIF3M7W-004x7r; Tue, 27 Oct 2015 18:05:01 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 27 Oct 2015 18:04:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3976D747-F6DA-4AC4-BCAB-D2B420E25B2D@gmx.de> References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> <7AE5EAF1-4177-466F-AEFA-3198F03F24B7@gmx.de> To: Justin Uberti X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:ly4l91k0sPd78l3//CreRIhFmBzfMQfons8oS4vYkLx7F6kouVf nlvXlOZ/9G7Uhh8PlJlGIEO6AelYtnNc7verIl9NJA0MiP8Q7kHiiI7NOX3MFGAD0XuqY3r TMhyvIsHCfzgaGyJ0AO1eRyH2thuOlS+NXCH1PmAVIfXvbjL3B4lvUtDnoXpS4FxwLL3IDX ege+GAmgRbLYp85gXjw+A== X-UI-Out-Filterresults: notjunk:1;V01:K0:JKswMMFuCW8=:aRbQ3PrzM4FiPszi6iZIdh lm6frKsD8bI4aGULvXWxncbQx3lHsYgf3KabkxVy5yJIIGmYmfM1LU7Uj0ohQ0dB4O/6tQizZ iHVKHBbs/y3bWCY+FAJ5ToU49ypfI++FCgSMsLGKJAj+UxI5Wcfy6A6Qap7HmsBIgr1LFXZMj 0m6mCk0ELyCXias6D98o2wjP+EbcqG14jdHuqGRRo7ecjzkCFqDkC2ZgxTQO1EEg9T7c4/sYw dGnIiHROZKRERgOwaNxOiRW1k6jBiOcTtkjjnOKJY15sTktRoy7Wa6ZWSBTl82/WfagyuZ+r2 8RKz8ViMwcSOqEpkER2veBLmLnaIvQJ9Rt54yp1O6RqoFVSEm6IP59DyTVKU/U8AXOld1Waof aNbowxErk30aNTnYYnhi0BgWc4PQOpwSvuCKfRuqjMWD++ATlaA6LdItrTSARWI0V8XSGQ1AZ sW1pJDALmHylkO/l9ZMu9vr5EgGIiezAR4rdqtDxDBi4O9Z2IDpvgyLx5zBaGRfKR42DOqEvO w8SKLC2qRanSezekGBEPJCcZdmE9NZAXTrzebTxPQmt450uXPvZuoMo1jZcS9DxMHe3yEf7xf Iue1WldACXIRRwYcW9Dsx5+6ct7PNtw9F/eZGTA3PvgSyBxY4u6UEPUzPJyn29HUKG7WiZxjU 22TU21EsmSHaVNpb7mddE5Do1MaZ0qeO/PJTdg9sGxDRARPtnuVpgNxfdJvG+FLkDs9OuFvvB kGt/hlu299pWnDoyJKrWMJaxAISg4jXiUFJYLXkRo0ssvVbMBkqh0D+kiMfYWyfr6W9nAOJuP MUqe8BC Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 17:13:19 -0700 Cc: "aqm@ietf.org" , "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [Cake] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 27 Oct 2015 17:05:25 -0000 Hi Justin, On Oct 27, 2015, at 17:16 , Justin Uberti wrote: >=20 >=20 > On Tue, Oct 27, 2015 at 1:06 AM, Sebastian Moeller = wrote: > Hi Justin, >=20 >=20 > On Oct 22, 2015, at 21:54 , Justin Uberti wrote: >=20 > > At present I'm not aware of any widely-deployed OS where an app can = read the received ECN markings. > > > > iOS9 added support for this within the kernel, and it's used for = TCP, but not exposed to userspace. There is an open Radar bug asking for = this info to be exposed to userspace. > > > > FWIW, Chrome supports setting the DSCP markings if you set a magic = parameter. But it's not on by default, mainly because we've never done = the auditing necessary to ensure this doesn't randomly break in various = dimly-lit parts of the internet. >=20 > Slightly related question, is this DSCP marking capability = restricted to webrtc packets or is there a way to make chrome use = (arbitrary) DSCP marks for all its packets? For exercising different = priority banding schemes such an option would be perfect (say to test = whether a aqm+qos system will allow snappy browsing even with heavy = download/upload/bittorrent traffic in other priority bands; this test is = especially interesting if all traffic sources can reside on the same = host, as this is a quite common set-up in home networks, one computer = that does everything concurrently and where the users still want a = decent browsing experience). >=20 > The option that currently exists only works for WebRTC packets.=20 Ah, thanks, that is a pity. It would be really sweet for testing = different qos systems. I guess on a linux machine I should e able to = fake it with a local iptable rule=85 Best Regards Sebastian= From nobody Sat Oct 31 17:13:32 2015 Return-Path: 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 B32DF1A8840; Thu, 29 Oct 2015 08:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.989 X-Spam-Level: * X-Spam-Status: No, score=1.989 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, FRT_STOCK2=3.988, 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 33E8m5Iws8be; Thu, 29 Oct 2015 08:25:59 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9F21A8725; Thu, 29 Oct 2015 08:25:58 -0700 (PDT) Received: by oifu63 with SMTP id u63so37920839oif.2; Thu, 29 Oct 2015 08:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rCLMcRPDv3sAbFoXS9+fu6LiYiHxlXeCRlr6lWHon80=; b=ivi68Mr7Qna03l7Prvp2CoC5mAsNu++AJ1wMANR8CfxuE/HMGcVomLwsFvhq5icve9 xN0wVC18pTnkC7t5HXbEvrgRbw1yjcS5t0YATdsv35CHLsC/b9srg3shxCoqKx7htDRZ Cq4g7gck3I0aqSl6ZwGo2CMcXYNYAnknw6Uw0Fz0woRNgq1LTiZDGPunnsOTXFEnJtVu zBHqnDOwUIv8+Hmkhq9Kh52JpkXYA5+UMBEUe+XrWKDPJr2A/nSJLVPJWDiK+XyZ30s/ pnOU4AZfyxbGkBuEznwa9FnuksGL0Jpzn0HUhj8xcUdRFgjn1IarRE0D8t4nbHpRuj3f 6WyQ== X-Received: by 10.60.58.67 with SMTP id o3mr1646960oeq.48.1446132358236; Thu, 29 Oct 2015 08:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.88.215 with HTTP; Thu, 29 Oct 2015 08:25:38 -0700 (PDT) In-Reply-To: References: <5627B90D.8070106@alvestrand.no> <43B59C2F-4B64-4318-8339-04903AF2A6AC@cisco.com> <34EEB0FF-1922-42B5-A778-9BB66B7C4FDC@csperkins.org> From: "Piers O'Hanlon" Date: Thu, 29 Oct 2015 15:25:38 +0000 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0158b69a82d41b05233fedc4 Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 17:13:19 -0700 Cc: "aqm@ietf.org" , "cake@lists.bufferbloat.net" , "rmcat@ietf.org" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [rmcat] Catching up on diffserv markings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 29 Oct 2015 15:26:01 -0000 --089e0158b69a82d41b05233fedc4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I implemented some prototype software that read and set ECN for UDP packets whilst working on RFC6679, but there's no published open-source code I'm aware of that fully implements RFC6679. I reported my experiences to the AVT list back in 2011, and I've updated them here: To set ECN on Linux, BSD and OSX one can use IP_TOS socket option, with the setsockopt() call, to set the relevant ECN bits of the TOS byte. On Windows one can use a similar technique though firstly one has to enable TOS byte setting by enabling a particular Registry key ( DisableUserTOSSetting=3D0 (see https://msdn.microsoft.com/en-us/library/windows/desktop/dd874008%28v=3Dvs.= 85%29.aspx One could also probably use the libpcap write functionality. To obtain the ECN bits from a packet one needs a mechanism to retrieve the ECN bits from each packet. On Linux, one needs to firstly set the IP_RECVTOS socket option on the receiving socket, and use the recvmsg() call to receive a packet, and then retrieve the TOS byte from the associated csmg structure returned by the recvmsg() call. This still works with linux-4.2.3. On OSX/BSD there are no suitable socket options to retrieve the ECN/TOS bits and one cannot use raw sockets as they do not function for UDP/TCP sockets (they do work with ICMP), so one has to use alternatives such the bpf interface, or a REDIRECT socket. Whilst on Windows it seems that the only way to retrieve the ECN bits is via a raw socket, or custom NDIS driver, though it's possible there's an API I'm missing. On 22 October 2015 at 20:54, Justin Uberti wrote: > At present I'm not aware of any widely-deployed OS where an app can read > the received ECN markings. > > iOS9 added support for this within the kernel, and it's used for TCP, but > not exposed to userspace. There is an open Radar bug asking for this info > to be exposed to userspace. > > FWIW, Chrome supports setting the DSCP markings if you set a magic > parameter. But it's not on by default, mainly because we've never done th= e > auditing necessary to ensure this doesn't randomly break in various > dimly-lit parts of the internet. > > On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins wrote: > >> On 22 Oct 2015, at 08:48, Pal Martinsen (palmarti) >> wrote: >> >> >> On 21 Oct 2015, at 18:10, Harald Alvestrand wrote= : >> >> Den 21. okt. 2015 17:51, skrev Dave Taht: >> >> I unsubscribed from rmcat and rtcweb groups a while back after I got >> overloaded, and appear.in started working so well, (for both ipv6 and >> ipv4! I use it all day long now!), to focus on finishing up the new >> "cake" qdisc/shaper/aqm/QoS system, among other things. >> >> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical >> >> Cake is now entering the testlab, and among other things, it has >> support for the diffserv markings discussed in the related, now >> concluded dart wg, but in ways somewhat different from that imagined >> there. We have not got any good code in our testbeds yet to test >> videoconferencing behavior, and we could use some, although it does >> look like we can drive firefox with some remote control stuff with a >> fixed video playback now.... >> >> Five questions: >> >> 1) Has anyone implemented or tested putting voice and video on two >> different 5-tuples in any running code out there? >> >> >> All VC systems I know of except WebRTC-based ones do it, AFAIK. >> It=E2=80=99s putting them on the same that's unusual. >> >> That sounds like the world I am living in as well. >> >> >> 2) How about diffserv markings in general? Do any browsers or webrtc >> capable software support what was discussed way back when? >> >> >> I know Hangouts did something like that internally, on the controlled >> network. But not according to spec. >> >> 3) Were diffserv marking changes eventually allowed on the same 5-tuple? >> >> >> Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table. >> >> 4) Did the ECN support that was originally in one draft or another >> ever make it into any running code? >> >> >> I don't know. I think we lost it from the docs. >> >> (yea, apple plans to turn on ecn universally in their next OS!) >> >> So how would ECN work on UDP? I do not think the necessary bits from the >> IP header are available for the application to do anything. I do think >> Linux supports this, have not tested. >> >> And what about the network, would it support UDP when setting the ECN >> bits? Probably a configuration related problem if not supported. >> >> >> RFC 6679 describes how to use ECN with RTP on UDP, although as you say >> there are implementation difficulties on some platforms. I=E2=80=99m not= sure >> whether there are implementations. >> >> >> 5) What else did I miss in the past year I should know about? >> >> >> For TCP and SCTP congestion controllers, we're back to one DSCP marking >> per flow, and resetting the congestion control state if DSCP marking >> changes. >> >> >> There is a new ICE wg. It was created so =E2=80=9Cnetwork people=E2=80= =9D could >> participate without the overhead of listening to the SDP related >> discussions. (https://datatracker.ietf.org/wg/ice/charter/) >> >> .-. >> P=C3=A5l-Erik >> >> >> Feel free to contact me off list if these have already been discussed. >> I have totally lost track of the relevant drafts. >> >> >> They're not finished still :-) >> >> >> Sincerely, >> >> Dave T=C3=A4ht >> I just lost five years of my life to making the edge >> of the internet, and, wifi better. >> And, now... the FCC wants to make my work illegal >> for ordinary people to install. >> https://www.gofundme.com/savewifi >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > --089e0158b69a82d41b05233fedc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I implemented some prototype software that read and s= et ECN for UDP packets whilst working on RFC6679, but there's no publis= hed open-source code I'm aware of that fully implements RFC6679. I repo= rted my experiences to the AVT list back in 2011, and I've updated them= here:

To set ECN on Linux, BSD and OSX one can use IP_TOS socket opt= ion, with the
setsockopt() call, to set the relevant ECN bits of the TOS byt= e. On Windows one can use a similar technique though firstly one has to ena= ble TOS byte setting by enabling a particular Registry key ( DisableUserTOSSetting=3D0 (see https://msdn.microsoft.com/en-us/library/windows/desktop/dd874008%28v=3D= vs.85%29.aspx=C2=A0 One could also probably use the libpcap write funct= ionality.

To obtain the ECN bits from a packet one needs a mechanism to = retrieve the ECN bits from each packet. On Linux, one needs to= firstly set the IP_RECVTOS socket option on the receiving socket, and use = the recvmsg() call to receive a packet, and then retrieve the TOS byte from= the associated csmg structure returned by the recvmsg() call. This still w= orks with linux-4.2.3. On OSX/BSD there are no suitable socket options to r= etrieve the ECN/TOS bits and one cannot use raw sockets as they do not func= tion for UDP/TCP sockets (they do work with ICMP), so one has to use altern= atives such the bpf interface, or a REDIRECT socket. Whilst on Windows it s= eems that the only way to retrieve the ECN bits is via a raw s= ocket, or custom NDIS driver, though it's possible there's an API I= 'm missing.


On 22= October 2015 at 20:54, Justin Uberti <juberti@google.com> = wrote:
At present I'= m not aware of any widely-deployed OS where an app can read the received EC= N markings.=C2=A0

iOS9 added support for this within the= kernel, and it's used for TCP, but not exposed to userspace. There is = an open Radar bug asking for this info to be exposed to userspace.

FWIW, Chrome supports setting the DSCP markings if you set= a magic parameter. But it's not on by default, mainly because we'v= e never done the auditing necessary to ensure this doesn't randomly bre= ak in various dimly-lit parts of the internet.

On Thu, Oct 22, 2015 at 2:13 AM, Colin Perkins <= csp@csperkins.org> wrote:


On 21 Oct 2015, at 18:10, Harald Alvestrand <harald@alvestrand.no> wrote:
Den 21. okt. 2015 17:51, skrev Dave Taht:
I unsubscribed from rmcat and rtcweb groups a while back after I got
overloaded, and appear.in started working so well, (for both ipv6 and
ipv4! I use it all day long now!), to focus on finishing up the new
"cake" qdisc/shaper/aqm/QoS system, among other things.

http://www.bufferbloat.net/projects/codel/wiki/CakeTechnica= l

Cake is now entering the testlab, and among other things, it has
support for the diffserv markings discussed in the related, now
concluded dart wg, but in ways somewhat different from that imagined
there. We have not got any good code in our testbeds yet to test
videoconferencing behavior, and we could use some, although it does
look like we can drive firefox with some remote control stuff with a
fixed video playback now....

Five questions:

1) Has anyone implemented or tested putting voice and video on two
different 5-tuples in any running code out there?

All VC systems I know of except WebRTC-based ones do it, AFAIK.
It=E2=80=99s putting them on the same that's unusual.

That sounds like the world I am living in as well.


2) How about diffserv markings in general? Do any browsers or webrtc
capable software support what was discussed way back when?

I know Hangouts did something like that internally, on the controlled=
network. But not according to spec.

3) Were diffserv marking changes eventually allowed on the same 5-tuple?

Yes, with caveats. draft-ietf-tsvwg-rtcweb-qos has the table.

4) Did the ECN support that was originally in one draft or another
ever make it into any running code?

I don't know. I think we lost it from the docs.

(yea, apple plans to turn on ecn universally in their next OS!)

So how would ECN work on UDP? I do not think the necessary bits from t= he IP header are available for the application to do anything. I do think L= inux supports this, have not tested.

And what about the network, would it support UDP when setting the ECN = bits? Probably a configuration related problem if not supported.

RFC 6679 describe= s how to use ECN with RTP on UDP, although as you say there are implementat= ion difficulties on some platforms. I=E2=80=99m not sure whether there are = implementations.=C2=A0


5) =C2=A0What else did I miss in the past year I should know about?

For TCP and SCTP congestion controllers, we're back to one DSCP marking
per flow, and resetting the congestion control state if DSCP marking changes.


There is a new ICE wg. It was created so =E2=80=9Cnetwork people=E2=80=9D c= ould participate without the overhead of listening to the SDP related discu= ssions. (https://datatracker.ietf.org/wg/ice/charter/)

.-.
P=C3=A5l-Erik


Feel free to contact me off list if these have already been discussed.
I have totally lost track of the relevant drafts.

They're not finished still :-)


Sincerely,

Dave T=C3=A4ht
I just lost five years of my life to making the edge
of the internet, and, wifi better.
And, now... the FCC wants to make my work illegal
for ordinary people to install.
https://www= .gofundme.com/savewifi

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


________________________= _______________________
rtcweb mailing list
rtcweb@ietf.o= rg
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb



--=C2=A0
Colin= Perkins






--089e0158b69a82d41b05233fedc4-- From nobody Sat Oct 31 22:40:37 2015 Return-Path: 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 55F5D1B643F for ; Sat, 31 Oct 2015 22:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqFTH2mt7zfc for ; Sat, 31 Oct 2015 22:40:33 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 671A31B643D for ; Sat, 31 Oct 2015 22:40:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0B8801E59F2 for ; Sat, 31 Oct 2015 22:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R8aMeFBhuh2 for ; Sat, 31 Oct 2015 22:40:06 -0700 (PDT) Received: from t20010c4000003024399ee8d5360fb14c.v6.meeting.ietf94.jp (t20010c4000003024399ee8d5360fb14c.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:399e:e8d5:360f:b14c]) by c8a.amsl.com (Postfix) with ESMTPA id AA7821E59F1 for ; Sat, 31 Oct 2015 22:40:06 -0700 (PDT) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 31 Oct 2015 22:40:34 -0700 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Sat, 31 Oct 2015 22:40:34 -0700 X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [rtcweb] Virtual Queue for RTCWEB Remote Attendees X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 01 Nov 2015 05:40:35 -0000 If you are planning to participate in the RTCWEB session here at IETF 94 = on Tuesday =97 either locally in Yokohama or as a remote participant =97 = we want to make sure that you are aware that the IETF is providing a = remote participants with a fairly new way to ask questions or make = comments. In addition to using the Jabber room, for the RTCWEB session = there is also the opportunity for remote participants to enter a virtual = queue and ask questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the RTCWEB session =97 a virtual queue and an actual (in-room) = queue. Remote attendees will log into the Meetecho platform and will = have a virtual mic line that they can enter if they have a question or = comment. In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com