On PPPoA, PPPoE, ATM and ADSL

This blog entry is based on my Usenet posting, which has been archived by Google.

The question raised was "what is the difference between PPPoE and PPPoA on ADSL? Is there any benefit from choosing one or the other?". This post goes into the details of how PPPoE, PPPoA and ATM are interrelated on UK ADSL providers.

Anyone who's looked at the options offered by their ADSL modem will have seen a huge variety of options; there's VC Mux, LLC, PPPoA, RFC1483/2684, PPPoE, CLIP and often others. These are all ways of carrying your Internet traffic in ATM. I'm only going to consider PPPoE and PPPoA encapsulation, as those are the only two options AAISP offer.

On a BT Wholesale line, you get to choose an encapsulation method (either PPPoA or PPPoE); the other end can autodetect what encapsulation you're using, by looking at the incoming ATM cells.

For PPPoA, the incoming ATM cells contain PPP directly. When the PPP link is not yet up, these will always begin C0-21.

For PPPoE, the incoming ATM cells contain a 6 byte Ethernet over ATM header, a 14 byte Ethernet header, then the PPP. The Ethernet over ATM header always begins AA-AA-03.

Incidentally, this means that PPPoE is always going to be slightly slower than PPPoA - when you're unlucky, it will use one ATM cell more than PPPoA for a packet, costing you some speed. Eagle-eyed readers will also recognise that this makes Be Retail's ethernet over ATM services use slightly more overhead than PPPoA services; there are 20 bytes of overhead for Be, to the 2 bytes of PPP overhead.

There are some differences in how this all works between BT 20CN and 21CN:

In 20CN, your DSLAM port is an ATM device - it knows nothing about PPP, IP, Ethernet etc, and just transfers ATM cells to the BRAS, using BT's ATM cloud. The BRAS does the encapsulation autodetection, handles the PPP to L2TP translation, and passes L2TP to AAISP.

In 21CN, the ATM cloud is replaced with an Ethernet cloud, running with jumbo frames. Your MSAN port does the autodetection, removes the ATM cell framing, adds Ethernet framing if you're doing PPPoA, and sends the resulting PPPoE frame (which can be oversized - allowing a full 1500 byte MTU) to the BRAS, which then does PPP to L2TP and passing data to AAISP.

There is never a performance gain on BT ADSL from using PPPoE; in 20CN, it's just one more block of bytes for the BRAS to strip. In 21CN, you save the MSAN adding a block of bytes to each packet, but it can do that without measurable impact at incredible speeds (easily into the gigabits per second per ADSL port), and you lose data rate on your line carrying those bytes.

Techy geeky stuff

First, a quick walkthrough of ADSL layers:

• At the bottom-most layer, you have a broadband analogue signal, changing at a rate of 4 kBaud; this is split into bins of 4.3125kHz, each of which encodes up to 15 bits per bin. Bins 0 to 5 are reserved for voice. The remaining bins vary depending on the standard.
  • Upstream is bins 6 to 31 in Annex A (for all the supported standards, ADSL1, ADSL2 and ADSL2+)
  • Upstream is bins 6 to 63 in Annex M (ADSL2+ only)
  • Downstream is bins 32 to 255 in ADSL1 and ADSL2
  • Downstream is bins 32 to 511 in ADSL2+ Annex A.
  • Downstream is bins 64 to 511 in ADSL2+ Annex M.
• The next layer is ADSL frames, which include error correction and sync framing. This level is normally invisible to the user.
• The uppermost layer I'm going to consider is the user frame level. There are two modes permited in ADSL1, and three in ADSL2 and ADSL2+: STM, ATM and PTM. STM uses the SDH frame structure; PTM carries higher-level protocol frames directly, typically Ethernet frames. ATM is the mode used in the UK (and most deployments worldwide); ATM cells are packed into ADSL frames, but all you see is a stream of ATM cells.

