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

Re: ICMP must fragment and IPsec

> From: Matt Crawford <crawdad@FNAL.GOV>
> To: vjs (Vernon Schryver)
> Cc: tcp-impl@cthulhu.engr.sgi.com, ipsec@tis.com

> > >   One way might be to have an ICMP or TCP option that requests the
> > > other end to provide a response, giving the size of the largest
> > > fragment received. This would be enclosed in the SA that the TCP data
> > > is flowing in. This is in some sense a variation of the TCP MSS option.
> > 
> > What is this "other end"?
> > If talking to the other end of a TCP connection were enough, then the
> > MSS negotiation would be enough ...
> 
> No, I think he meant for one end to tell the other what was the size
> of the largest IP packet-or-fragment it has actually received.  It
> can't rightly be a TCP option, because TCP wouldn't know this.  And
> besides, it becomes pretty hairy at any level when you try to find
> out what was the largest packet received "lately."  Ugh.


Yes, I foolishly missed that very interesting idea.

I'm not bothered by the "lately" in "the largest packet received
lately", since you must have timers even to use the DF bit.  The
idea just moves the timers.  Instead, it bothers me that:

  - it requires changes in both hosts.  PMTU discovery is a hack that
    works without any changes in the rest of the net including the
    peer.  Consider how long it has taken for routers to support the
    improved ICMP error message.

  - it also requires protocol changes.  The IETF aint what it used to be.

  - when would you re-probe to discover if the PMTU has increased?
    This is not a showstopper, but doesn't have an obviously neat answer.

  - I think it assumes UDP does not need PMTU discovery.

  - it assumes no intermediate router is doing fragment reassembly
    I don't know of any that do that, but it is a recurring idea
    for good reasons.

  - the largest fragment is as large as PMTU.
    First, since all but the last IP fragment must be a multiple of 8
    bytes, the largest fragment will generally be the largest multiple
    of 8 less or equal to the MTU.  For example, you'll probably guess
    1496 or 1488 instead of 1500 or 1492 for an Ethernet segment.

    Second, instead of the usual algorithm, a router might try to
    fragment into evenly sized pieces.  At the cost of a divide
    instruction (cheap on modern CPU's), that can reduce the total
    fragmentation should the datagram have to be fragmented twice.
    Consider the silly UDP/IP fragment sizes seen often seen from
    NFS servers with FDDI interfaces.


Vernon Schryver,  vjs@sgi.com