IETF Logo Mail Archive

Re: [tsvwg] Your NQB presentation

Michael Welzl <michawe@ifi.uio.no> Fri, 22 November 2019 07:42 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14DF120113 for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 23:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 S8VQ9DkY6KqK for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 23:42:14 -0800 (PST)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3669912000F for <tsvwg@ietf.org>; Thu, 21 Nov 2019 23:42:14 -0800 (PST)
Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <michawe@ifi.uio.no>) id 1iY3a0-0006xn-5Q; Fri, 22 Nov 2019 08:42:12 +0100
Received: from dhcp-96d5.meeting.ietf.org ([31.133.150.213]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from <michawe@ifi.uio.no>) id 1iY3Zy-000EvU-Mt; Fri, 22 Nov 2019 08:42:12 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <BD67E565-AB8A-4934-A2C7-3E6089724FB5@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A43948A3-2237-466B-A8B1-57BC16BB4858"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 22 Nov 2019 15:42:04 +0800
In-Reply-To: <B2BBC082-8D8E-417A-BD85-E4BDD577A503@cablelabs.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>, "runabk@ifi.uio.no Barik" <runabk@ifi.uio.no>
To: Greg White <g.white@CableLabs.com>
References: <B654E9D3-A5E2-45AC-A4D3-E86757263CFB@gmx.de> <490F228F-57B3-430F-ABC8-38350E44EAC7@cablelabs.com> <AAEB98A9-9524-4772-B9D2-95E10DD90677@ifi.uio.no> <B2BBC082-8D8E-417A-BD85-E4BDD577A503@cablelabs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 31.133.150.213 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.150.213; envelope-from=michawe@ifi.uio.no; helo=dhcp-96d5.meeting.ietf.org;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 145C4CC2DF68827A6338CB38C992F651F93A316D
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uV2yqQC1VLEX-8zOw16odKKCMgU>
Subject: Re: [tsvwg] Your NQB presentation
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 07:42:17 -0000

Hi,


> On Nov 22, 2019, at 11:18 AM, Greg White <g.white@CableLabs.com> wrote:
> 
> Hi Michael, 
>  
> Thanks for sending the reference.  I only scanned it, but on first blush I don’t think this study reports on the situation that we’re discussing.  I likely missed it, so if you think I’m wrong, could you point out where in the data it is reported?
>  
> To be clear, I think the specific situation we’re talking about is where a residential ISP allows DSCPs marked by 3rdparties to be delivered intact to their residential customers.  How many of the 39 “Home Network” nodes in that data set received DSCP marked traffic that had passed through an interconnect?

Because the number of "home network" nodes that we had available was so small, we didn’t categorize the end hosts in our results but decided to lump them together, focusing on the behavior per AS in our study. This lumped data, for the direction that you’re interested in (from a server to a client) is shown in Figure 2, c and d.

I’m cc’ing Runa, my co-author who worked with this data. Runa, do you happen to know how many of the ARK nodes were able to receive an unchanged DSCP value from the other end?

A side note: if the DSCP would really ALWAYS be bleached for residential customers, then this work would also only apply to business environments:
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18 <https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18>

Cheers,
Michael

v2.23.0 | Report a Bug | By Email