[Bloat] Apple ECN, Bufferbloat, CoDel

[Bloat] Apple ECN, Bufferbloat, CoDel

[Mikael Abrahamsson]

I highly encourage people to take a look at:

https://developer.apple.com/videos/wwdc/2015/?id=719 (you might have to 
reigster as an apple developer to watch it, I don't know)

"Your App and Next Generation Networks
IPv6 is growing exponentially and carriers worldwide are moving to pure 
IPv6 APNs. Learn about new tools to test your apps for compatibility and 
get expert advice on making sure your apps work in all network 
environments. iOS 9 and OS X 10.11 now support the latest TCP standards. 
Hear from the experts on TCP Fast Open and Explicit Congestion 
Notification, and find out how it benefits your apps."

Being on this list you might not learn much from the talk, but I really 
appreciate a talk aimed at a wider (developer) audience which so clearly 
outlines the benefits of ECN, CoDel and TCP host opimization to reduce 
end-to-end experienced application communication latency. One of the major 
takeaways is that Apple is planning to by default enable ECN in iOS9 and 
OSX 10.11. This would mean hundreds of millions of devices will be using 
ECN in a few months.

You can skip to 16 minutes into the talk if you're not interested in the 
new requirement for applications to support an environment where it's 
Internet access is IPv6 only behind NAT64+DNS64 (I'm myself super excited 
about this).

Let's hope this brings a lot of buzz and requests towards device 
manufacturers to start supporting ECN marking and AQM. Apple is usually a 
good megaphone to bring attention to these kinds of issues...

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] Apple ECN, Bufferbloat, CoDel

[Dave Taht]

On Sat, Jun 13, 2015 at 9:07 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> I highly encourage people to take a look at:
>
> https://developer.apple.com/videos/wwdc/2015/?id=719 (you might have to
> reigster as an apple developer to watch it, I don't know)

No, it's worse than that - the talk is in a format that can only be
parsed by safari. Both firefox and google-chrome fail.

You can download it without registration... and mplayer for linux can
play it back.
(watching it now)

and it is nice to hear they are adopting other standards like ECN.

Nice to see stuart cheshire on the big stage!

>
> "Your App and Next Generation Networks
> IPv6 is growing exponentially and carriers worldwide are moving to pure IPv6
> APNs. Learn about new tools to test your apps for compatibility and get
> expert advice on making sure your apps work in all network environments. iOS
> 9 and OS X 10.11 now support the latest TCP standards. Hear from the experts
> on TCP Fast Open and Explicit Congestion Notification, and find out how it
> benefits your apps."
>
> Being on this list you might not learn much from the talk, but I really
> appreciate a talk aimed at a wider (developer) audience which so clearly
> outlines the benefits of ECN, CoDel and TCP host opimization to reduce
> end-to-end experienced application communication latency. One of the major
> takeaways is that Apple is planning to by default enable ECN in iOS9 and OSX
> 10.11. This would mean hundreds of millions of devices will be using ECN in
> a few months.

I have generally hoped that a replacement for cubic would arrive... and/or their

and have

> You can skip to 16 minutes into the talk if you're not interested in the new
> requirement for applications to support an environment where it's Internet
> access is IPv6 only behind NAT64+DNS64 (I'm myself super excited about
> this).

I don't understand how badly this is going to break dnssec. dnsmasq in
particular has been dealing with edge case after edge case on dnssec
for the last few months, and it was my hope we'd finally got them all.

> Let's hope this brings a lot of buzz and requests towards device
> manufacturers to start supporting ECN marking and AQM. Apple is usually a
> good megaphone to bring attention to these kinds of issues...

There is an awful lot of "personal" networking that can benefit from this.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

Re: [Bloat] Apple ECN, Bufferbloat, CoDel

[Jonathan Morton]

> On 13 Jun, 2015, at 19:07, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> One of the major takeaways is that Apple is planning to by default enable ECN in iOS9 and OSX 10.11. This would mean hundreds of millions of devices will be using ECN in a few months.

That *is* big news.

I have no doubt that all the various Linux folks will watch this mass deployment of ECN closely, and - as long as no major fails show up as a result - might finally grow the balls to turn it on by default themselves.

If major fails *do* show up, then hopefully it’ll just be an impetus to get the remaining blackholes and stupid firewalls fixed.

Microsoft is, as always, an unknown factor in all this, but who cares.

 - Jonathan Morton

Re: [Bloat] Apple ECN, Bufferbloat, CoDel

[Mikael Abrahamsson]

On Sat, 13 Jun 2015, Dave Taht wrote:

> I don't understand how badly this is going to break dnssec. dnsmasq in 
> particular has been dealing with edge case after edge case on dnssec for 
> the last few months, and it was my hope we'd finally got them all.

DNS64 breaks DNSSEC because it creates an AAAA response where none is 
present in the zone being queried. It's basically doing MITM for DNS, 
which is exactly what DNSSEC was supposed to fix.

DNSSEC would work if Apple decided to just do NAT64 discovery and then do 
their own DNS64 in the host, but I have no information as to what is being 
done here.

At least DNSSEC still works between the Internet and the ISP DNS64 
resolver, but the end host won't be able to verify the response using 
DNSSEC.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] Apple ECN, Bufferbloat, CoDel

[Mark Andrews]

In message <alpine.DEB.2.02.1506131908320.9487@uplift.swm.pp.se>, Mikael Abraha
msson writes:
> On Sat, 13 Jun 2015, Dave Taht wrote:
> 
> > I don't understand how badly this is going to break dnssec. dnsmasq in 
> > particular has been dealing with edge case after edge case on dnssec for 
> > the last few months, and it was my hope we'd finally got them all.
> 
> DNS64 breaks DNSSEC because it creates an AAAA response where none is 
> present in the zone being queried. It's basically doing MITM for DNS, 
> which is exactly what DNSSEC was supposed to fix.
> 
> DNSSEC would work if Apple decided to just do NAT64 discovery and then do 
> their own DNS64 in the host, but I have no information as to what is being 
> done here.
> 
> At least DNSSEC still works between the Internet and the ISP DNS64 
> resolver, but the end host won't be able to verify the response using 
> DNSSEC.

RFC 6147 is total broken when it talks about DNSSEC.  The WG wanted
so much for there to be a bit that said "validation will be performed
on this answer" that they stopped listening.  There is no such bit
or combination of bits.

NAT64 and DNS64 need to die.  There are much better solutions to
providing IPv4 over IPv6 than NAT64 and DNS64 and 464XLAT that grew
from NAT64 and DNS64.

MAP and DS-Lite are better solutions.  They work with DNSSEC.  They
have the same PMTUD issues as NAT64.  Address selection rules provide
enough bias towards IPv6.

> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

Re: [Bloat] Apple ECN, Bufferbloat, CoDel

[Henrique de Moraes Holschuh]

On Sun, 14 Jun 2015, Mark Andrews wrote:
> NAT64 and DNS64 need to die.  There are much better solutions to
> providing IPv4 over IPv6 than NAT64 and DNS64 and 464XLAT that grew
> from NAT64 and DNS64.

Please make it "NAT64 WITH DNS64 needs to die".

It is too easy to forget that there is such a thing as NAT64-FE (RFC 7269).
Fortunately, NAT64-FE is not used together with DNS64 in any remotely sane
scenario, so it is not going to break DNSSEC.

It is also a somewhat rare beast most of us never will have to deal with (I
do, and it doesn't make me happy).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh