* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lwig Status Pages

Light-Weight Implementation Guidance (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2011-Mar-27 —  
Chairs
 
 


IETF-100 lwig minutes

Session 2017-11-15 0930-1200: Olivia - Audio stream - lwig chatroom

Minutes

minutes-100-lwig-00 minutes



          ¨j  ¨j ¨j¨j¨X¨T¨[
          ¨U  ¨U¨U¨U¨U¨U ¨j
          ¨m¨T¨a¨^¨m¨a¨m¨^¨T¨a
          
          Light-Weight Implementation Guidance Agenda at IETF-100
          Jabber: xmpp:lwig@jabber.ietf.org
          Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-lwig
          
          Chairs:
          Mohit Sehti
          Zhen Cao
          
          
          11:00-12:00
          Wednesday Morning session Room: Olivia
          -----------------------------------------
          
          Minute Takers:
          Jaime Jimenez
          
          Intro & Overview Co-chairs
          New chair Mohit Sehti
          
          TCP for Constrained devices
          Presenter: Carles Gomez Montenegro [20min]
          https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks
          
          https://datatracker.ietf.org/meeting/100/materials/slides-100-lwig-1-tcp-for-constrained/
          
          
          Carles: Presenting updates on the draft.
          
          Mohit: The table, the code size is the tcp part only?
          Carles: some are the whole protocol stack and some just the tcp, we need
          to fix this.
          Mohit: the stars are missing data?
          Carles: we would have to update it.
          Hannes: thanks for the work. One thing that could be added is whether
          multiple concurrent tcp connectons could be interesting. Also who
          is responsible to maintain the buffers. I was surprised that most
          implementations 8-16 bit microcontrollers and not 32.
          Carles: Usefull, will try to add.
          Rahul: is socket interface supported on top of tcp?
          Carles: usefull to be added.
          Ari: Very usefull. Would be interesting to know RAM use and over
          constrained network (LPWAN).
          Carles: No experience on that. Not aware of specific effor tin this
          area.
          Ari: variety of algorithms for TCP. Exploring the impact and when is
          TCP even possible to run.
          Michael Scharf: TCP should work well over very constrained networks. It
          was designed in a time when 10kb network were common.
          Ari: Thinking about edge of nbiot cell, less than 10kb.
          Suresh: If you put everything on the LPWAN bucket there are lots of
          things that won't work in TCP.
          Carsten: Range in which things work and range in which it doesn't. It'd
          be interesting to know.
          Hannes: Did you check freertos and micrium use as tcp stack? Zephyr,
          Mbed... it'd be good to find out if the table covers various IoT OSs.
          Carles: Taking in feedback, thanks.
          Hannes: On the introduction it'd be good to know about the perception
          of TCP heaviness, here it comes from and the performance, sticking to
          the bare minimum.
          Carles: We will provide insights on this. In reality many of the arguments
          on TCP are not valid or are issues found in other reliable protocols. We
          will explain which aspects increase complexity.
          Hannes. A bit like mythbusting. For example if you support many
          cyphersuits.
          Rahal: Second that thought.
          Carsten: True, but there is a flip side. When you say "Support TCP"
          it does not really mean that. It is also true of TLS. When you cut down
          options the benefit of using a standard protocol its also cut down.
          
          Carles: updating on details for changes on -02.
          
          
          CoAP Security Overhead
          Presenter: John Mattsson [15min]
          https://www.ietf.org/internet-drafts/draft-mattsson-core-security-overhead-02.txt
          
          https://datatracker.ietf.org/meeting/100/materials/slides-100-lwig-2-coap-security-overhead/
          
          
          John: Presenting updates. Draft analyzes overhead of DTLS1.2, TLS1.2
          and OSCORE.
          
          Hannes: Curious on why did you focus on sequence number.
          John: TLS and DTLS compression depends on it.
          Hannes: I'd have started with "here are various on algorithms and the
          length would depend on it."
          John: ?
          
          John: Continues presentation
          
          Hannes: there is a new document that compresses the epoch number and
          other fields.
          John: will add it to the next version.
          Carsten: Foresight when doing this. We put the tls1.2 version number
          there, so now tls1.3 also will have that number.
          Hannes: Can you explain why responses in oscore are always 11bytes in
          size independent of sequence number?
          John: OSCORE does not send it inband. Also it uses COSE which uses CBOR
          which includes numbers with small data value. Compression.
          Hannes: trafficwise is good for analysis (as responses are always the
          same size).
          John: well you can also see that from whom is sending the packets.
          
          John: Continues presentation
          
          Carten: (back to the response comment). Impact of compression on
          visibility of information. Hannes has valid point.
          Hannes: TLS1.3 has some features to make traffic analysis more
          difficult.
          Hannes: Change title cause it gives the impression that security ads
          overhead.
          Jaime, Ari, Hannes: Use Comparison.
          Mohit: seems that there is interest. Authors should submit to lwig.
          Carsten: overhead is also useful. numbers would make more snese if you
          separate the information that cannot be compressed. Also there is a
          security cost.
          Ari: Handshake was also not analyzed.
          John: no, not included. ACE is doing some analysis but not public at
          the moment.
          Hannes: not very useful
          Ari:  maybe give a pointer when it is available.
          John: there is no easy to find numbers on how large tls packets are in
          the handshake.
          Hannes: you added some work that was not picked up and continued
          so it might be counter productive. Handshake is more complex to
          analyzed. Carsten pointed out that most of the overhead is caused by
          the sec algorythm itself. With the handshake you are comparing apples
          and oranges, they have different purpose.
          Mohit: be concise please.
          Ari: should we have a document with handshakes?
          John: not in this doc, in ACE will be done.
          
          
          Neighbor Management Recommendations
          Presenter: Rahul Jadhav [15min]
          https://tools.ietf.org/html/draft-jadhav-lwig-nbr-mgmt-policy-01
          https://datatracker.ietf.org/meeting/100/materials/slides-100-lwig-3-lwig-neighbor-management-recommendation/
          
          
          Rahul: Presenting updates on draft, decribing problems associated with
          neighbor cache management in constrained multihop networks and solutions.
          
          No questions.
          
          



Generated from PyHt script /wg/lwig/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -