Archives

Connect Working Group

Wednesday, 5 November, 2014, at 11 a.m.:

REMCO VAN MOOK: Very good morning everyone. If you could all find your seats or some seats or any seats, and if you want to keep talking, please do so outside of this room.

So, good morning everyone. Welcome to your most favourite new Working Group every, the Connect Working Group, we exist now. So we managed to put an agenda together for this session. I am hoping you will enjoy it. Today's session will be scribed by Amanda and we have Laura sitting in the back who is keeping track of Jabber and there is other people involved in the back over there. The agenda was updated yesterday so I am not sure if you have seen it, it's on the mailing list and it's also in the presentation. I hope you will enjoy. Anything else you would like to add? This is Florence and this is me, me is Remco.

FLORENCE LAVROFF: Me is Florence, I guess you all know me by now. So, really happy to see you this morning after a 24 trip from California, I do hope that you really do feel the love.

REMCO VAN MOOK: So we have a couple of more boring things to do first. So, the agenda. Here we go. This is the agenda, so we have done item 0 and 1. Any comments, additions, changes to the agenda? I had a cancellation of one presentation. Mr. Hilliard is afraid to stand up, I heard. It's his first presentation ever, he didn't want to ‑‑ he got scared when he saw the room. So that means more time for other people. We have just won another five minutes back on the schedule. Anything else? Any other business? Anything I keep should keep in mind, track of? Forever hold your peace. Thank you. So there is a couple of things that got left from the BoF; one of them is a continued discussion on Working Group charter. There were some feedback, we had a rough consensus on a charter but we might want to sharpen it up a little bit. So, we are going to talk about that and then there is the awfully dreary item of selecting/unselecting/re‑electing and whatever you do to Chairs, we need to have a chat about that.

So the charter, this is what you guys agreed to previously. If you remember. So, the Working Group will facilitate discussions about interconnect for Internet purposes covering layer 1 to 8 and 8 is pretty loosely defined. Raise awareness in the community about interconnection role plays for the global Internet. Education policy makers on how this stuff works. Act as a knowledge base and the activities of the Working Group to achieve this is without being exhaustive, present and discuss topics related to IP interconnection at Working Group meetings. You are here.

Discussion topics on the mailing list, monitor and take part in discussions about interconnection in other Working Groups like routing and cooperation, and seek to take part in IP interconnection discussions taking place outside the community, like other people in Brussels, maybe.

Does anyone feel like we are missing out on something, this is awfully wrong and broken? We had a couple of suggestions at the BoF. We can go through this really quickly if you like. Is everyone happy with this? That is fantastic. Are you sure? So I just want five minutes on the agenda. So we are going on swingingly.

Here is another thing that we haven't discussed yesterday, we very undemocratically, /TPROFRPBS and I got selected to become Chairs of this Working Group (Florence) we need a process in place to make sure we have something better in place going forward. So, and it's really up to the Working Group to decide what we are going to do, as long as we have a way to select a chairperson, we have a way to unselect a chairperson and we define terms and possibly term limits. Hans Petter, is there anything I am missing here?

HANS PETTER HOLEN: Sounds good.

REMCO VAN MOOK: Excellent. Since it's left up to the Working Groups we can do whatever the hell we like. So my suggestion for this, for now, is a pretty loose process, which is we set a three‑year term for Chairs after which they are automatically unappointed but we can reappoint them if we so like. We do this in a staggered way so we have some continuity and do all of it on the mailing list and aim to always have a minimum of two Chairs. Comments? Suggestions? Eggs? Tomatoes?

WILL: I want to express support for that idea.

REMCO VAN MOOK: Thank you, Will. Anyone else supporting? Is this the IETF? Humming. It's your Working Group, a humming, do we agree with this? I am not sure if I'm equal tied to gauge what a proper humming sounds like. I'll take this as a yes.
(Applause)

That's good. So Hans Petter, can we now get some scribe to the Working Group Chair list. Thank you. Which I am grateful for, by the way.

So we ‑‑ that is the comments and that. So we now ‑‑ we have a charter that everyone agrees with and we have a process to select and unselect Chairs. That is fantastic. And we are how many minutes ahead of schedule now? A quarter of an hour I think. Fantastic. I will let you go to lunch so quickly you won't even believe it.

So, coming back to the real meat and potatoes of this discussion. We have Uta, welcome you to the stage. And take your time. That is a luxury.

UTA MEIER‑HAHN: Let me briefly introduce myself. And let me practice to handle all this together. I am a researcher from Berlin, and I am writing my PhD and the topic is the social side, the social glue that holds the Internet together. So I am a social scientist and as such the technical endeavours are not so much of my expertise but of course I try to describe things accordingly.

So, what I'd like to talk about today is this very topic, Internet interconnection is social. But how? And as a small teaser I would like to show a quick video clip which might indicate a little bit what we can be talking about.

(Video played)

You can find this video on‑line, and some of you may have recognised some people, some may have even participated in this, I believe. And I am showing this because you, the peering coordinators, the network engineers, the exchange point operators, are the objects, the agents of my research, and I'd like to share some ideas with you about a scientific view on Internet interconnection. And when we look at this video, we can say OK this is fun, this is a joke, this may be a statement, even, maybe a running, may be true and it doesn't really mean that anybody acts upon the principles which have been just declared in this video. What it does show, though, is that it's not sufficient to explain Internet interconnection just in terms of clear‑cut economic modelling which draws its basis from, yeah, from just clear‑cut economic modelling, from neo‑classical ideas. So we failed to see other motivations or obstacles also for Internet interconnection when we just look at this. And today, I'd like to offer two perspectives and this is more a teaser than a full presentation of results, I'd like like to make you think about this topic and gather your feedback.

