Russell Heilling's Comments

Chewtoy's Technical Musings : Fear and Loathing in IPv6

Fri, 4 Feb 2011 07:16:49 +0000

Looks like we're actually in full agreement. Of course some people are going to strongly push for IPv6 anyway (there has been an epic thread arguing this for about 4 days now on Nanog with no sign of consensus. See the "quietly..." thread in the nanog archive if you have a few hours to spare...) I can see some of their arguments, but they don't are going to cause friction in the long term because they don't align with the vision of the IAB for Internet development. Essentially nodes behind the NAT are not truly part of the Internet... Maybe for these cases sticking with IPv4 with NAPTv4 and NAT64 is the best way for them to continue to connect in future. If IPv6 doesn't give you what you want then don't use it. But at the same time respect the people it does work for.

Chewtoy's Technical Musings : Fear and Loathing in IPv6

Tue, 1 Feb 2011 18:05:03 +0000

I agree 100% with the fact that we need to expect and plan for growth.
I don't agree that attempts to route more intelligently are simply
bit shaving exercises though.

As things stand at the moment the size of the Internet RIB is an order
of magnitude greater than the number of AS numbers originating those
routes and this disparity is increasing. There are a number of
drivers here, certainly mobility is one, scarcity of IPv4 addresses
leading to fragmentation of allocations is another and there are also
concerns such as traffic engineering and multihoming.

The work that the IRTF Routing Research Group (RRG) is doing is taking
these fundamental drivers causing growth of the global table and
trying to find a long term architecture that allows us to address
these drivers while keeping the amount of information that has to be
distributed to a minimum.

By keeping the information in the global table down to a minimum both
stability and scalability are improved and everyone wins. Certainly
one of the outputs of the RRG is of the bit shaving type: Aggregation
with Increasing Scopes (AIS) but this is seen as a short term
solution. In the longer term something more fundamental is required.

Something else that it is also worth bearing in mind is that while
Moore's Law holds, CPU speed and memory capacity are growing
exponentially (as are the number of entries in the routing table);
however memory access speed does not show this same behaviour (see
http://www.dba-oracle.com/oracle_tips_hardware_oracle_performance.htm)

Locator / Identifier separation techniques allow the causes of routing
table growth to be addressed while removing the need for every router
needing to maintain a full set of endpoint routes but they also
introduce new functionality (e.g. enabling multihoming without the
edge network needing to run BGP). LISP allows routers to only carry
the identifier mappings for destinations that they are communicating
with. ILNP takes this even further and allows for locator mobility at
the host level enabling hosts to get everything they would gain from
PI space while using PA space. These approaches (as well as several
others being proposed) are a fundamental change in the way we think
about IP routing that allow for much higher bounds on long term
growth. They allow us to keep simplicity in BGP, current issues are
leading to proposals that make BGP significantly more complex under
the hood and complexity is the enemy of scale.

Putting these into the same camp as PPP header compression isn't
comparing like with like. Header compression is a useful technique to
improve efficiency of transport on expensive links but it doesn't
increase functionality so as higher capacity links come down in price
the need for it goes away. I do not believe this is the case with the
Locator / Identifier techniques

Chewtoy's Technical Musings : Why Mobile is Different

Fri, 22 Oct 2010 12:39:55 +0000

All three of these technologies will certainly help to reduce the power required for transmission, which is a good thing. The ability to detect the direction of the base station and to send directionally is also a good way to reduce interference and increase the density of information you can get in the air too. These are certainly good steps forward but will they be enough when we are looking at an exponential growth in demand? We are still talking about non-coherent radiation sources too so dispersion will be a significant limiting factor in transmission distances even if power is lowered. And of course I didn't really mention the NIMBY effect that tends to stand in the way of new RF deployments. Once the road surface is back down on a fibre dig people tend to forget about it. While if you put up an RF mast you will be plagued with people campaigning to have it taken down over unverified health claims (Oh, won't someone think of the children!) Maybe I am just too pessimistic. We can certainly squeeze a lot more out of these technologies. Maybe demand will slacken off before we have exhausted that potential...

