[v6test] Concerns about network impact

[Kevin Day]

On Jan 12, 2008, at 11:39 AM, Iljitsch van Beijnum wrote:

> On 12 jan 2008, at 2:53, Kevin Day wrote:
>
>> For #1 and #2, we're going to suggest to networks that feel their
>> network is going to break to preemptively block or rate-limit access
>> to the IPs used for this experiment.
>
>> Thoughts? Comments?
>
> I would suggest a different strategy. Rate limiting is not an easy  
> thing to do (depending on equipment), and especially not easy to do  
> in a TCP-friendly way. (I.e., just dropping the packets over a  
> certain bps limit is deadly for TCP performance.)
>

Yes, but less deadly than breaking their network entirely. :)

> It would be great if some kind of limiting could be implemented at  
> the side of the experiment server(s). That way, operators only need  
> to communicate their address blocks and acceptable bandwidth  
> figures. I believe there are web servers that can handle traffic/ 
> user limitations.
>

I thought about that, but I'm not sure how feasible it'd be. I'm more  
than happy to blackhole any networks that ask me to, but I don't know  
that it's any easier for me to do that than it is for them to. As for  
rate limiting... It's possible, but tends to come with a performance  
penalty on the server side which I'd like to avoid if at all possible.  
I'm expecting to have our cluster crushed from traffic as it is.

> Also, how do you plan on talking to 6to4 users? Using native  
> connectivity or by having a local 6to4 relay? Since the majority of  
> the traffic is from the experiment servers to the users, having a  
> local relay means that the traffic is pretty much end-to-end IPv4.  
> If you send it out natively, you just test the capacity of the  
> closest public relay.
>
> One approach could be to have a landing page that redirects people  
> (and possibly implements user limitations for users of IPv6- 
> constrained ISPs) so you can experiment with redirecting 6to4 users  
> to a 6to4 address for the service, which means that there are no  
> 6to4 relays in the path from the user to the service either, or  
> redirecting 6to4 users to a native address so there are relays in  
> the path.
>

6to4 has been an interesting problem for me so far. In our Chicago  
POP, where this experiment is going to take place for the most part,  
we've got 3 primary transit providers. Each giving me a different set  
of paths to 6to4.

* Through provider A, anycast v6 takes me to Carpathia(AS29748)'s 6to4  
relay. But, if I send any traffic to 2002:: towards them, it doesn't  
seem to make it to any 6to4 users on the v4 side.
* Through provider B, I get Titan Networks(20640)' relay. This works,  
but I've got inside knowledge that my upstream's bandwidth towards  
them is not going to be sufficient for this experiment.
* Through provider C, I get Sprint(AS1239)'s relay. However, I've been  
told this is going over two tunnels. It's also quite slow.

So, in the end we set up our own 6to4 relay and announced it to the  
world. It wasn't the easiest decision, because it ends up meaning that  
all outbound traffic to 6to4 users is leaving our network on the v4  
side. I'm not ending up exercising much of the v6 network for all of  
6to4 access.

But, I'm guessing I'm not going to be the closest anycasted relay for  
95% of the world out there, so traffic coming IN to us is still going  
to be native v6 (from our perspective anyway).

Your idea about using a 6to4 addressed server for 6to4 users is  
interesting, I'll have to simulate that to make sure it's doing what I  
think it would.

-- Kevin