34 Matching Annotations
  1. Dec 2022
    1. This goal caused TCP and IP, which originally had beena single protocol in the architecture, to be separated intotwo layers. TCP provided one particular type of service,the reliable sequenceddata stream, while IP attempted toprovide a basic building block out of which a variety oftypes of service could be built. This building block wasthe datagram, which had also been adopted to supportsurvivability. Since the reliability associated with thedelivery of a datagram was not guaranteed, but “besteffort,” it was possible to build out of the datagram aservice that was reliable (by acknowledging andretransmitting at a higher level), or a service which tradedreliability for the primitive delay characteristics of theunderlying network substrate. The User DatagramProtocol (UDP)13 was created to provide a application-level interface to the basic datagram service of Internet.

      Origin of UDP as the split of TCP and IP

      This is the center of the hourglass protocol stack shape.

    2. D. Clark. 1988. The design philosophy of the DARPA internet protocols. In Symposium proceedings on Communications architectures and protocols (SIGCOMM '88). Association for Computing Machinery, New York, NY, USA, 106–114. https://doi.org/10.1145/52324.52336

      The Internet protocol suite, TCP/IP, was first proposed fifteen years ago. It was developed by the Defense Advanced Research Projects Agency (DARPA), and has been used widely in military and commercial systems. While there have been papers and specifications that describe how the protocols work, it is sometimes difficult to deduce from these why the protocol is as it is. For example, the Internet protocol is based on a connectionless or datagram mode of service. The motivation for this has been greatly misunderstood. This paper attempts to capture some of the early reasoning which shaped the Internet protocols.

  2. Jun 2022
    1. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

      Gall's Law

      Gall's Law is a rule of thumb for systems design from Gall's book Systemantics: How Systems Really Work and How They Fail.

      It reminds me of the TCP/IP versus OSI network stack wars.

  3. May 2022
    1. Shaping has four main steps that we will cover in the next four chapters.

      1. Set boudaries. First we figure out how much time the raw idea is worth and how to define the problem.

      2. Rough out the elements. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem with the appetite but without all the fine details worked out.

      3. Address risks and rabbit holes. Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.

      4. Write the pitch. Once we think we've shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be reused at kick off to explain the project to the team.

    2. Two tracks

      You can't really schedule shaping work because, by it's very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that's been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment has been made to bet on it.

      That gives the shapers the option to put work in progress on the shelf or drop it when it's not working out.

    3. Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There'll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It's that kind of private, rough, early work.

    4. It's also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem.

      • What are we trying to solve?
      • Why does it matter?
      • What counts as success?
      • Which customers are affected?
      • What is the cost of doing this instead of something else?
    5. Knowledge about how the system works will help you see opportunities or obstacles fro implementing your idea.

    6. Shaping is primarily design work. The shaped concept is an interaction design viewed from the user's perspective. It defines what the feature does, how it works, and where it fits into existing flows.

      • what the feature does
      • how it works
      • where it fits into existing flows
    7. When a project is defined in a few words, nobody knows what it means. "Build a calendar view" or "add group notifications" sound sensible, but what exactly do they entail?

      Team membres don't have enough information to make trade-offs.

    8. Principles of Shaping

      When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.

    9. Second, we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.

    10. To manage this new capacity, we switched from ad-hoc project lengths to repeating cycles. (It took some experimentation to find the right cycle length: six weeks. More on that later.)

      We formalized our pitching and betting processes.

      My role shifted again, from design and product management to product strategy.

      I needed new language, like the word "shaping", to describe the up-front design work we did to set boudaries and reduce risks on projects before we committed them to teams.

    11. Don't think of this asa a book. Think of it as a flashlight. You and your team have fumbled in the dark long enough. Now you've got something bright and powerful to help you find a new way.

    12. Founders ask themselves: "why can't we get features out the door like we used to in the early days?" 创始人问自己“为什么我们不能像早期那样把功能推出去?”

    13. At the time I wasa a web designer with a focus on usability and user interfaces. I executed Json's design direction for key features of the app and collaborated with him to fill in details of the concept.

    14. We knew we wouldn't get anywhere with those ten hours of programming unless we used them very deliberately. Our intense focus on "hammering" the scope to fit within a given time budget was born under these constraints.

    15. I learned the techniques programmers use to tame complexity: things like factoring, levels of abstraction, and separation of concerns.

      with one foot in the design world and one foot in the programming world, I wondered if we could apply these software development principles to the way we designed and managed the product.

    16. I wore the designer and product manager hats on the project and prototyped the breadboarding and scope mapping techniques described in this book to manage the complexity.

    17. ...we redesigned Basecamp from scratch for version 2.0.

    18. We needed language to describe what we were doing and more structure to keep doing it at our new scale.

  4. Apr 2022
    1. EvoArch suggests an additional reason that IPv4 has been so sta-ble over the last three decades. Recall that a large birth rate atthe layer above the waist can cause a lethal drop in the normalizedvalue of the kernel, if the latter is not chosen as substrate by thenew nodes. In the current Internet architecture, the waist is the net-work layer but the next higher layer (transport) is also very narrowand stable. So, the transport layer acts as an evolutionary shield forIPv4 because any new protocols at the transport layer are unlikelyto survive the competition with TCP and UDP. On the other hand,a large number of births at the layer above TCP or UDP (applica-tion protocols or specific applications) is unlikely to significantlyaffect the value of those two transport protocols because they al-ready have many products. In summary, the stability of the twotransport protocols adds to the stability of IPv4, by eliminating anypotential new transport protocols that could select a new networklayer protocol instead of IPv4.

      Network Layer protected by Transport Layer

      In the case of IPv4 at the network layer, it is protected by the small number of protocols at the Transport Layer. Even the cannibalization of TCP by QUIC, that is still happening at the Transport layer: [QUIC] does this by establishing a number of multiplexed connections between two endpoints using User Datagram Protocol (UDP), and is designed to obsolete TCP at the transport layer for many applications, thus earning the protocol the occasional nickname "TCP/2"..

    1. The EvoArch model predicts the emergence of few powerful and old protocols in the middle layers, referred to as evolutionary kernels. The evolutionary kernels of the Internet architecture include IPv4 in the network layer, and TCP and the User Datagram Protocol (UDP) in the transport layer. These protocols provide a stable framework through which an always-expanding set of physical and data-link layer protocols, as well as new applications and services at the higher layers, can interoperate and grow. At the same time, however, those three kernel protocols have been difficult to replace, or even modify significantly.

      Defining the "EvoArch" (Evolutionary Architecture) hour-glass model

      The hour-glass model is the way it is because these middle core protocols profile a stable foundation experimentation and advancement in upper and lower level protocols. That also makes these middle protocols harder to change, as we have seen with the slow adoption of IPv6.

  5. Mar 2022
  6. Feb 2022
  7. blogs.baruch.cuny.edu blogs.baruch.cuny.edu
    1. nd wat

      "clay" elicits ideas of rebirth and reformation; a new shape, a new you.

      "wattle" as well--is symbolically laden with anatomy connotations, but also can be reference to twings, and other images of nature.

  8. Apr 2021
    1. This way the text will wrap above the shape even though the div extends to the top.
    2. shape-outside: inset(100px 100px 100px 100px 10px);
    3. It might be better to think of it this way: with the shape-outside property we’re changing the relationship of other elements around an element, not the geometry of the element itself.
  9. Feb 2019
  10. Jan 2019
  11. Sep 2013
    1. It may be said that every individual man and all men in common aim at a certain end which determines what they choose and what they avoid.

      What is left out is as important to shaping the argument and what is chosen.