You're viewing an archived page. It is no longer being updated.
EIX Working Group - RIPE 64
Wednesday, 18 April, 11:00-12:30
EIX co-Chairs - Andy Davidson, Fearghas Mackay
Scribe: Amanda Gowland
Chat monitor: Susannah Gray
* Scribes
* Agenda Bashing
* Approval of previous minutes
EIX co-Chair Fearghas Mackay opened the session at 11:00 local time. He welcome attendees, thanked the support staff for the session and asked for comments for the RIPE 63 EIX draft minutes. There were no comments and the minutes were approved.
The presentation is available at:
https://ripe64.ripe.net/presentations/137-ripe_64_interconnection.pdf
There were no questions.
The presentation is available at:
https://ripe64.ripe.net/presentations/80-e-an-20120418-RIPE64-Interconnecting-IXP.pdf
Harald Michl, Univi /ACOnet/VIX asked Arnold what the difference was between connecting Hamburg and Frankfurt compared to other Internet exchange points.
Harald replied that the difference is that you usually have a third party involved that takes care of the interconnection and perhaps you have the choice to have different carriers which take traffic from one IX to the other. He added that by interconnecting smaller IXPs to bigger ones means that you have a reselling partner relationship: the smaller IX might take care of billing, support, etc.
Maksym Tulyuk, AMS-IX, via chat, asked a question about slide 11 and what RFC or standard describes VPLS interconnections.
Arnold replied that there was no RFC.
David Freedman, in response to Maksym's question, said that people might be confusing Arnold's use of the term VPLS. He said he didn't assume that Arnold meant that people would do VPLS signaling between networks but that there are some VPLS instances that are interconnected and the End Users of the exchange just see a VLAN or a port as they normally would. He asked if this was a correct assumption.
Arnold confirmed it was.
Kurtis Lindqvist, Netnod, explained that VPLS is used for VLAN-type rewrites. Some use VPLS internally, but not against the customer.
There were no further questions.
The presentation is available at:
https://ripe64.ripe.net/presentations/152-history_of_peering_and_learning_for_future.pdf
There were no questions for Kurtis.
The presentation is available at:
https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_-_IX_Jumbo_Frames_-_RIPE64_EIX-WG_-_Slovenia.pdf
David Freedman, Claranet, commented that jumbo MTU isn't a magic bullet because as you pack more things into larger TCP segments into larger IP packets, when there is a loss, you suffer a lot more from the CPU overhead of having to regenerate and debuffer that data. He added that this could be catastrophic in BGP. He added that if you are relying on large LRI pack updates between BGP peers and you lose a heavily packed segment you are going to suffer a lot more trying to reconverge that.
David added that he didn't understand from Martin's presentation what the implications were if a member on the exchange doesn't support any greater than 1,500 bytes and whether they are isolated from the exchange and what should be done.
In response to the first question, Martin recommended looking at the issues of moving from ATM to frame relay and “Poz”, where they are at now, ten gig and 100 gig. He said that over time they have increased the underlying frame size of their communication mechanism and changed the processing, whether it be at the ASIC level or CRC level. He added that that is a problem for TCP and there are are two references in the draft about checks on validity over larger frames. He said 9,000 was okay and that 64kb breaks the CRC mindset completely. He added that the packet loss issue is covered heavily in the draft.
In response to the second question, Martin said that in the draft, they talk about various ways of doing it but says the way not to do it is to just tell your members to try 9,000 and see how it goes. He said if certain members on an exchange are still configured at 1,500 and you send them a 9,000 byte packet it will silently drop. He added that you can't just say to people “go to 9,000” because some won't get the message and some don't have jumbo frame capable hardware. Martin added that this is why the draft suggests multiple VLANS or whatever the various techniques are, and that it does result in potentially twice as many BGP sessions: one over a 1,500 byte fabric or VLAN (or whatever the number is) and over 9,000. He said that it works this way and that you can't have disparate MTUs on an exchange. Martin welcomed feedback.
Wolfgang Tremmel, DE-CIX, commented that they have a separate VLAN with 9,000 bytes but that no one connects. He welcomed Martin to be the first one.
Martin replied that he will be the first but that it takes two to tango.
Maksym Tulyuk, AMS-IX, via chat, asked who must migrate on the flag day: the IX or the IX and the customers.
Martin replied that if you do have a flag day, both have to migrate. He added that flag days don't work and if you are an Internet Exchange, avoid it.
Gert Doering said he liked jumbo frames but for different reasons than Martin. He has customers that encapsulate stuff so the End User MTU tends to be small. He added that he has a complaint about Martin's methods of simplifying too much, that Martin claims throughput is proportional to packet size, which it isn't. There's the TCP window in between, for example. Throughput goes up by packet size but not twice the packet size, twice the throughput.
Martin said that the caveat is that he oversimplified the formula to get through the math for the purpose of the presentation. He said there was ten to twenty pages of this in more detail and welcomed people to read it.
David Freedman agreed with Martin and said it was complicated. He said it would be good to see more data on real-world performance.
Martin said there are 20 references in the draft. He said that there is nothing new in what he is presenting. The work has already been done, it's a bit dated, but it scales. The math is there and it deals with the questions David asked.
The presentation is available at:
https://ripe64.ripe.net/presentations/107-ripe64-eix-hm-wishlist.pdf
There were no questions for Harald.
The presentation is available at:
https://ripe64.ripe.net/presentations/156-RIPE64.pdf
There were no questions.
Eric Nguyenduy from AMS-IX gave an update on Route Server Performance Test Euro-IX 20th.
Jen from LINX gave an update and informed attendees about a change freeze for the Olympics from 14 July to 19 September. She advised people to get their orders in by mid-June.
Tomoya Yoshida from JPNAP gave an update.
A representative from the local Slovenian exchange gave an update.
There were no AOCBs.
Fearghas thanked the speakers and closed the session.