So I discovered two perspectives which may be helpful to look at Internet interconnection from a point of view from economic sociology. The first is the so‑called embeddedness approach by US researcher. He is very popular especially in the US, and in short, Mark Granovetter stated that economic action is not only determined by rational self‑interest, as neo‑classical economics suggest; instead, social, culture, competence, play an important role as well. And through social network analysis, Mark found evidence for this, by the way in 1973, so quite some time ago, and he found out that it's the weak ties which connect otherwise closely coupled groups and to distant groups that are especially valuable. For instance, when you are searching a job or maybe also when you are meeting at a RIPE meeting. So, with I'm asking is there a social network underlying the Internet as a network of networks? What does it look like? And how do the two relate?

Now, I am not pursuing this any further here because there is a certain critique with this perspective, or we need to bear in mind this critique and that has to do with methodology, social network analysis focuses on interactions and this means that inactive structures, discourses, and also the making of these ties cannot be seen if you just focus on ties which you can see. So, like what you are engaging in here could probably not be seen in this methodology.

So, I am moved on to different line of theory, which I believe helps us get a rich understanding of Internet interconnection. And that is the approach from economic sociology or even broader sociology, it stems from French scholars, and in the mid‑1980s, they developed ideas which they claim that we should not separate the economic and the social per se. They favour a general theory. And to start off, they noticed or they emphasised the importance of looking at uncertainties. They say that as humans, in order to interact with each other, we have to mutually adjust our frames of reference just in order to interact, we need to find a common frame of reference. And we do this according to a situation. This means that these frames are not generally attached to us, we can act in one way and in one situation and draw up on different values in another situation. And this basically means that there is always the possibility of a plurality which we can apply to situations. Take this example from the abstract down to an example: Two persons make a blood donation. Now, one may do it for the money; the other out of solidarity for humanity. One applies a market logic to his doings and motivated by self‑interest and maybe the desire for money. The price, where can I get as much money as possible for my blood, this is mode for evaluation. And the other actively actively acknowledges that every human is equal and deserves equal access to resources like blood and the other may determine the value by the measure of collective interest.

Now, what is interesting is that both of these logics can be regarded as rational. There is no irrationality here, they are just different rationales and both can claim some kind of a general legitimacy depending on what you agree on.

So how can we apply this to interconnection? I have conducted some interviews, increasing number of interviews but I am just referring to preliminary interviews which I have conducted in August and with some of the people are here today as well, and just by looking at this, this is not a fully fledged analysis, just by looking at these preliminary interviews, we could ‑‑ or I could make out four rationales which happen to happen in Internet interconnection. One is the market rationale. So Internet interconnection is about the price, about load transaction costs and the one who have purchasing power rule. This market logic concentrates on the moment. It has no ties with the history or the past, really, when you are looking through these glasses, as we would say in Germany. Then there is an industry logic and rationale, the motive evaluation is fish see, automation, also, and this is a theme I have heard in many interviews. Other aspects of this industrial logic are also planning ahead, investing in the future. And this is sometimes at odds with the market logic, as you may know from personal experience.

And two different rationales which are not so obvious but definitely can be found in interconnection or among Internet interconnection practitioners are a domestic and a civic rationale. The domestic is interesting because depending on whom you talk to, people will say trust, trust is of great importance for peering, and others will say I never trust anyone. Definitely, trust is part of a domestic rationale. You trust sometimes and some don't. You may trust peering coordinators with a good reputation, you grant them certain authority, and in the interviews a lot of times I have heard that peering coordinators are very much experts who, in their own company, have such a specific knowledge that even within the company by other colleagues, trust is necessary for this economic relationship to work, because nobody can really judge whether do you a good job or a bad job, especially in smaller companies, talking about BGP, for instance.

And then the civic rationale. This to me was one of the most interesting findings, is that ‑‑ it was interesting because there seemed to be two types of peering coordinators: Those who have a very, very strong idea about the Internet as something precious which enables something good for everyone, for all people. So such people may agree on peering in order to lets say, improve Internet telephony in a structurely weak area, I have heard someone says this or engage in certain types of peering to reduce energetic footprint. There is those who cannot relate to this at all. Tentatively I would say rather older peering coordinators maybe one relate to the civic rationale better or more directly and the younger ones less. The best explanation I had for this is younger peering coordinators may have been born into this commercial Internet while older have experienced how important cooperation was in order just to make the Internet work.

But tell me your opinion about this later.

Now, as part of this theory is that you start looking at what you want to be looking at by finding specific uncertainties. I mean, there are general uncertainties but have to do with Internet interconnection and these are the network actors face systemic uncertainty and architectural opaqueness. Let me go into this a little bit. Systemic uncertainty means the Internet is live; network actors strongly depend on each other in dynamic way, there is limited control. And architectural opaqueness means that network and application layers on the Internet are separated, as you all know much better than I do, and in comparison to at layer businesses or content companies, network actors, if we would stick to this a little bit broad stroke differentiation, who operate an AS have less abilities to qualify data and corrector rise data as specific in material goods. So there is this kind of a boundary zone which limits the interconnection market.

