Subject: [Lwip] Fwd: New Version Notification for draft-bormann-lwig-guidance-00.txt

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 Jul 2011 22:23:44 +0200

I have submitted draft -00 of what is proposed to become the LWIG Guidance document.

Please enjoy at

	http://tools.ietf.org/html/draft-bormann-lwig-guidance-00

Thanks to the contributors so far.
(But it's not too late: Anything you want to contribute now might go into a -01 before the I-D update deadline next week.)

Gruesse, Carsten

Begin forwarded message:

> From: [email-masked]
> Date: July 4, 2011 22:16:19 +0200
> Subject: New Version Notification for draft-bormann-lwig-guidance-00.txt
> 
> A new version of I-D, draft-bormann-lwig-guidance-00.txt has been successfully submitted by Carsten Bormann and posted to the IETF repository.
> 
> Filename:	 draft-bormann-lwig-guidance
> Revision:	 00
> Title:		 Guidance for Light-Weight Implementations of the Internet Protocol Suite
> Creation date:	 2011-07-04
> WG ID:		 Individual Submission
> Number of pages: 28
> 
> Abstract:
>   Implementation of Internet protocols on small devices benefits from
>   light-weight implementation techniques, which are often not
>   documented in an accessible way.
> 
>   This document provides a first outline of and some initial content
>   for the Light-Weight Implementation Guidance document planned by the
>   IETF working group LWIG.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Qin Wu <[email-masked]>
Date: Wed, 13 Jul 2011 12:03:34 +0800

Hi,
Read the draft , it looks to me it is a interesting topic to discuss how to integrate native IP capability into constrained device.
Some comments as follows:
section 1:
"
   More and more communications technology is being embedded into our
   environment.  Different types of devices in our buildings, vehicles,
   equipment and other objects have a need to communicate.  It is
   expected that most of these devices will employ the Internet Protocol
   suite.  The term "Internet of Things" denotes a trend where a large
   number of devices directly benefit from communication services that
   use Internet protocols. 
"
   
   [Qin]: Is the benefit from communication services is the only reason
   to add native IP capability to constrained device? What about other requirements like
   energy saving.
Section 1.1:
"
   Building a small implementation does not have to be hard.  Many small
   devices use stripped down versions of general purpose operating
   systems and their TCP/IP stacks.  
"

  [Qin]: Since the small devices has limited capability and power, memory, 
  Is theire TCP/IP stacks a complete stack or reduced stack?
  Should small device support all the Internet Protocol suites or only support
  basic protcol suites, e.g., TCP/IP, UDP/IP, ARP, ICMP, TFTP, Telnet, Auto IP, DHCP.
  It looks to me it is not pratical to support all. Since most of constrained device
  is application specific system, only designed for a specific task, therefore I 
  think only a small portion of the whole suite need to be supported.

Section 1.1:
"
The topics for this working group will be chosen from Internet
   protocols that are in wide use today, such as IPv4 and IPv6; UDP and
   TCP; ICMPv4/v6, MLD/IGMP and ND; DNS and DHCPv4/v6; TLS, DTLS and
   IPsec; as well as from the optimized protocols that result from the
   work of the 6LoWPAN, RPL, and CoRE working groups.  
"

   [Qin]: It seems small portion of protcols like 6LowWPAN, CORE are desinged for constrained device, 
   but I am not sure all these Internet protcols are designed for constrained
   device? e.g., MLD/IGMP,IPSec may be too much heavy weight to constrained device. On the other hand,
   how to reduce the weight of the existing Internet protocol to adapte to the constrained device? what kind of
   the requirements this document want to deal with for constrained device are what I am most interested and want
  to know.

Section 2.1:
"
       +---------+-----------------------+-------------------------+
       | Name    | data size (e.g., RAM) | code size (e.g., Flash) |
       +---------+-----------------------+-------------------------+
       | Class 1 | ~ 10 KiB              | ~ 100 KiB               |
       |         |                       |                         |
       | Class 2 | ~ 50 KiB              | ~ 250 KiB               |
       +---------+-----------------------+-------------------------+
"
   [Qin]:Constrained device is characterized by limited processing, memory
   and energy resource. I am not sure you should  catogerize different 
   constrained device only based on various memoery.

Section 2.2:
   [Qin]: Is there any overlapping between design objection in section 2.2
   and objective in the section 1.1?

Section 6 and 7:
[Qin] Look at the section 6 and section 7, it is not clear to me who has such constrains?
the Internet protocol or the device? It will be good to expand these two section and say more.

Regards!
-Qin
----- Original Message ----- 
From: "Carsten Bormann" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 05, 2011 4:23 AM
Subject: [Lwip] Fwd: New Version Notification fordraft-bormann-lwig-guidance-00.txt

> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 13 Jul 2011 09:48:18 -0400

> (But it's not too late: Anything you want to contribute now might go into a -01 before the I-D update deadline next week.)

I think this is a fair start and the outline mostly looks good
to me.

I don't entirely understand the purpose of Section 6 (Wire-
Visible Constraints) or 7 (Wire-Invisible Constraints).  If
the content really turns out to be what Section 2.5 says is
intended for those, then wouldn't they be better to do up
front before getting into the discussion of individual
protocols?  It seems like that's where you would talk about
collapsing layers together within an implementation, and
other general techniques?

It seems like Section 2.3 (Implementation Styles) should include
mention that systems may or may not provide memory protection,
and that multiple tasks in some systems are supported through a
cooperative multitasking mode rather than as actual processes.

Additionally, some implementations are done in FPGAs, which are
an even more different class.  Is this document / WG intended to
touch on hardware/firmware-based implementations?

Some constrained nodes are being used in distributed control
systems that have real-time constraints and protocol
implementations have been tailored for real-time operation
with consistent and bounded processing delay, etc.  I'm not
sure if there would be interest in considering some of the
tailoring that has been done in those systems within this
document (or WG), but often there's a balancing act
between keeping the implementation small but making the
burden of management small as well.  In general, when some
features are trimmed off, they often include things that
would have been useful in auto-configuration or adaptation
of the configuration parameters (like PMTUD), and so there
are more parameters that are either manually configured or
perhaps even hard-coded and compiled into implementation.
This seems like an important trade-off to discuss.

-- 
Wes Eddy
MTI Systems

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 14 Jul 2011 10:55:08 +0900

Hi,

> 	http://tools.ietf.org/html/draft-bormann-lwig-guidance-00

I support this draft as a base line of the guidance.

> 2.4.  Roles of nodes
>
>    Constrained nodes are by necessity more specialized than general
>    purpose computing devices; they may have a quite specific role.  Some
>    implementation techniques may also
>
>    o  Constrained nodes
>
>    o  Nodes talking to constrained nodes
>
>    o  Gateways/Proxies

I think both gateways and proxies should belong to the 2nd category,
which means Nodes talking to constrained nodes.
Here, I assumed that "gateway" translates a protocol to different one,
and it can act as a cache server optionally.  "proxy" acts as a cache
server, but it doesn't translate protocols.  Both are not constrained
in terms of the classification of section 2.1.

Here, we have two aspects.

         Acpect A.
           1. constrained nodes (NC)
           2. nodes talking to constrained nodes (CN)
           3. nodes talking to constrained nodes via a gateway (N)

         Acpect B.
           1. clients (C)
           2. servers (S)
           3. proxies (P)
           3. gateways (G)

The relationship in my mind is:

         .----.             .----.
         |NC-S|             |NC-C|
         '----'             '----'
            A     .-----.   / |
            |  .->|CN-P |<-'  |
            | /   '-----'     V
         .----.             .----.
         |CN-C|------------>|CN-S|
         '----'-.        .->'----'
                 \-------/
                 |)  G  (|
                 /-------\
                 |       |
         .----.<-'       '--.----.
         | N-S|             |N-C |
         '----'             '----'

The arrows indicate an initiation of a transaction.  So, a client
only initiates any session.  In the observation (pub/sub),
a subscriber becomes a server in listening to a publication
though a subscriber was a client in the subscription phase.

Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 14 Jul 2011 10:58:27 +0900

> 2.4.  Roles of nodes
>
>   In all these cases, constrained nodes that are "sleepy" pose
>   additional considerations.  (Explain sleepy...)  E.g., a node talking
>   to a sleepy node may need to make special arrangements; this is even
>   more true where a gateway or proxy interfaces the general Internet

Reference to the section of the Sleep Mode in the following draft
is helpful to explain "sleepy",

https://datatracker.ietf.org/doc/draft-iab-smart-object-workshop/

Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 14 Jul 2011 11:03:44 +0900

> 5.4.1.  PANA
>
>   PANA carries UDP
>   encapsulated EAP [RFC3748] and includes various operational options.

Not critical, but it should be "PANA carries EAP encapsulated by UDP".

Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 14 Jul 2011 12:27:51 +0900

Carsten,

Let me correct my post.

> Here, we have two aspects.

CN means Constrained Nodes.
NC means Nodes talking to Constrained nodes.
and, P(prxoies) and G(gateways) should belong to NC.
Clients and servers might be better to be replaced
into initiators and responders respectively.

I am sorry for confusing you.

Corrected picture is below:

Acpect A.
1. constrained nodes (CN)
2. nodes talking to constrained nodes (NC)
3. nodes talking to constrained nodes via a gateway (N)

Acpect B.
1. clients (C)
2. servers (S)
3. proxies (P)
3. gateways (G)

         .----.             .----.
         |NC-S|             |NC-C|
         '----'             '----'
            A     .-----.   / |
            |  .->|NC-P |<-'  |
            | /   '-----'     V
         .----.             .----.
                 |)NC-G (|
                 /-------\
                 |       |
         .----.<-'       '--.----.
         | N-S|             |N-C |
         '----'             '----'

---

From: Zhen Cao <[email-masked]>
Date: Thu, 14 Jul 2011 16:45:08 +0800

Wesley, thank you for the comments, and see inline for the response of
some of your points.

> touch on hardware/firmware-based implementations?

In this class, specific to the protocol implementation part, is there
some sharp difference that cannot be included by others. If not, we do
not have to touch this.

> document (or WG),

Interesting. I did know some companies are good at this, but failed to
find the people who have the experience and contribute.  Can you
recommend some experts? Thank you

> but often there's a balancing act

Experiences regarding the configuration part are definitely expected,
MTU/Checksum handling flow into this part, and are important to
discuss.

-- 
Best regards,
Zhen