Subject: [MEXT] about the nature of "flows" Re: weird idea about flow bindings

From: George Tsirtsis <[email-masked]>
Date: Mon, 18 May 2009 12:17:26 -0400

Marcelo,

It might be useful to step back a bit to understand better what the issue is.

I think one issue in this discussion is that the use of the term
"flow" in flow bindings in the flow bindings and flow description
drafts, is currently a bit wider than that used in flow labels. Flow
bindings, with any of the filter description formats discussed (text
or binary) should be more accurately described as "packet filter rule
binding".

In other words, all our filter descriptions so far, have taken the
view that the MN should have as much flexibility in identifying
"flows" (or more accurately "filter rules") as a regular packet
classifier e.g., firewall. You seem to think this is a bad idea and
that only IP layer (and possibly transport layer?) fields should be
used in the context of flow bindings.

Am I right so far?

I think that in the extreme, one could go further and say that packet
routing should really be ONLY based on IP Addresses. Anything else is
mostly broken since it can never scale and it is not compatible with
regular IP routing. I am actually sympathetic to this view of the
world in which it requires that the MN uses a different source address
for every "flow" it wants to be able to route separately. Then flow
bindings are simply implemented by redirecting the various MN
addresses used to the different CoAs of the MN.

The flow label, however, is IMO mostly an inadequate field to use for
flow bindings. This is because a given MN has no control over when and
how a given CN uses the flow label. Flow Bindings allow the MN to
affect the 'last hop routing' of packets going from the HA to itself.
It makes no sense to me for the MN to have to rely on the use of what
is basically an optional field by random 3rd party nodes.

In contrast, the flexibility provided by the binary flow description
as you know is mostly about IP layer and Transport Layer fields, which
I think are the minimum required to provide effecting flow binding
capabilities. The recent addition of the Pointer idea simply expanded
the capabilities to random upper layer field matching, I believe very
elegantly and powerfully, if you do not mind me saying so ;-)

Still, I think it is valid to question whether such higher layer
matching capability is a good thing architecturally. As of yet,
however, I am not sure I see what the issue is with providing such
capability, beyond a somewhat academic issue of regular IP routing
compatibility.

As a side note, I have no problem whatsoever requiring that HAs
perform deep packet inspection as the binary flow description draft
requires. Commercial HAs are able to perform packet filter inspection,
and are actually expected to do so, for other needs already
(firewalling, lawful interception, value-add bells and whistles etc)
so I do not see any issue there. Note that the use of Pointers for
such deep header inspection is trivial compared to other methods since
it does not require that the HA understands the upper layer header
formats. It simply moves to byte X and matches Y number of bytes. On
the MN side things are different and as I explained the complexity on
the MN side is implementation specific.

George

