[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>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, 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----- --=-=-=--
- [Roll] (no subject) Michael Richardson
- [Roll] (no subject) Qasem, Mamoun
- Re: [Roll] (no subject) Rahul Jadhav