[Roll] (no subject)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 25 October 2012 21:43 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0AD21F860F for <roll@ietfa.amsl.com>; Thu, 25 Oct 2012 14:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level:
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, MISSING_SUBJECT=1.762]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp0qt5yL3FTG for <roll@ietfa.amsl.com>; Thu, 25 Oct 2012 14:43:58 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE5F21F867C for <roll@ietf.org>; Thu, 25 Oct 2012 14:43:57 -0700 (PDT)
Received: from sandelman.ca (74-115-197-230.eng.wind.ca [74.115.197.230]) by relay.sandelman.ca (Postfix) with ESMTPS id 2680681B7 for <roll@ietf.org>; Thu, 25 Oct 2012 17:36:18 -0400 (EDT)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D92D8CA0BC for <roll@ietf.org>; Thu, 25 Oct 2012 09:16:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "roll@ietf.org" <roll@ietf.org>
Date: Thu, 25 Oct 2012 09:16:48 -0400
Message-ID: <26644.1351171008@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [Roll] (no subject)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2012 21:43:58 -0000

cc: Brian E Carpenter <brian.e.carpenter@gmail.com>om>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>om>,
Fcc: +outgoing
Subject: Re: [Roll] using the flow label instead of hop by hop
In-reply-to: <5087F457.1050409@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD8221CB0DA@xmb-rcd-x01.cisco.com> <5081A327.9010505@exegin.com> <E045AECD98228444A58C61C200AE1BD8221D85A6@xmb-rcd-x01.cisco.com> <5087F457.1050409@gmail.com>
Comments: In-reply-to Brian E Carpenter <brian.e.carpenter@gmail.com>
   message dated "Wed, 24 Oct 2012 14:59:51 +0100."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
--------
--=-=-=
Content-Transfer-Encoding: quoted-printable


First, I think that the intro, section 1, para 2 is very much misleading
people into thinking that this is somehow about what the flow label is
for packets leaving the LLN and crossing the Internet.=20=20
It's a consideration, but only for one case, which is not necessarily a com=
mon one.

There are three cases to consider.
1) packets within the LLN.
2) packets entering the LLN.
3) packets exiting the LLN.

We care mostly about #1.=20=20
It's where optimizations save the most bits (=3D=3Denergy), and in which it
matters whether we use the right DODAG or not.  In particular, for the
cases where a P2P DODAG has been constructed (with storing nodes,
therefore no source routes), the packet never goes to the DODAG root.
My gut is that case #1 is at least 90% of the packets, in some cases, 99.9%.

Note that where two low power layer-2s are connected via a wired
network (or higher power wireless network), RPL messages connect
the two islands into a single DODAG, and so the packet isn't technically
leaving the LLN.=20=20

For case #2, a) the gateway can't trust the flowid to be sensible
anyway, and b) the gateway needs to do some larger analysis to determine
what DODAG to use.  As such, it's hard to do anything other than add a
6in6 header in order to preserve the inner flow label, which is what
would be done in the absense of this proposal.  Having done so,
the opportunity to set the outer flow label presents itself, or to add
the hop-by-hop header.=20=20=20

For case #3, packets leaving the LLN, the encoded flow label seen on the
outgoing packet is meaningless to the Internet.  If left as is, however,
it does rather uniquely group flows.  If the sending node needed a
specific flow label expressed in an end to end fashion, and this
proposal was active, then a 6in6 header would be appropriate as before.

I think the question is, what is 6man going to say about host stacks
(TCP for instance) setting the flow label on packets?  Is there going to
be any suggestion that a TCP SYN-ACK should use the same flow label as
was seen on the SYN?

=2D-=20
Michael Richardson
=2Don the road-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJQiTu/AAoJEKD0KQ7Gj3P2MrsH/2yZ4XS84vXVeAI2zDbeKgDW
z1G9wQT9fJT9pfiJrslsgsVgd4RUxRQSxAQc99ArDMOl4Qr71cNa7dVjFBfuYXEA
00HamIYfRgzGVcbRPlNG9ORSNNNO+J9CrOdYIWyFV22WGrHG2d3YyijWBicWwkFB
I8z3BF3gzdCNXA9aqG45JHu0/0ZsB82bmaCFq9svhaD8JHAW1f84oa5NAeOyhvjt
oJmGsklJyXxGjhwzdyqnE2IEP+LrU3cqeJQco4XNW8NWXb6VpitgIWcWTP0LbtDf
1rOwxyK5NbdBlt3hYcUTJFNMkcC2hQcTlakBBZ+hl1sYIt1F/945RbrFcEn5hRw=
=LkMl
-----END PGP SIGNATURE-----
--=-=-=--