Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation

[back on RAM because I believe that's where the LISP folks hang out  
and this is relevant for them, besides, people may think I'm a  
researcher...]

On 11-sep-2007, at 22:05, Brian E Carpenter wrote:

>>> I'm still operating under the assumption that both those places  
>>> are in
>>> ISP networks. Now obviously there are lots of places in ISP networks
>>> that only support 1500-byte packets,

> Can somebody provide evidence for this statement?

Minira#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Minira(config)#interface fastEthernet 1/0
Minira(config-if)#ip mtu ?
   <68-1500>  MTU (bytes)

Granted, this is a fairly old box in a small network, but I don't see  
anyone seriously claiming that ALL ISP networks support packets  
larger than 1500 bytes on ALL their internal links (and also on inter- 
ISP links).

That said, it may very well be feasible to engineer a "jack up"  
solution such that the encapsulated = larger packets only see parts  
of networks that support more than 1500 bytes with a level of effort  
that is within reason. (Let me put it this way: what's easier to  
support: a million prefix in the routing table or a 1600 byte MTU?)

>>> but what would be a better decision
>>> here: push out a reduced packet size EVERYWHERE which we probably  
>>> won't
>>> be able to raise any time soon, or require ISPs to either:

>>> 1. Implement path MTU discovery correctly, or:
>>> 2. Make sure that all encapsulated packets travel over paths that
>>> support at least 1500 byte + encapsulation sized packets

>> All these options look impossible or ugly to me.

> The first one has been eluding us for years, but the network
> still works. What's the evidence on actual deployment? (Also
> see below.)

Please note that this is about the network between *TRs, which is a  
much simpler universe than the host-to-host universe where weird  
OSes, NAT and firewalls get in the way. (Again, assuming that end- 
users don't get to run en/decapsulation boxes themselves.)

> The second one sounds like something that is in the ISPs'
> enlightened self interest, in which case it will happen.

Right. However, that would probably still be a deployment problem  
because we may have to wait for upgrades to happen. Elsewhere, I was  
more or less dragged into a discussion about tunnel MTU issues.  
Believe me when I tell you that  this is a minefield. However, the  
good thing with a LISP-like solution is that we get to design  
everything on all ends (ITR, ETR, mapping) so it's not too hard to  
implement fragmentation at the encapsulation layer. The issue with  
IPv4 encapsulation is that the ID space is too small to support  
decent packet rates. With something like LISP, we can implement an ID  
field there and severely tighten the reassembly window (maybe even go  
so far that fragments from one source must arrive in-order) so this  
works much better. The mapping system could distribute MTU/MRU  
information if that's helpful.

[...]

> Hence RFC 4821, which does need to get deployed.

RFC 4821 (PMTUD without ICMP) is great for TCP, but it's not  
reasonably implementable for most UDP-based protocols/applications.  
It also suffers from the problem that you don't know if your  
corresponent supports it so it requires a leap of faith that things  
will work out.

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram