Re: [P2PSIP] draft-knauf-p2psip-disco-00

Peter Musgrave <peter.musgrave@magorcorp.com> Thu, 16 September 2010 16:54 UTC

Return-Path: <peter.musgrave@magorcorp.com>
X-Original-To: p2psip@core3.amsl.com
Delivered-To: p2psip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017873A690F for <p2psip@core3.amsl.com>; Thu, 16 Sep 2010 09:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.781
X-Spam-Level:
X-Spam-Status: No, score=-100.781 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeK6kpEQhM99 for <p2psip@core3.amsl.com>; Thu, 16 Sep 2010 09:54:20 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id CAC993A68F6 for <p2psip@ietf.org>; Thu, 16 Sep 2010 09:54:19 -0700 (PDT)
Received: by qyk9 with SMTP id 9so1450637qyk.10 for <p2psip@ietf.org>; Thu, 16 Sep 2010 09:54:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.66.27 with SMTP id l27mr2453379qai.41.1284656084598; Thu, 16 Sep 2010 09:54:44 -0700 (PDT)
Received: by 10.229.72.135 with HTTP; Thu, 16 Sep 2010 09:54:44 -0700 (PDT)
In-Reply-To: <4C92220D.3030802@gmx.de>
References: <AANLkTikdZSqifd04ofmxM4QhhAvxK7uA-dsZN9rTp8eb@mail.gmail.com> <4C92220D.3030802@gmx.de>
Date: Thu, 16 Sep 2010 12:54:44 -0400
Message-ID: <AANLkTimN_SSGG9zfNbgYuZA4DfAxjMb2aTs_t_aYnQW3@mail.gmail.com>
From: Peter Musgrave <peter.musgrave@magorcorp.com>
To: Gabriel Hege <gabriel-mailinglists@gmx.de>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: hege@fhtw-berlin.de, alexander.knauf@haw-hamburg.de, mw@link-lab.net, p2psip@ietf.org
Subject: Re: [P2PSIP] draft-knauf-p2psip-disco-00
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2010 16:54:21 -0000

Here are my comments on -00. Looking forward to -01


2.
Add a definitions for
Owner Peer ?
Peer Co-ordinates?

3.1 Where does the URL that E uses resolve to? A? B? O?

3.5 Call Delegation
Could 302 be used instead? (REFER does have the advantage that it can
be used later on to load balance, i.e. not just on incoming calls)


In 4.2 a node SHOULD be aware of it's relative position but in 4.1 it
MUST select the focus peer whose co-ordinate value best matches. Is
this inconsistent?

4.2
Is the N-dimensional cartesian co-ordinate defined anywhere? Is this
presuming e.g. Chord. The statement is made that a concrete set of
topology algorithms is out of scope - hence I would have thought the
topology designator (i.e. cartesian co-ordinates) is also
out-of-scope. Some topologies may elect to use a different
representation.

4.4
Co-ordinate in contact field:
- will all peers know the co-ordinate scheme being used?

4.5
DisCo peers can not be behind a NAT…
I understand why this is a challenge but p2psip has NAT traversal and
I see a very common application of DisCo to aggregate conference
traffic within an enterprise to reduce the amount of media going
outside. I think this would be of huge benefit to Disco.

5.1
Is the use of the term 'media types' indicating audio/video or the
CODECs which are in use?

5.2 When a potential peer becomes active - how does it exchange media
with the other active focus?
Figure 7: Is there any merit in sending the REFER to the Joining Peer
instead of the PotentialFocus? In general dialog-creating REFERs are
less common and some nodes make a policy choice not to respond to
them. Does e.g. the ICE exchange get simpler if the new INVITE comes
from the Joining Peer?


Nits:
1.
s/complies the/complies with the/

3.3
"A conference member proposes as a focus"  ->
"A conference member proposes itself as a focus"

4.1 (last para)
s/inadequate/inappropriate/  ?

4.3 point 2
s/another a DisCo/another DisCo/

4.3 point 3
s/is like to register/is similar to registering/

4.3
s/MAY registers/MAY register/

5.1
s/differnt/different/
s/participating the conference/participating in the conference/

Regards,

Peter Musgrave



On Thu, Sep 16, 2010 at 9:56 AM, Gabriel Hege
<gabriel-mailinglists@gmx.de> wrote:
> Hi Peter,
>
> thank you very much for your comments.
>
> The first version of the draft is really just about distributing the control
> of the conference, but the idea is that the focus peers also do media
> distribution. Whether this involves mixing and reencoding or just relaying
> is dependent on the implementation and the media types involved.
>
> We are currently working on a major update to the draft, which will talk
> more about media distribution.
>
> best regards,
>  gabriel
>
> Am 15.09.2010 12:30, schrieb Peter Musgrave:
>>
>> Hi,
>>
>> I am reading this more carefully now (and will post some detailed
>> questions and comments in a few days).
>>
>> One high-level question. Is DisCO *just* about distributing the
>> control of the conference? It talks about distributed focus peers but
>> does not indicate whether these are doing a distributed audio mix (and
>> it does not indicate how such peers would exchange audio data). e.g.
>> the description in 5.2 does not discuss how a new focus peer exchanges
>> media with existing focii...
>>
>> Thanks,
>>
>> Peter Musgrave
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2psip
>