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

From: "Black, David" <[email-masked]>
Date: Mon, 11 Jul 2016 13:55:53 +0000

[+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:[email-masked]] On Behalf Of Michael Welzl
> Sent: Friday, June 24, 2016 4:52 PM
> To: Brian E Carpenter
> Cc: [email-masked]
> 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 <[email-masked]>
> 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
> >>
> >>
> >

---

From: <[email-masked]>
Date: Mon, 11 Jul 2016 14:34:28 +0000

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:[email-masked]] Im Auftrag von Black, David
Gesendet: Montag, 11. Juli 2016 15:56
An: Michael Welzl; Brian E Carpenter
Cc: Cullen Jennings (fluffy); [email-masked]; [email-masked]
Betreff: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?

[+rtcweb]

> 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.

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 ...

That  message begins with:

> 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

> 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.
> 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)
> 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.
> 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.
> >>
> 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).
> >>
> >> 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
> 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.
> >>
> 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
> >>
> >>
> >

---

From: "Black, David" <[email-masked]>
Date: Mon, 11 Jul 2016 18:22:23 +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.

> covered in sufficient detail there.

Nope, it isn't ...

Thanks, --David

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 11, 2016 10:34 AM
> To: Black, David; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?
> 
> Hi David,
> 
> 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.
> 
> 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.
> 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).
>

---

From: "Gorry (erg)" <[email-masked]>
Date: Tue, 12 Jul 2016 08:44:04 +0100

The DART work warns of the pitfalls. 

My suggestion is that for protocols using ICE that STUN packets could be used for this path check - if this is desired. I am not sure we need to hold the current draft for this sort of addition.

Gorry

---

From: "Black, David" <[email-masked]>
Date: Tue, 12 Jul 2016 12:55:49 +0000

> My suggestion is that for protocols using ICE that STUN packets could be used for
> this path check - if this is desired. I am not sure we need to hold the current draft
> for this sort of addition.

I'd add a sentence to say that ICE uses STUN for this sort of DSCP-specific path
check and cite the draft that specifies how that path checking is performed.
Which draft would that be?

I concur that this draft on DSCP usage should not specify how path checking is done.
 
> >>> When WebRTC connections start, they send a bunch of STUN packets as part
> of
> >> ICE.
> >>> seeing communication failing entirely, over a longer period (perhaps in line
> with
> >> a circuit-breaker).
> >>>
> >>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jul 2016 03:56:25 +1200

Hi,

Having made time to read the paper at
http://heim.ifi.uio.no/~michawe/research/publications/anrw16-measurement.pdf
I do have one comment on the paper itself, which I think is relevant here.
The paper shows that there is a high prevalence of DSCP re-marking on the
paths surveyed. We should be clear that this is all quite legitimate behaviour;
it's exactly what RFC2474 describes. So no surprise there, although the results
would have been good input for RFC7657.

The results indicating drops for some packets with DSCP or ECN bits set
are worrisome because they suggest badly configured firewalls.

Together, the observations confirm that fallback to the default DSCP is a must.

(Not really for this WG, but I am not really shocked by packets with the
evil bit being dropped. It's an MBZ bit in RFC791, so finding it set makes
a packet suspect, so a firewall might drop it, incidentally conforming to
RFC3514.)

Regards
   Brian

On 25/06/2016 08:25, Brian E Carpenter 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.
> 
> to WebRTC. I think a generic RFC ("Happy Eyeballs with Differentiated Services"?)
> would be the way to go. But (as with a lot of recent discussion about IPv6
> extension headers causing packet drops) we really need to understand why this
>> We recently did DSCP related measurements that lead us to propose a change to draft-ietf-tsvwg-rtcweb-qos.
>> 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).
>>
>> "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
>> measurement packet. We only assumed a communication failure when the test
>> "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
>>
>>
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 12 Jul 2016 16:19:34 +0000

short answer here but as David suggested …  some implementation use the STUN packets in ICE  or just  in WebRTC style liveness tests to do the tests of if a given DSCP works or not. In general ICE is a good tool to take a bunch of possible paths, test which work, and select the best. 

> On Jul 11, 2016, at 9:55 AM, Black, David <[email-masked]> wrote:
> 
> [+rtcweb]
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 12 Jul 2016 16:20:29 +0000

On Jul 12, 2016, at 8:55 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

+1

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Jul 2016 12:26:05 -0400

This is great work information. Thank you. The numbers of packets with non 0 DSCP that got dropped seemed higher than other testing I had seen but I think the other tests had been done only using UDP packets. I wonder if it might be possible to run this experiment at a much wiser scale with the help of Google or Mozilla ?

> On Jun 24, 2016, at 8:17 AM, Michael Welzl <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 12 Jul 2016 23:21:25 +0200

Hi,

First, thanks Brian (his email isn’t contained below) for reading the paper, and for your comments.

Second, about doing the experiment on a wider scale: there will be a talk from Runa (main paper author) in MAPRG showing some new data, but these are also hardly results at a “wider scale”. However, these data essentially confirm the prior findings - some more paths where DSCP!=0 packets are consistently dropped.

The measurements are carried out in conjunction with the NEAT project, in which we collaborate with Mozilla; I’m cc’ing the Mozilla people who work with us.

I think my own, quick answer regarding testing in Mozilla would be:
- you can write but not read the DSCP value from user space AFAIK, so you testing DSCP value changes is off limits...
- we’re more interested in the drops, of course; drops could, in principle, probably be measured, but I think the Mozilla folks are (understandable) neither keen to add active measurement traffic nor to make communication failures more likely in their browser…  so that’s probably a problem for measurements.

That’s all from me, I’ll let them speak for themselves  :-)

Cheers,
Michael

> On 12. jul. 2016, at 18.26, Cullen Jennings <[email-masked]> wrote:
> 
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 12 Jul 2016 23:28:42 +0200

> On 12. jul. 2016, at 17.56, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> it's exactly what RFC2474 describes.

Just out of curiosity: also remarking into e.g. 2, which is undefined according to
http://www.iana.org/assignments/dscp-registry/dscp- registry.xhtml  ?

> So no surprise there, although the results

It happened only on paths where a nonzero DSCP also caused a drop; it was never zeroed…. so we actually conclude that this bit might be useful  :)   but of course, not enough data….

Cheers,
Michael

---

From: "Black, David" <[email-masked]>
Date: Tue, 12 Jul 2016 21:43:53 +0000

> http://www.iana.org/assignments/dscp-registry/dscp- registry.xhtml  ?

Not exactly ;-).  Ruediger described what's happening here -a pre-RFC 2474
implementation is treating the first 3 bits of the DSCP as the (RFC 791) IP
Precedence field and is "bleaching" those bits, but only those bits, to zero.

This behavior is not compliant with RFC 2474 (or 2475) when the resulting DSCP
is not valid for the Diffserv domain.
 
> It happened only on paths where a nonzero DSCP also caused a drop; it was
> never zeroed…. so we actually conclude that this bit might be useful  :)   but of
> course, not enough data….

Like Brian, I am intrigued that there appears to be "running code" that
implements the expected response to the "evil bit" ;-).

Thanks, --David

---

From: Michael Welzl <[email-masked]>
Date: Tue, 12 Jul 2016 23:50:34 +0200

> On 12. jul. 2016, at 23.43, Black, David <[email-masked]> wrote:
> 

Right (I found his email pretty interesting)

> is not valid for the Diffserv domain.

Ok, thanks for confirming that. I would have thought so - just wanted to make sure, as I don’t want to go around making false statements.

> implements the expected response to the "evil bit" ;-).

The expected response being what? Dropping?
Dropping is a matter of checking for “anything unusual”, I guess. Like, this bit being 1, or DSCP not being 0, …  I’m not surprised that we saw both happen on the same paths (only).
Letting it pass is what a good Internet citizen should do, right?

Cheers,
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jul 2016 18:27:53 +1200

> Ok, thanks for confirming that. I would have thought so - just wanted to make sure, as I don’t want to go around making false statements.

It's impossible to know, in principle, what DSCP markings *are* valid inside
somebody else's network. So while the values you observed may be rubbish,
they aren't a protocol violation. And unless I'm forgetting something, the
diffserv architecture doesn't have a rule about what diffserv domains should
do when sending packets outwards: it mainly covers remarking of inbound packets.

"Specifications of DS field translations at DS
boundaries are the subject of service level agreements between
providers and users, and are outside the scope of this document."
-- RFC2474 section 3.

RFC2475 section 5 observes that a DS domain egress may re-mark traffic sent
to a non-DS domain, but does not require it.

So, with no SLA in place, all bets are off.

   Brian

---

From: "Gorry (erg)" <[email-masked]>
Date: Wed, 13 Jul 2016 10:28:13 +0100

The pathspider tool that are we working on in the MAMI Project can also help with a different view of where and how DSCPs are being used on paths through the Internet. We'll share some initial results on this in the Saturday ANRW poster session prior to the IETF. 

Gorry

> On 12 Jul 2016, at 22:21, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jul 2016 10:53:22 +0200

Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy):
>
> short answer here but as David suggested …  some implementation use
> the STUN packets in ICE  or just  in WebRTC style liveness tests to
> do the tests of if a given DSCP works or not. In general ICE is a
> good tool to take a bunch of possible paths, test which work, and
> select the best.

