Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory

"Stach, Thomas" <thomas.stach@siemens-enterprise.com> Wed, 10 April 2013 07:18 UTC

Return-Path: <thomas.stach@siemens-enterprise.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 9B2C321F8FC6 for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2013 00:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnm7EY2M0BZm for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2013 00:18:47 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF521F8FA5 for <mmusic@ietf.org>; Wed, 10 Apr 2013 00:18:47 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 976CF23F0491; Wed, 10 Apr 2013 09:18:46 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 10 Apr 2013 09:18:46 +0200
From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Emil Ivov <emcho@jitsi.org>
Thread-Topic: AW: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory
Thread-Index: AQHONSYruecfKNfWd0Owxkajp9hYoJjPC6zA
Date: Wed, 10 Apr 2013 07:18:45 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE120E575BEF@MCHP04MSX.global-ad.net>
References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <F81CEE99482EFE438DAE2A652361EE120E5725E2@MCHP04MSX.global-ad.net> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> <515FBA77.1030007@jitsi.org> <F81CEE99482EFE438DAE2A652361EE120E573FA4@MCHP04MSX.global-ad.net> <51633ED7.4080407@jitsi.org> <51641792.2050100@alum.mit.edu>
In-Reply-To: <51641792.2050100@alum.mit.edu>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 10 Apr 2013 07:18:48 -0000

inline

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] 
> Gesendet: Dienstag, 09. April 2013 15:29
> An: Emil Ivov
> Cc: Stach, Thomas; mmusic@ietf.org
> Betreff: Re: AW: [MMUSIC] 
> draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-
> ice - PRACK not mandatory
> 
> On 4/9/13 6:04 AM, Emil Ivov wrote:
> > Hey Thomas,
> >
> > On 08.04.13, 14:15, Stach, Thomas wrote:
> >> I agree, that Paul has a good point.
> >> However, I still do not see a requirement for PRACK.
> >> I would still like to avoid it due to the big debate 
> during development of ICE that occurred back in IETF64.
> >
> > For those of us who weren't around back then, it would help 
> if you could
> > remind exactly what the reasons were. This way we can decide if they
> > also apply to the trickle ICE case.
> 
> My argument was that without a reliable provisional the UAS can't be 
> certain that the UAC has established an early dialog, and 
> without that 
> the UAC can't trickle using INFO.
> 
> Thinking further, *if* the UAS keeps retransmitting the unreliable 
> provisional until it receives some ICE messages then things may work. 
> But in the case of trickle ICE this might effectively mean 
> that it must 
> keep retransmitting until it receives an INFO with additional 
> candidates, 

... or if the UAS receives a 200 OK (instead of 481) for an INFO request. 
That would also indicate that the 18X was received and the early dialog was established.

Regards
Thomas

> because none of the initial candidates may be usable.
> 
> 	Thanks,
> 	Paul
> 
> >> Once the UAS has sent the 183 there is an early dialog.
> >> Of course the 183 can be lost, such that UAS and UAC are 
> out of sync with respect to the dialog state.
> >>
> >> Now, RFC5245 specifies (in case PRACK is not used) that 
> the provisional response is retransmitted
> >> with the exponential backoff timers. I want to keep this 
> behaviour also for trickle ICE because now
> >> the UAC will eventually receive one of the retransmissions 
> and could also send trickled candidates.
> >
> > Not necessarily. The UAC may be performing half trickle in 
> which case it
> > won't be sending anything else.
> >
> >> Interesting is of course what happens with the INFO if the 
> UAC has not yet received a provisional response.
> >> I would expect receipt of a 481 response to the INFO 
> request since the UAC does not yet know about the dialog.
> >> This 481 could trigger at the UAS the immediate 
> retransmission of the provisional response
> >> in order to establish the early dialog. Then, the INFO 
> could also be retransmitted.
> >
> > This could indeed work and it could potentially help gain 
> almost up to
> > an RTT. Anyone has a problem with it?
> >
> >> Of course you are right.
> >> However, since the INFO can carry arbitrary SDP fragments, 
> you can also include ufrag and password
> >> and any of the other ICE attributes.
> >
> > I didn't mean to imply you couldn't, however Paul's 
> comment, discussed
> > above, killed this approach anyway.
> >
> > Cheers,
> > Emil
> >
> >>
> >>
> >> Regards
> >> Thomas
> >>
> >> Emil Ivov wrote:
> >>> On 05.04.13, 21:10, Paul Kyzivat wrote:
> >>>> Note that until at least one provisional response makes 
> it back to
> >>>> the UAC it won't be possible for the UAC to send INFOs. 
> (It can't do
> >>>> so until there is an early dialog.)
> >>>>
> >>>> So its possible that if you only send unreliable 
> provisionals then
> >>>> the trickling from UAC to UAS may not be happen until the call is
> >>>> established.
> >>>
> >>> Great point! So it seems like we are back to mandating PRACK.
> >>>
> >>> What would be the issue with this anyway?
> >>>
> >>> Emil
> >>>
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul
> >>>>
> >>>> On 4/6/13 2:51 AM, Emil Ivov wrote:
> >>>>> Hey Thomas,
> >>>>>
> >>>>> On 05.04.13, 12:04, Stach, Thomas wrote:
> >>>>>> inline
> >>>>>>
> >>>>>> Emil Ivov wrote:
> >>>>>>> Hey Marc and thanks for your comments!
> >>>>>>>
> >>>>>>> Replies inline.
> >>>>>>>
> >>>>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote:
> >>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>>>> Hash: SHA256
> >>>>>>>>
> >>>>>>>> I read draft-ivov-dispatch-trickle-ice-sip and
> >>>>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the
> >>>>>>>> rfc5245bis draft and I have some suggestions that I will be
> >>>>>>>> presenting step by step below:
> >>>>>>>>
> >>>>>>>> 1. The 180 needs to be reliable
> >>>>>>>
> >>>>>>> Agreed. We'll make the change in the next revision.
> >>>>>>>
> >>>>>> The answer with any initial candidates needs to be in 
> a 183 not a
> >>>>>> 180.
> >>>>>
> >>>>> Well 5245 actually talks about 18x but I agree that 
> using 183 rather
> >>>>> than 180 would help manage post pick-up latency better.
> >>>>>
> >>>>>> In addition, I don't think that the 183 needs to be reliable.
> >>>>>> This was not necessary for RFC5245 and could also be
> >>> avoided for trickle ICE, since the
> >>>>>> INFO with the new candidates is already reliably sent.
> >>>>>
> >>>>> Well, it's not only about the candidates (the 183 could actually
> >>>>> contain none of those). However, we'd also need to make 
> sure that
> >>>>> things like the ufrag and password are also received.
> >>>>>
> >>>>>> If the INFO contains always the complete list of
> >>> candidates (instead of just a delta), the ICE agents will
> >>>>>> eventually have all candidates even if the 183 with the
> >>> initial candidates got lost with the initial candidates.
> >>>>>> As an optimisation if you don't want to always send 
> the complete
> >>>>>> list, you could just include it in the first INFO and 
> use deltas
> >>>>>> afterwards.
> >>>>>
> >>>>> I like this suggestion and I agree we could add something along
> >>>>> those lines in case PRACK is not user or supported.
> >>>>>
> >>>>> Thanks for the tip!
> >>>>> Emil
> >>>>>>
> >>>>>>
> >>>>>> Regards
> >>>>>> Thomas
> >>>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> mmusic mailing list
> >>>> mmusic@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
>