Subject: Re: [tsvwg] Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.

From: Piers O'Hanlon <[email-masked]>
Date: Fri, 6 Feb 2015 17:28:50 +0000

On 6 Feb 2015, at 16:57, Michael Richardson wrote:

> 
> Jim Gettys <[email-masked]> wrote:
>> ​What effect does this algorithm have in practice? Here are some examples:
>> o real time isochronous traffic​ (such as VOIP, skype, etc) won't build
>> a queue, so will be scheduled in preference to your bulk data.
>> o your DNS traffic will be prioritized.
>> o your TCP open handshakes will be prioritized
>> o your DHCP & RA handshakes will be prioritized
>> o your handshakes for TLS will be prioritized
>> o any simple request/response protocol with small messages.
>> o the first packet or so of a TCP transfer will be prioritized: remember,
>> that packet may have the size information needed for web page layout in it.
>> o There is a *positive* incentive for flows to pace their traffic (i.e.
>> to be a good network citizen, rather than always transmitting at line rate).
> 
>> *All without needing any explicit classification.  No identification of
>> what application is running is being performed at all in this algorithm.*
> 
> This last part is I think the part that needs to be shouted at residential
> ISPs on a regular basis.  I wish that the IETF and ISOC was better able to
> do this... in particular to ISPs which do not tend to send the right people
> to NANOG/RIPE/etc.
> 
Explicit class-based queueing is seeing fairly substantial deployment in some places - such as the UK - where for a few years now the default home routers (Thomson/Technicolor TG587/582 etc) for a number of the big ISPs (Plusnet, O2/Sky, Talk-talk and others) have shipped preconfigured with 5 queuing classes that classify traffic and provide for differing treatment. They also have some ALGs that work with SIP/H.323. I'm not aware of AQM enabled on the individual queues but at least they separate the traffic into different queues - albeit based on port number or ALG classifiers. Better than nothing anyway.

Also the DOCSIS3.1 standard now mandates the use an AQM - namely PIE, though others can be implemented. I'm not sure where that is in terms of deployment though. There's a good report on it here:
http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf

