Re: [tram] SSODA in TURN-bis
Justin Uberti <juberti@google.com> Thu, 08 January 2015 20:23 UTC
Return-Path: <juberti@google.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21AD1A1A73 for <tram@ietfa.amsl.com>; Thu, 8 Jan 2015 12:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.387
X-Spam-Level:
X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xXKZrgb095qE for <tram@ietfa.amsl.com>; Thu, 8 Jan 2015 12:23:39 -0800 (PST)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1551A1A5E for <tram@ietf.org>; Thu, 8 Jan 2015 12:23:38 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id hy4so1922843vcb.2 for <tram@ietf.org>; Thu, 08 Jan 2015 12:23:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9qoSzTRIu/s+ZgoNKQdUhM6fDcNVbiQZnZQY81CL+C8=; b=AFcwu6Gfr+F6SDJX6Ln806tozLQJqhMGA9A6ToUu6nE2ge9acFJvY+2enk656PuXbS YzFqj2xRBFNCrUYF5GZhKdhIXeUQIEwC3rH57WTEiX2o1FBqFqyPFhq4wlJxFgGl2pGn 7Ilyh+PJAmnanzF2YCLXEgeDqVOYPVbT8VoFgzonRvoa/Pu1+OrBFnH34oQachL0QLwC 4FHbAtpdwmooe89tdRFbr20VPTEkaavUCJ7ix1pJSVAOqzlgIL8TjmpiJOG2Q821Us7l SlInUvnQXbRs7yY4gpEyZc8ewMOEQ4IEib0kotsYzpIuJyuZdRGBnMz05Jch2j+95bD2 jvzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9qoSzTRIu/s+ZgoNKQdUhM6fDcNVbiQZnZQY81CL+C8=; b=eh4Sn6bouk1S7y7i3bbrmR62A+jsWENBX548Jbkg/ZFkN21xROv2/uprd/7+tWTsRi fABGPredkiyMeWys6HvhsSkSqUcZd/RgxvmS7yEyXiFg1xkvL467cjVsRoE+fTrbkIFT wWSVy/7hTnGBb0JutAE9Cy3cyYcbF0RtX11o0PAAerDdNcm/0MasSz3u/YsSdm6HJTZv BRAHP2b0vTP6nemAiQORdAosUeQiXK7sEd0w1gHr7DafJFM/2r95YzuXXwcmoA7guaK5 sBJcjW9h8iUl//cCQhJIJ6eX2paqUCr9I4yFn+kA2IkcVKdJCl6LN7Kfw52Hgelv0fhw KJeA==
X-Gm-Message-State: ALoCoQkKgNpqlJ7O9FVDk++vEVmTy18MOZtLCgMUuz9eanr9UQm2lqBp/COGhSCEUTR4y1ubg1fw
X-Received: by 10.53.12.139 with SMTP id eq11mr6985323vdd.58.1420748617944; Thu, 08 Jan 2015 12:23:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 12:23:17 -0800 (PST)
In-Reply-To: <00b201d02b12$c0ca8d50$425fa7f0$@org.cn>
References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <CAOJ7v-2RVPm=7eWaw05Um6kysbp=1Ch5KQ_me4Q4XXyE4jaTkA@mail.gmail.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn>
From: Justin Uberti <juberti@google.com>
Date: Thu, 08 Jan 2015 12:23:17 -0800
Message-ID: <CAOJ7v-0HNYpYcE5a1XUH-AiL_hPeTCDHj0i+=A5M7owkMFjjgQ@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Content-Type: multipart/alternative; boundary="001a1134a3f2b02ea1050c29d047"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/N1fL5L8HNIMEXD5N6MdWEo7mSIg>
Cc: "tram@ietf.org" <tram@ietf.org>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Subject: Re: [tram] SSODA in TURN-bis
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 20:23:42 -0000
On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote: > Hi, Justin, > > > > Is it more straightforward to define one new attribute that named > “Additional-Address-Family ” instead of the R-A-F and > OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this attribute > will be assigned the relay address that is the same type as seen from the > source address of “Allocate Request” packet, not default in IPv4 relay > address. > I suppose this could be a third option (c), in addition to (a) multiple R-A-F and (b) multiple optional-a-f. Here's how a/b/c look on the wire when requesting v4+v6 simultaneously. If requesting v4 or v6 only for some reason, a/b/c would all send a single RAF. a: RAF (v4) + RAF (v6) a1: server is 5766: error (RAF required-comprehension but unknown) a2: server is 6156: v4 address, or error (undefined behavior) a3: server is SSODA: v4 address + v6 address b: OAF (v4) + OAF (v6) b1: server is 5766/6156: v4 address (OAF ignored) b2: server is SSODA: v4 address + v6 address c: AAF (v6) c1: server is 5766/6156: v4 address (AAF ignored) c2: server is SSODA: v4 address + v6 address Note that for c), one could send RAF(v4) + AAF(v6), but since that would fail on a 5766 server, sending just AAF(v6) would be preferable. Note that for b), if one sent OAF(v6) by itself for some reason, a 5766 server would return a v4 address, which is slightly inelegant. For either b/c, we would need to say that including both RAF and OAF/AAF for the same address family is prohibited. b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the default AF), but feels a bit more complicated than c). I am supportive of either b)/c), with maybe a slight preference for c). > > For reducing the port resource consumption on TURN server that described > in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have > another proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ > that can mitigate the ip address/port allocation burden on TURN > server------All endpoints that under one TURN server can use the same > IPv4/IPv6 relay address/port. > The port consumption is a side benefit; the primary benefit of SSODA is the reduction in the overall number of candidates. > > > Best Regards. > > Aijun Wang. > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Thursday, January 08, 2015 12:02 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* [SPAM] Re: [tram] SSODA in TURN-bis > > > > I promised I would write up a summary of the current mechanism, and what > we could do instead, so here goes: > > > > The currently documented mechanism is to send two R-A-F attributes in the > request, and get back either a single address (from legacy servers), v4 + > v6 addresses (from new servers), a single address + a 0.0.0.0/:: (for new > servers that only support one address family), or an error-code (to > indicate complete failure). > > > > At the time, there were 2 concerns listed, namely: > > 1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may > fail the request completely, or do other weird things. > > 2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; > specifically, detailed error information cannot be included. > > > > I also thought of a 3rd problem: > > 3) an old(5766) server may fail the request completely, due to the fact > that R-A-F is comprehension-required. Thus an extra roundtrip may be needed > in this case, negating one of the benefits of SSODA. > > > > I think the ideal solution to #1/#3 is to add a new > OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but > comprehension-optional, where multiple values are explicitly supported. Old > servers can safely ignore this and will return IPv4 (solving #3), while new > servers can process this to return multiple XOR-RELAYED-ADDRESSes in the > response. > > #2 is not a serious issue, but it could easily be solved by defining a new > ADDRESS-ERROR-CODE as follows: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Address Family | Rsvd |Class| Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reason Phrase (variable) .. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Then a server could return a normal IPv4 address, but a error code for IPv6 with either 440 (unsupported address family) or 508 (insufficient capacity) or some other TBD error. > > > > I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple and prevents potential interoperability problems with old servers. I could go either way on ADDRESS-ERROR-CODE. > > > > > > > > On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi all, > > > > We are working on incorporating RFC6156 and SSODA into TURN-bis. During > IETF-91 meeting there was discussion if the technique proposed in > https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break > existing TURN server implementations. Pal had mentioned testing with four > implementations and did not face any problem. > > > > Please let us know if there are any concerns with the existing proposal of > conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute > values in Allocate request ? > > > > Cheers, > > -Tiru > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > >
- [tram] SSODA in TURN-bis Tirumaleswar Reddy (tireddy)
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Aijun Wang
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Tirumaleswar Reddy (tireddy)
- Re: [tram] SSODA in TURN-bis Aijun Wang
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Aijun Wang
- Re: [tram] SSODA in TURN-bis Simon Perreault
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Ca By
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Tirumaleswar Reddy (tireddy)
- Re: [tram] SSODA in TURN-bis Pal Martinsen (palmarti)
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Pal Martinsen (palmarti)
- Re: [tram] SSODA in TURN-bis Tirumaleswar Reddy (tireddy)
- Re: [tram] SSODA in TURN-bis Aijun Wang
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Justin Uberti
- Re: [tram] SSODA in TURN-bis Aijun Wang
- Re: [tram] SSODA in TURN-bis Oleg Moskalenko
- Re: [tram] SSODA in TURN-bis Justin Uberti