On Sun, May 17, 2009 at 11:34 AM, marcelo bagnulo braun
<[email-masked]> wrote:
> George Tsirtsis escribió:
>>
>> Marcelo,
>>
>> Flow Movement is supposed to work in combination with DSMIPv6. Are you
>> suggesting the flow bindings should only work for IPv6 traffic then?
>>
>
> no, i ma suggesting that for IPv6 traffic, we should use the flow label
> for ipv4, we certainly need to use something else
> What i am not buying is that we cannot build a method that relies in the
> flow label cause IPv4 doesn't support it. In other words, i think it is
> perfeclty ok to build our reccomended method relying on the usage of the
> flow label, and define some other hacks to support ipv4.
>>
>> why would we place such a restriction?
>>
>> BTW, as far as I know flow label is the least well defined aspect of
>> IPv6.
>
> but that is not the porblem of IPv6, but it is an inherent problem of
> defining a flow. The IP layer has a problem cause it is agonstic to flows.
> So, only the application knows what really a flow is. And IPv6 does provide
> the means for the application to signal the packets that belong to flow to
> the IP layer i.e. the flow label.
> In other words, this is a fundamental problem: IP does not knows about flows
> and we are trying that MIP which is in the IP layer to discriminate flows.
> We can either try the IP layer to guess what are the common bits of a flow
> or we can leverage on the explicit definition of a flow, which is what the
> flow label is for.
>>
>>  How does the MN know whether a given CN marks each relevant flow
>> with a different flow label?
>
> becuase it needs to be compliant with RFC3697?
>>
>> Also note that flow labels are source
>> address specific so the flow label by itself is not sufficient.
>>
>>
>
> sure, the flow description is src add, dst add and flow label
>
>> Also the binary format
>> (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in
>> fact allows for a very simple MN implementation if the only thing you
>> want to classify is flow labels. An implementation could only allow
>> the flow label to be set resulting in the following flow descriptor:
>>
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 |       (M)   Flow Label
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>         FB (cont)     |
>>     +-+-+-+-+-+-+-+
>>
>> Or actually something like the above but including the source address
>> too (flag C), do me more correct..
>>
>> If an MN implementation does not want to deal with any of the other
>> fields, it does not need to implement them.
>> In that sense multiple compatible implementations are allowed as long
>> as the HA implements the flow descriptors in their full complexity.
>>
>>
>
> this is my problem. I don't want to impose the HAs to be able to parse
> arbitrary bits in the application data. I think this is not the right way to
> do it. I don't think the IP layer should be snooping into application data
> bits
>
>> Finally note that what constitutes a "flow" could be something like
>> "ALL TCP Traffic", no matter which source address and what flow label
>> is used. How would the MN be able to say push all TCP to one CoA and
>> all UDP to another based on your scheme?
>>
>
> well, you can do this based on the protocol field of the IP header
> As i stated in my earlier reply to Hesham, i don't have a problem with using
> any IP header fields as flow descriptors and i may be ok with sing the
> transport header bits (not what i would preffer, but hey, you can't always
> get what you want)
> My problem is with supporting application data bits as part of the flow
> description, which i really think is broken
>
> Makes sense?
>
> Regards, marcelo
>
>
>> George
>>
>>
>> On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun
>> <[email-masked]> wrote:
>>
>>>
>>> George Tsirtsis escribió:
>>>
>>>>
>>>> Hi Marcelo, I now understand what you propose better. and it makes more
>>>> sense than I initially thought.
>>>>
>>>> Two issues, though:
>>>>
>>>> 1) this requires the CN to cooperate i.e., make proper use of flow
>>>> labels.
>>>>
>>>
>>> according to RFC3697:
>>>
>>>  To enable Flow Label based classification, source nodes SHOULD assign
>>>  each unrelated transport connection and application data stream to a
>>>  new flow.
>>> ...
>>>
>>>  To enable applications and transport protocols to define what packets
>>>  constitute a flow, the source node MUST provide means for the
>>>  applications and transport protocols to specify the Flow Label values
>>>  to be used with their flows.  The use of the means to specify Flow
>>>  Label values is subject to appropriate privileges (see section 5.1).
>>>  The source node SHOULD be able to select unused Flow Label values for
>>>  flows not requesting a specific value to be used.
>>>
>>> So, yes but node should do this if they expect things to work properly
>>>
>>>
>>>>
>>>> It is not clear to me that even if all nodes populated the flow label
>>>> (which I think is not even true)
>>>>
>>>
>>> does anybody has information about the support of RFC3697 in current
>>> OSes?
>>>
>>>
>>>>
>>>> , its use would be universally consistent in a way that would ensure
>>>> that the setting of the flow label by the CN would be inline with what the
>>>> MN would like to identify as a flow.
>>>>
>>>
>>> that would determine the granularity of the method
>>> I am not sure the spectrum of choices is so big that this can be a
>>> problem
>>> could you think of some very different criteria to define what a flow is
>>> that this would be an issue?
>>>
>>>>
>>>> 2) This does not work for IPv4 traffic.
>>>>
>>>>
>>>
>>> i don't buy this argument. If we apply this argument, then we could never
>>> use the flow label for anything, since it doesn't work for IPv4.
>>>
>>> Reagrds, marcelo
>>>
>>>
>>>>
>>>> Thoughts?
>>>> George
>>>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>   ok, let me try again because it seems i am failing miserably to
>>>>   communicate what i want to say (or it simply so broken that people
>>>>   cannot believe what they are reading :-)
>>>>
>>>>   Let's try with an example.
>>>>
>>>>   We have the MN who has two CoAs, CoA1 and CoA2.
>>>>
>>>>   The MN has a policy that says that it wants flows from app1 to be
>>>>   exchanged through CoA1 (well, the policy would say that they
>>>>   should be received by the interfece in which CoA1 is configured)
>>>>   and that flows from app2 to be exchanged through CoA2 (same
>>>>   comment about the interface applies here)
>>>>
>>>>   In addition, MN has defined CoA1 to be the primary CoA i.e. the
>>>>   CoA with highest priority.
>>>>
>>>>   So, we have two different situations. Either the MN starts the
>>>>   communication or the CN starts the communication. Actually, this
>>>>   is pretty irrelevant, cause the two directions of a connections
>>>>   are handled independently. the MN will send packets from app1
>>>>   through CoA1 and packets from app2 through CoA2 and it doesn't
>>>>   need any additional actions from the HA for outgoing packets.
>>>>
>>>>   Now, the difficulty is with incoming packets. the MN needs to
>>>>   inform the HA about which CoA it wants to use to receive any flow.
>>>>
>>>>   Suppose that the HA has no flow bindings for the MN so far.
>>>>
>>>>   So, suppose that the app1 in CN starts a flow to the MN. The HA
>>>>   will receive the packet and will send it though the CoA1 cause it
>>>>   is the one with higher priority. the MN is happy and there is no
>>>>   need to do anything else.
>>>>
>>>>   Suppose now that the app2 in the CN starts a flow to the MN.
>>>>   According to RFC3697, the CN SHOULD assign a different flow label
>>>>   to the packets belonging to this flow e.g. to this TCP connection.
>>>>   Let's assume it is actually a TCP connection to make the example
>>>>   more concrete.
>>>>   So, app2 opens a TCP connection to MN. CN then sends the TCP SYN
>>>>   to the MN.
>>>>   The HA receives the TCP SYN and since there is no flow binding
>>>>   state for this flow it forwards it through the CoA1 (the one with
>>>>   highest priority)
>>>>   The MN receives the TCP SYN through CoA1 and it realizes that this
>>>>   is not compliant with its flow policy. So, it extracts the flow
>>>>   label value, the src address and the dest address and it sends a
>>>>   BU to the HA stating that the flow identified by the flow label,
>>>>   src add and dest add needs to be bound to the CoA2.
>>>>   Simultaneously, it also sends the TCP SYN+ACK back to the CN.
>>>>   The CN receives the TCP SYN+ACK and sends the Ack back. the HA
>>>>   receives the ACk and will forward it based on the flow binding,
>>>>   i.e. through the CoA.
>>>>
>>>>   the result is a method that never looks into higher layer
>>>>   information for setting the flows.
>>>>
>>>>   makes sense?
>>>>
>>>>   Regards, marcelo
>>>>
>>>>
>>>>   Hesham Soliman escribió:
>>>>
>>>>
>>>>       On 17/05/09 3:04 PM, "marcelo bagnulo braun"
>>>>       <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>>           Hesham Soliman escribió:
>>>>
>>>>               The flow label should be part of any filter descriptor
>>>>               anyway. So at anytime
>>>>               A MN can send a BU specifying that packets with flow
>>>>               label X should be
>>>>               directed to CoA1. I'm not sure how your proposal
>>>>               changes/adds to this.
>>>>
>>>>           what i am saying is that you don't need anything else
>>>>           other than this
>>>>
>>>>
>>>>       => see below
>>>>
>>>>
>>>>               As a general issue, the flow label is unlikely to be
>>>>               used for this purpose
>>>>               until we resolve it's mutability issues
>>>>
>>>>           what mutability issues are you referring to?
>>>>           AFAIU, the flow label is set randomly b the source and
>>>>           remains unchanged
>>>>           e2e and for the duration of the flow.
>>>>
>>>>
>>>>       => I thought RFC 3697 talked about it being changed en route
>>>>       then changed
>>>>       back before it hits the destination. But I just scanned it and
>>>>       I can't find
>>>>       this text. Maybe it was never included.
>>>>
>>>>
>>>>                and until it is actually _used_ in
>>>>               the API. At least until recently no one was using it.
>>>>
>>>>           why do we need to have it in the API? It is only imporntat
>>>>           the the
>>>>           source sets it to a random value and keep it unchenged e2e
>>>>           and for the
>>>>           duration of the flow. I understand that these conditions
>>>>           are met today,
>>>>           right?
>>>>
>>>>
>>>>       => But are you saying the src MIP6 module overwrites the
>>>>       potential flow
>>>>       label set in the API? Because it is possible that an app sets
>>>>       the flow
>>>>       label. RFC 3697 assumes the presence of an e2e mechanism to
>>>>       negotiate the
>>>>       flow label. If not then how do you make sure it's always
>>>>       unique? And how do
>>>>       you make sure that the CN echoes back the same value in the
>>>>       flow label?
>>>>       And what if the CN initiated the connection?
>>>>
>>>>       Hesham
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>   _______________________________________________
>>>>   MEXT mailing list
>>>>   [email-masked] <mailto:[email-masked]>
>>>>   https://www.ietf.org/mailman/listinfo/mext
>>>>
>>>>
>>>>
>>
>>
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 18 May 2009 18:38:30 +0200