But lets go into this a little bit further. This systemic uncertainty, it's live, yes, I mean, I don't know how many network centres actually look like this. Maybe you can invite me to come and see your network centre, I would be interested in that. This seems to be somewhere in the Asian area. You need to watch out for your networks and the uncertainty has to do with BGP as a protocol. This is by many concerned both critical and highly complex. Some even say it's black art. And others say anybody can learn it. However, it doesn't really depend which side you are on here, it doesn't exactly matter because if the networks you are connected to mess with the configurations it's just likely that you will be affected, at least somehow, maybe indirectly, maybe more and maybe less.

So, the beauty of Internet interconnection also is its risk, I would say; you become interdependent. Other networks' uncertainties are your uncertainties.

So, how do you all deal with this? Tell me more about it. Two ways I have found ‑‑ well, or three: Trust is one way, but it may not ‑‑ may not go too far because in the end, you have to pursue further action and two of these ways of acting are developing a procedure for the resolution of irregularities. Now, this sounds very technical; basically what I mean is just throughout the last couple of years from what I have found and again, correct me, the peering coordinator community has established rules about how you get in touch about peering dB and where you get the e‑mail address and approach different networks when you have a problem with them, that you need to solve, and all this. So these procedures actually help mitigate this type of uncertainty which you are all subjected to. And then there are initiatives, collective initiatives like the routing resilience manifesto which has been presented two days ago here as well, so these initiatives for collective responsibility and collaboration are also like we will hear later in this session, common practices or rules. So these ways ‑‑ these social investments, I would say, they facilitate coordination by making things more general in carrying coordination forward.

What about architectural opaqueness, what is important about this? Well, as you all know Peter than me, the architecture applies the separation between network and application layers and it's the end users' devices where meaningful relationships between the IP packets are reconstructed. Where is the uncertainty here? Some of you may be product managers. As a product manager, you are probably constantly looking for new ways to create products and find markets. From an economic sociology point of view, however, markets and products are not a given, they cannot be found; they have to be created. This implies that participants need to achieve some kind of a shared understanding of the characteristics of the qualities of the products before exchanging them. Now, what is the product in Internet interconnection, tell me. Back to the architectural opaqueness, this situation prevents network operators from qualifying data content, as I said earlier, and by content I mean information and its meaning for its users or goods or services. This uncertainty caused by the architectural structure of the Internet lives in the boundary zone of the Internet interconnection market and I think many of you are dealing with this by tailoring or trying to tailor products and having difficulty in getting the right products. It's not as simple as sometimes described.

Summing up: The product may be less homogenous in reality than on the sketch board. It demands a construction effort. And there is not one market for connectivity, but many markets, and these types of what I would call quality conventions, they characteristic the borders of these markets.

I am almost done here. Just as a takeaway, some questions, and one claim, I suggest to dispose of a universal view of Internet interconnection, I believe that you always have to do a situational analysis, and I believe many of you even do this and yet try to apply broader and general models, so there may be a mismatch between practice and theory there. I am asking you, do you believe that there is some kind of a social network beneath the Internet, is this plausible? Should we pursue this any further? And when thinking about this plurality of rationales, I'd like to ‑‑ you to think about when do you change justifications, when you communicate with other peering coordinators, when you are doing business dealing, where the moments you switch which kind of arguments you apply or is it applying certain arguments here and when you go to having business, it's all some other kind of rationale. And in the end, the specific uncertainties and there may exist more which I don't know of yet, tell me about it, and how do you mitigate them. Maybe there is something I haven't seen yet.

Finally, as I said, I am here to study you and it would be lovely if would you participate in my research. You can do by either talking to me directly so we will set up a date and possibly do an interview or just talk. Also you can just go to my website, drop me a note and we can set up a date for some point of time. Thank you very much.
(Applause)

FLORENCE LAVROFF: Thanks very much for this nice presentation about the social side of the Internet interconnects peering coordinator.

So now we are to have another presentation.  ‑‑ oh, yes, has anybody questions, please, don't be afraid to approach the mic.

AUDIENCE SPEAKER: Andy Davidson from non‑app IX Leeds ‑‑ peering hippy for all. So I think an interesting ‑‑ I enjoyed the presentation, it's good to hear your work in progress so far. And I thought that something that is of interest and probably a common belief of everybody who is a peering coordinator, a way to deal with the specific internet weakness on the internet is to build more of it and that is in answer to your direct question how do we get around the inherent weaknesses of the system, how do we get around the fact that there is complexities hard to map and modes that are different each time, building more Internet, peering, is the way the single best way of getting around that that problem and that is something that motivates interconnection as well because it is a real risk, you have identified a real thing but this is a solution that a lot of people believe is the way forward.

Another motivation I think might be interesting is about control. The more interconnection, the more densely meshed the network is, I think there are people who believe that that means that it's harder for any one organisation, one carrier or one system to control or again be a weakness on the Internet. So I think that that is something that motivates everybody, making sure that the interent is open, that needs for the Internet to be well peered, that is the motivation that drives me and I think it drives other people too (Internet).

FLORENCE LAVROFF: Thanks for that. Any other question here? I think that is it. Thanks a lot.
(Applause)

All right. So lets move on to our next point in this agenda which is a presentation from about IP interconnection for voice. Martin John.

MARTIN JOHN: Good morning. Thank you for this opportunity to talk about something which is not directly related to IP addressing or IP. I am Senior Telecoms Architectect, a position I have held for ten years. I am the Senior Telecoms Architect, a position I have held for the last ten years. This is my first time standing up talking in front of such a group but for those of you who know Adam Beaumont, I didn't have much choice.

