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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Carsten:

> I really would like to hear a technical argument why the flow label hack is needed.

? Then you probably missed most of my mail from yesterday ?
? The sentence is a rhetorical abuse - like "our just cause" as opposed to "our cause is just" which can be argued -, and there is no consensus that the flow label technique is a hack ?
 
Answering both pending mails from you; I'll rephrase, but please give a second glance at my previous mail where I made 4 points and you responded to only one.

In short, a 6lo compression draft will not achieve all the purposes of the draft, it will not achieve the same compression, and the use case will not be fully congruent.

For instance, the draft is asking 6MAN the right to reset a flow label at the ingress RPL domain. Without this right, a flow label coming from the Internet will be transported in the RPL domain or (more probably) implementation will voluntarily fail to conform 6437, and elide them regardless. I'd rather have a realistic rule that sets the expectations right.

We disagree on the argument that both approaches save the same bits and always result in frames of a same size is technically incorrect. In the scenario above, the flow label draft saves 20 bits that a 6lo compression cannot save without the blessing that is being asked here, and the 6lo approach will need signaling bits that are implicit in the flow label, thus consuming extra space. OTOH, the 6lo approach could compress the instanceID and save bits there - not sure I'd play more with the rank as your version suggests. 

Another disagreement is on your assumption that compression is the only reason for preferring the flow label technique. We have an IOS implementation that is not for use in 6LoWPAN networks, and relies on the (stateful) storing mode. HbH has known issues in classical routers, makes the header chain longer and requires silicon processing or punt, so there are reasons not to use it there either. OTOH making a routing decision that takes the flow label into account is quite natural, this is what load balancers will do at the core. We have prototyped indexing the VRF with the RPL instance in the flow label, and it works like a charm.

And even if compression is the reason why the flow label is used, RPL is a rather new routing protocol and we do not know what the world will make of it. For all I know it may be deployed in RoHC environments to aggregate femtocell traffic for instance. Assuming that the compression will always be 6LoWPAN is short sighted.

And there is no "politics", but external SDOs that base their work on our RFCs and that we need to treat with all respect. Facts:
- ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a stateful indicator of the flow (called a contract ID). We need to be clear on how we position this WRT 6437 now that we shipped it. The draft makes that legal, as long as we extend the RPL domain to an ISA100 domain as well.
- We can promote behaviors in WCI (e.g. reset the flow label to something valuable to the Internet at large at the backbone router) but then we need to document them in an RFC that they can reference.

I agree that multiple techniques is not a good idea, mostly in LLNs. Sadly the HbH is already there, uncompressed, and implemented in shipping devices. So the argument would stall the situation and we cannot have that. What I'd rather do is have the 6lo proposal converge the format with the FL, so the logic to parse is common. Finding it in the packet is not the complex piece anyway.

If we still disagree then we can talk one-to-one, the lists are probably overwhelmed with this thread, and come back when we reach an agreement. We can also talk about the compression logic if you like. I can setup a webex.

Cheers,

Pascal


> -----Original Message-----
> From: Carsten Bormann [mailto:[e-mail]]
> Sent: jeudi 14 août 2014 11:05
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms; Routing Over Low power and Lossy networks; Ines Robles;
> 6man WG; [e-mail] WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> On 14 Aug 2014, at 10:54, Pascal Thubert (pthubert) <[e-mail]>
> wrote:
> 
> > If the 6lo work concludes as an RFC, it should recommend to prefer the 6lo
> way against the flow label way.
> 
> It is a bit more complicated.
> 
> If both representations of the RFC 6553 information are in use:
> A compressor may need to decide whether a flow label present in an
> uncompressed packet is an RFC 3697 flow label or one of these.
> A decompressor may need to decide whether the information is to be
> represented in canonical RFC 6553 form or making use of the flow label hack.
> 
> In any case, I'm not a big fan of providing two different ways of doing the
> same thing, at different layers.
> In particular not in the constrained environment.
> 
> I really would like to hear a technical argument why the flow label hack is
> needed.
> (Or a political one, if that is the reason.)
> 
> Grüße, Carsten