Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

[Brian E Carpenter <[e-mail]>]

On 17/08/2014 21:52, Ray Hunter wrote:
>> Brian E Carpenter <mailto:[e-mail]>
>> 16 August 2014 21:55
>> Ray,
>>
>> On 16/08/2014 18:49, Ray Hunter wrote:
>>>> Philip Levis<mailto:[e-mail]>
>>>> 16 August 2014 02:33
>>>>
>>>> 1) There is an extension header already; the problem is that it can
>>>> introduce a significant (ballpark estimates are, in well engineered
>>>> networks, up to 5-10%) cost. The proposal is to replace the extension
>>>> header with using the flow label.
>>>>
>>>> 2) There'a already significant IP header compression in the cases
>>>> we're talking about.
>>>>
>>>> Phil
>>> I'm sympathetic to the needs of low power devices.
>>>
>>> However, to be clear, we are reengineering a standards track document
>>> that is around 2 years old (http://tools.ietf.org/html/rfc6553) and
>>> which works technically, and we are proposing an additional encoding of
>>> exactly the same information to achieve theoretical efficiency gains
>>> that are still only rough estimates?
>>>
>>> Where's the experimental proof that this will really pay off in
>>> increased battery life?
>>>
>>> You write "replace". Will 6553 now be deprecated?
>>>
>>> If not we'll have:
>>>
>>> 6553 to carry RPL information as an option header.
>>>
>>> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a
>>> flow label
>>>
>>> flow label information used to select patch and load balancing in
>>> multi-path networks. e.g.
>>> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
>>>
>>>
>>> http://tools.ietf.org/html/rfc6438
>>> http://tools.ietf.org/html/rfc7098
>>>
>>> I do not see that these applications for this one field are mutually
>>> compatible, and worse still, the only way to decode the semantics of the
>>> overloaded field is by applying some unknown external context ("within
>>> RPL domain"/ "on the Internet").
>>
>> No, I don't see a problem there. The boundary of a RPL domain is
>> very well defined and flow-label-for-rpl clearly specifies that
>> outside that boundary, RFC 6437 applies (which enables RFC 6438
>> and 7098).
> But inside an RPL domain, you cannot use any RFC's that reference the
> flow label as per 6437, because all of the entropy has gone.

Correct. But isn't that a trade-off that might be reasonable in
the low-power lossy environment? (That's not intended as a rhetorical
question - I just don't have enough knowledge of that environment
to answer it.)

> 
> And what happened to our end to end architecture?

There are various views of what e2e means, but I still like the
phrase "certain required end-to-end functions can only be performed
correctly by the end-systems themselves". Load balancing and adaptive
routing are not actually e2e functions in that sense.

> I just do not like the concept of parsing a packet, and then having to
> determine the semantics of the contents of a particular field based on a
> "domain" that is not carried anywhere in the packet.

I see the objection, but we've been doing it for years; diffserv does
it by definition.

   Brian

> e.g. think about decoding offline captures

>>> The hidden "cost" here is that we will have 3 different overlapping
>>> solutions = code bloat and potentially a lot of additional processing to
>>> locate the correct information and then process it, which is also a hit
>>> on energy efficiency.
>>>
>>> IMHO the bar should be pretty high for accepting this proposal, as it is
>>> not actually solving a tangible issue.
>>
>> Whether ROLL wants to endorse alternative methods within RPL
>> domains is not a 6man question.
>>> Also my prediction of the next request for field overloading will be:
>>> My ISP only delegates one /64 with PD
>>> I have multiple links in my Homenet
>>> All my media is EUI48 based. No one really uses EUI64.
>>> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for
>>> routing in Homenet by encoding a (V)LAN ID in it.
>>> It's OK though. Homenet is a walled garden and I'll rewrite the field at
>>> the exit so no one will ever know.
>>
>> Nice strawman, but why is it relevant? There's no need to rewrite
>> the bits, BTW. As RFC 7136 says:
>> "However, the method of generating IIDs for specific link types MAY
>> define some local significance for certain bits... the whole IID value
>> MUST be viewed as an opaque bit string by third parties, except possibly
>> in the local context."
>>
>>     Brian
>>
>>> As an alternative: if this information is really RPL specific, why not
>>> just add the RPL Information as a tag to the front of the packet e.g.
>>> via an MPLS label?
>>>
>>> MPLS labels are only 4 octets, and are designed to be very efficient and
>>> fast.
>>> You can easily strip them at egress, and munge it/set it on ingress.
>>> It's clear where an MPLS domain ends and starts: no chance of RPL
>>> information leaking onto the Internet, or entering from the Internet.
>>> The MPLS label also transports the 20 bits of information you need.
>>> MPLS labels are at a clear fixed position in the packet and are easy and
>>> efficient to parse.
>>> You could also then nest RPL domains if you ever wanted to do that.
>>> It's also extensible, as you can push more labels on the stack in the
>>> future if you ever want to extend the RPL Information transported,
>>> whereas the flow label is a single fixed field.
>>> It does not require any new standard, except maybe an informational RFC
>>> on how to encode the RPL Information into MPLS labels.
>>> And it doesn't overload anything.
>>>
>>> regards,
>>>
>>>> Ray Hunter<mailto:[e-mail]>
>>>> 15 August 2014 21:49
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>> Apologies for tardy response (holidays)
>>>>
>>>> After reading the draft it seems to me that what is being attempted is
>>>> 1) to add some stuff to the IPv6 header that is RPL domain specific
>>>> 2) to reduce the overall packet length to reduce active radio time and
>>>> thus save energy
>>>> by
>>>> 3) overloading an existing well-defined and used IPv6 header field
>>>>
>>>> My simple logic tells me that
>>>> 1) could be best solved at an architecture level via an extension
>>>> header http://tools.ietf.org/html/rfc2460#page-11 +
>>>> http://tools.ietf.org/html/rfc7045
>>>> 2) could be best solved at an architecture level via IP header
>>>> compression http://tools.ietf.org/html/rfc2507.html with or without
>>>> additional tweaks
>>>> and that overloading an opaque field in 3) by incorporating values
>>>> with low entropy (as per the RPL flow label) gives additional security
>>>> risks to http://tools.ietf.org/html/rfc7098
>>>>
>>>> So what's wrong with my simple logic?
>>>>
>>>> "But if we consider the whole RPL domain as a large virtual host from
>>>> the standpoint of the rest of the Internet" would suggest to me that
>>>> the cost of stripping out the additional IPv6 hop by hop extension
>>>> header at the edge of the domain is a bogus argument, as you'll anyway
>>>> have to provide some adaption and security at the root of each RPL
>>>> domain to detect and bounce spoofed RPL Information from entering, or
>>>> private RPL Information leaking out of each domain. Whether this
>>>> domain-specificRPL Information is encoded in an explicit hop by hop
>>>> option or an overloaded flow label would seem largely irrelevant to
>>>> that operation at the RPL root (especially since the RPL root anyway
>>>> has to be a high power node to be able communicate with the rest of
>>>> the Internet).
>>>>
>>>> IMHO If you overload the flow label you're looking at creating an
>>>> incompatible walled garden, with competing IETF standards that are
>>>> mutually exclusive.
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>> ------------------------------------------------------------------------
> 
>