Re: [v4v6interim] Fragmentation Options in NAT6 presentation

On 3 okt 2008, at 21:16, Eric Vyncke (evyncke) wrote:

> Or more precisely, SP won't block ICMP in transit but have NO choice  
> but rate limiting the number of ICMPv6 packet too big _generated_ by  
> a router to 100 pps or so... (NB: this is already the case now in  
> IPv4 and IPv6 in order to save CPU)

Right.

> Of course, if Google Map (or any other applications) has to open 50+  
> connections per end-user transaction

Which it doesn't. In fact, when I try it I only see a single  
connection, but a bunch of stuff may be cached. AFAIK, a browser only  
sets up two sessions to the same FQDN. When there are lots of sessions  
this happens when lots of elements (ads...) need to be loaded from  
different FQDNs.

Also note that Google uses packets smaller than 1500 bytes.

> and if there are more than 2 end-users connecting to Google Maps  
> within the same second (this is assumed to by ironical -- Friday  
> evening), then some connections will fail...

Only if 100 sessions all send a large packet within a roundrip from  
the server to the router. Since the client needs to load a bunch of  
stuff before the additional sessions can be started this won't happen.

But I guess it could with 100+ different users at the same time.

> (cached information will only be available after the connection  
> timed out I'm afraid).

What do you mean timed out?

> Hence the importance of setting 'manually' the MTU right at the edge  
> where the ICMP generation rate is probably (?) lower than in the core.

You mean using large MTUs in the middle. Then you don't have trouble.  
Using small MTUs in the middle isn't a good idea.
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim