Re: Detailed approaches for demux

[Steven Blake <slblake@petri-meat.com>]

On Sat, 2005-04-30 at 11:09 +0200, marcelo bagnulo braun wrote:

[snip]

> Demux at the receiver side is performed based on (flow label, src, dst)
> 
> The problem is what happens when a host run out of available flow label 
> values and need to start repeating. Note well that this happens when 
> the host has 1.048.576 (2^20) simultaneous communications.
> 
> If a repeated value is used in a communication with a different node, 
> then no problem, since the addresses will never collide.
> 
> So, the first measure to avoid problems is to avoid re-using flow label 
> values for communications with the same host whenever is possible.
> However, this is not always possible because the initiator may not be 
> aware that two communications are established with the same node.

Ignoring shim6 for a moment: a host that may have more than 2^20 active
connections can generate additional addresses (e.g., by synthesizing
additional IIDs) on an interface, and avoid ever having two or more
active flows sharing the same <S, Fl> tuple.

> So, the problem occurs when the same value is used for the same host.
> This may occur because the initiator may not be aware that two 
> different addresses belong to the same receiver.
> For example, consider the following case:
> I establishes a communication with R1 using S1 as source address and 
> assigns the flow label value f1.
> Next, I runs out of flow label values, and need to start repeating 
> values.
> At this point, I establishes a communication with R2 using S2.
> Since the Destination address R2 has not been previously used, I has no 
> means to know that is the same host, so I assigns the flow label value 
> f1.
> When the SHIM contexts are established for each of the communications, 
> the resulting contexts are:
> 
> SHIM context for the first communication:
> ULIDs: I1,R1
> Flow Label: f1
> Locator set for I1: I1,...,In (or a subset)
> Locator set for R1: R1,...,Rj (or a subset)
> 
> SHIM context for the second communication:
> ULIDs: I2,R2
> Flow Label: f1
> Locator set for I2: I1,...,In (or a subset)
> Locator set for R2: R1,...,Rj (or a subset)
> 
> The problem is that the tuple (flow label, src, dst) does not provide 
> enough information for proper demux
> 
> The possible solution for this is not to allow overlapping locator sets 
> when the same flow label value is being used in the two contexts.
> This means that in the previous case, when the context are established, 
> the nodes avoid adding locators to the locator sets that would result 
> in overlapping src,dst address pair combinations.
> 
> So, if we apply this to the previous example, the result is:
> 
> First communication: I1,R1
> 
> Second communication: I2,R2
> 
> At some point, I decides to create a SHIM context for the first 
> communication, so it proposes through SHIM signaling, the following 
> context parameter:
> 
> ULIDs: I1,R1
> Flow Label: f1
> Locator set for I1: I1,...,In
> 
> Upon reception of such information, the receiver R replies proposing 
> the following locator set for the context:
> 
> Locator set for R1: R1,R3...,Rj  (R2 is not included so that I2, R2 is 
> not valid combination for this context)
> 
> Next, the initiator establishes the SHIM context for the second 
> communication, proposing the following parameters:
> 
> ULIDs: I2,R2
> Flow Label: f1
> Locator set for I2: I1,...,In (or a subset)
> 
> At this point the receiver replies proposing the following locator set:
> 
> Locator set for R2: only R2 because all the remaining combinations are 
> included in the SHIM context of the first communication.
> 
> Through these means, proper demux can be guaranteed.
> 
> I think this provides proper demux functions.
> The problems that i see with this approach are:
> - Complexity
> - In some corner cases, some communications will end up with limited 
> fault tolerance because of a reduced set of locators.

I believe that this analysis is correct.  But if a host always generates a
complete (in terms of available prefixes) set of locators for every 2^20
active connections, and never reuses flow label values across these sets 
(i.e., keeps <IID(S), Fl> always unique) , then the complexity is tractable
and fault tolerance is not impacted, because the number of usable locators in
a shim6 context is not reduced.


Regards,

// Steve