> used in the context of flow bindings.

correct
> routing should really be ONLY based on IP Addresses.

not really, the flow label is explcitly there to provide special 
treatment to flows. Same with the traffci class bits. It is perfectly ok 
to use those a part of the routing decisions imho
>  Anything else is
> how a given CN uses the flow label.Flow Bindings allow the MN to
>   
I think we are focusing in different ways of splitting the problem.
IMHO, the IP layer does not know what an application flow is. It doens't 
knwo how the application set different bits and what it is more it 
doesn't have to know.
The flow label is a handle for the IP layer to know what a flow is. 
Making the IP layer second guess what a flow is, is not the best idea.
So, while you see the division MN/CN, i am concerned in the divsion IP 
layer/app layer

> elegantly and powerfully, if you do not mind me saying so ;-)
well, i do mind.

as defined in the draft

   Offset

      The Offset field identifies an integer number of bytes from the
      beginning of the IP header.  It points to the beginning of the
      field of interest in the packet.

So, suppose that the idea is to use application layer bits.
Now what happens if the IP layer adds an extension header or an option 
inside a header?
What happens if the TCP inserts one option?
What happens with applications that we don't know the format (such as 
skype)?

> capability, beyond a somewhat academic issue of regular IP routing
well, here i guess we disagree. including application data bit pattern 
in mip signalling doesn't seem the best architecture to me. Layer 
violation seems at least one issue here

