Subject: Re: [mobile-ip] RH and path MTU discovery

From: [email-masked]
Date: Thu, 31 Jan 2002 15:19:51 -0500

Erik,

I believe a lot of the questions you raised (and Francis answered)
are design and implementation details which are solved differently
by each vendor (eg Compaq).  I think they're outside of the scope
of the draft.

Comments below.

-Brian

> > => this kind of stuff should be cached per PCB (i.e. per connection).
> > There are two ways:
> >  - the active way: when the BCE is created, all PCBs connected to the
> >    MN destination are notified they have to recompute the MTU/MSS
> >    (the routine already exists for ICMP packet too big arrival)
> >  - the reactive way: when the stuff is added the packet becomes too
> >    large, an error is returned and the sending routine recomputes
> >    the MTU/MSS and retries.
> > In fact both are used because of unconnected PCBs, i.e. the reactive
> > way is considered as the not optimized but always working way.
> 
> So existing MIPv6 implementations do this?

Yes, we essentially do both active and reactive.

> >    If a TCP connection starts out without using RH and later route
> > optimization
> >    has been setup (causing RH to be added by the IP layer) then a packet
> >    that previously fit in the MTU will no longer fit. Thus the IP layer 
needs
> >    to be able to notify the TCP layer that it is adding N bytes to the
> > packets
> >    so that TCP can adjust its understanding of the effective path MTU.
> >    
> > => I agree but if an ICMP packet too big is received the TCP layer has
> > to adjust too.
> 
> So existing MIPv6 implementations do this?

Yes.  First, since we are the end-node, we can fragment this packet and
not drop it (usually) if adding the RH causes us to exceed the mtu.
Second, like you said, the IP layer can notify TCP that it is adding
N bytes of options into each packet, so it should adjust it's view of
the mtu.  This is an implementation detail of course - not every IP stack
has this capability.

> >    Such packets would need to be recognized by TCP as effecting the MTU
> >    for the connection even though the destination field in the
> >    "packet in error" in the ICMP packet is the CoA instead of the HoA.
> > 
> > => the packet in error has the RH too so the problem is only on the
> > code which peels headers in order to do the proper action (this is
> > easier than reception code because headers are dropped). Of course
> > this works only if the packet in error was not too truncated.
> > (PS: if headers are replaced by hard state this is still possible
> > but can become a bit hairy).
> 
> If so you need to have the ICMP handling code in IP always find the final
> destination. I hope only Solaris has the bug I mentioned above.

Seems like a general RH/ICMP/IP interaction problem to me, which is
not specific to Mobile IPv6 since others can use RHs, like traceroute.

> Was there explicit tests where during such a connection a router in the path
> have its MTU lowered?

I haven't seen it done at a test event, but then most of the conformance
testing done is with you and a test generator on a private network, no
routers.

> Finally, how did the implementors figure this out and share the need for it
> amongst themselves given that the specification has zero mention of it?

I noticed it in hiccups with high bandwidth streams going from a CN to a MN.
I don't see this as being any different than spending many days/months/years
fine-tuning an IP stack to get that last bit of performance out of it.

P.S.  Sometimes sharing provides competitors inside information, I'd like
	to stay a step ahead of Solaris if I can...