I do agree that how you do the path checks when setting DSCP values != 0 
is dependent on the context. For the WebRTC I do agree doing checks 
using ICE is quite reasonable.

We already have similar path testing usages of ICE in the ECN for RTP 
specification (RFC6679), see Section 7.2.1. I will note that taking this 
as blueprint for DSCP testing, what is needed clearly requires a new 
separate specification. The components needs are: 1) A new STUN 
parameter to request the ICE peer to echo the DSCP field value received. 
2) A ICE capability parameter to be used in signalling negotiations to 
determine capability for this feature. 3) Behaviour specification on how 
to test values and interpret responses. This include things like if one 
should actually establish multiple candidate pairs one with DSCP testing 
and one without?

So the question here is how to proceed with this issue. So I would 
suggest the following way forward.

1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the 
user to apply path verification methods but don't specify them.

2. Someone takes on the task to write a DSCP path verification extension 
to ICE.

3. The natural place to indicate the need/recommendation for 
implementing this functionality would be in draft-ietf-rtcweb-transports 
(Currently in IETF LC). However, here I think we need to have a 
discussion if RTCWEB WG wants to only place a suitable warning about the 
need, and indicate future forthcoming specification or if we hold this 
document up until this solution is available?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Thu, 14 Jul 2016 21:13:16 +0000

Magnus,

> document up until this solution is available?

I'll attend the Thu RTCWEB session in Berlin to see how this comes out,
after which it should be straightforward for the draft authors and yours
truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will
need.

Thanks, --David

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, July 14, 2016 4:53 AM
> To: Cullen Jennings (fluffy); Black, David
> Cc: RTCWeb IETF; Michael Welzl; [email-masked]
> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Jul 2016 09:55:48 +0200

David,

repeating for transparency what I asked in person:

Can you post the links to the measurements that led to the conclusion
that non-arrival of DSCP-marked packets is a big enough problem that we
should develop specific mechanisms to detect it?

I'd like to make sure we're all on the same page wrt what the problem
is, how we can measure it, and in what contexts the problems are likely
to have significant impact.

(I worry in particular about how many false positives a blackhole
detection mechanism is likely to have, and how much this will in turn
increase randomness in performance as percieved by the user, making
performance problems harder to diagnose.)

-- 
Surveillance is pervasive. Go Dark.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Jul 2016 10:06:11 +0200

Answering my own question:

perusing my TSVWG archives, I found
http://heim.ifi.uio.no/~michawe/research/publications/anrw16-measurement.pdf,
which says:

" We did, however, see consistent packet drops too: on 23 paths for DSCP
value 8, 21 paths for 36, 19 for 46. This failure rate of approximately
10 - 13% is a reason to be concerned about WebRTC QoS; implementations
should probably react to consistent failures with a fall-back to DSCP
value 0."

The data is not broken down further on what kinds of paths the failures
were detected on, but the design of the experiment seems fairly solid if
I understand the description right.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jul 2016 10:15:58 +0200

> should develop specific mechanisms to detect it?

https://irtf.org/anrw/2016/anrw16-final17.pdf

-- 

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Mon, 18 Jul 2016 11:24:34 -0400

> https://irtf.org/anrw/2016/anrw16-final17.pdf

Interesting (especially the drops; remarking to 0 is what I'd expect).  
10+ % chance of a non-working path definitely requires us to anticipate it.

Using ICE makes some sense, but I'm a little concerned at multiplying 
the combinatorial number of connectivity checks yet again.

Note this would need to be redone on ICE restart or any connection 
change of course.

Intermediate route changes could also cause it to suddenly fail if DSCP 
is in-use.  Fallback to DSCP 0 (or re-probing) on connection loss (or 
when doing media retransmits?) may also be needed, though restarting ICE 
should work, if ICE can re-establish quickly.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jul 2016 11:10:55 +0200

See inline.

> 10+ % chance of a non-working path definitely requires us to anticipate it.

Yes, the measured set is small, but the existance proof for black holes 
due to DSCP !=0 is not good.

> the combinatorial number of connectivity checks yet again.

This is one of the design questions. For ECN we did the choice to run 
the ECT path verification after we found a working path using the normal 
connectivity checks. The trade-off there was that it was more important 
to find a path with basic connectivity, rather than looking for path 
that supports ECN. For DSCP that choice might be different, but the 
alternative to make the DSCP checks sequential to basic connectivity is 
a clear possibility.

> Note this would need to be redone on ICE restart or any connection

Yes
> should work, if ICE can re-establish quickly.

Yes, I think such monitoring is needed.

Cheers

Magnus Westerlund