Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 01 June 2018 23:45 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DBF12E045; Fri, 1 Jun 2018 16:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 YbNoqjOg2TDp; Fri, 1 Jun 2018 16:45:21 -0700 (PDT)
Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C493412E03F; Fri, 1 Jun 2018 16:45:21 -0700 (PDT)
Received: by mail-yw0-x241.google.com with SMTP id j190-v6so8688531ywe.4; Fri, 01 Jun 2018 16:45:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=US60cfYP+IwpKF6wCAJBNpfq2LPFZReY/cjjHSxf6KY=; b=gqld/GVQKp4DrxYfPAHHWYRDDcOWMrvlL7Bw9sEiXr/9wTeISuNi+RRpnAt1Ib+sTW tgjTpASxGLVSZbSo4AxOAyBU5w/2LEPGtUNyP0k0pPalFqssP6zQYruaFXifJNMuflRP JM/rfB34wFifBWIogFlKw3LkQLR2H7rj+qIjp14zpoWiuO8C68PurkymyeBbaYyJVE21 vQqzhgr+BJ2osSE4BQ77cslDQT9gIdp3Csdp2IwrBFlo6tdwIYB++M6AUwBz9jK27nzs zONQBoS+Ba9+Jzrwfj88EONFm6m8J0ub3BDsekVkrYH9fke17nHFa0S4bLBKuFx29kgB nmmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=US60cfYP+IwpKF6wCAJBNpfq2LPFZReY/cjjHSxf6KY=; b=c+4v+zmhLjTv9ApRrg3z7UHjfdcZ/tCJuoR/rjb1ctXQ1dCQyoy49NMOXioLcjMErR QYZw+K8gDRKht2YI8OikVAciBcWwwNzfNyiHwVHXg8vM2EXi04Y6gEvz96YTlIucqdDT 1EIPCXem30bmy5215U2t8m6W0/bke77O/1T1237LioJXZ3+RuBV80kdPD4Bo50WZwH1Z ic4VN1umHOMYj9MC/ImNeKvtbFgwlhsDuG+nZ8dyXbSuH4LmGoQ5OYi/6Px/kakRQlKK CP4DDgfM/q6kNg9HgNVtyuIaC13KSzIqmJQ7RBzrRMzFKqGhC78ezBlq6E38ZCnQ30es aVLw==
X-Gm-Message-State: ALKqPweAHA8KhLOGPXFSBImWlWU8qSjsG8q0Xax+epzy1n1MsNd/gneU 2lmcGUkONFx8sjNL+UQKKPzNJfQfoqG8ajF//V4=
X-Google-Smtp-Source: ADUXVKIYGhLTYgm0W+m4NKTAz9bGwdxzC/+weH+KI/EFOkgJ9bL1+xDmEBs3F5ESiQP1i/9zBd/odgkzAMhiP4N8vtk=
X-Received: by 2002:a0d:ed06:: with SMTP id w6-v6mr6609338ywe.467.1527896720746; Fri, 01 Jun 2018 16:45:20 -0700 (PDT)
MIME-Version: 1.0
References: <152276622276.14060.4683526444260158304.idtracker@ietfa.amsl.com> <d87ca5f9-3b36-d71e-667b-1396ea8a7ee9@gmail.com> <7CED4E17-86D2-407D-AF36-89C075121E9D@kuehlewind.net> <6ce0a44f-cca8-2105-73f5-75689dd8c611@gmail.com> <1A91DAFC-8022-4B11-92F0-E6B7644A7218@kuehlewind.net> <de37b547-e278-4fa5-b28e-70298a414843@gmail.com> <4A9014B4-102A-4894-BA41-1DA49A662D8B@kuehlewind.net> <fb95e318-50b3-fb42-f94a-c78e124af651@gmail.com> <D9BF2D39-0B51-4697-A5F1-5801916F543D@kuehlewind.net> <a702e5b6-c540-77f9-1f08-08d5a5e1feed@gmail.com> <b1d7c7fa-eea5-ae8a-4a10-b7d5f58d6353@nostrum.com> <0a05813f-21ac-43ba-9caa-fa4dc1000914@cisco.com> <CBA18047-8484-44D3-97A0-465D2441EE0E@nostrum.com> <b7cba717-f611-b7ff-6a59-2cc1de1b117a@gmail.com> <CAD5OKxujrAqk-wKkg5ASvRHM0_0NE12z+Np_J98=aBQhVzNcJA@mail.gmail.com> <53a79cff-8bd9-b676-d534-0aca57ce43fe@cisco.com> <2fa03c8a-3a71-e77e-a76c-d78890b51df3@gmail.com> <CAD5OKxsaeOiv=wNKa-F_kZBBW48BVner7kk8=zbM5+MZbGkPMw@mail.gmail.com> <93422207-c1bd-481b-000b-be000c6e2730@nostrum.com> <A2855A45-1741-4BAA-AE6C-9BF539967C00@nostrum.com>
In-Reply-To: <A2855A45-1741-4BAA-AE6C-9BF539967C00@nostrum.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 01 Jun 2018 18:45:08 -0500
Message-ID: <CAKKJt-faDpbfdOx4GepNcHtFC=dUVRKfJ1Xs3N+SxGUTqEkzqA@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: Adam Roach <adam@nostrum.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, mmusic-chairs@ietf.org, mmusic WG <mmusic@ietf.org>, Roman Shpount <roman@telurix.com>, Thomas Stach <thomass.stach@gmail.com>, Flemming Andreasen <fandreas@cisco.com>, The IESG <iesg@ietf.org>, draft-ietf-mmusic-trickle-ice-sip@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004b2fcb056d9d2d8b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/sI7281-pWV5CEegncSM1Rrvej5Y>
Subject: Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2018 23:45:25 -0000
My co-AD is off the net this week - she is back on next week, I believe. Silence is not a reflection of AD response to the proposed text. Spencer On Fri, Jun 1, 2018, 16:29 Ben Campbell <ben@nostrum.com> wrote: > +1. > > Mirja: does Roman’s proposed text (below) work for you? > > Thanks! > > Ben. > > > On May 31, 2018, at 2:37 PM, Adam Roach <adam@nostrum.com> wrote: > > > > Of the solutions proposed so far, this is the one I like the most. > Thanks, Roman. > > > > /a > > > > On 5/31/18 2:11 PM, Roman Shpount wrote: > >> Thomas, > >> > >> One slight correction: > >> > >> "Implementors MUST aggregate ICE candidates in case that unreliable > transport protocol such as UDP is used. A Trickle ICE agent MUST NOT have > more than one INFO request pending at any one time. > >> When INFO messages are sent over an unreliable transport, they are > retransmitted according to the rules specified in RFC3261 section > 17.1.2.1." > >> > >> Regards, > >> > >> _____________ > >> Roman Shpount > >> > >> On Thu, May 31, 2018 at 3:06 PM, Thomas Stach <thomass.stach@gmail.com> > wrote: > >> Hi, > >> > >> I'd be also OK with Roman's Proposal and go ahead with the following > text: > >> > >> "Implementors MUST aggregate ICE candidates in > >> case that UDP is used as transport protocol. > >> A Trickle ICE agent MUST NOT have > >> more than one INFO request pending at any one time. > >> When INFO messages are sent over an unreliable transport, > >> they are retransmitted according to the rules specified in > >> RFC3261 section 17.1.2.1." > >> > >> I hope that this text is also acceptable for the WG and our ADs. > >> Thanks > >> > >> Thomas > >> > >> > >> On 2018-05-31 16:28, Flemming Andreasen wrote: > >>> Hi > >>> > >>> Did we reach a conclusion on this thread ? If not, what do we need to > move it forward ? > >>> > >>> Thanks > >>> > >>> -- Flemming > >>> > >>> On 5/22/18 5:11 PM, Roman Shpount wrote: > >>>> On Tue, May 22, 2018 at 4:07 PM, Thomas Stach < > thomass.stach@gmail.com> wrote: > >>>> E.g. something like: > >>>> > >>>> "Implementors MUST aggregate ICE candidates in > >>>> case that UDP is used as transport protocol. > >>>> It is RECOMMENDED that Trickle ICE implementations > >>>> implement a way to estimate the round-trip time (RTT) > >>>> and send only one INFO request per estimated RTT. > >>>> If the RTT is unknown, a Trickle ICE agent MUST NOT have > >>>> more than one INFO request pending at any one time. > >>>> In case of re-transmissions a Trickle-ICE agent needs to adhere to > the default SIP > >>>> retransmission schedule resulting in intervals of 500 ms, 1 s, 2 s, 4 > s, 4 s, 4 s, etc." > >>>> > >>>> > >>>> I think it should be enough to require that a Trickle ICE agent MUST > NOT have more than one INFO request pending at any one time. Requiring only > one request in progress will also deal with remote proxy or client overload > more gracefully. RTT is likely not a right measure here since INFO message > can traverse multiple proxies and RTT would need to include transport > delays between the proxies as well as proxy processing delay. > >>>> > >>>> Also, there is no need to specify how normal SIP re-transmission > works, especially as it can be interpreted that you disallow modification > of SIP timer values when trickle ICE is used or modify RFC 3261 in some > way. I think it would be better simply state that when INFO messages are > sent over an unreliable transport, they are retransmitted according to the > rules specified in rfc3261 section 17.1.2.1 ( > https://tools.ietf.org/html/rfc3261#section-17.1.2.1). > >>>> > >>>> Finally, is it allowed to cancel (stop transmitting) the current INFO > request with ICE candidates and start a new INFO request with new candidate > set if new candidate is discovered while INFO message is being transmitted? > My assumption is that it is not allowed. > >>>> > >>>> Regards, > >>>> _____________ > >>>> Roman Shpount > >>>> > >>>> > >>> > >> > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > >
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Flemming Andreasen
- [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-… Mirja Kühlewind
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Thomas Stach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Spencer Dawkins at IETF
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Thomas Stach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Thomas Stach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Thomas Stach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Thomas Stach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Adam Roach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Ben Campbell
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Flemming Andreasen
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Ben Campbell
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Flemming Andreasen
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Thomas Stach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Roman Shpount
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Flemming Andreasen
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Thomas Stach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Roman Shpount
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Adam Roach
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Ben Campbell
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Spencer Dawkins at IETF
- Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-i… Ben Campbell