Chewtoy's Technical Musings : Going with the Flow

Tue, 28 Sep 2010 19:37:21 +0000

It is ideas like this that make me favour making the flow label mutable... I really don't see how encoding port numbers in the flow label is supposed to give a greater level of stateless QoS than simply using the DSCP...

Chewtoy's Technical Musings : Going with the Flow

Tue, 14 Sep 2010 19:51:30 +0000

Hi Sam, That's an interesting perspective. Are you suggesting that your application register would specify the full 20-bit flow label? To be honest from my reading of RFC3697 I don't think this is an invalid use of the label. The RFC states that IPv6 Nodes should make no assumptions about the properties of the flow; however it appears to be talking about forwarding nodes. In your example it is not the forwarding node that is making an assumption, it is a remote management station that is using it for statistical purposes (presumably using something like IPFIX of Netflow v9 templates). I can see how some form of structured flow-id assignment could be useful within an administrative domain but it is only going to be useful if the standards allow re-writing of the flow label at the edge. As you say, if you let stuff in from an untrusted zone then you risk overlapping (either randomly or maliciously) flow labels. And is trust of flow values really only limited to public networks? Unless you are 100% responsible for writing all application code used in the network (including OS level network communications) can you really afford to trust flow values? Any registered value that you set aside could easily coincide with a pseudo-random value generated by an app that doesn't follow your coding guidelines. The statement that the validity would be zero on a public-accessible network kind of gets to the crux of it. The default area of applicability of IETF standards is the "Big I" Internet. Private internets are certainly allowed, but they tend to be treated as special cases and are unlikely to wield a lot of weight during protocol definition. Any attempt to map flow labels to application is likely to remain outside of the standards and therefore it is also less likely to turn up in off the shelf products. Getting your network management platform to map from flow values to applications using your register is likely to involve you rolling you own code. Another thing I would throw into the mix is the fact that by definition we are using IPv6. This means that the address space is not constrained. Using the flow-label for load balancing may seem like a waste of 20 bits to you, but isn't assigning addresses on the basis of a node also a bit of a waste of a 64-bit link address space? Would having a seperate end-point identifier per-application not also be a way of encoding this information? This would also have the benefit of being carried in a checksum protected part of the header. I'm kind of thinking aloud here and there may well be mile wide holes in what I'm saying. I would be interested in further thoughts on this :)

Chewtoy's Technical Musings : Down, down, down the Rabbit Hole

Tue, 24 Aug 2010 15:47:06 +0000

The way I read the draft (and I have only read one of the set so far)
host changes would be required to gain full benefit of mobility, but
they are not mandated for initial deployments (although I am not clear
how ILNPv4 could be done without host changes).