Regards, marcelo

---

From: <[email-masked]>
Date: Mon, 18 May 2009 19:06:28 +0200

Isn't the HA strictly routing and signaling, not verifying packets belong to a flow? Other functions handle that duty already. If so, the HA flows should be within scope of L3 routing, and the HA's signaling plane.

Kind Regards,
Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext George Tsirtsis
Sent: 18 May, 2009 17:17
To: marcelo bagnulo braun
Cc: mext
Subject: [MEXT] about the nature of "flows" Re: weird idea about flow bindings

Marcelo,

I think one issue in this discussion is that the use of the term "flow" in flow bindings in the flow bindings and flow description drafts, is currently a bit wider than that used in flow labels. Flow bindings, with any of the filter description formats discussed (text or binary) should be more accurately described as "packet filter rule binding".

In other words, all our filter descriptions so far, have taken the view that the MN should have as much flexibility in identifying "flows" (or more accurately "filter rules") as a regular packet classifier e.g., firewall. You seem to think this is a bad idea and that only IP layer (and possibly transport layer?) fields should be used in the context of flow bindings.

Am I right so far?

I think that in the extreme, one could go further and say that packet routing should really be ONLY based on IP Addresses. Anything else is mostly broken since it can never scale and it is not compatible with regular IP routing. I am actually sympathetic to this view of the world in which it requires that the MN uses a different source address for every "flow" it wants to be able to route separately. Then flow bindings are simply implemented by redirecting the various MN addresses used to the different CoAs of the MN.