I guess my title is not really that important I answer directly, as CEO he lets me get on with it, I guess I control the whole says voice network. I specialise in developing international voice networks into emerging markets, working alongside incoming operators. Predominantly Middle East and Asia. Technology moved to IP and frame in between. After travel I decided to settle in the UK. For those of you who do not already know AQL, we are a UK based service provider, operating predominantly through the wholesale channel. We see the background and provide what we hope to be reliable services which are resold largely through Internet service providers. We host over 80 million UK numbers. As an MVNO we provided voice and data for a period and soon realised no one uses a phone to make phone calls. We provide 3G data along fix line to go mobile, sold from machine ‑‑ smart metring. We also message hub. We supply wholesale message termination to several international message hubs and network operators and responsible for the message service over 94 million approximately 42 telecoms operators. The part of that businesses use 4 SS7 stack. I am going to call about C7 voice part, we do TDM, C and a few others things on IP.

We are also a data centre operator. If you are an XIP hopefully we have seen you in Leeds. Is the home of IX leads Internet exchange. The reason IX leads is in our data centre is partly due to our voice services and the need for ISPs to peer to in a northern location as well as peering with us over links LN lap in London. I am going to speak about some of the challenges between word world of IP and voice. It's coming ever closer, expanding the services that can be used and enjoyed by end users, increasing productivity but presenting challenges along the way. We have seen voice‑over LTE being adopted and IP exchange services start to be adopted by major Telcos.

In the same way as our differences in circuit switch V carrier switch they are complete different ways of working. In the IP world, we have an ISP looking after address space for Europe, we have Internet Exchanges which look after peering relationships, proactively co‑operatively and productively. However, voice is a regulated service so we can't be quite as proactive. Rather than having a central body, voice generally falls under the telecoms regulator of each country. In the UK OSPF come, while the allocation of new ‑‑ having allocation is only the start of the challenge. With IP address space there will nice and well‑designed protocols to making the process very efficient. We have telecoms numbering the process is much lengthier. Historically BT is the incumbent operator in the UK and can be viewed as a form of peering exchange. They, however, unlike most popular peering are for profit and if you want to service the UK market interconnection is not optional, unless of course you host your number ranges on already established communications provider such as AQL. Whichever route you take between finding paperwork and submitting routing plans the time frame from allocation to numbers being live on the BT network is around 40 business days. That is just for geographic numbers.

The announcement of new ranges to other communication providers is much more archaic and actually takes part via Yahoo mailing list, and you can imagine the fun that adds. Voice networks traditionally are dedicated TDM circuits. While this ensures core quality is not as assured, it's for this reason we invested heavily into our geographically resilient network over the past ten years. As telecoms operator it's our responsibility to make sure that we have enough connectivity in different parts of PSTN Cloud.

AQL wholesale, we started life in 2004 so we are ten years in. We started as a joint venture company as equal shareholder. The purpose of the venture was to stare interconnection agreement with UK providers, our main business was mobile business and reason for joint venture was back at that time we saw Joyce as an extra service, not a stand‑alone business. In 2004 we purchased our first switch, it was a German called Teles, a big leap but it was worth it and continues to form the centre of our core. It was our aim not only to provide voice services but the first company to extend to the ‑‑ domain registration, in a couple of minutes the customer could be operational with UK numbering wherever the number false, this is something that wasn't achievable before. Our job is to sit in the background and provide our ISP customers to million of phone calls to choose from and to be able to provision realtime. To do this, we use ENUM and it's ENUM database which provides that realtime agility.

Going back to numbering allocations, which is a task in itself, it used to be only possible to deliver a local area phone number to a customer if you had an exchange in that town or village. However, when you are delivering over IP to the end user you can just have a few exchanges. In key cities numbers delivered and handled by those central exchanges. Ofcom is the regulator and this is a regulated product wasn't really prepared for the changing model and once we built our network we realised we could host any range. It was a fairly lengthy process with the regulator but we wanted to get a block of for example 1,000 or 10,000 numbers in every area code in the UK. So we started to send these in bulk which highlighted another failing in the system. OfCom soon started to grind to a halt and we were asked to slow down our process. Turned out first year to go from 0 in a matter of days. This is a problem that still exists, again, you can't just go for national coverage, it's a long drawn out process.

Over time, we started to spread our network throughout the UK. We now have a geographic deploy switching core and it's a marriage plus point for our customers and. In only minimises travel over the BT network but based on good geographic IP P peering is kept to a minimum maintaining quality. In the voice world there is not really an equivalent of BGP, but we need to ensure that should we loose connectivity to BT or even entire data centre that we could maintain service and quality to our customers. By indicating to BT and multi‑geographic locations ensuring spare capacity by separate parts, this was achieved.

For the past ten years, engineering operations in the voice network have been under the control of AQL and the 1st of October we acquired JV company as entirety and launched voice wholesale. Having control of the network opens up a whole new chapter. We are currently filtering a carrier grade resilient solution, which include VIX support, somethinging that we hope will change. 2015 was the more exciting features in APIs.

Geography is dead but for some time our low cost of number outside of their traditional area code or country, geographical considerations are still much alive.

