Re: [6lo] fragment forwarding document

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 24 July 2017 11:00 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74017129AAD for <6lo@ietfa.amsl.com>; Mon, 24 Jul 2017 04:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXpJHTquXjf4 for <6lo@ietfa.amsl.com>; Mon, 24 Jul 2017 04:00:39 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708B5129A92 for <6lo@ietf.org>; Mon, 24 Jul 2017 04:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6272; q=dns/txt; s=iport; t=1500894039; x=1502103639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IGaVdAWg2H1sMqdjRrCybkAk/LUh6fR0croTqiCsYAM=; b=Zh7AkQ1GmP5/gk1oP5RiCXhDAnp/aUCfPoySamUa2Z8Agkf3rbfd59H4 eB0flQyl6PwJtw3zNfqafRHf/0ukBdexX2N/AJmnpfiavxRzrZo1/T+X8 66ezTWJh7yaMub5vXrOZxWvEcGT73oac6CDeb9iV7sp72J2ilEIiv8XHd c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgCR0nVZ/40NJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy0tZIEbtXCCEi6FGQKEDkAXAQIBAQEBAQEBayiFGQY6LRIQAgEINhA?= =?us-ascii?q?yJQIEAQ0NEooVELIHiy8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMog02BYYIYg?= =?us-ascii?q?QyKQB8FiV6Nb4gBAodMg0qIfYIViUiGY5VjASEBNYEKdRWHX4lLgQ4BAQE?=
X-IronPort-AV: E=Sophos;i="5.40,406,1496102400"; d="scan'208";a="460360563"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jul 2017 11:00:38 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v6OB0ctZ011773 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jul 2017 11:00:38 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Jul 2017 06:00:37 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Mon, 24 Jul 2017 06:00:37 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Jonathan Hui <jonhui@nestlabs.com>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: fragment forwarding document
Thread-Index: AQHTA1ARqirsPXclOEu95N7yVToAJaJinMMA
Date: Mon, 24 Jul 2017 11:00:15 +0000
Deferred-Delivery: Mon, 24 Jul 2017 10:59:48 +0000
Message-ID: <1a6bcf9600b7411ba35dca390a3d9a7d@XCH-RCD-001.cisco.com>
References: <30821.1500764685@dooku.sandelman.ca>
In-Reply-To: <30821.1500764685@dooku.sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.244.51]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/u2FGjo8GV9rG6YZJs9ESzp5zj6Q>
Subject: Re: [6lo] fragment forwarding document
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2017 11:00:41 -0000

Hello Michael:

Huge thanks.

Let's see:

pg: 6, section 4.1:

 Sequence:  5 bit unsigned integer; the sequence number of the
      fragment.  Fragments are sequence numbered [0..N] where N is in
      [0..31].  As long as the overheads enable a fragment size of 64
      bits or more, this enables to fragment a packet of 2047 octets.
      ^^^^ <- I think you mean octets?

[Pascal] that's a oups, fixed in 07.

-------------------


 Fragment_offset:  11 bit unsigned integer; when set to 0, this field
      indicates an abort condition; else, its value depends on the value
      of the Sequence.  When the sequence is not 0, this field indicates
      the offset of the fragment in the compressed form.  When the
      sequence is 0, denoting the first fragment of a datagram, this

reword. I think it means:
  if Sequence > 0; fragment_offset == 0 => abort.
                 ; else offset of fragment
  if Sequence ==0; fragment_offset is total size of datagram.
  
--------------------

   
[Pascal] This is effectively a big stone you are unturning. The intent of the initial logic is:

If fragment_offset == 0; forward of you can and cleanup (aka abort)
          ; else
                  if Sequence ==0; fragment_offset is total size of datagram
                                      ; else fragment_offset is offset in the datagram in octets


[Pascal] With the current text (sequence, offset) tuple of (0, 0) is significant whereas with your proposal, this tuple becomes a protocol error. Either way, we probably need some more text what nodes should do in that case. I'm not too much in favor of creating an error case; error flows have a tendency to not perform well.

[Pascal] Let's consider this: (0,0) could be useful, because it carries the original IP header so there's a chance it goes all the a to the reassembly end point even if the forwarding state is broken midway; this could be important because the end point is where the buffers are wasted. And because it may be routed differently than a previous (0, X>0), a (0, 0) may fail to clean up state along the old path even when the old path is not broken. We'll note that the old path may be cleanup all the way back (to the breakage if there's one) by a reset message from the end point. That reset message could be stimulated by receiving  a (0, 0). But with the 6LoWPAN signaling as it stands now, the end point may not recognize that this is the same IP packet because the datagram tags would possibly be different, being switched differently along different routes. If we care to take that path, we need the end points to exchange end-to-end IDs for the flows. Doable but expensive. Worth it?

[Pascal] In order to protect the future, I'd say that (0, 0) should be supported. It should be routed, using the same label path if one exists that is not broken on this next hop. Cleanup should be performed. I reformed the text along those line





-------------------------------



Are FRFRAG-ACK's subject to 6loRH compression in anyway?
(I don't think it helps, but, whenever I see a potential series of zeros, I
wonder)
 
[Pascal] No to the 6LoRH piece, but possibly yes to the idea of compression. You'll find in earlier versions of the draft that a compression of the bitmap was proposed. I spent iterations adding and removing it based on one person's feedback; not an easy choice since it is a tradeoff between over the air performance and code complexity. 

More in section 6.2 of https://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-06

Let's reach consensus on that! 


-------------------------------

section 5 says:
   The process ensures that at every hop, the source
   MAC address and the datagram_tag in the received fragment are enough
   information to send the RFRAG Acknowledgment back towards the source
   6LoWPAN endpoint by reversing the MPLS operation.

It seems that we are assuming SLAAC built addresses using EUI-64s?
(which could well be 2-byte short addresses too!)  otherwise, mapping From MAC address back to an IPv6 address is not possible?

[Pascal] I do not see how/why. 

[Pascal] All it means is that the MPLS operation address is indexed by the tuple (incoming link - as identifies by smac, label - the datagram tag). No big news there, once created an MPLS LSP can carry non IP traffic. 

[Pascal] The novelty is rather that the LSP is created on the fly with the first fragment of an IP packet, and removed once the packet as fully flown through.

----------------------------------------

then says:
   It is
   expected that the upper layer retries obey the same or friendly rules
   in which case a single round of fragment recovery should fit within
   the upper layer recovery timers.

"the same or friendly rules"  <-- missing a word?

[Pascal] slight rewording, added ref to 8085 
[Pascal] 

----------------


section 6:
   Upon the first
   fragment, the routers along the path install a label-switched path
   (LSP), and the sollowing fragments are label-switched along that
   path.

s/sollowing/following/

6.1: s/ia route lookup/a route lookup/

  allocates a label-swap entry indexed by (MAC_previous,
  DT_previous) that contains (MAC_next, DT_next)

[Pascal] done, thanks!

----------------------

It seems that really do have to go read LSP documents to understand things :-)
RFC3031 had better be a normative reference then, or section 6.1 needs to have some pictures and much more explanation.  I will have to go re-read
3031 to understand what a "label-swap entry" is exactly.

[Pascal] well, this refers to text in this spec:
"
allocates an abstract label-swap entry indexed by (MAC_previous, DT_previous) that contains (MAC_next, DT_next)
"
Maybe some reorg is needed to highlight that structure.

------------
   change the source MAC address to from MAC_prev to MAC_self

"to from" --- is this correct, or is there an extra word here?
[Pascal] 
[Pascal] fixed typo : )

--

I just pushed 07. Thanks again Michael!

Pascal