[net2-wg] Notes from the Dec 15 meeting.

[Gilman Tolle]

-------------- next part --------------
December 15th, 2005
-------------------

   Phil: Let's talk about group membership. What approach will the
	 group take for admitting new members?
    Gil: Is the group going to be long-lived?
   Phil: I hope we will consider broader networking architecture, so yes.
  Henri: Let's set the membership bar low, because the community is small.
   Phil: One person said "let's do HTTP". I said it was outside the
         scope. A few people didn't meet the requirement of having
         written a publicly-available networking protocol. Is that bar
         too high?
  Henri: Sounds reasonable to me.
Rodrigo: Should we set a requirement on writing code?
   Phil: What do you think?
Rodrigo: We seem weak on application experience, describing
         constraints from above.
   Kyle: Are we looking for members or setting rules?
   Phil: We need to do the latter, so we can be prepared for the former.
   Kyle: We could set the bar high and look for people who will make a
         good contribution.
  Henri: That could be percieved as only bringing in the people we like.
    Gil: I think we should focus on using the members we have.
   Phil: How should we decide to admit a new member? Email the list
         and consensus? More formal? Voting? Keep off the list because the
	 list is public?
Rodrigo: Agreed. (others agreed too)
Rodrigo: How many applied?
   Phil: 15. I denied about half. The group has 9 people now.
   Phil: In TOS2, we usually have about half the group.
   Kyle: Application experience is important. We should look for it.
   Phil: Sounds like we don't want a formal joining protocol.
Rodrigo: Agreed. 
  Group: Agreed.
   Phil: Anybody want to lead the discussion on collection?

Rodrigo: Many different protocols do similar things when forwarding
	 messages. Scheduling initiation vs. forwarding. Deciding
	 where to send the messages. From a high level, I have a
	 message and need to know how to get it there. If you have a
	 forwarding discipline you like, why can't you use it with a
	 MintRoute tree or an AODV route? We're looking for the
	 minimal interface between a Forwarding engine and a Routing
	 engine. In the internet, we have a control plane and a data
	 plane, which interact through a table. In sensor networks,
	 our protocols are more different. For example, opportunistic
	 forwarding, like MIT's XP or Rob Poor's gradient routing.

Rodrigo: In what I sent out, the forwarding engine sends a
	 getNextHop() request to the forwarding engine. Addresses are
	 opaque to the forwarding engine. In trivial collection, with
	 a gradient, the address is implicit.

Rodrigo: Om asked whether the interface is too narrow for richer
	 protocols. One way around this is for the routing engine to
	 keep a state machine and produce part of the network-layer
	 header, for itself.

Rodrigo: Henri asked whether the app really needs to know the exact
	 addressing format used by the underlying collection. Not
	 really. You can easily put a component above the
	 forwarding-routing combination that abstracts the exact
	 address, that provides Collection.send() and knows how to get
	 the address.

Rodrigo: It's a great opportunity to stop implementing monolithic
	 protocols, and find what's in common.

    Jon: As Om said, there might be greater interaction between the
         router and the forwarder. What if the forwarder wants to tell
         the router about queue length or congestion? What if it wants
         to provide feedback to children of the routing engine to
         encourage fairness? The router might want to get info from
         the forwarder, but it doesn't seem to work with only an
         additional header.

Rodrigo: If the queue is too full, the router should return a
	 different address?

    Jon: Or, the forwarder could tell the router to send different
	 beacons indicating queue depth.
    
Rodrigo: Only way to be sure is to implement a bunch of protocols. 

Rodrigo: Next hops is plural, which allows for alternative hops. But,
	 I can see that the forwarder might want to know about
	 children.

    Jon: What if a network protocol wanted to piggyback some routing
        info in the packet?
 
Rodrigo: That's what the routing header does.

   Phil: Want to get back to Jon's question of additional
         information. The trick there is the coupling between
         components. There's a component above the network layer that
         translates an address into a void*. So, there's coupling
         between the routing protocol and the routing engine. But, the
         trick is dealing with multiple forwarding engines. It's hard
         to share info with the forwarding engine because it makes a
         claim about what it can do.

    Jon: I like the decomposition, but am not sure if the narrow
         interface is enough.