Piers

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [
>

---

From: Piers O'Hanlon <[email-masked]>
Date: Fri, 6 Feb 2015 19:05:19 +0000

On 6 Feb 2015, at 18:24, Richard Shockey wrote:

> 
> Fine now how do you get the labeling/queueing across the AS boundary?  I
> don’t know any ISP that accepts or recognizes the packet labeling of
> another AS.
> 
Sure - that's another whole ballgame! A number of ISPs blow away the DSCP bits in packets from and to the home, as I understand they use their own set of DSCPs internally. But agreements of use across boundaries aren't that clear and probably wouldn't generally be extended to end users. I guess they're also using things like MPLS, or SDN (e.g. Google B4) for traffic engineering.

Piers

> 
> 
> On 2/6/15, 12:28 PM, "Piers O'Hanlon" <[email-masked]> wrote:
> 
>> 
>> Explicit class-based queueing is seeing fairly substantial deployment in
>> some places - such as the UK - where for a few years now the default home
>> routers (Thomson/Technicolor TG587/582 etc) for a number of the big ISPs
>> (Plusnet, O2/Sky, Talk-talk and others) have shipped preconfigured with 5
>> queuing classes that classify traffic and provide for differing
>> treatment. They also have some ALGs that work with SIP/H.323. I'm not
>> aware of AQM enabled on the individual queues but at least they separate
>> the traffic into different queues - albeit based on port number or ALG
>> classifiers. Better than nothing anyway.
>> 
>> Also the DOCSIS3.1 standard now mandates the use an AQM - namely PIE,
>> though others can be implemented. I'm not sure where that is in terms of
>> deployment though. There's a good report on it here:

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Feb 2015 08:27:31 +1300

On 07/02/2015 08:05, Piers O'Hanlon wrote:
> Sure - that's another whole ballgame! A number of ISPs blow away the DSCP bits in packets from and to the home, as I understand they use their own set of DSCPs internally. 

That is entirely in keeping with the diffserv architecture, which is
explicit that DSCPs are domain-specific and that traffic may be
reclassified at domain boundaries. (Which is what operators wanted
when diffserv was designed.)

> But agreements of use across boundaries aren't that clear and probably wouldn't generally be extended to end users. 

Agreements across boundaries require mutual trust, so it's to be
expected that ISPs will reclassify traffic arriving from subscribers.
For ISP/ISP boundaries, see
http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon

> I guess they're also using things like MPLS, or SDN (e.g. Google B4) for traffic engineering.

Diffserv isn't traffic engineering, however.

   Brian

---

From: Piers O'Hanlon <[email-masked]>
Date: Fri, 6 Feb 2015 19:57:45 +0000

Hi Brian,

> http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon
Sure - I guess I was just pointing out that one can't generally use DSCPs end2end even if one wanted to try...

> Diffserv isn't traffic engineering, however.
Agreed - that's yet another ballgame ;)

Piers

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Feb 2015 16:05:05 -0700

On Feb 6, 2015, at 12:13 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> What would be useful to us is knowing electricity use by circuit which means instrumenting the circuit breaker board or by socket which means even more measurement.

We have that.   It was a PITA to install, requiring an extra box because of the space it consumed.   The data is sort of cool, but I'm not convinced anybody but an energy geek would be willing to pay the cost.

On the other hand, being able to look at my flows in real time and in history would actually be useful to me.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Feb 2015 14:57:03 +1300

Hi Richard,
On 07/02/2015 08:51, Richard Shockey wrote:
> 
> On 2/6/15, 2:27 PM, "Brian E Carpenter" <[email-masked]>
> wrote:
> 
>>>> don¹t know any ISP that accepts or recognizes the packet labeling of
>>>> another AS.
>>>>
>>> Sure - that's another whole ballgame! A number of ISPs blow away the
>>> DSCP bits in packets from and to the home, as I understand they use
>>> their own set of DSCPs internally.
>>
>>> But agreements of use across boundaries aren't that clear and probably
>>> wouldn't generally be extended to end users.
>>
> Well Brian after Feb 26 we don¹t know what DIFFSERV will be.  It may be
> illegal unless you can define what a ³specialized service², ³reasonable
> network management² or ³commercially reasonable²  actually is.

I assume you are referring to some particular jurisdiction, which isn't
a standards problem since diffserv is a voluntary standard anyway.
However, since the naive politicians blundering about in this area
usually attempt to forbid "prioritization" and diffserv is not a
priority-based scheme, I doubt that there will be a real problem.

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Feb 2015 10:31:04 -0500

On Fri, Feb 6, 2015 at 8:47 AM, Jim Gettys <[email-masked]> wrote:

>
>
> On Thu, Feb 5, 2015 at 6:34 PM, Richard Shockey <[email-masked]>
> wrote:
>
>>
>>
>>>>
>> OK yes, My Netflix download is going to kill your VOIP call.
>>
>
> ​Yes, it may, though pacing traffic may help (see the sched_fq work in
> Linux).​
>
>
>>
>> RS > Well ..its always been more subtle than you think. You have to
>> distinguish between a Voice OVER IP call aka Skype etc vs a “managed
>> service” like Voice USING IP or VuIP which is an entirely different beast.
>> Modern VuIP which is all of Cable Voice in Europe and the US  VZ FIOS etc
>> and VoLTE is managed and  uses IP technologies such as SIP/IMS but the
>> routing may or may not have anything to  to do with BGP.  And BTW you have
>> to still do the first order number translation as well.  AKA RFC 6116 ENUM
>> or something new which we are actually debating in RAI.
>>
>> Its segmented managed traffic. Its not Netfilx killing Skype its
>> Microsoft Apple Android Updates as well.   We have no visibility on how the
>> OS actually queues application packets if at all.
>>
>
> ​Yup; this is a problem in the upstream direction (so is not the case you
> state above, but the inverse case, typified by events such as some one
> emailing a pile of images to your friends/family, backup and similar
> operations.
>
> One of the most common bottlenecks is the WiFi or cellular hop, and if the
> operating system does a single bloated FIFO drop tail queue discipline, you
> get into trouble.​
>
> ​ On Linux, this queue discipline has historically been one called
> PFIFO_FAST, and implemented​ a large (typically 1024 packet) FIFO drop tail
> queue (with a little bit of diffserv thrown in for good measure).
>
> ​Turning on a different queue discipline​ is a single configuration line,
> and it appears that people have been deciding to make fq_codel the default
> in various Linux distributions as of last fall (it has been the default in
> OpenWrt on routers for a while).
>
> At some point, it may make sense to use a different queue discipline
> (sched_fq) as the default, but I think more testing is needed.  That's a
> bit of a discussion better left to a different message.
>

OK we have a technical fix. But the problem is how to get it deployed by
the broadband providers.

There is a very good paper on computer security that might be relevant
here. 'Folk models of home computer security'

http://www.rickwash.com/papers/rwash-homesec-soups10-final.pdf

One of the thing we have found at Comodo is that virtually every home
computer issue is almost automatically attributed to being 'a virus'. What
the customer actually wants is for their damn machine to work. Or
alternatively, they want their relatives to stop calling them to ask them
to fix their computers.

The point is that people tend to leap to external attack as being the most
likely cause of any computer failure issue that isn't obviously dead
hardware. Which is really weird when I spent most of the 90s being told I
was an evil scaremonger for suggesting those cuddly-wuddly hackers might
actually be rather nasty thieving types.

So people see their Netflix or their Vonage suddenly sputter and the first
explanation that comes into their heads is 'my ISP is trying to kill them
to sell me their stuff instead'.

We have the potential here for a really bitter dispute. Instead of picking
up the phone to complain to their ISP, people have been picking up the
phone to complain to their Senator or the guy in the White House.

And it is going to be really difficult to explain to a lot of people who
have taken up arms on either side of this dispute that this might be the
cause of the slowdowns. One side is going to accuse us of being shills for
the corporate interests. And on the other side there are a lot of lobbyists
licking their chops at the thought of fat billable hours for as long as
they can make the fight worse.

So how do we de-escalate the situation?

One part is that we need more than a technical fix for this problem. We
need to be able to tell Joe or Jane Consumer how often these slowdowns
occur and what the cause is. The problem being that the cause of the
problem might be on the broadband provider side or the home user side of
the network.

So maybe have the residential gateway collect some data and expose it to
the consumer in some fashion. This could also help debug other connection
issues. I was having unexplained network slowdowns for a month that were
eventually found to have been caused by a falling tree snapping the fiber
but not the sheath round it. So the result was a flaky connection that had
the peculiar property of working for some frequencies but not others.

Another is to point out that just as the fact that you can't print from
your computer is because you have the wrong printer port assignment rather
than a virus does not mean viruses do not exist, the fact that buffer bloat
explains some network slowdowns does not mean it explains every slowdown.
Nor does it mean that malice is never a cause.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Feb 2015 11:57:49 -0500

---

From: Richard Shockey <[email-masked]>
Date: Fri, 06 Feb 2015 13:10:05 -0500

So people see their Netflix or their Vonage suddenly sputter and the first
explanation that comes into their heads is 'my ISP is trying to kill them to
sell me their stuff instead'.

RS> Of course didn¹t you get the memo?   ISP's are evil. Even more evil than
the evil airlines.  :-)

We have the potential here for a really bitter dispute. Instead of picking
up the phone to complain to their ISP, people have been picking up the phone
to complain to their Senator or the guy in the White House.

RS> Potential!  Potential dispute! We¹re already there. The missiles are in
the air.! They call it Obamanet around this town.  The cynics are already
calling it the Federal Internet Commission and or the Bureau of Transit and
Peering. It just leaked that the proposed FCC Open Internet order that will
drop Feb 26 is over 332 pages long. ( That is not the record BTW)  There's
³light touch² regulation for you.

And it is going to be really difficult to explain to a lot of people who
have taken up arms on either side of this dispute that this might be the
cause of the slowdowns. One side is going to accuse us of being shills for
the corporate interests. And on the other side there are a lot of lobbyists
licking their chops at the thought of fat billable hours for as long as they
can make the fight worse.

RS> Welcome to Washington DC, Ottawa, Brussels depending.

One part is that we need more than a technical fix for this problem. We need
to be able to tell Joe or Jane Consumer how often these slowdowns occur and
what the cause is. The problem being that the cause of the problem might be
on the broadband provider side or the home user side of the network.

So maybe have the residential gateway collect some data and expose it to the
consumer in some fashion. This could also help debug other connection
issues. I was having unexplained network slowdowns for a month that were
eventually found to have been caused by a falling tree snapping the fiber
but not the sheath round it. So the result was a flaky connection that had
the peculiar property of working for some frequencies but not others.

Another is to point out that just as the fact that you can't print from your
computer is because you have the wrong printer port assignment rather than a
virus does not mean viruses do not exist, the fact that buffer bloat
explains some network slowdowns does not mean it explains every slowdown.
Nor does it mean that malice is never a cause.

RS>  Speaking from personal experience the easiest way to put some internet
policy wonk to sleep is say the word bufferbloat.  I've tried.  A lot of
people have been proposing this idea of more consumer control of packet
labeling at the edge or more consumer information.  I¹m deeply skeptical of
any of these ideas.  Life is simply too complicated as it is.  99.8% of
consumers just want their cat videos or House of Cards and they want them
now.  Having some White Paper on the causes of network congestion for
consumers, legislators, regulators etc is a fine idea and could be useful.
That is something IMHO ISOC could and should commission. Actually MIT SAIL
and CAIDA  have filed a number of papers with the USG on this. However the
counter argument I often point out  are smart meters in the power industry.
Sure they gather lots of interesting data but the evidence is consumers
never use it.  Historically we went through this congestion issue  in the
late 1990¹s with dial up 9600/56k modems etc.  Eventually we all worked
through it though there was a lot of pain network engineers had to endure.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 06 Feb 2015 13:24:52 -0500

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Feb 2015 14:13:02 -0500

On Fri, Feb 6, 2015 at 1:10 PM, Richard Shockey <[email-masked]> wrote:

>
> RS>  Speaking from personal experience the easiest way to put some
> internet policy wonk to sleep is say the word bufferbloat.  I've tried.
>

> late 1990’s with dial up 9600/56k modems etc.  Eventually we all worked

I never check the ODBII data on my car. Until that is it won't start and I
need a fix.

The smart meter folk had a lot of peculiar ideas. They are not collecting
the data that I or any other home owner needs or wants. What would be
useful to us is knowing electricity use by circuit which means
instrumenting the circuit breaker board or by socket which means even more
measurement.

Knowing the aggregate use is only of interest if I was worried that my
mains hookup was insufficient.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 06 Feb 2015 14:51:12 -0500

---

From: <[email-masked]>
Date: Mon, 9 Feb 2015 09:47:20 +0100

As Brian pointed out, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/ proposes a method "how to get the labeling/queueing across the AS boundary". Input is welcome.

Commercial DiffServ interconnection products are available. They may however not be be widespread. 

If you however ask the question how to transit the complete QoS concept and codepoints of a sending domain to a customer connected to another domain - that hasn't been standardized yet.  
If your expectation is that a consumer (device) sets priorities of packets and carriers honour these markings, a technical and commercial model accepted by all parties is required. I'm not aware of one (I'm not interested in discussing how to get one on this list).
There's also no generally specified set of packet marks within the Best Effort class, which can transparently cross carrier boundaries on an end to end basis. That might offer a separation of WAN and LAN or application QoS marks (should this be useful).

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Richard Shockey
Gesendet: Freitag, 6. Februar 2015 19:25
An: Piers O'Hanlon; Michael Richardson
Cc: [email-masked]; Phillip Hallam-Baker; Jim Gettys; IETF Discussion Mailing List
Betreff: Re: [tsvwg] Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.

