"L3DSR -- Overcoming Layer 2 Limitations of Direct Server Return Load Balancing" Video?

Might someone have the video for this presentation in their personal stash?

http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf

http://www.nanog.org/meetings/nanog51/abstracts.php?pt=MTc1MyZuYW5vZzUx&nm=nanog51

It would be much appreciated!

-M

I don't have the video handy, but there really wasn't all that much more
info in the presentation than in the slides. It might be worth noting
that the modules are now open source:
https://github.com/yahoo/l3dsr

If you have questions, just email me.

-Jan

Hi, Jan. It's a great presentation and I really love your approach.
However, I am curious -- why was IP-in-IP not pursued? I know the
presentation mentioned the MTU issue, but your final solution seemed
full of enough pitfalls itself (ie -- lots of cooperation from
numerous groups, people, and processes) that raising MTU in your
network might be an easier proposition. Thought you might have went
into it a bit in the video, that's all. Any insight?

-M

We have come to the conclusion that Path MTU Discovery on the internet
at large... doesn't work so well. :slight_smile:

With IP-in-IP or GRE, our MTU increases, so either we keep the MTU the
same (to the outside) and declare (internally) our own largest packet to
be smaller than 1500 or change the MTU (internally) to be larger than
1500 (to account for the overhead). Either way, we end up with an MTU
that's different between at least two of the client, the LB and our
server.

The idea of using the DSCP bit then seemed to be more reasonable to us.

-Jan