Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?

"Black, David" <david.black@emc.com> Mon, 11 July 2016 18:22 UTC

Return-Path: <david.black@emc.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797512D63A; Mon, 11 Jul 2016 11:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.589
X-Spam-Level:
X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com
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 VnYLsBNgn-cR; Mon, 11 Jul 2016 11:22:38 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 8A74A12D633; Mon, 11 Jul 2016 11:22:38 -0700 (PDT)
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6BIMZAu006073 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jul 2016 14:22:36 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u6BIMZAu006073
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1468261356; bh=evR68eDoSOZgRBj7XkvEs8OOjrE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=uPKziJx7IXluywg6NX7x6Dm19uCe+Z9BLwUJr1MdRr9eqRwiZSXfS3fMiX35ujiI9 apHfLpvmOmiioxHKYyWfsbspFpk3kU/rwMBdEc2jNvVIAH9wCX3iCxv4ccmi3d7V9G r5985v5fC+UaNFzBDMwwuPcQk39lR/bNUYsEUgq4=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u6BIMZAu006073
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 11 Jul 2016 14:22:19 -0400
Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6BIMPMI006613 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 11 Jul 2016 14:22:25 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0266.001; Mon, 11 Jul 2016 14:22:24 -0400
From: "Black, David" <david.black@emc.com>
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "michawe@ifi.uio.no" <michawe@ifi.uio.no>, "brian.e.carpenter@gmail.com" <brian.e.carpenter@gmail.com>
Thread-Topic: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?
Thread-Index: AQHRzhJbsZyuYvv6mE+PQ2kNBpP9KZ/5U/cAgAAHhwCAGfiowIAAC+UAgABFHwA=
Date: Mon, 11 Jul 2016 18:22:23 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F5D8376@MX307CL04.corp.emc.com>
References: <CB087237-108A-44B1-8293-3498F24A2303@ifi.uio.no> <e3ebbf6c-58ab-1f70-3a5c-36a660dc73e7@gmail.com> <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <CE03DB3D7B45C245BCA0D243277949362F5D6D94@MX307CL04.corp.emc.com> <f06ecef448a84c6787acd3fda02b56ec@HE101653.emea1.cds.t-internal.com>
In-Reply-To: <f06ecef448a84c6787acd3fda02b56ec@HE101653.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.97.8.65]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/w1ltkABxBiaannDCqNV8pAF4nNg>
Cc: "fluffy@cisco.com" <fluffy@cisco.com>, "Black, David" <david.black@emc.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2016 18:22:41 -0000

> are you asking, whether the treatment of unexpected DSCPs

No, I'm asking which draft should document what a WebRTC application or a browser
hosting a WebRTC application should do in order to be robust to black-hole
(unreachability) behavior caused by use of a DSCP other than 000000.

> Didn't read the DART work before replying, but I assume the situation isn't
> covered in sufficient detail there.

Nope, it isn't ...

Thanks, --David

