Re: UDP dont fragment bit

From: Sten Daniel Sørsdal (lists_at_wm-access.no)
Date: 09/22/05

  • Next message: Sten Daniel Sørsdal: "Re: tap devices and DHCP." 
    Date: Thu, 22 Sep 2005 13:34:10 +0200
To: Jeremie Le Hen <jeremie@le-hen.org>

    Jeremie Le Hen wrote:
    > Hi,
    >
    >
    >>Often there already is need for a tcp connection for authentication,
    >>negotiation and so forth.
    >>
    >>RTT could, among other things, make a discovery process choose how fine
    >>the increments/descrements should be.
    >>
    >>Estimated bandwidth could also help the actual data transport start out
    >>with a more situation correct value.
    >>
    >>However with the abundance of routers modifying TCP MSS correctly
    >>incorrectly and the odd chance that the data path of UDP packets is
    >>different than TCP packets it wouldnt really give anything necessarily
    >>reliable discovery process. And taking advantage of such values could
    >>make the process more complex or less reliable.
    >
    >
    > This is a rather specific case IMHO. BSD community didn't use to take
    > care of such non standard behaviours, AFAIK. What you describe here
    > is not really what's currently stated in RFCs.

    That it is not stated in an RFC is true. Please explain why it would
    have to be?

    > I would not be in favor of adding such an option in the FreeBSD kernel
    > because, as Robert stated, this doesn't bring anything if not coupled
    > with a non-trivial mechanim that could provide the user with ICMP MTU
    > events. If one adds this option to the manual page, this will lead
    > for sure to have mails emitted on this even list asking for how to
    > retrieve those informations. Furthermore, I ought to add that the
    > algorithm you described in pseudo-code lacks of robustness because
    > of possible network congestion, which means this isn't something one
    > would really see in wide use.

    You assume such an application would need ICMP.
    Again, let me state that such an application would not need ICMP's and
    it would work despite fragmentation issues.

    Retrieve what information?

    And an application based solely on my pseudo-code lacks robustness to
    network congestion is correct. So what?

    > In other words, I think the feature you're calling for is really
    > specific to your problem, regarding your current network environnement.
    > The misbehaviour of some particular network-fascist ISP should not
    > reach the FreeBSD source tree.

    You are mistaken in assuming my isp would block icmps or fragments.
    And you are mistaken that this was meant to solve a problem specific to
    one network. It is about giving unprivileged applications the
    opportunity to find the optimal packet size without relying on network
    policies or flaws. 

    -- 
Sten Daniel Sørsdal
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Sten Daniel Sørsdal: "Re: tap devices and DHCP."

    Relevant Pages

    • Re: Socket send blocking problem
      ... The network becomes congested, ... sending thus slows down dramatically and *thus* the buffer fills. ... TCP will packetise the data in buffer as suits the ... You have no direct control over what packets TCP will send ...
      (microsoft.public.win32.programmer.networks)
    • Re: UDP vs TCP
      ... TCP for instance will break up a large packet into smaller ... into the packets and then the receiving app would have to read ... Network Layer -> ethernet ... DOMAIN over port 53 ...
      (microsoft.public.vb.enterprise)
    • RE: ICMP type 12 packets
      ... I am seeing ICMP type 12 packets being returned to my network from ... They are destined for 386 unique IPs in our network, ...
      (Incidents)
    • RE: What could this icmp mean?
      ... Your devices on the 10.30.1.x network have 10.30.1.254 as their ... default gateway, but traffic to 10.30.0.x needs to go by 10.30.1.1 ... ICMP packets carry, as payload, a portion of the packet that triggered ...
      (Security-Basics)
    • ICMP type 12 packets
      ... ICMP Type 12 is a parameter problem. ... We have logged about 1400+ packets since May, ... They are destined for 386 unique IPs in our network, ...
      (Incidents)