The flow label, however, is IMO mostly an inadequate field to use for flow bindings. This is because a given MN has no control over when and how a given CN uses the flow label. Flow Bindings allow the MN to affect the 'last hop routing' of packets going from the HA to itself.
It makes no sense to me for the MN to have to rely on the use of what is basically an optional field by random 3rd party nodes.

In contrast, the flexibility provided by the binary flow description as you know is mostly about IP layer and Transport Layer fields, which I think are the minimum required to provide effecting flow binding capabilities. The recent addition of the Pointer idea simply expanded the capabilities to random upper layer field matching, I believe very elegantly and powerfully, if you do not mind me saying so ;-)

Still, I think it is valid to question whether such higher layer matching capability is a good thing architecturally. As of yet, however, I am not sure I see what the issue is with providing such capability, beyond a somewhat academic issue of regular IP routing compatibility.

As a side note, I have no problem whatsoever requiring that HAs perform deep packet inspection as the binary flow description draft requires. Commercial HAs are able to perform packet filter inspection, and are actually expected to do so, for other needs already (firewalling, lawful interception, value-add bells and whistles etc) so I do not see any issue there. Note that the use of Pointers for such deep header inspection is trivial compared to other methods since it does not require that the HA understands the upper layer header formats. It simply moves to byte X and matches Y number of bytes. On the MN side things are different and as I explained the complexity on the MN side is implementation specific.

George

On Sun, May 17, 2009 at 11:34 AM, marcelo bagnulo braun <[email-masked]> wrote:
>> Flow Movement is supposed to work in combination with DSMIPv6. Are
>> you suggesting the flow bindings should only work for IPv6 traffic then?
>>
>
> no, i ma suggesting that for IPv6 traffic, we should use the flow
> label for ipv4, we certainly need to use something else What i am not
> buying is that we cannot build a method that relies in the flow label
> cause IPv4 doesn't support it. In other words, i think it is perfeclty
> ok to build our reccomended method relying on the usage of the flow
> label, and define some other hacks to support ipv4.
>>
> So, only the application knows what really a flow is. And IPv6 does
> provide the means for the application to signal the packets that
> belong to flow to the IP layer i.e. the flow label.
> In other words, this is a fundamental problem: IP does not knows about
> flows and we are trying that MIP which is in the IP layer to discriminate flows.
> We can either try the IP layer to guess what are the common bits of a
> flow or we can leverage on the explicit definition of a flow, which is
> what the flow label is for.
>>
>> Also note that flow labels are source address specific so the flow
>> label by itself is not sufficient.
>>
>>
>
> arbitrary bits in the application data. I think this is not the right
> way to do it. I don't think the IP layer should be snooping into
> application data bits
>
> well, you can do this based on the protocol field of the IP header As
> i stated in my earlier reply to Hesham, i don't have a problem with
> using any IP header fields as flow descriptors and i may be ok with
> sing the transport header bits (not what i would preffer, but hey, you
> can't always get what you want) My problem is with supporting
> application data bits as part of the flow description, which i really
> think is broken
>
> Makes sense?
>
> Regards, marcelo
>
>
>> George
>>
>>
>>>> Hi Marcelo, I now understand what you propose better. and it makes
>>>> more sense than I initially thought.
>>>>
>>>> Two issues, though:
>>>>
>>>> It is not clear to me that even if all nodes populated the flow
>>>> label (which I think is not even true)
>>>>
>>>
>>>> , its use would be universally consistent in a way that would
>>>> ensure that the setting of the flow label by the CN would be inline
>>>> with what the MN would like to identify as a flow.
>>>>
>>>
>>> that would determine the granularity of the method I am not sure the
>>> spectrum of choices is so big that this can be a problem could you
>>> think of some very different criteria to define what a flow is that
>>> this would be an issue?
>>>
>>>>
>>> i don't buy this argument. If we apply this argument, then we could
>>> never use the flow label for anything, since it doesn't work for IPv4.
>>>
>>> Reagrds, marcelo
>>>
>>>
>>>>
>>>> Thoughts?
>>>> George
[email-masked]

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 18 May 2009 13:06:50 -0400

inline...

>> used in the context of flow bindings.

GT> Just to make sure we are on the same page, do you agree that flow
label is not sufficient, and that other IP and transport layer fields
need to be used too? i.e., are you only against adding the Pointers to
binary filter rules? or you want to limit the fields used further?

> not really, the flow label is explcitly there to provide special treatment
> to flows. Same with the traffci class bits. It is perfectly ok to use those
> a part of the routing decisions imho

GT> classification is different from routing. Do you know many routers
(beyond lab experiments on QoS routing) that use Flow Labels or even
DSCPs for routing? In any case I was making an "extreme"  argument. Of
course I think it is ok to use flow labels for routing .... but I
think it needs to be combined with other fields too.

> knwo how the application set different bits and what it is more it doesn't
> have to know.
> The flow label is a handle for the IP layer to know what a flow is. Making
> the IP layer second guess what a flow is, is not the best idea.

GT> I agree. All this, however, is supposed to become known to the MIP
layer via an API...no one expects the MIP engine itself to figure
these things out.

>> elegantly and powerfully, if you do not mind me saying so ;-)