In inside our network we can manage the path the traffic takes and ensuring quality as best as possible for 2010 arrives at a customer is next challenge. Taking aside the local loop and copper wiring in a pure void world and it is rare problem manifests itself that results in core quality issue. When we converge voice and IP, quality of service and RTCP play a big part in delivering quality. In the converged world packet loss and latency leads to calls taking on a direct nature. It's why we peer and directly connecting multi‑geographic locations. It makes little lens for ‑‑ to have to traverse network in London so for AQL is not about big traffic graphs, we don't have a lot of network traffic but it's highly sensitive for quality rooting and peering. Convergence is coming ever closer, we have done a lot of work to ensure we can root voice and SMS. The reassuring bit for us all we always need good quality data with low latency and in the same way as AQL provide commodity service can only be resold if commodity with security and reliability. I am not sure if there are any questions.

AUDIENCE SPEAKER: I am curious. Maurice Dean from Facebook. I am curious. What do you need from interconnection facilities like IXPs to support your voice and SMS traffic, are there needs not being met today?

JOHN MARTIN: About having good peering and good quality of S the SMS traffic is not ‑‑ is an overthe top application that we run. The voice is about having good peering, low latency and low jitter, the more peering we have the more reliable and the regional, the better it is for the end customer.

AUDIENCE SPEAKER: You are not in need of like Internet Exchange points because if jitter and lacency are quality characteristics are important is it interesting to render those at various points ‑‑

JOHN MARTIN: Absolutely. The more data the better.

AUDIENCE SPEAKER: Maybe we will talk about that after.

FLORENCE LAVROFF: No other questions? I guess that is it. Thank you.
(Applause)

And we shall move forward now with the next point on our agenda which is about best peering practices working with CDN. Our presentation from Maurice Dean and myself.

So important disclaimer for this presentation, Maurice and myself will speak in our own names. We won't mention that we work for Facebook and for Google in this presentation. Just to let you know.

So, working with CDN towards best practices. Lets start with the beginning. What do CDN do, what do content delivery network stand for? The aim of consent delivery networks is to optimise the delivery of content to end users within an ISP. They do this in a very important win‑win basis; I can't ‑‑ I can't say enough how important that is. The aim for CDN is really to create long‑term win‑win relationship with ISPs. How how do CDN optimise content delivery? They do this in various labels, lets start with proximity which is serving content on the shortest reliable path to user. There is also traffic flow control and optimisation to serve this to the end customer also called eyeball in our language. By balancing the load across the architecture infrastructure of the ISP. What is also important is to note that the CDN offer a cost efficient delivery of this traffic to end users and this is particularly important for unpredictable traffic, depending on popularity and fashion patterns like media content and video content.

So lets move on to next slide, which is actually the goal of this presentation. So why are we doing here, Maurice and myself? What we would like to do is to propose recommendation for ISP how to best interact with CDN and this regardless of the interconnection type, whether this is embedded in caches or peering, private peering, public peering, or even transit. They are three challenges that ISP would like to solve with CDN. So the first one is to how to optimally deal with overflow and load balancing of content within the network. And another one is how to ensure that optimal geotargeting and mapping to the end user is reached with the CDN. And last one would be capacity planning, how to optimally deal with capacity planning.

And those are three different questions that Maurice is going to walk us through right now.

MAURICE DEAN: Next slide. So I thought I had start off with just talking about a very simple model that describes something of a challenge for CDNs and ISPs trying to optimally target traffic. Now, most of the folks in this room will probably, after looking at this very overly complex model, figure out most of the elements here. So we have got here are two regions on a given network, the share and resolver for DNS. The challenge is how to target to those users in those region A and region B. The challenge for CDNs are that of course a CDN wants to choose the closest, that may be geographically be true or in terms of latency, the closest cache. Client IPs are mapped ‑‑ sorry, they say the Internet as a whole is sort of mapped and grouped by resolver IPs, as a proxy for proximity to client IPs. That poses a challenge particularly in this sort of scenario where you have got a resolver shared over two distinct regions. Client IPs, similar request, they are aggregated by resolver address and then the targeting algorithm has to make a decision on which has the closest cache. Generally, it will be, if there is no other tie breaker other than resolver IP grouping, then the ‑‑ there is possibility for the target cache to be in the sub optimal location. Because only one cache can serve from ‑‑ in this portal on the client IPs associated with that resolver.

It's kind of a challenge in the sense that it produces not only suboptimal routing but also it tends to be or can be under some targeting systems somewhat variable as well, that if there are connectivity or if the resolver mapping changes between region A and B for any given resolver, you will see a generally see all of the traffic being targeted to the other cache localisation. So these series of problems.

So, there are solutions for this type of challenge. There are solutions for a more advanced targeting systems, and this is mainly around being able to offer the CDN targeting algorithm, more signals about and deLynniation between geographically diverse areas. Examples there could be regionalising DNS resolvers, enabling interesting ideas around DNS extensions, I think there is a tend to grass ‑‑ draft has been actively debated at the moment around this and these techniques provide at least more signalling data or at least means to have a tie breaker when trying to map a client's IP resolvers.

Lets go to the next slide. So this slide tries to also see other ‑‑ by looking at more advanced systems, targeting systems here, other sources that are used. They are observed source like BGP characteristics, some routing protocols. There are kernel measurements or network measurements like latency packet loss, etc. And then the more advanced systems are generally using application level metrics, be they sort of concepts of optimality in terms of throughput or some combination of QOE characteristics. These characteristics are generally guesswork, they are informed guesswork but they are fundamentally guesswork, they seek to infer preferred paths across networks. I think there is space for some collaborative work between the ‑‑ in this area to make that ‑‑ those signals more deterministic; for example, exchanging geolocation data about IP assignments in some structured way that can be shared between CDNs and ISPs. And I think this is ‑‑ am I going to talk to this one, right. That is the targeting area, or at least an example of how we can improve on the targeting area.

