Re: [pilc] RE: AD request / L2 Triggers Chapter Statement

From: Vernon Schryver (vjs@calcite.rhyolite.com)
Date: Tue Jul 09 2002 - 19:46:36 EDT

  • Next message: Lloyd Wood: "Re: [pilc] RE: AD request / L2 Triggers Chapter Statement"

    > From: Lloyd Wood <l.wood@eim.surrey.ac.uk>

    > > Again, why can't the host's applications that care open a routing
    > > socket and to hear all about interfaces coming and going?
    > >
    > > Or is all the world a Solaris box?
    >
    > interfaces going up/down is not the same as interfaces coming or
    > going.

    What's the substantive difference?
    Shouldn't a good L2 driver twiddle an IFF_ON or IFF_RUNNING bit when
    bad things happen, and so signal routing socket listeners?
    I think reasonable `routed` implementations notice when an Ethernet
    cable is disconnencted. What's the difference between that case
    and a datagram application on a mobile phone suffering some sort of
    fading or dropped handoff?

    Granted, I'm playing a little loose with the details. In the common
    BSD `routed` code, the daemon notices the error counts that result
    from a disconnected Ethernet cable or a kaput FDDI ring and marks the
    interface down. UDP applications then start getting errnos equivalent
    to ICMP Unreachables. TCP applications start their normal 90 to 300
    second timeouts, if they send any traffic. I don't know about telephony
    appliations, but UDP conferencing applications tend to have enough
    regular traffic to notice a dead link. However, from what I've seen,
    they tend follow the primary rule of programming and ignore errors
    they can't handle.

    > > > ...
    > > > A simple function call to find out would suffice. No MIB. Minimal
    > > > running code. But routers are integrated beasts, while typical
    > > > endhosts aren't.
    > >
    > > What are the decades old getifaddrs() and the merely decade old
    > > routing sockets, chopped liver?
    >
    > And what gets to mark the interface as up or down?

    Why not the L2 driver?

    I've forgotten more than just the details, but I think I remember
    writing BSD-style FDDI drivers that downed the interface on bad
    situations such as stuck-BEACONing.

    I fear this discussion has again wandered into the weeds of hypothenticals
    far from practice. The separateness of IP from L2 is more evident in
    cloud diagrams than in code. For that matter, the distance between
    TCP and L2 is larger in theory than in practice, at least if you've
    ever made a system page flip or use hardare for the TCP and UDP
    checksums. For example how does TCP know whether compute checksums
    when some of the L2 interfaces on a system has checksum hardware and
    some doesn't? Teaching a system to page flip tends to make the L2 driver
    want to know about stuff in the application stratosphere above TCP or UDP.

    Vernon Schryver vjs@rhyolite.com

    _______________________________________________
    pilc mailing list
    pilc@ietf.org
    https://www1.ietf.org/mailman/listinfo/pilc
    http://www.ietf.org/html.charters/pilc-charter.html
    http://pilc.grc.nasa.gov/



    This archive was generated by hypermail 2b29 : Tue Jul 09 2002 - 19:37:15 EDT