[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 at iab.org
https://www1.ietf.org/mailman/listinfo/ram