Then the other is sort of capacity planning, and I am kind of reading here to be honest. Generally ‑‑ so there is ‑‑ I think the point here is that providing more structured ways to share knowledge about the required capacity for CDNs, where that capacity should be placed and the sort of growth forecast over the sort of longer cycles, is probably an interesting way to do that and there is probably ‑‑ probably a mechanism or lets say a layer 8 protocol, I think we were talking about before, to exchange those datas in structured ways and maybe we should consider that part of a BCOP as well.

FLORENCE LAVROFF: All right. So we are already towards the end of our presentation and this is our conclusion slide. So, what is our conclusion and what is the best common practices that we can define. The first one is announce us all your prefixes, announce us everything, internal, downstream prefixes, really everything, please, because if you do not, if you, there is a risk that they get dropped, and this is is a situation that we really would like to avoid.

And if you would like to indicate to us some preferences, no problem, use traffic engineering for that, communities and ‑‑ yes, just to give an example, something also very important as a best common practice, please talk to us so we may not be able to get things right at first, so jeer owe targeting, let us know and we can work together to make this better, and also this is really useful for us to know some information about your capacity planning, what that is that you really would like to achieve; that way, we can ensure that we are in sync on the long‑term. And I think that is it. So if you have any questions, please let us know.

REMCO VAN MOOK: All right.

JIM REID: I must complain about the height of the microphone. Representing nobody but myself. I think this is a great idea and more power to your elbow. I think we need more information about this kind of stuff and the more people who can participate the better. The one question I would have about this is, if there is to be a BCP on this how would you manage it being published, would this be a RIPE document or do you imagine going it going into the IETF or some other forum? Or is this something that prehaps just publish some kind of joint statement if you like and then leave it to ISPs to figure out how to make the stuff work within their own network? What is your ideas about that.

MAURICE DEAN: Actually, I must admit I am not as familiar with RIPE's processes around BCOP as I am with NANOG's and as a defined process to public a documents to discuss, implement, draft stage and move to publishing, and I would love input on equivalency type of procession ‑‑

JIM REID: Within the RIPE region it's relatively simple: Here is a document, pub publish it, that is it. The best thing to do is have a Working Group come up with a consensus around that, we don't have documents to last call review phrase or that type of thing. So it's relatively lightweight and maybe this might be a good starting point. Publish something and say as RIPE document starting point then BCOP such as NANOG or are you not crazy enough to take it to the IETF?

MAURICE DEAN: Thanks again. That is great. I think this presentation is mostly about gathering interest in developing this thing.

JIM REID: I want to talk about DNS things, we will do that over a beer later.

AUDIENCE SPEAKER: Joe, speaking for myself as usual. I wanted to echo what Jim was saying, here, here in a recently birthed Working Group where this might be a useful work product for this Working Group and a significant subset of your suggested BCOPs are actually just good peering practice, so it might be part of a larger document as well as specifically called out NC D specific usage. I also was wondering, the second question was if you all were considering to the point on the BCOP element, if you were considering encouraging a standardised format for such reporting across several different parties, since being inside a large organisation I have had people come to me personally and say can you help me fix this? Who do I talk to? And the external interfaces for some of those things are opaque, to be polite.

FLORENCE LAVROFF: Well, on the long‑term, this is definitely something that we can aim doing and I would like to see something reading a CDN Google ‑ it might be interesting to check the portal, there are some interesting documentation there and hints as well for GC partners about some best practices.

REMCO VAN MOOK: I see Nenagh up next.

AUDIENCE SPEAKER: Working for Netflix. I totally support, I think we should definitely discuss this more in this Working Group and come up with something. If I take my hat on from my old job and go back a couple of years where I did a presentation from the ISP side, actually, also asking kind of for best common practices from the CDNs that I was working with at that time. I think we should try and make this document go both ways because what I see here is stuff what I would like everybody to do in my current job except the DNS things, we don't need that; you can do whatever you want with your DNS. So just saying. But, I also feel and I also hear when you talked to my partners that also a number of things that we as CDNs or content providers can do to help the ISPs work better with us. We all have documentations on our websites, you were just mentioning, we have good links as well, lots of stuff where you can read everything you need to do to make Netflix CDN work well inside your network. A lot of you don't know it. There is another thing that we can definitely improve on on the content delivery side.

REMCO VAN MOOK: Thank you.

MAURICE DEAN: Can I make a comment. I think that this proposal is really a bilateral proposal, this isn't CDNs telling ISPs what you should do with your network. I think the goal here is to reach a common understanding of the best practices. And I am really interested in the input about how we achieve that, we understand the common goal first we have already made some progress.

AUDIENCE SPEAKER: University of Krakow, Poland. I don't know if ‑‑ to what extent do you want to cover topic of exchange of information on topology between ISPs and CDNs, if it's the case I'd like to raise your attention to ALT owe protocol traffic which has been standardised in September this year by IETF. It emerged from peer to peer networks but they are as important now CDNs are getting more and more important and they are generic to more and more traffic, so this protocol tries to extract some information about topology and pass it to another third party, for example, CDN, and to align overlay top on CDN, for example, to underlay topology. It does not have to be ‑‑ AS hop number doesn't have to be a metric, it may be any metric, it's a flexible protocol.

REMCO VAN MOOK: Anyone else? I can't see all the microphones from here. I think not. So, yes, this sounds like something that we might need to take up ‑‑ oh, yes, there is ‑‑ here we go.

ANDY DAVIDSON: Sorry, I was being lazy, I thought there was a queue, I and it wasn't a queue. I have got a question asking whether, if the problem that we are trying to solve is traffic being ‑‑ being served on the wrong place, going via the wrong place, are we asking too much of the DNS generally to do this? Instead of saying lets look at the resolver IP and saying that is therefore where the user lives and tells us everything we need to know, DNS is really good but it wasn't for this so should that maybe point to something which serves up a generic page which sets a cookie saying which region is user is in and how to find the host names and not try and trust the DNS so that way, ISPs can tell you about users based on the source IP and you can use that in your metrics to serve up where the heavy lifting should be served from by different means. It strikes me that DNS is great but isn't a magic wand.

MAURICE DEAN: Yes, I gave the DNS resolvering as an example and wanted to underline that is a simple version. Most targeting systems are much more advanced, a group of signals and determination. But and I think the ‑‑ to take this sort of high order bit, the idea of reviewing and trying to understand how we can add further signals, is something that is definitely in scope.

FLORENCE LAVROFF: Yes, just wanted to regarding this DNS stuff, so this is of course, a very important for some CDN but some other CDN just to echo previous remark from Nenagh, do not map content to the DNS but BGP only, thanks.

AUDIENCE SPEAKER: A remark to that question with the DNS, the DNS extension you mentioned earlier is where you put the client's address into DNS request and a lot of CDNs don't like the idea of doing http requests and redirect for reasons like as I say, old certificates, things like that, so they really want to have the first contact as a redirect by DNS. So that is the reason why they often use DNS.

REMCO VAN MOOK: All right. Thank you. Do you want to comment on that? No. Thanks. So, wrapping this up, I think this is ‑‑ I think there is work for us here, oh, dear. I think we should take this to the mailing list, see if there is people interested in starting to draft a best practice document, and present again at the next meeting in Amsterdam. How is that? So thank you very much Maurice and Florence.
(Applause)

So now we move to the next party of the agenda which is ‑‑

FLORENCE LAVROFF: Euro‑IX presentation by Bijal.

BIJAL SANGHANI: Hello, and welcome to London everyone. It's nice ‑‑ it's first time RIPE has been to London and it's nice to have everyone here.

I am going to give a quick update on Euro‑IX and about the federation. So this year was actually a really big year for Euro‑IX. Since it started 13 years ago, Euro‑IX was hosted by AMS‑IX and the contract, the secretariat contract naturally came to an end at the 31st of August this year, so since the 1st of September, the secretariat has been run by Euro‑IX itself which means we are doing everything ourselves and we now have two employed staff by Euro‑IX; I was the first and Julia the second. So, I don't know if there is anyone from AMS‑IX here, we would like to say thanks for hosting us for 13 years, and yeah, it's great to be independent now.

Right. So, I am not going to give a full update like I usually do because I have only got five minutes today, but a few projects that we have been working on and quick updates. I presented the IXP BCOPs on Monday during the task force, and this was basically we did a review of the current BCPs that were on the website and we realised it needed to be updating so these have been updated and the link is over there and this was done by actually a few of the Euro‑IX members in the room. So, again, it was done by the IXPs who run the exchanges and if you are interested to see what the best common practice is for IXPs is, you can find it there.

We have a newsletter, it's been over a year now, we have a monthly newsletter so if you are interested in hearing about news from IXPs, you know, we bet the members to write blogs and information, you can find out about what events are on, and even things that are happening at the events, then please feel free to subscribe, it is open to everyone.

A project that we started talking about last year was with a team were put together an IXP Bogan list. Some of you may have seen that announcement a couple of weeks ago and that went live. And what this means is that the IXPs are on their profile pages within the Euro‑IX website, they can just tick a box for each prefixes that they want to send to the bogon list and this will happen automatically and they are using that now so it's active. So that will give hopefully some of the networks here some confidence in that.

I am very happy, I thought I was ‑‑ I am very happy, I am not going to talk about this too much, but I presented about the data task force, I think it was a year‑and‑a‑half, two years ago, at the RIPE meeting, and we have put together, Euro‑IX have put together a data task force and looked at the data we wanted to collect and last year I presented on the new database scheme that we have been working on and that is still work in progress. Just this week speaking to Nick we now have an IXP member list, Jason, which will be talked about later. Traffic is still going up.

IX‑F update: We had an IX‑F kind of very informal meeting just NANOG last month and we finally got around to publishing the definition of an IXP. So, if you still are not sure what an IXP is, feel free to take a look there.

During the meeting we were actually having a discussion on successful models for IXPs and what really is, what really makes an IXP successful, so we are ‑‑ we put ‑‑ we published a kind of document on that as well and that again can be found on the IX‑F website.

The really great news was that African Internet Exchange point association joined the federation last month so now the IX‑F now consists of AF‑IX, AP‑IX in Asia and Europe and Latin America and Caribbean. Very happy to say during the NANOG as well, NA‑IX, which is the north American association, had its first meeting and all I can say is we really hope they will join the federation soon as well.

And that is it. Are there any questions?

FLORENCE LAVROFF: Nobody. Last chance, last call? That is it.

REMCO VAN MOOK: Bijal, just out of curiosity, which is an IXP exactly and can you explain that in less than four pages? So, here is your homework for next time.

BIJAL SANGHANI: It's not as simple ‑‑

REMCO VAN MOOK: Go back to the slide with the URL, this is your homework assignment for next time is go to this website, read the definition and come back with your thoughts. Sang I think we should have a test next time.

REMCO VAN MOOK: We should. All right. So thank you, Bijal.

BIJAL SANGHANI: Thank you.
(Applause)

FLORENCE LAVROFF: Lets move on to a presentation from Elisa, called IXP Member List API.

ELISA: Welcome everyone, I am with Netflix, and I am going to talk about a proposed output format for IXP member lists by the nature of being a CDN network we connected quite a few Internet Exchanges, I counted them up the other day, it's about 30 of them, and automation is crucial for us to be able to determine where we have interconnection points with other peers and automate those set‑ups.

So, we use peering quite extensively but it's great and we haven't waited for the second version. Unfortunately, not all the members of Internet Exchanges are up‑to‑date or have their information up‑to‑date in peering dB at all times so we tend to fall back on the member lists, on the Internet Exchange websites that are tied into the connection process at the Internet Exchange and are usually the latest and newest who is connected at a certain point. But then some IXPs don't provide any exportable member lists from the website; some of them have a couple of different formats, some of them have a few more and some of them have really extensive list of them. The problem being, awful them are kind of different and none of them are in any more extensible format than a text file that just doesn't provide the flexibility and the layers to represent what an actual member at an Internet Exchange is.

What we would like to do, Nick and I sat down last week to write down a JSON schema and propose a flexible format for member lists to export out of the website.

In the really, really simplest version, it is technically a list of AS numbers that is kind of all you need, so all the fields that we have tried to include into the schema are fields that Nick has been following about what Bijal just mentioned, the data task force at Euro‑IX, what Euro‑IX would like to import, also fields that various member lists already provide on their websites. All of them are however optional, so this is kind of the simplest list that people could put out there in this format.

So Bijal put this up on the Euro‑IX website. You can look at the schema here if everyone could just click that real quick and check it out and have a read and give us a feedback. Let us know what you think. Nick and I are here all week and lets come up with a diff to to the current version that includes some information that we might not have thought about in this initial release and to all kind of present how this would work in practice, Nick went real quick into his code for IX manager, the software that INEX and a couple of other exchanges use as their website. So he implemented this real fast and if you go to the INEX website you can create an API key for yourself, I deleted this one, and then this is the URL you insert your key ID at the end, and then this is the format that kind of comes out of that with a long list of all the members.

So this is great. Please, look at the proposed schema. It would really help the IX members a lot and help Euro‑IX a lot and this is all we have got. Any questions?

JOB SNIJDERS: NTT peering dB. I reviewed your schema and I think it looks very, very useful. So I would like to thank you and Nick for putting effort into this. It looks complete and contains exactly the data I would use to automate that I currently scrape through other means. And on the peering dB side, I would be interested to see if we can expose the data according to the schema, maybe sooner than version 2 already and just piggyback on the current data model that we have, so I will reach out to you and see what we can do. Thank you.

Elisa: Thanks to Bijal, we were talking about this yesterday, how Euro‑IX could use the same format for importing that data back which would reinforce the schema and the usability of it. All right.

Vesna: Community builder from RIPE NCC. We are grateful for this and we have a project called open IP maps which is crowd sourcing geolocation information for Internet infrastructure. It's a mouthful. And this will be really useful information to import into our data set. So thank you again.

Elisa: All right.

REMCO VAN MOOK: Thank you, anyone else? There is no queue. Thank you very much, Elisa.

ELISA: Great feedback, thank you very much.

REMCO VAN MOOK: So that brings us to the end of our formal agenda, which means it's feedback time. Since this was the first session of this Working Group, we would really, really appreciate your feedback, preferably in forms other than rotten tomatoes. So, say what you want to say, do you think the room is too small, too hot, too big, too cold, like the agenda, hate the agenda, want something else on there? Now is the time to let us know and we will take it to the mailing list which is a lot more boring. It's fairly quiet. You are unusually quiet. Do we need to do a humming against Carsten? Did you like the agenda or should we do something else. As you saw we almost had no update presentations, that was a goal I think we managed to hit that, short of a little thing that Bijal put in her presentation. So is this the way forward do you think?

(Applause)

I see Carsten coming to the microphone.

CARSTEN SCHIEFNER: That was a little bit of outlook beyond, say, the usual parameter of interconnection, IP interconnection stuff and so forth. So if you guys could arrange to have this this a little more or at least one presentation per meeting in this regard, then I'd appreciate that as well. Thanks.

REMCO VAN MOOK: That is excellent feedback. If do you have suggestions for this slightly out of left field kind of subject, still touch on interconnection let us know and we will see what we can find.

JIM REID: Just again speaking for myself. I think the tone and content of the agenda is perfectly fine and if there is a problem with that Bijal would have killed the Working Group by now.

REMCO VAN MOOK: Oh, dear, Bijal. Please don't say anything. Anyone else? So, with that, I think it's closing time. I thank you all for your time and attention and not starving to death in this little bit too hot meeting room. Enjoy lunch and see you next time.

FLORENCE LAVROFF: See you next time. Enjoy lunch.
(Applause)

LIVE CAPTIONING BY AOIFE DOWNES RPR

DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.

WWW.DCR.IE