Source address in response always the same as target address inrequest? - NTP

This is a discussion on Source address in response always the same as target address inrequest? - NTP ; David L. Mills wrote: > Brian, > > You say "until recently"; NTP has been intimate with Unix since the > early 1980s. Is this recent? > What I am saying here is that the ability to easily accomplish the ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 35 of 35

Thread: Source address in response always the same as target address inrequest?

  1. Re: Source address in response always the same as target addressin request?

    David L. Mills wrote:
    > Brian,
    >
    > You say "until recently"; NTP has been intimate with Unix since the
    > early 1980s. Is this recent?
    >


    What I am saying here is that the ability to easily accomplish
    the necessary address bindings have been added on some operating
    systems to the sockets protocol, not that NTP was recently added.


    > Second and more importantly, if the address is not used to bind a
    > request to a reply, what else can replace it?


    Port number and transaction id's for example. That's what are used
    in the current RPC protocol, for instance. Not IP address.

    >
    > Why do you have 300 sockets bound to an interface with a stateless
    > protocol? This appears to be a fundamental violation of the stateless
    > paradigm.


    Not sure what you mean here. The 300 sockets are bound to 300
    different UDP ports by some large number of different processes.
    All of them bound to the wildcard address except NTP.

    Brian Utterback

  2. Re: Source address in response always the same as target addressin request?

    David L. Mills wrote:
    > Brian,
    >
    > I recall the SHOULD was inserted to support the anycast model where any
    > of a number of servers could respond to a specific request. NTP along
    > with many others in the late 1970s did not anticipate such a model and,
    > even if they did, as later in NTP manycast, the addresses are still
    > necessary for operation sugbsequent to discovery.
    >
    > Dave
    >


    Perhaps. You were there, I was not involved at the time. However, my
    understanding is that not all systems at the time could be made to
    meet the requirement and thus the SHOULD was necessary. But even so,
    my point is that although ther SHOULD is there, most UDP applications
    on most operating systems do not actually follow the SHOULD at all.

    Brian Utterback.

  3. Re: Source address in response always the same as target addressin request?

    David L. Mills wrote:
    > Brian,
    >
    > Are we having a disconnect here or are we talking right past each other?


    Probably both. 8-)

    > NTP has evolved from very many protocols of the late 1970s and early
    > 1980s, including ICMP, GGP, EGP, UDP/TIME, UTP/DAYTIME, UDP/QOD, SNMP
    > and countless others. These protocols multiplex among possibly many
    > servers and clients using the IP addresses and ports (UDP). A client
    > sending a request to a server must know the source address of the reply
    > in ordet to match the request to the reply data structures.


    Well, ICMP packets rarely have a source address that matches the
    original packets destination address. Many UDP protocols that deal with
    routing and network management need to have knowledge the interface
    used, so they do indeed follow the same model of binding all the
    interfaces; I certainly do not claim that NTP is alone in that regard.

    >
    > This was the intent of the original design and as evolved in the Gateway
    > Architecture and Data Structures (GADS) task force and its successor the
    > Internet Architecture (INARC) task force, both of which I happened to
    > chair.
    >
    > This engineering design might today be considered archaic and maybe even
    > a collossal mistakce. However, you need to make the case. Furthermore,
    > this has absolutely nothing to do with sockets or Unix programming
    > style. I made this abundantly clear to Mike Karels of UCB at the time in
    > a meeting with DARPA principals concerned that UCB was a loose cannon
    > and uncooperative with Internet design principles.


    I do not think that the requirement that the addresses match to be
    mistake in the UDP protocol. I think that it would have been a good
    idea. What I am saying is that the requirement is not in the protocol
    at all, so the need for NTP to have it be so is a NTP decision. The
    fact that it was unnecessary and to have resulted in the bind all
    interfaces ugliness is the reason I think it was ill-advised. If the
    UDP protocol had had this requirement all along, then the sockets API
    would have had a way to do it easily and then I would not object at all.

    >
    > Hyde Park in London on Sunday Morning...


    If you are saying that you are going, then have a good trip.

    Brian Utterback

  4. Re: Source address in response always the same as target address in request?

    >>> In article , "David L. Mills" writes:

    David> Why do you have 300 sockets bound to an interface with a stateless
    David> protocol? This appears to be a fundamental violation of the
    David> stateless paradigm.

    Dave, this tells me that Brian is on a machine that has 300 virtual IPs on
    it.

    This is becoming more and more common - people assign 1 IP per 'service' so
    the service can be easily put on an arbitrary machine, or they use several
    IPs for the service on different subnets/vlans for network architecture and
    security reasons.

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  5. Re: Dimensioning NTP Server

    Aggarwal Vivek-Q4997C wrote:
    > Hi
    > Iam planning to have NTP Server for something around 50,000 Clients in
    > the Network
    >
    > Can Anyone guide me in dimensioning the NTP Server. What are the
    > guidelines that I should take care for dimensioning the NTP Server
    >


    I'd probably set up 3 stratum 1 servers at each site and then use
    multicast to distribute the NTP packets to the clients. The exact
    configuration can depend a great deal on what the clients need in the
    way of accuracy and how the network is laid out. While in general
    network topology is not important to NTP you can reduce the error budget
    by keeping the network stable.

    > Also can I two NTP Servers running in active-stand by or in Load
    > balancing scenario in the same network


    load-balancing has no meaning to NTP. You send a NTP packet and the
    server sends a response. You don't need anything in standby, just
    include all of the relevant servers in the DNS and NTP will do the rest.
    With the new pool conf option you can have it use all of the addresses
    listed in the DNS.

    This is not different from DNS which has no use for a load balancer or
    standby either.

    Danny

    > Regards
    > Vivek Aggarwal


  6. Re: Source address in response always the same astarget address in request?

    Brian Utterback wrote:
    > David L. Mills wrote:
    >> Brian,
    >>
    >> You say "until recently"; NTP has been intimate with Unix since the
    >> early 1980s. Is this recent?
    >>

    >
    > What I am saying here is that the ability to easily accomplish
    > the necessary address bindings have been added on some operating
    > systems to the sockets protocol, not that NTP was recently added.
    >
    >
    >> Second and more importantly, if the address is not used to bind a
    >> request to a reply, what else can replace it?

    >
    > Port number and transaction id's for example. That's what are used
    > in the current RPC protocol, for instance. Not IP address.
    >
    >> Why do you have 300 sockets bound to an interface with a stateless
    >> protocol? This appears to be a fundamental violation of the stateless
    >> paradigm.

    >
    > Not sure what you mean here. The 300 sockets are bound to 300
    > different UDP ports by some large number of different processes.
    > All of them bound to the wildcard address except NTP.
    >


    How many of them use UDP?

    Danny

  7. Re: Source address in response always the same astarget address in request?

    Harlan Stenn wrote:
    >>>> In article , "David L. Mills" writes:

    >
    > David> Why do you have 300 sockets bound to an interface with a stateless
    > David> protocol? This appears to be a fundamental violation of the
    > David> stateless paradigm.
    >
    > Dave, this tells me that Brian is on a machine that has 300 virtual IPs on
    > it.
    >
    > This is becoming more and more common - people assign 1 IP per 'service' so
    > the service can be easily put on an arbitrary machine, or they use several
    > IPs for the service on different subnets/vlans for network architecture and
    > security reasons.


    This sounds like laziness. Instead of updating the DNS to change the IP
    address of a name, they add move the IP address to a different machine.
    It doesn't make much sense to me.

    Danny

  8. Re: Source address in response always the same astarget address in request?


    >>> Why do you have 300 sockets bound to an interface with a stateless
    >>> protocol? This appears to be a fundamental violation of the stateless
    >>> paradigm.

    >> Not sure what you mean here. The 300 sockets are bound to 300
    >> different UDP ports by some large number of different processes.
    >> All of them bound to the wildcard address except NTP.
    >>

    >
    > How many of them use UDP?
    >


    I said that "300 sockets are bound to 300 different UDP ports".


    To be clear; This is a Sun Ray server with many different users. At
    this point in time, there are some large number of applications in
    use which are using UDP, all bound to the wildcard interface, none of
    them bound explicitly to any particular local IP address.

    My point is that NTP is, while not unique, one of a small number of
    applications that feels the need to bind all the local IP addresses.

    --
    blu

    "Mr. Jefferson, build up that wall!"
    ----------------------------------------------------------------------
    Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
    Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

  9. Re: Source address in response always the same as target addressin request?

    Danny Mayer wrote:
    > Harlan Stenn wrote:
    >> This is becoming more and more common - people assign 1 IP per 'service' so
    >> the service can be easily put on an arbitrary machine, or they use several
    >> IPs for the service on different subnets/vlans for network architecture and
    >> security reasons.

    >
    > This sounds like laziness. Instead of updating the DNS to change the IP
    > address of a name, they add move the IP address to a different machine.
    > It doesn't make much sense to me.
    >


    Really? Consider:

    The service is administered locally to a system and although the
    IP address may be administered by someone else, it will usually
    be fairly close (i.e. the local sub-net) and doesn't require any
    further administration once assigned. The DNS may be administered
    non-locally or even globally, with potentially two separate
    organizations required to change it (one for forward lookups and
    one for reverse lookups). Once the DNS is changed, it takes some
    time to propagate the change due to caching, and already running
    applications may never see the change unless they re-resolve.
    Having one service per IP address also makes the job of
    load-balancing software much simpler.

    Brian Utterback

  10. Re: Source address in response always the same as target addressin request?

    Brian Utterback wrote:
    > Danny Mayer wrote:
    >
    >> Harlan Stenn wrote:
    >>
    >>> This is becoming more and more common - people assign 1 IP per
    >>> 'service' so
    >>> the service can be easily put on an arbitrary machine, or they use
    >>> several
    >>> IPs for the service on different subnets/vlans for network
    >>> architecture and
    >>> security reasons.

    >>
    >>
    >> This sounds like laziness. Instead of updating the DNS to change the IP
    >> address of a name, they add move the IP address to a different machine.
    >> It doesn't make much sense to me.
    >>

    >
    > Really? Consider:
    >
    > The service is administered locally to a system and although the
    > IP address may be administered by someone else, it will usually
    > be fairly close (i.e. the local sub-net) and doesn't require any
    > further administration once assigned. The DNS may be administered
    > non-locally or even globally, with potentially two separate
    > organizations required to change it (one for forward lookups and
    > one for reverse lookups). Once the DNS is changed, it takes some
    > time to propagate the change due to caching, and already running
    > applications may never see the change unless they re-resolve.
    > Having one service per IP address also makes the job of
    > load-balancing software much simpler.
    >
    > Brian Utterback


    I believe that there is a solution to the DNS caching problem. Each DNS
    record can be given a "Time To Live" or TTL. If you are planning to
    change the record, set the TTL to seven days, then six, five, four,
    three, two, one. . . . All of those cached records should expire at
    more or less the same time. It's not perfect but it works. If you time
    it just right, you can minimize the amount of disruption.


  11. Re: Source address in response always the same as target addressin request?

    Richard B. Gilbert wrote:
    > I believe that there is a solution to the DNS caching problem. Each DNS
    > record can be given a "Time To Live" or TTL. If you are planning to
    > change the record, set the TTL to seven days, then six, five, four,
    > three, two, one. . . . All of those cached records should expire at
    > more or less the same time. It's not perfect but it works. If you time
    > it just right, you can minimize the amount of disruption.


    Still requires the clients to re-resolve the server address (something
    ntpd famously does not do currently; desparate attempt at getting back
    on-topic ;-)

  12. Re: Source address in response always the same as target addressin request?

    Jan Ceuleers wrote:
    > Richard B. Gilbert wrote:
    >
    >> I believe that there is a solution to the DNS caching problem. Each
    >> DNS record can be given a "Time To Live" or TTL. If you are planning
    >> to change the record, set the TTL to seven days, then six, five, four,
    >> three, two, one. . . . All of those cached records should expire at
    >> more or less the same time. It's not perfect but it works. If you
    >> time it just right, you can minimize the amount of disruption.

    >
    >
    > Still requires the clients to re-resolve the server address (something
    > ntpd famously does not do currently; desparate attempt at getting back
    > on-topic ;-)


    Well, how often does a typical NTP server change it's address? Any
    server with a dynamic address is going to create problems. AFAIK it's
    not a common situation.

    ISTR that you can use ntpdc or ntpq (I'm too lazy to look up which one)
    to drop or add servers without needing to restart ntpd.


  13. Re: Dimensioning NTP Server


    "Aggarwal Vivek-Q4997C" escribió en el mensaje news:750BBC72E178114F9DC4872EBFF29A5B05217A23@ZMY1 6EXM66.ds.mot.com...
    > Hi
    > Iam planning to have NTP Server for something around 50,000 Clients in
    > the Network


    If you are being to deploy NTP to 50,000 clients, perhaps you'd better to put your routers (sure you don't have only one) or your DHCP servers to proxy NTP for them. You don't have to use just one NTP server, you can get several in synch so time is distributed with not so much network load.

    In doing so you'll get several advantages:

    * You'll get less network load, as NTP traffic don't pass over the local net. NTP is very sensible to network load. Time offsets get greater in loaded network. NTP proxies can use their clocks to stabilize time offsets due to network load.

    * You'll get less synch delay. People tends to think that using only one server will get all clients synched with it, but you'll get a couple of 50,000 pcs with different times, because of network load at time servers. NTP gets better results in a low loaded net. Time exactitude depends on two factors: network load introduces noise in time measurements, leading to greater time offsets from the source of time. Network NTP hops introduces a constant (or nearly constant) latency from the source of time, but this latencies are taken into account when synchronizing and you'll have better results using more levels of deploying time than making everything point to a master server.

    * You'll get more exact times if you balance the levels of stratumness with the number of clients that will ask a single server. I think a good starting balance is making all routers take time from your master server (better two or three servers for all the routers to get fault tolerance) and then the final clients to ask the routers for time. If you are considering to join 50,000 network nodes in a network, you'll be able to select routers capable of acting as timeservers for the localnet.

    >
    > Can Anyone guide me in dimensioning the NTP Server. What are the
    > guidelines that I should take care for dimensioning the NTP Server
    >
    > Also can I two NTP Servers running in active-stand by or in Load
    > balancing scenario in the same network


    You can use better several NTP servers, and point routers to them all. NTP is designed with fault tolerance in mind, even to get better clock timeline.

    >
    > Regards
    > Vivek Aggarwal


  14. Re: Source address in response always the same astarget address in request?

    Richard B. Gilbert wrote:
    > I believe that there is a solution to the DNS caching problem. Each DNS
    > record can be given a "Time To Live" or TTL. If you are planning to
    > change the record, set the TTL to seven days, then six, five, four,
    > three, two, one. . . . All of those cached records should expire at
    > more or less the same time. It's not perfect but it works. If you time
    > it just right, you can minimize the amount of disruption.
    >


    This is exactly how we tell people who are changing IP addresses of the
    DNS servers for a zone to migrate. We also tell them to keep the old
    server running for a short while after the changeover but handing out
    the new NS records of the new server(s). After requests stop coming in
    to the old server then it can be shutdown permanently.

    Danny

  15. Re: Source address in response always the same astarget address in request?

    Jan Ceuleers wrote:
    > Richard B. Gilbert wrote:
    >> I believe that there is a solution to the DNS caching problem. Each DNS
    >> record can be given a "Time To Live" or TTL. If you are planning to
    >> change the record, set the TTL to seven days, then six, five, four,
    >> three, two, one. . . . All of those cached records should expire at
    >> more or less the same time. It's not perfect but it works. If you time
    >> it just right, you can minimize the amount of disruption.

    >
    > Still requires the clients to re-resolve the server address (something
    > ntpd famously does not do currently; desparate attempt at getting back
    > on-topic ;-)


    I'm working on it.

    Danny

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2