An ATM cell is 53 bytes long, 5 bytes header, 48 bytes payload. A 48 byte MTU is too small, so we use an encapsulation called AAL5, which takes 8 bytes from the last cell in a set, and lets you have up to 65535 bytes of payload. So, 100 bytes of payload in AAL5 is carried in 3 cells; the first two cells have 48 bytes each of the payload, and the last cell has 4 bytes of payload, 36 bytes of padding, and 8 bytes AAL5 trailer. For a second example, if you had 96 bytes of payload (a disaster case), you get 3 cells. Two cells contain 48 bytes each of payload, and the last cell contains 40 bytes of padding, and 8 bytes of AAL5 trailer.

PPP adds a 2 byte header to each IP frame - so, to send 1500 bytes of IP data, you send 1502 bytes of PPP. If you're doing PPPoA, this 1502 bytes becomes 31 cells containing 48 bytes of payload, and a cell containing 14 bytes payload, 26 bytes padding, and the 8 byte AAL5 trailer. Your sync speed is measured in kilobits of cells per second, so a 832kbit/s sync speed is around 1,900 cells per second (832kbit/s divided by (53 bytes per cell)).

If you add PPPoE into the mix, the PPPoE header adds another 6 bytes. The Ethernet header adds a further 14 bytes, for 20 bytes overhead. When doing Ethernet over ATM, you normally drop the Ethernet checksum, but add 10 bytes of headers, for a further 30 bytes of overhead. To send 1500 bytes IP in this setup, you need to send 1532 bytes of payload. This becomes 31 cells carrying 48 bytes of payload each, a cell carrying 44 bytes of payload and 4 bytes padding, and a cell carrying 40 bytes padding and 8 bytes of AAL5 overhead.

As you can see, there are whole ranges of packet sizes where PPPoA takes up one fewer frame on the wire than PPPoE. 8 to 37 bytes of IP (never normally seen, as IPv4 is 20 bytes overhead, and TCP adds another 20) are 1 cell in PPPoA, 2 cells in PPPoE. You then get 18 bytes (38 to 55) where the overheads are the same. 56 bytes to 85 bytes of IP take up 2 cells in PPPoA, 3 cells in PPPoE, and the cycle continues. Thus, depending on your packet size distribution, you may see the same speeds with PPPoA and PPPoE, or slightly more with PPPoA.

This is also where the faulty advice to use a 1478 byte MTU with PPPoA comes from - when doing bulk transfers, most of your packets are MTU-sized. A 1478 byte MTU, with the 10 bytes of PPP and AAL5 overhead works out to precisely 31 cells, so you don't "waste" 26 bytes in every 1536 bytes of payload on padding; the downside is a slight increase in number of packets sent, so more lost to TCP/IP headers. Assuming IPv4, a minimum size IP and TCP header is 40 bytes, so this can end up costing you more in extra IP headers than it saves in ATM padding.

Finally, if you're wondering why 48 bytes - there are good technical reasons to make the payload size a power of 2. The Americans wanted 64 bytes, because that would be more efficient for data, and still good enough for voice with echo cancellers in a US-wide network. The French wanted 32 bytes, because that would allow them to have a France-wide network without echo cancellers for voice. They refused to agree, so management types compromised on 48 bytes, a pain for *everyone*.

Aren't committees wonderful?

Edited 2010-04-27 - the 1478 byte MTU advice is correct for bulk transfers, but not for some mixed size transfers. In a bulk transfer, you get one padded ATM cell per 1500 byte packet; my error in reasoning was in not noticing that you don't also get one extra IP packet per 1500 bytes transferred if you do 1478 byte MTU. In practice, this means that for small transfers, 1500 byte MTU is more efficient - for larger transfers, 1478 byte MTU is more efficient; I leave calculating the point at which the extra IP headers outweigh the extra ATM cells to the reader. Thanks to Simon Arlott for pointing this out to me.

Subtle discrimination

Note: this post was edited on 26th February 2009.

