Subject: Re: [Lwip] LWIG tentative minutes

From: Zhen Cao <[email-masked]>
Date: Mon, 1 Aug 2011 09:58:17 -0400

Thanks very much for the minutes, Yoshi.

I listen to audio and add two sentences as below.  If no more problem,
I will post it to the website.

----------------------
Angelo: Static or dynamic allocation of memory?

***Olaf: Currently use dynamic

Cao:  Previous part mentions how to simplify fragmentation. Here you
suggest avoiding fragmentation.  What is the overall guidance?

***Olaf: Anyway applications should be aware of L2 that only supports
very small packets.
------------------------

On Fri, Jul 29, 2011 at 1:19 PM, Yoshihiro Ohba
<[email-masked]> wrote:
> This is the minutes I took today.
>
> Yoshihiro Ohba
>
> ------------------------------------------
> IETF81 LWIG WG meeting minutes (tentative)
>
> (Minutes taken by Yoshihiro Ohba)
>
> 1. Opening
>
> Cao presented goals and milestones.
>
> Cao mentioned lwig-guidance draft is under development and needs more
> input.
>
> 2. Agenda bashing.
>
> Jari: Let the group know that Samita and Eric are working on energy-
> aware ND in 6man WG.
>
> 3. Guidance for Light-Weight Implementations of the Internet Protocol
> Suite (draft-bormann-guidance):
>
> Cao presented route-over fragment forwarding
>
> Angelo: there is a risk of collision in fragmentation.  Two fragmented
> packets may have the same datagram tag.
>
> Cao: I don't think collision happens.
>
> Angelo: we can talk offline.
>
> Olaf presented CoAP guide, including message layer processing
>
> Jari: It may be difference between sending and receiving fragm.  Just
> sending messages, more complex impl. receiving can be a bigger problem.
>
> Michael: IP fragment?
>
> Jari: Yes.
>
> Olaf: Block option avoid fragmentation of IP layer.
>
> Alex: Is CoAP running proxy?
>
> Olaf: Not necessary.
>
> Kerry: Device may not use IP.  KNX and BACnet prevent use of CoAP
> proxies.  Needs to consider very careful.
>
> Jari: Just clarify that CoAP is an IP based protocol.  Deployment may
> use non-IP proxy for non-IP devices.
>
> Angelo: What is generating separate responses?  A server may need to
> keep state of requests.  Maintaining a state may not be a requirement
> for servers.
>
> Olaf: Server will need to keep state.  You need additional memory for
> template of response.
>
> Angelo: Static or dynamic allocation of memory?
>
> Olaf: ...
>
> Cao:  Previous part mentions how to simplify fragmentation. Here you
> suggest avoiding fragmentation.  What is the overall guidance?
>
> Olaf: ...
>
> Kerry: General question.  CoAP uses retry mechanism such that if
> response does not come back client retry.  In your view, it is up to
> server?
>
> Olaf: Server probably needs to keep request state for that purpose.
>
> Kerry: It is a uniform interface for http and coap?
>
> (from jabber): These are solved by message ids.
>
> Jari: Process comment.  If something is wrong with the CoAP protocol,
> it should be solved by CORE WG.
>
> ...: Comment about risk of collisions.  If collisions happens, it can
> consume bandwidth.
>
> -- Token handling
>
> Olaf explained that default vaule 0 is used while not pipelining.
> Need non-0 for multiple outstanding requests.
>
> Angelo: There is a problem with token.  Token will be request/response
> layer.  We are interested in msg layer.
>
> Olaf: I don't separate clearly the two layers.
>
> Angelo: Keep the token in some layer-violating way cause some problem.
>
> 4. Yoshihiro presented PANA on behalf of Mitsu Kanda
>
> 5. Jari Arkko presented Tiny CoAP sensors
> (draft-arkko-core-sleepy-sensors).
>
> Jari: Prototype implementation on ARM-based platform.  Implemented
> protocols: Ethernet, IPv6, UDP, COAP, XML, and appliation, multicast,
> checksums msg and device IDs.  No configuration is needed.
>
> Jari claims that CoAP communication model is wrong.
>
> Angelo: Could consider use of some L2 features of radio to address
> communication issue.
>
> Jari: Cellular does L2 mechanisms for sleepy nodes.  Probably needs
> both L2 and higher layer optimization.
>
> Michael: L2 will try to synchronize with beacons.  Lots of optimized
> way may not be necessary with using L2 features.
>
> Jari: Wired is special.
>
> Alex: There is an RFC giving code of checksum.  Implementors need
> guideline on how to implement checksum.
>
> Michael: Is there a pseudo header?
>
> Jari: Yes.
>
> Michael: If you preserve the RAM, it drains power.
>
> Kerry: What is observe?  Who is observing who?  You are just
> multicasting data.
>
> Jari:  This is a very different way to observe data.
>
> Oscar: What would be the key type message to use template?
>
> Jari:  Such as DHCP response and CoAP observe request.
>
> Michael: dot decimal format should be ok.
>
> Cao:  Any buffer?
>
> Jari: There is one buffer.
>
> Cao:  In 6lowpan, implementation complexity is a lot.
>
> Jari: Communication model is important.
>
> Alex: In your draft communication model is very different from other
> usages.  Is your implementation using network byte order or host byte
> order?
>
> Jari: Depending on CPU, the types of byte orders are the same.
>
> Ralph: You are not changing protocols, but you are very careful what
> part of the protocol needs to be considered.  OTOH, you address a
> single deployment scenario instead of general deployments.
>
> Ralph: Are you really getting IPv6 at this point?
>
> Jari: No need for DHCP (joking).  Protocols give you flexibility to
> choose the right design.
>
> Ralph: What we are getting by having IP on these devices?
>
> Alex: I would say this effort is a future proof.
>
> Jari: Answering to Ralph.  I want to get rid of small Ethernet switch
> with IP stack to connect my tiny devices to IP network.
>
> Michael: Another answer to Ralph.  Example: Temperature sensors.  You
> need specific box to talk to.  Important thing is you plug-in the
> device and you can use IP-based tools to analyze protocols, etc.  You
> need to rely on a particular manufacturer to connect it to the network.
>
> Jari: I would like to have general purpose technologies.
>
> Kerry: If you have IP, you can measure temperature and send it remote.
>
> - HTTP-CoAP (by Angelo)
>
> Angelo claims that http-coap proxy requires cross-protocol URI
> mapping.  Identification of cross-protocol URIs is needed.
>
> Cao: It is stateful, isn't it?
>
> Angelo: Having state can reduce the network load.
>
> Cao: How the proxy determine to do translation or not?
>
> Angelo: It's based on static configuration.  Dynamic configuration can
> be a next step.
>
> Alex: Is this prosy using socket interface or something else?
>
> Angelo: You can use whatever.  My implementation uses squid module
> with sockets.
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

-- 
Best regards,
Zhen