Fine now how do you get the labeling/queueing across the AS boundary?  I don’t know any ISP that accepts or recognizes the packet labeling of another AS.

On 2/6/15, 12:28 PM, "Piers O'Hanlon" <[email-masked]> wrote:

>>> o real time isochronous traffic​ (such as VOIP, skype, etc) won't 
>>>build  a queue, so will be scheduled in preference to your bulk data.
>>> o your TCP open handshakes will be prioritized  o your DHCP & RA 
>>>handshakes will be prioritized  o your handshakes for TLS will be 
>>>prioritized  o any simple request/response protocol with small 
>>>messages.
>>> *All without needing any explicit classification.  No identification 
>>>of  what application is running is being performed at all in this
>>>algorithm.*
>> 
>> This last part is I think the part that needs to be shouted at 
>>residential  ISPs on a regular basis.  I wish that the IETF and ISOC 
>>was better able to  do this... in particular to ISPs which do not tend 
>>to send the right people  to NANOG/RIPE/etc.
>> 
>Explicit class-based queueing is seeing fairly substantial deployment 
>in some places - such as the UK - where for a few years now the default 
>home routers (Thomson/Technicolor TG587/582 etc) for a number of the 
>big ISPs (Plusnet, O2/Sky, Talk-talk and others) have shipped 
>preconfigured with 5 queuing classes that classify traffic and provide 
>for differing treatment. They also have some ALGs that work with 
>SIP/H.323. I'm not aware of AQM enabled on the individual queues but at 
>least they separate the traffic into different queues - albeit based on 
>port number or ALG classifiers. Better than nothing anyway.
>
>though others can be implemented. I'm not sure where that is in terms 
>of deployment though. There's a good report on it here:
>http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Manage
>men
>t_Algorithms_DOCSIS_3_0.pdf
>
>Piers
>
>
>> --