Subject: [Lwip] LWIG tentative minutes

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 30 Jul 2011 02:19:01 +0900

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.