Hi Iljitsch, I am responding to what you wrote in "Re: [RRG] Inviting people to join the RRG" http://psg.com/lists/rrg/2007/msg00575.html.
>> http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > > I only scanned this quickly (it's a bit long...), I aim for something which, when read fully just once, is reasonably complete and understandable. The Ivip ID is pretty long too: http://tools.ietf.org/html/draft-whittle-ivip-arch-00 but I think this level of explanation and detail is needed for any ITR-ETR scheme. It is the other IDs which are too short! > but it looks like a complex scheme in the same vain as Fred's MTU > proposals. Fred's latest revision of Sprite: http://tools.ietf.org/html/draft-templin-inetmtu-06 contains some changes which address the criticisms I made here: http://www.firstpr.com.au/ip/ivip/pmtud-frag/#sprite_critique When I get a chance I will revise my critique accordingly. One change is that it would be allowable to assume an MTU_R of up to 1280 on IPv4, which would be better than having to assume something much lower, such as 576. This reduces the number of instances in which the proposed protocol needs to be activated - as long as there is a rule about ITR and ETR placement to suit the assumed limit. Sprite is an attempt to make a generalised protocol for many situations while my IPTM (ITR Probes Tunnel MTU) on the above page is purely designed for an ITR-ETR system. Ideally, perhaps, as you suggest, the single generalised protocol approach would be best, but I think such a generalised protocol needs to be crafted so it can meet the specific lightweight, flexible, requirements which I think are important in an ITR-ETR system. Most of my approach could be used for one of the other ITR-ETR schemes, in which the traffic packet is tunneled with the outer header's source address being that of the ITR. However, my proposal is primarily intended for Ivip in which the outer header's source address is that of the original sending host. It would be quite a twist of Sprite or some other generalised PMTUD proposal to have this as an option, but I have several reasons for believing this latter, unconventional, approach is superior for an ITR-ETR scheme. Firstly, I think "Outer header source address = sending host's address" is the only practical way ETRs can enforce (on the packets they decapsulate and forward to receiving hosts) the ISP's filtering which tries to prevent spoofed source addresses in the ISP's network. http://www1.ietf.org/mail-archive/web/ram/current/msg01691.html http://www1.ietf.org/mail-archive/web/ram/current/msg01697.html http://www1.ietf.org/mail-archive/web/ram/current/msg01705.html Secondly, I think this approach lends itself to support for Traceroute, with relatively simple modifications to the Traceroute software. There may also be some other reasons for preferring this. The reason links to a separate issue of why I believe all traffic to an ITR-ETR mapped address should go through an ITR and the correct ETR. Only the ITRs - not the local routing system of an ISP in which a packet originates, and in which the destination host might be located - are responsive to the mapping database, which I think should solely be in control of the forwarding of packets. This leads to the concept of the ETR not being able to rely on the local routing system forwarding packets with the raw destination address to the final destination - local routers should forward those packets to an ITR. Therefore, I think the ETR needs some locally determined arrangement of a direct link, or a tunneled, method of forwarding packets towards, or to, the receiving host (or end-user network router). I think all this is very different from from the way the proponents of the other ITR-ETR schemes think. I will maintain my separate IPTM proposal as either a specific approach to be used only in an ITR-ETR scheme in general (Ivip in particular) or as an outcome to which a generalised approach such as Sprite might aspire when used by an ITR-ETR scheme. You wrote: > In my opinion, that's not the best way to handle this. > First of all, operators need to make sure that they use decent > MTUs after tunneling so that hosts that send 1500-byte packets > won't get in trouble or lead to much, if any, MTU discovery. I think it may be reasonable to insist on something like "Every ITR and ETR must be on a link with at least an XXX MTU to the core of the Net", but XXX needs to be below 1500 for a variety of reasons - although I have only a rough understanding of the various situations where it is currently lower. Encapsulation in DSL links is one. GRE or some other tunneling is another, for instance as some parts of some networks use this continually, or perhaps to handle outages. Bill Herrin gave a good example of this: http://psg.com/lists/rrg/2007/msg00348.html As far as I know, we can't reasonably insist that any operator provide an MTU above 1500. Even if, for some reason (and I understand this is not the case, due to typical limitations of 100Mbps Ethernet gear) the "core" of the Internet had a greater than 1500 byte MTU, I don't think we could insist that ITRs and ETRs be located in places with an MTU >= (1500 + worst case ITR-ETR tunneling overhead), since we need ETRs to be deep in ISP networks, and we need ITRs to be almost anywhere. For instance, I think that in quite a few circumstances it would be best to have the ITR function (a caching ITRC function) in the sending host. So I think we do need a scheme such as Sprite or IPTM, rather than what I understand you suggest - insisting on larger than 1500 MTUs in most of the Net, so hosts can carry on sending 1500 byte packets which do not fragment, even when tunneled. > Second, tunnel endpoints should simply implement two sides of > path MTU discovery: they should discover the maximum packets they > can successfully send to the other endpoint, and they should set > their own inbound MTU to that value minus the size of the header > that's added. This is simple enough that it's possible to get it > right and doesn't add much overhead. This is what Fred's and my approaches are trying to achieve. However, when sending the first packet to an ETR, there is no time for the ITR to muck around testing the PMTU limit before sending the packet. So I suggest sending it if it is shorter than some assumed limit (eg. 1280) and fragmenting it if it is longer - irrespective of whether its do not fragment bit is set. Later, if more such packets need to be sent, the ITR and ETR can work on determining the real PMTU. I do this with probe packets, rather than traffic packets. I think Fred's approach and mine have a lot in common, but he is trying to make a generalised protocol for many other scenarios beyond ITR-ETR schemes. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