GT> OK, shameless self-promotion did not pan-out :-)

> Now what happens if the IP layer adds an extension header or an option

GT> It is a matter of identifying the start of the offset at an
appropriate place e.g., at the end of IP header and all options.

> What happens if the TCP inserts one option?

GT> OK, maybe the offset should start at the end of the transport
layer header :-)
Joking aside, this is trivial; I remind you that these offset-based
pointers have been used in packet classifiers in the field for many
years....not really my idea. The only case it does not work is when
e2e security is used (e.g. IPSEC), in which case of course only IP
layer fields can be used for classification.

> What happens with applications that we don't know the format (such as

GT> But that's the whole point of the Pointers. You do not have to
know! It is the Skype app that would have to use the API to set-up an
appropriate Pointer.

> well, here i guess we disagree. including application data bit pattern in
> mip signalling doesn't seem the best architecture to me. Layer violation
> seems at least one issue here
>

GT> As I said, I think you are making a valid argument for discussion.
I would in fact be willing to consider dropping the Pointers from the
binary flow description draft as long as "flexibility" is not used as
an argument when comparing it to text based flow description; remember
this was the main reason the Pointers where added to the draft in the
first place.

George

>>> provide
>>> flows
>>> flow
>>>>> never

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 18 May 2009 21:02:41 +0200

George Tsirtsis escribió:
> label is not sufficient,

flow label is clearly not sufficient since at least the src and dst 
address are also needed
but i am ok with using any IP layer information
I am not so comfortable with transport information, but as is stated 
earlier, i guess i can live with that
>  and that other IP and transport layer fields

just the pointers

> Joking aside, this is trivial;
i don't know if i would call it trivial.
I tcan certainly be done, (and it is done in DPI) but that doesn't make 
it easy or a good idea.
Making the IP layer to understand the trasnport options and app data bit 
patterns still doesn't sound like a good idea to me

>  I remind you that these offset-based
mmm, i don't follow this.
suppose i own a PDA and i want that the skype traffic is routed through 
my GPRS link. How do i configure my PDA to do so? Skype won't do it for 
me. So we have two options. Wait for skype to support the flow binding 
API or wait for te OS to properly set a random flow label. I really 
think the second is more reasonable.

> this was the main reason the Pointers where added to the draft in the
mmm, i have even more issues with any other flow language descriptors 
that enter even more into the app land.

Regards, marcelo

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 19 May 2009 09:23:53 +1000

George, 

One comment here.

> binary filter rules? or you want to limit the fields used further?

=> The only reason IMO the flow label is not sufficient on its own for a
spec right now is that it's not used. If it were used as specified then it
would in fact replace upper layer information. That's what it is designed to
do.

Hesham