> -----Original Message-----
> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
> Sent: Monday, July 11, 2016 10:34 AM
> To: Black, David; michawe@ifi.uio.no; brian.e.carpenter@gmail.com
> Cc: fluffy@cisco.com; rtcweb@ietf.org; tsvwg@ietf.org
> Subject: AW: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?
> 
> Hi David,
> 
> are you asking, whether the treatment of unexpected DSCPs
> - should be documented within draft-ietf-tsvwg-rtcweb-qos or
> - should be documented within draft-jennings-ice-rtcweb-timing-01 or
> - should be documented within a to be written draft-unexpected-dscp-
> treatment?
> 
> We've discussed bleaching vs transport of unexpected DSCPs while working on
> diffserv-intercon as a possible measure (but never discussed dropping). I favor a
> separate and generic RFC dealing with the issue, if that is what you ask for. I think
> the issue of unexpected DSCP treatment is not rtcweb/STUN/... specific. The
> same holds for the avoidance of blackholing due to DSCP marks. Hints to avoid it
> should be part of that draft.
> 
> Didn't read the DART work before replying, but I assume the situation isn't
> covered in sufficient detail there.
> 
> Regards,
> 
> Ruediger
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Black, David
> Gesendet: Montag, 11. Juli 2016 15:56
> An: Michael Welzl; Brian E Carpenter
> Cc: Cullen Jennings (fluffy); rtcweb@ietf.org; tsvwg@ietf.org
> Betreff: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?
> 
> [+rtcweb]
> 
> > >> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting
> > >> the DSCP
> > values as proposed here consistently produces packet drops, senders
> > should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP.
> > >
> > > This is an interesting and worrying result indeed, but it's in no
> > > way specific to WebRTC. I think a generic RFC ("Happy Eyeballs with
> > > Differentiated
> > Services"?)
> > > would be the way to go.
> >
> > Well, if you use the DSCP within your own administrative domain for
> > DiffServ, you should be safe…. so I guess this problem mostly matters
> > for usage across domains, or even end-to-end.
> > => It seems to me that it’s broader than WebRTC in exactly the same
> > way as
> > RFC7657 is broader than WebRTC.
> 
> We have an immediate issue about what to add to the rtcweb-qos draft, which is
> IESG approved, and will go to the RFC Editor once this concern is resolved.
> While I greatly appreciate Michael's suggestion of text, I wonder whether this is
> part of a larger problem ...
> 
> Cullen recently sent a message to TSVWG about initial use of bandwidth by ICE
> for STUN:
> 
> https://www.ietf.org/mail-archive/web/tsvwg/current/msg14497.html
> 
> That  message begins with:
> 
> > When WebRTC connections start, they send a bunch of STUN packets as part of
> ICE.
> > Typically most of these STUN packets do not actually reach a valid
> > destination so they have 100% packet loss from the point of view of
> > the sender. This is discussed more in
> > draft-jennings-ice-rtcweb-timing-01
> 
> This feels like part of the same problem - black-holing caused by DSCP selection
> feels like it could be dealt with as part of STUN probing, although some caution is
> in order  (e.g., if EF is used to set up audio).
> 
> What's the "right way" to deal with this possibility that non-default DSCP usage by
> Web RTC may cause black-holing, and which draft should specify the black-hole-
> avoidance behavior?
> 
> Thanks, --David
> 
> > -----Original Message-----
> > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael Welzl
> > Sent: Friday, June 24, 2016 4:52 PM
> > To: Brian E Carpenter
> > Cc: tsvwg@ietf.org
> > Subject: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?
> >
> > Hi,
> >
> >
> > > On 24. jun. 2016, at 22.25, Brian E Carpenter
> > > <brian.e.carpenter@gmail.com>
> > wrote:
> > >
> > >> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting
> > >> the DSCP
> > values as proposed here consistently produces packet drops, senders
> > should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP.
> > >
> > > This is an interesting and worrying result indeed, but it's in no
> > > way specific to WebRTC. I think a generic RFC ("Happy Eyeballs with
> > > Differentiated
> > Services"?)
> > > would be the way to go.
> >
> > Well, if you use the DSCP within your own administrative domain for
> > DiffServ, you should be safe…. so I guess this problem mostly matters
> > for usage across domains, or even end-to-end.
> > => It seems to me that it’s broader than WebRTC in exactly the same
> > way as
> > RFC7657 is broader than WebRTC.
> >
> > As a side note, I think the term “Happy Eyeballs” is misleading here.
> > This term, to me, indicates parallel usage of multiple packet types to
> > see which one(s)
> > succeed(s) and then try to make the best choice.
> > This isn’t what you would do here - we’re talking about a rare failure
> > situation. It’s really only something I’d suggest as a fall-back, upon
> > seeing communication failing entirely, over a longer period (perhaps in line with
> a circuit-breaker).
> >
> >
> > > But (as with a lot of recent discussion about IPv6 extension headers
> > > causing packet drops) we really need to understand why
> > this
> > > happens. Is it traffic policing that fails to reclassify and re-mark
> > > packets, misguided firewalls, or what?
> >
> > I have no clue… but as my previous email said, we have indications
> > that this behavior occurred close to the senders (most of them being
> > in people’s homes), hence it’s more likely that this was done by a
> > middlebox or an edge router than by a core router.
> > That’s as much as we know...
> >
> > Cheers,
> > Michael
> >
> >
> > >
> > > Regards
> > >   Brian
> > >
> > > On 25/06/2016 00:17, Michael Welzl wrote:
> > >> Dear all,
> > >>
> > >> We recently did DSCP related measurements that lead us to propose a
> > >> change
> > to draft-ietf-tsvwg-rtcweb-qos.
> > >> These measurements are reported in this paper:
> > >> http://heim.ifi.uio.no/~michawe/research/publications/anrw16-
> > measurement.pdf
> > >> ... which will be presented at the ANRW workshop, the Saturday
> > >> before the
> > IETF meeting.
> > >>
> > >> The paper reports on tests between people's homes and 3 servers
> > >> that we
> > ran - one in Oregon (amazon cloud) and two in Norway. This gave us 185
> > distinct paths (IP address pairs). The test was a TCP handshake, done
> > with raw sockets, and we played around with values in the IP header.
> > Meanwhile, Runa (main
> > author) did some more tests from various public places during a trip
> > from Norway to India, essentially confirming the finding we discuss
> > here; we'll ask for a slot to report about both the data in the ANRW
> > paper and the newer data in the MAPRG session.
> > >>
> > >> The number of data points isn't exactly huge in both cases, but
> > >> still relevant,
> > we believe: it is about a persistent failure that we saw on different
> > paths, and so we think it's probably reasonable to take it into
> > account (given that a fix shouldn't be very complicated either).
> > >>
> > >> We used, as input, DSCP values from the table in draft-ietf-tsvwg-rtcweb-
> qos.
> > >> Here are some sentences copy + pasted from our paper:
> > >>
> > >> ***
> > >> "To minimize the chance that congestion-based drops make us believe
> > >> in a
> > failure
> > >> to communicate using certain values in the IP header, we re-tried
> > >> failed
> > packet
> > >> exchanges up to three times, and we sent an ICMP packet just ahead
> > >> of every measurement packet. We only assumed a communication
> > >> failure when the
> > test
> > >> failed three times and the ICMP packet succeeded."
> > >>
> > >> "Considering table 1 in [6], we assumed the flow type “Interactive
> > >> Video with
> > or
> > >> without Audio” with application priorities “Very low” (DSCP value
> > >> CS1 (8)),
> > “Low”
> > >> (DF (0)) or “Medium” (AF42 (36)), and flow type “Audio” with
> > >> application
> > prioritiy
> > >> “High” (EF PHB (46))."
> > >>
> > >> "We did see consistent packet drops too: on 23 paths for DSCP value
> > >> 8, 21
> > paths
> > >> for 36, 19 for 46."
> > >> ***
> > >>
> > >> We also saw DSCP value changes, but nothing very alarming there -
> > >> in one
> > case, AF42 was changed to AF41, which is even nice  :)     however, this
> consistent
> > drop behavior that appears only when using a DSCP value != 0 isn't good at all.
> > Now these things could in principle have happened close to our 3
> > servers, meaning there were only few devices that did it, but in fact
> > this measurement was a part of a larger measurement campaign in which
> > we also checked where such packet drops typically happened. The result
> > was: most such drops seem to be close to the client, which may
> > indicate that there were in fact multiple such boxes.
> > >>
> > >> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting
> > >> the DSCP
> > values as proposed here consistently produces packet drops, senders
> > should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP.
> > >>
> > >> Cheers,
> > >> Michael
> > >>
> > >>
> > >