This blog post has been triggered by a discussion on LWN.net (a site whose editorial content is of a very high standard - if you have an interest in FOSS, I'd highly recommend subscribing - I comment on there as "farnz").

The particular subthread that set me off was one on the (relatively) low participation of women in Free Software; it began with a commenter suggesting that whatever was ongoing was not discriminatory, as all project work happens over the Internet, and it's therefore impossible to even guess whether someone's male or female.

We know that women are generally underrepresented in programming compared to the general population, but the numbers we have suggest that around 20% of programmers in the proprietary software world are women, whereas only around 3% of programmers in Free Software are women. It's clear from these figures that something is putting women off contributing to open source; the remaining question is what?

One argument is that women just aren't interested in programming, and those that are aren't interested in open source. This is a possibility, but before we can accept it as an explanation, we need to understand why women aren't interested; as yet, I have not seen anyone try to do this in terms that don't either beg the question, or assume a skills difference without evidence.

Another argument is that the people in charge of open source projects are openly and actively discriminating against women; in particular, if they notice contributions from a woman, they'll either actively campaign against her, or simply ignore her contributions until she gives up. As this requires an active anti-female conspiracy, and yet there are some known female contributors, who are not protesting sexist behaviour by the people in charge, it's a weak argument.

The third class of argument is the one I wish to focus on, as it's often ignored. It takes as an axiom that different groups of people have different views on what's appropriate behaviour for other people, and that those views tend to splinter down lines like gender and race. For example, in the culture I live in, men who argue vehemently against a view they disagree with are being "strong" and "decisive"; women who do the same are being "pushy" and "opinionated". English hacker culture respects people who stand up to authority and say "no, you're wrong, and this is why"; other cultures simply do not permit such behaviour, and actively cast out people who stand up to authority in such a crass fashion; you must instead influence authorities into recognising their mistakes themselves.

Following on from this, people learn to stay away from communities where they believe that there will be a culture clash; for example, women learn to not get involved if they believe that they'll be forced into arguing vehemently against something, as past experience tells them that if they behave equally, they'll be seen as pushy and opinionated. This applies even if the community wouldn't actually treat them that way; the perceived risk is much higher than the perceived gain.

At this point, there's a strong risk of a vicious cycle. The community is behaving in a way that puts off a group; there aren't enough people from that group to change the way the community behaves, and the existing community members don't see a problem. Sometimes, this vicious cycle is exactly what you want; if the group you put off cannot contribute in any useful way. More often, it's not actually helpful, as you lose useful contributors.

So, how does a community avoid getting caught in the vicious cycle? The first problem is finding out that you even have a problem; the people being put off won't speak up, as they've learnt that the consequences of doing so are bad. People outside the group being put off have to make a conscious effort to notice when the community is heading in a bad direction and speak up; note that you will be attacked for speaking up, as you are going to be telling people that they're behaving unacceptably, when they don't think that they are.

The good news is that in the long term, speaking up helps. By making it clear that the offputting behaviour is unacceptable, you create an environment in which some of the people who would have been deterred from contributing feel able to speak up if they're feeling that they're being discriminated against. In turn, this lets them join the community, and over time, their presence will shape the community into being welcoming of members of their group, too, not just the existing people.

---

Footnotes:

An explanation that begs the question is one that includes the question in the answer; for example, "most women who could contribute to open source don't do so because there aren't enough female role models". There aren't enough female role models because not many women contribute, so this explanation begs the question.

An explanation that assumes a skills difference without evidence is one that asserts that the lack of contributions from a group can be entirely explained away by the relatively high standards of the community, without first showing that the group does not normally meet those standards. There are two common variations on this theme:

1. This community wants higher quality contributions than whatever other community has a more even statistical record. We know that some people are better than others at this activity, ergo the bias is just because we want high quality contributions; when the group which is feeling discriminated against raises its game, the balance will even out.
2. This community doesn't pay (or pays less) for contributions, whereas the other one pays well - that's why the bias.

The first of these needs evidence that the skills difference is really present; it's objectively measurable, so you could back it with something like "the proportion of women with 1st class degrees in software engineering as against women with software engineering degrees of any class matches this" - if 3% of firsts in SE are women, but 20% of SE degrees are women, the figure for open source versus proprietary has an explanation.

The second isn't an explanation; all it says is that money can persuade people to do things that are otherwise going to make them unhappy.

Edit on 26th February 2009:

A friend of mine has pointed out that I've been rather one-sided in this post. I've talked about ways in which men unintentionally deter women from participating, but I've omitted discussion of ways in which women end up excluded by their own social expectations.

In my culture, men and women are expected to resolve conflict in very different ways; men typically have it out as a big, big argument, after which everything is settled. Women typically acquiesce in the short term, but apply gradual pressure to individuals (often seen as manipulative "nagging" and "whining") to bring the final result round to something they can live with.

I would argue that the "male" way of resolving conflict is more appropriate for a group project; it results in arguments being resolved in the group as a whole, not in private discussions. Further, the "female" route leads to a perception that there's no point arguing against women who speak up; they'll get their way in the end, so you might as well give in now.

There's no FOSS-only solution to this; as a man, all I can do is avoid being suspicious of women's motives when they break this cultural model. Everyone needs to be aware of when their cultural conditioning is pushing them into bad habits or behaviours, and we need more general cultural change, so that we don't expect people to behave differently (as programmers) depending on gender, race, or other irrelevances.

Market abuse; or, extending control from one market to another

As a geek with an interest in broadcasting, I see an awful lot of people justifying market abuse by Apple, Microsoft and Sky, amongst others. I thought I would jot down my personal views on what is and is not market abuse, and why I don't consider it acceptable.

So, what is market abuse? Market abuse is where you use your power in one market to unreasonably influence another market. In this circumstance, unreasonable means that a competitor who's only playing in the market you're trying to influence cannot possibly match your influence, without first having power in the market you're using.

It's easier to explain by examples of abuse, and not abuse:

Abuse

Tying your web browser in with your OS, and forbidding resellers of your OS from removing your browser or adding another browser.

Not abuse

Giving your web browser away for free, and permitting unlimited distribution of copies without a fee.

Abuse

Tying reception of your TV channels with your TV receiver box.

Not abuse

Tying reception of your TV channels with your encryption card.

Abuse

Tying your mobile phone to a specific provider, and requiring people who want your phone to take out service from your chosen provider.

Not abuse

Permitting mobile providers to subsidise your phone and apply a subsidy lock.

There's a thread running through all of these; when you are engaging in market abuse, there are two separate products being sold. One is worth buying (or getting for free) on its merits, the other is not, so you tie the two together, forcing me to take the poor quality product if I want the good product. But note that there's a slight twist; it's not market abuse if I can get equivalent products elsewhere in the market without the tie.

So, offering me your MP3 player tied to your music player software isn't abuse; I can buy other MP3 players, not tied to your music player easily enough. If I can't get an equivalent to your phone elsewhere in the market (e.g. because your application store means that network effects compel me to have your phone or lose out), it's abuse.

Why do I consider market abuse bad? Simply put, it's because I'm compelled to accept a worse overall experience. Either I accept the poor quality product with the good product, or I lose out on both; it gets really bad when network effects mean that I must accept one of the two products and lose out.

How do companies avoid market abuse? By not tying two products together unreasonably; sell them both separately, and let your immediate customers make decisions for themselves. If you're moving into a new market, don't get tempted to do anything that couldn't be done by a competitor in the new market with enough money. In particular, don't tie your existing product together with your new product, unless a competitor could tie your existing product together with their existing product.

Science, pseudo-science and non-science

As someone who holds strong opinions, I'm often found arguing with people; because my education is scientific, the debate is often around a subject where "scientific evidence" is expected to carry the day. Most of the time, the claimed "scientific evidence" is nothing of the sort - often, it's nonsense using "sciency" words to seem right.

It's quite simple to tell science from non-science, and not that much harder to distinguish pseudo-science from science. If you're planning to argue using "scientific evidence", please make sure it's genuinely scientific before you start.

Non-scientific claims are based on authority, not on testable evidence. Examples include "my doctor tells me that this drug will suppress the symptoms of my hayfever", or "the Bible tells me that God loves everyone". Non-scientific claims don't have to be false; they can be a useful shortcut to avoid going over basic knowledge again and again, or you could be in a realm that science cannot speak on.

Scientific claims have two properties. Firstly, they are based on testable evidence; secondly, when the claim has been tested, it has been found to be "not false".

Pseudo-scientific claims are very similar to scientific claims. The difference is that where a scientific claim has been found to be not false, a pseudo-scientific claim has been found to be true.

The distinction between found not false and found to be true is subtle, and bears further examination; it's about the way in which you test the relationship between your claim and your evidence. When you find a claim "not false", you start with your claim, and think of a way to gather evidence that the claim is false. You then try to gather that evidence; the claim is found not false when your evidence does not contradict the claim.

In contrast, when you find a claim "true", you start with the claim, and try and gather as much evidence as you can of the claim being true. The claim is found to be true if the evidence does indeed agree with your claim.

This does not sound like a huge difference; however, in practice, people tend to find the evidence they set out to gather, unless that evidence genuinely does not exist. What's more, for many of the claims we wish to evaluate, there are many reasons why the claim could appear true.

For example, earlier in the year, I suffered from a bout of flu, lasting about 4 days in total; during that time, I took Tamiflu. Now, I could claim that Tamiflu cured my illness, and point to the fact that I had flu, I took a course of Tamiflu, and I was then healthy again as evidence. This would be evidence that backs up the claim that "Tamiflu cures flu" in a pseudo-scientific fashion, and would be clearly flawed - would I have recovered without Tamiflu?

Against that, I might claim that my camera "sees" infrared light; the test would be to get a high intensity IR source, and if it didn't show up in a photo taken by my camera, I'd know my claim was wrong. If it shows up, then that reinforces the claim, and it's up to me to try another way of disproving it; as I struggle to find a way to disprove it that works, it becomes less and less likely that my claim is false.

The challenge, then, for people presenting "scientific" claims, is to show that they are backed by evidence, and that the evidence has been gathered by trying to prove the claim wrong. In an ideal world, you describe why you gathered the evidence you did, and how I could gather it myself, so that I can check your claim. I can then be confident in your claim, knowing that if I start to disagree, I can check it.

Ground Rules

Welcome to my blog. This is a place for me to post my opinions and thoughts, and to invite feedback from anyone who happens to be interested.

I do not intend to cause offence; I will try and explain my views clearly and rationally. In return, I would like anyone who comments to do the same. All comments are moderated; if I edit or redact part of a comment before letting it through, I will clearly indicate the change. I will also clearly indicate any changes made to blog posts after I publish them.

I am English, socially liberal, fiscally conservative, white, male, middle-class and university-educated; I try to see other points of view, but you may have to explain things that you would expect to be obvious. If it looks like I don't get it because I've not been there, tell me what I'm missing.

If you think I'm wrong on an objective fact, please provide references to back your point of view up. Web references are best, as I can check them at the computer, but I can always go and look in the local library for a book if needed. In particular, if you are claiming that something is illegal in the UK, please cite an act that I can look up on the Statute Law website; similarly, if you are claiming that an organisation prohibits or permits something, please give me something that I can use to go and check exactly what they claim.

For example, if you wish to claim that Ofcom (a UK regulatory body) requires telephone providers to route 112 to the emergency services, saying "Ofcom requires them to route 112 to the 999 call centre" isn't helpful. Saying "Ofcom's general condition 4 requires them to route 112 to the 999 call centre" allows me to check what the regulation actually is, and is therefore a better way of saying it. There are bonus points if you provide a link to your reference on the web, so that I can easily find it - in this example, something like "Ofcom's general condition 4 requires...".

I hope to learn from this experience, and I hope you enjoy reading my blog.