Re: [Softwires] MAP draft 11 question on fragment ID space reduction
Andrew 👽 Yourtchenko <ayourtch@gmail.com> Thu, 16 October 2014 11:12 UTC
Return-Path: <ayourtch@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458B61AD047 for <softwires@ietfa.amsl.com>; Thu, 16 Oct 2014 04:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YstCOSahVLKz for <softwires@ietfa.amsl.com>; Thu, 16 Oct 2014 04:12:05 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8801AD010 for <softwires@ietf.org>; Thu, 16 Oct 2014 04:12:05 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id ar1so3064860iec.24 for <softwires@ietf.org>; Thu, 16 Oct 2014 04:12:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pIW8AGRafvAXeUiZrVsf/myubajFzMg43E9U967EVCc=; b=wz7Kkbtt0LmEiPZzYQ/a16rWxoqFCVzcLN5W2GkvTTAEhsaUbU08ELuaajrOXs3JlK KLw2t6UjPe1qdEUwK6uKKOP7VH0Rf9enK4aAd+K5lT8rRuumghKoMkOpL5yhiVKsNp+A eLyKhZAnx5kLBKfhDEEDis05YJKEsiW5LMGPqrOxHpoJBnrukS2ZzOkdQaBf3P0fn4VY fOfptN+vdH0UJJjctjFGb9AqAwMTObG/wS/GaRqomOAQCpO6TXhc3mAF1UW5JmKLw9kM JsY0a09MC3HkIqtuTiekIRgE60jklLpjFag8MSzCFi7NsHAXkX4WwxL8rhWsQXv2mkJo y9Eg==
MIME-Version: 1.0
X-Received: by 10.107.27.2 with SMTP id b2mr747581iob.70.1413457924644; Thu, 16 Oct 2014 04:12:04 -0700 (PDT)
Received: by 10.107.137.231 with HTTP; Thu, 16 Oct 2014 04:12:04 -0700 (PDT)
In-Reply-To: <25A95528-FA71-48C6-B238-D5D90B99386B@laposte.net>
References: <CAPi140MdbJQBLSRS+g4Jx0G1zm1dx6PLBBQ7oPeALU2z-Vp81g@mail.gmail.com> <A9F4CC49-3409-482E-8DD1-D60770719370@employees.org> <365F683D-89D6-4A42-B9F1-780453D9C1A5@nominum.com> <D14390B1-8628-4372-B664-A5EA82BE0327@employees.org> <25A95528-FA71-48C6-B238-D5D90B99386B@laposte.net>
Date: Thu, 16 Oct 2014 13:12:04 +0200
Message-ID: <CAPi140P5FWm7onve7ibHwYC=d3-k1TEnV0LbZmM1jaY+EWwVPg@mail.gmail.com>
From: Andrew 👽 Yourtchenko <ayourtch@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/k1pUVnOqwen_Q1RwCLXA2I5ENTE
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] MAP draft 11 question on fragment ID space reduction
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2014 11:12:07 -0000
Hi Remi, On 10/16/14, Rémi Després <despres.remi@laposte.net> 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 <otroan@employees.org> 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 <Ted.Lemon@nominum.com> wrote: >>> >>> On Oct 14, 2014, at 5:01 AM, Ole Troan <otroan@employees.org> 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 >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >
- [Softwires] MAP draft 11 question on fragment ID … Andrew 👽 Yourtchenko
- Re: [Softwires] MAP draft 11 question on fragment… Ole Troan
- Re: [Softwires] MAP draft 11 question on fragment… Ted Lemon
- Re: [Softwires] MAP draft 11 question on fragment… Rajiv Asati (rajiva)
- Re: [Softwires] MAP draft 11 question on fragment… Ted Lemon
- Re: [Softwires] MAP draft 11 question on fragment… Joe Touch
- Re: [Softwires] MAP draft 11 question on fragment… Ole Troan
- Re: [Softwires] MAP draft 11 question on fragment… Rémi Després
- Re: [Softwires] MAP draft 11 question on fragment… Andrew 👽 Yourtchenko
- Re: [Softwires] MAP draft 11 question on fragment… Ted Lemon