Rodrigo: There's a balance between expressiveness and
	 plug-and-play. Someone might write a routing engine to work
	 with one forwarding engine. For example, not all routing
	 engines can produce a cost. This can be detected at compile
	 time.

    Jon: I'm just trying to get at, for example, how someone would do
         congestion feedback like ECN? Can we walk through the example?

Rodrigo: This example is a transport one. 

   Kyle: Hmm. Our experience is this: if you're not in a many-to-one
         topology, congestion control is hard to implement and is
         still an open question that we should put off.

   Phil: If one were to try this, where would one put it? If the
         forwarding engine noticed congestion, how would it propagate
         that information?

   Kyle: Hmm. 

Rodrigo: The forwarding engine could ask for a new route because this
	 one is congested. Initially, a lot of the functionality would
	 be in the forwarding engine itself.

   Phil: Easier to add new info than remove it. Maybe we should just
         try it, and see where the rough edges are.

   Phil: SnaSend...provided by the forwarding engine to
         application. void* becomes an untypecheckable blob. There
         should be a protocol with a concrete type that translates to
         a void*. There's no length argument, for example. How do apps
         pass this around?

Rodrigo: This interface is fragile. If a protocol is a combo of a
	 specific routing and forwarding engine, the protocol
	 configuration could provide a typed address field. But, the
	 forwarding engine has to treat this as a blob.
   
   Phil: You say a protocol is a combination of a routing engine and a
         forwarding engine. But, there's also the state machine. There
         are 2 state machines, perhaps retransmissions in the
         forwarding engine and link selection in the routing engine.

Rodrigo: These are orthogonal. But, there is a state machine. Can the
	 state be embedded in the header? Is it per-packet? Largely,
	 yes.

   Phil: An example. I'm asked to send a packet to a set of GEM
	 coordinates. For some reason, the routing engine doesn't know
	 how to route to these coordinates. It wants to initiate route
	 discovery. Now we have separate route discovery and
	 forwarding state machines. But, they interact.

    Gil: Do multiple routing protocols use the forwarding engine at
         the same time? That's even more complex.

Rodrigo: Sharing could happen, but could get complicated.

   Phil: Let's take synopsis diffusion. You can do it up a tree or
         across a gradient.

Rodrigo: For example, you might have one slow reliable forwarding
	 engine and one fast forwarding engine that share the same
	 routing tree. Or, the reliable forwarding engine might want
	 to use a tree sometimes or AODV other times.

    Gil: Internal decomposition is interesting, but we need to focus
         on the interface above.

  Henri: We need to include an intercept interface for in-network
         processing. And, given how little in-network processing
         occured in TinyOS 1.x, a new interface might help.

   Phil: At the datalink layer, the packet abstraction provides a
         separate Snoop interface. There's nothing quite like it in
         the network layer.

   Kyle: If we have Snoop at the link layer, why would we need
         Intercept at the network layer?

   Phil: I shouldn't have to parse the network fields again, which
         using Snoop would seem to require.

   Kyle: It's about making applications' lives easier.

Rodrigo: I could see the forwarding engine providing Snoop and
         Intercept.

   Phil: Let's say I have a single AM type, and my network has bits
         for different kinds of packets. The app might not want to
         snoop control packets, but does want to snoop data packets.

   Kyle: Letting the network layer keep the two separate makes
         applications' lives easier. I see the point.

    Gil: Maybe we could try to abstract from existing examples.

Rodrigo: Let's work on how the interfaces appear from above.

         Meeting next week? Yeses, noes, and not sures.
 
   Phil: Conference next week? Let's have one. We'll talk about
         dissemination, and set a deadline of next week for the
         top-level interfaces to collection. Sound good?

  Henri: Target date for implementation? 
 
   Phil: Mid-Jan. But, there's a lot of code that should come together
         quickly once we get the interfaces right.