Re: [Softwires] MAP draft 11 question on fragment ID space reduction

[Andrew 👽 Yourtchenko <[e-mail]>]

Hi Remi,

On 10/16/14, Rémi Després <[e-mail]> wrote:
> Hi, Ole,
>
> FWIW, a look at
> https://tools.ietf.org/html/draft-ietf-softwire-4rd-09#section-4.6.3 might
> be helpful.

This is exactly the problem. You replace the problem of a highly
visited destination (for whom the natural path is to deploy IPv6
anyway and bypass the whole transition mechanism?) having potential
for reassembly errors with a problem of N-fold increased fragment
collision probability on *all* streams, where N is your share ratio,
and which side of this tradeoff is worse is unclear to me - both are
bad in different ways.

Fortunately, since CGNs provide a higher sharing ratio of addresses
(and they can't possibly rewrite the IDs because they do not have a
deterministic algorithm), and are much more widely deployed than any
of the tech we are discussing, we should have already hit this problem
in real life many times over ? Any feedback on this ?

--a

>
> Cheers,
> RD
>
>
> Le 15 oct. 2014 à 15:27, Ole Troan <[e-mail]> a écrit :
>
>> Ted, et al,
>>
>> there are good arguments going both ways, so apologies for my changing
>> opinion here. ;-)
>>
>> we could go with the hand-wavy, there is a problem here, we don't have a
>> good solution:
>>
>>       <t>If two IPv4 host behind two different MAP CE's with the
>>       same IPv4 address sends fragments to an IPv4 destination host
>>       outside the domain, those hosts may use the same IPv4
>>       fragmentation identifier, resulting in incorrect reassembly of
>>       the fragments at the destination host. Given that the IPv4
>>       fragmentation identifier is a 16 bit field, it could be used
>>       similarly to port ranges. A MAP CE could rewrite the IPv4
>>       fragmentation identifier to be within its allocated port-set,
>>       if the resulting fragment identifier space was large enough
>>       related to the rate fragments was sent. However, splitting the
>>       identifier space in this fashion would increase the
>>       probability of reassembly collision for all connections
>>       through the CPE. See also <xref target="RFC6864"/></t>
>>
>> the alternatives are that we could say, since the problem of multiple CPEs
>> with same IP address sending fragments to same destination required
>> coordination that if the fragment id space was say 10 bits, then rewrite.
>> or we could go even further and say that the CPE would have to throttle
>> traffic to ensure that the id space didn't cycle within the reassembly
>> timeout.
>> or we could drop the text altogether.
>>
>> my preference would be the above proposed text. it has the problem
>> description but it doesn't prescribe a solution.
>>
>> any other opinion?
>>
>> ps: whatever solution we have here should probably also apply to the other
>> mechanisms. e.g.
>> https://tools.ietf.org/html/draft-ietf-softwire-4rd-09#section-4.6.3
>>
>> cheers,
>> Ole
>>
>>
>>
>>> On 14 Oct 2014, at 15:32 , Ted Lemon <[e-mail]> wrote:
>>>
>>> On Oct 14, 2014, at 5:01 AM, Ole Troan <[e-mail]> wrote:
>>>> splitting the fragment id space so that there is only a single bit per
>>>> CPE sounds like a corner case that should be disallowed. I don't know if
>>>> we have the knowledge to be able to specify exactly how much of the
>>>> fragment id space is safe to split up though.is it 4, 6, or 8 bits?
>>>
>>> There's a lot to think about here.  The fragment ID translation algorithm
>>> probably needs to maintain a cache so that it doesn't accidentally
>>> overload fragment IDs.   The set of all outstanding fragments has the
>>> potential to be larger than the set of all ports in use, so there is
>>> definitely reason to be concerned about shrinking the fragment ID space.
>>>  However, shrinking the fragment ID space _does_ serve the useful purpose
>>> of isolating fragment ID collisions to the nodes that are supposed to be
>>> receiving the fragments.
>>>
>>> It may be that the right thing to do is to note that this is a problem,
>>> make a recommendation, but essentially leave it as future research, since
>>> we really haven't analyzed the problem in enough depth to make an
>>> informed recommendation.
>>>
>>>> if changing back to SHOULD from the MUST would lead people to accept
>>>> that we leave the exact recommendations for further study I would be
>>>> happy to do that.
>>>
>>> So yes, this might be a good way to go.
>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>