Some of the problems that solutions like ILNP and LISP are trying to
solve are coming from the higher levels of the stack (most notably the
fact that an IP address identifies an interface, not a host) and
because of this solutions that only address the network (i.e. LISP)
are not guaranteed to scratch everyone's itch. In many ways I think
host changes are inevitable; however they make things much more
difficult to implement :(

One thing that I plan on expanding on in a later post is that neither
LISP nor ILNP seem to be particularly friendly to existing middle box
gear. Firewalling of either of these Map+Encap technologies will be a
nightmare...

Chewtoy's Technical Musings : When is Video Prioritisation Good vs Evil

Mon, 23 Aug 2010 20:08:41 +0000

What browsers are you guys using? I have been unable to reproduce here in Chrome, Firefox or IE. I have even grabbed the URL from a the command line on a couple of boxes using wget. I really don't understand what is going on here...

Chewtoy's Technical Musings : When is Video Prioritisation Good vs Evil

Mon, 23 Aug 2010 09:50:05 +0000

Thanks for reporting this. The diagrams are set to public and they
work for me when I am logged out of my accounts so I'm not sure what
the problem is :(

I'll get my investigating hat on and try and track down the problem...

Chewtoy's Technical Musings : When is Video Prioritisation Good vs Evil

Thu, 19 Aug 2010 05:49:43 +0000

Just a quick thought about how this could work in the future... When carrying L2TP over IPv6 it would be useful if the BRAS could expose the session ID (or a hash of it) in the Flow header. This would keep a per-user distinction in standard IP headers within the SP network and reduce the desire to make L3 decisions based on L4+ headers...

Chewtoy's Technical Musings : When is Video Prioritisation Good vs Evil

Wed, 18 Aug 2010 20:22:01 +0000

Hmmm... this response seems to have gotten lost when I posted by email earlier... Apologies if it shows up twice... My past experience in the broadband area is that providers try to cram as many customers as possible on to a BRAS, so some level of congestion on the output interface is basically a given ;) On the queuing front, I have run hierarchical queues using exactly this model on the Juniper E series. I was assuming that Cisco could do something equivalent. As a disclaimer, I am not currently working with DSL on a large scale and it is over a decade since I last worked in the consumer space so a lot of my knowledge is second hand.

Chewtoy's Technical Musings : When is Video Prioritisation Good vs Evil

Wed, 18 Aug 2010 11:58:10 +0000

Hi Ivan,

Thanks for the comment.

On the subject of per-user queuing, I'm not sure this is necessarily
the case. Often a DSL access network (and lets face it, that is
usually where the problem is) is built from a number of components.
You have your DSLAM / MSAN at the end of the user's copper line. This
part generally doesn't have much responsibility. In a lot of cases it
will simply be acting as a LAC and tunneling the user's IP traffic
back to a more intelligent BRAS further into the network using a
technology such as L2TP.

The BRAS will have access to the per-user information required to
build a hierarchical structure as listed above because it has to
associate the packets with the individual L2TP sessions.

Over the broadband backhaul network (BBN) all traffic from a BRAS to a
DSLAM/MSAN will be in a single UDP flow. Any congestion in the BBN
using standard per-flow fairness algorithms could potentially favour
customers on less busy BRAS devices over those on the busiest devices,
but it is still going to be generally fair.

True fairness would probably involve extending the flow fairness to
include the tunnel/session ids from the L2TP header, but fairness on
the aggregate flow gives you a pretty good approximation without the
need for DPI traffic grooming boxes...

Chewtoy's Technical Musings : Travelling in Strange Directions (or is RFC4761 broken)

Mon, 16 Aug 2010 18:54:10 +0000

Hi Omar,

Thanks for the response.

The main problem I have is that when packets are relayed from a third
network location, they are pretty much by definition going to be the
last packets to be received at the intended destination. This means
that it is pretty much guaranteed that the forwarding table is going
to end up with the wrong information.

In my experience from a platform that functions according to the RFC
(Juniper J-Series) the sub-optimal routing is anything but transient
and it is actually quite common for forwarding to converge to the
wrong paths :(

The strict split horizon of RFC4762 makes much more sense.

Chewtoy's Technical Musings : Travelling in Strange Directions (or is RFC4761 broken)

Thu, 12 Aug 2010 15:22:42 +0000

Yes, there is... It is showing for me in Chrome and IE, not sure why it wouldn't be showing for you... Here's a direct link to the source diagram: https://docs.google.com/drawings/edit?id=1dQYbXg7... (requires SVG support in your browser)

Chewtoy's Technical Musings : The Emperor's New Transport

Thu, 21 May 2009 14:26:59 +0000

OK, so Gates never said the 640K thing ( http://www.wired.com/politics/law/news/1997/01/14... ). Not sure if that negates or reinforces my point though :)

Random Meanderings : Taking a chance

Fri, 19 Dec 2008 07:01:36 +0000

Thanks for the comment, nice to know I'm not just talking to myself here :) Yeah, I've been blogging since before it was a verb... Only just imported the history over here though. I'm not looking forward to fixing all the broken links...