Subject: [P2PSIP] New versions of RELOAD and sip draft

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Oct 2009 11:52:34 -0600

I just submitted
draft-ietf-p2psip-base-04
and
draft-ietf-p2psip-sip-02

These contain technical changes but do not have a lot of editorial  
changes. At some point we need to go and reorganize the documents with  
editorial changes.

Cullen <in my individual contributor role>

---

From: jc <[email-masked]>
Date: Tue, 6 Oct 2009 16:11:02 -0400

Thanks Cullen and everyone else.

Julian

On Oct 6, 2009, at 1:52 PM, Cullen Jennings wrote:

> changes. At some point we need to go and reorganize the documents  
> with editorial changes.
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Sat, 10 Oct 2009 16:20:06 +0800

Hi Cullen,

I've had a quick review of these two drafts, and still not quite clear
with some Client related issues. 

I know Client is not the first-class concept in RELOAD, but as it has
been involved in the RELOAD protocol, RELOAD should give full support to
client anyhow, right? 

In the terminology chapter of RELOAD Base draft, the connection table is
defined as:  
     "The set of peers to which a node is directly connected.  This
includes nodes with which Attach handshakes have  been done but which
have not sent any Updates."
although, the second sentence implies that clients are also involved in,
I still suggest to replace the "peers" in the first sentence with
"nodes" to make it more clear that both peers and clients can be
maintained in the table. 

In my opinions, connection setup and maintenance between client and its
connected peer (responsible peer or arbitrary peer) is a key issue for
client support in RELOAD.  My question is: Does a peer in RELOAD
distinguish if the connection is to a peer or to a client? Because the
reaction of the peer could be different when the connection is lost.  

As a client could set up a connection only with an arbitrary peer. Does
this peer distinguish such connection from those it is responsible to?
Should this peer inform the client's responsible peer about the
Destination List to the client? So that it can still be accessed by
other nodes. Or should the Destination List been stored with some usage,
say SIP Usage? If so, the SIP usage must be extended to allow a
Destination list containing more than one Node IDs.  In current SIP
usage draft, the SipRegistration structure only allow one address being
stored in the Destination List, as:
  " Destination          destination_list<0..2^16-1>;"
It should be replaced by: "Destination          destination_list
[dest_list_length];"  
to enable a longer list stored by arbitrary connected clients.

Anyway, IMHO, RELOAD should make sure to cover all situations a client
could meet or at least clearly distinguish issues of clients, especially
for arbitrary connected ones, which are left to be solved by other
drafts. Thanks.

Best Regards,
Xiao, Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Cullen Jennings
Sent: Wednesday, October 07, 2009 1:53 AM
To: P2PSIP WG
Subject: [P2PSIP] New versions of RELOAD and sip draft

I just submitted

---

From: jc <[email-masked]>
Date: Sat, 10 Oct 2009 15:04:29 -0400

Xiao,
If a node has is not a part of the ring it is a peer otherwise it is a  
client.

For simplicity I keep state of each node internally but this brings no  
external value. These can be determined outright by checking your  
connection table against your routing table as well without  
enumerations but brings complexity to this simple query.

/**
  * Current node klass. May be client or peer, will default to none  
for pre-bootstrap setup.
  */
enum {
     node_klass_none = 0,
     node_klass_client = 1,
     node_klass_peer = 2,
};

There is no possible way to determine via the base protocol if a node  
is a client or a peer except by the fact that it may or may not be in  
the ring. I handle this internally and don't feel that sending this  
over the wire would bring benefit.

What you describe here would require changes to the protocol header  
and would be defining a first class concept for nodes.

Julian Cain

---

From: Michael Chen <[email-masked]>
Date: Mon, 12 Oct 2009 15:48:20 -0700

Cullen,

I posted several issues regarding the -03 draft late July but received 
no reply. I don't see changes related to these issues in the new -04 
draft. I want to make sure they are not overlooked:

 http://www.ietf.org/mail-archive/web/p2psip/current/msg05019.html

1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does not 
conform with section 15.1 of the current mmusic-ice-19 draft, which has 
the following text:

"<rel-addr> and <rel-port>:  convey transport addresses related to the
     candidate, useful for diagnostics and other purposes. <rel-addr>
     and <rel-port> MUST be present for server reflexive, peer
     reflexive and relayed candidates."

Therefore, the definition of IceCandidate should be:

        struct {
          ...
          select (type){
            case host:
              ;          /* Nothing */
            case srflx:
            case prflx:
            case relay:
              IpAddressPort     rel_addr_port;
          }
          ...
        } IceCandidate;

  rel_addr_port
     corresponds to the related address and port of ICE, which MUST
     present for type "srflx", "prflx" and "relay".

2) In Section 13.6, IANA message codes for AppAttachReq and AppAttachReq 
are not added. I suggest fill these two values (app_attach_req=5, 
app_attach_ans=6) in the holes left by the abandoned tunnel_req and 
tunnel_ans.

3) In Section 6.4.1.2, if the store request has multiple kinds, the 
current answer structure will send replica node IDs multiple times. For 
efficiency, I suggest moving the replica node IDs to the outer layer as:

        struct {
          KindId                  kind;
          uint64                  generation_counter;
        } StoreKindResponse;

        struct {
          StoreKindResponse       kind_responses<0..216-1>;
          NodeId                  replicas<0..216-1>;
        } StoreAns;

4) It seems that mmusic-ice-tcp-07 has been abandoned. The key members 
of this draft should address the lack of ice-tcp standard in the next 
draft, meeting or on the mailing list.

That is it so far. Thanks

--Michael

---

From: jc <[email-masked]>
Date: Mon, 12 Oct 2009 19:17:11 -0400

Michael,

1:

I was actually working in that area ATM. There is an exclusion "Only  
present for type "relay"",  however I'm not certain as to why that is.  
I agree it MUST be as you've stated .

2:

There also must be a codes for app_attachlite_req = 29 and  
app_attachlite_ans = 30.

3:

No comment.

4:

Seeing that ICE is required for RELOAD as is TLS over TCP I cannot  
think of any other protocol off the top of my head that is more  
dependent on that draft than this one.

Julian

On Oct 12, 2009, at 6:48 PM, Michael Chen wrote:

> Cullen,
>
> I posted several issues regarding the -03 draft late July but  
> received no reply. I don't see changes related to these issues in  
> the new -04 draft. I want to make sure they are not overlooked:
>
> 1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does  
> not conform with section 15.1 of the current mmusic-ice-19 draft,  
> which has the following text:
>
> 2) In Section 13.6, IANA message codes for AppAttachReq and  
> AppAttachReq are not added. I suggest fill these two values  
> (app_attach_req=5, app_attach_ans=6) in the holes left by the  
> abandoned tunnel_req and tunnel_ans.
>
> current answer structure will send replica node IDs multiple times.  
> For efficiency, I suggest moving the replica node IDs to the outer  
> layer as:
>
>         struct {
>           KindId                  kind;
> 4) It seems that mmusic-ice-tcp-07 has been abandoned. The key  
> members of this draft should address the lack of ice-tcp standard in  
> the next draft, meeting or on the mailing list.
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Oct 2009 19:04:44 -0600

Thank you, few comments inline....

> "nodes" to make it more clear that both peers and clients can be

I agree. I changed this - thank you for the careful review to catch  
things like this.

> reaction of the peer could be different when the connection is lost.

Reload does distinguish at some level but what do you think a node  
needs to do differently when a connection is lost if the connection  
when to a peer or client. Clearly how data replication is handled and  
some of the finger table stuff is handled differently but I think that  
is covered in the draft. If you see something specific missing, let me  
know.

> this peer distinguish such connection from those it is responsible to?
I don't se the need to.

> say SIP Usage?

Yes, that is the approach to store destination lists where they are  
needed.

> If so, the SIP usage must be extended to allow a
> Destination list containing more than one Node IDs.

agree that it needs to allow storing multiple Node IDs but I think it  
already does that.

>  In current SIP

The destination_list here is an array of Destinations so it allows  
between 0 and 65K entries in the array. I agree the syntax for  
specifying arrays might seem a bit weird but I think the structure is  
what you are pointing out we need to have.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Oct 2009 19:04:33 -0600

agree on all points - fixed in next ver.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Oct 2009 19:06:23 -0600

>      present for type "srflx", "prflx" and "relay".

This was my mistake and an issue of having several people working on  
text. I thought the problem in 03 was we were missing rel_add_port, I  
went to look the draft and decided that, oh, someone already dealt  
with the email from Michael. I did not realize the problem was the  
with where the "; /*nothing*/ was in the select statement. Sorry we  
missed this email last time, it will be in the next version.

> abandoned tunnel_req and tunnel_ans.

Added along with the lite version JC pointed out was missing. I did  
not use use the values 5 and 6 as I wanted to avoid a conflict with  
anyone that was using tunnel.

> the next draft, meeting or on the mailing list.

I don't know that ICE-TCP has been abandoned. It is still listed as a  
key milestone for the MMUSIC WG. I think the authors, chairs, ads, etc  
decided there was not to much criticality to working on it before the  
base ICE stuff got done. That said, I agree we should get ice-tcp  
moving again. Someone could go bug the mmusic WG and point out the  
charter says it will go to the IESG in Oct 2009. Of course the P2PSIP  
WGs milestones say this document will got the the IESG in September  
2008.

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Wed, 21 Oct 2009 15:59:09 +0800

Hi Cullen,

Thanks for your reply.

I agree that RELOAD have covered  most of the functionalities of peers
and clients. However, there is still a little different between clients
and peers while connection is lost besides data replica. What I mean
here is the Node ID. 

Because all the peers in the overlay are connected according to a strict
overlay algorithm. The position of a peer in the overlay is decided by
its Node ID. If a peer lost its position (disconnected) in the overlay
because of moving and NAT, but still want to work as a peer, it must
change its Node ID, which means it need do the enrollment again and
rejoin the overlay.  

But, because a client can attach with an arbitrary peer. It is not
necessary for a client to change its Node ID when it change its
attaching peer. The most important thing here is that, this behavior
make it possible for a client  to keep session continuity while its
attaching peer is switched. 

Considering to deploy  RELOAD in reality, stable nodes are preferred to
work as peers while mobile nodes can take the advantage of the client
behavior mentioned above. Sessions can be kept with high mobility, as
unique Node ID is maintained by clients. I'm not sure if RELOAD has
considered this distinction of client, which help clients to be attached
with the ovelay as long as it can build at least one connection to the
overlay.

Br
Xiao, Lin

-----Original Message-----
From: ext Cullen Jennings [mailto:[email-masked]] 
Sent: Friday, October 16, 2009 9:05 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: P2PSIP WG
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft

> been involved in the RELOAD protocol, RELOAD should give full support 
> to client anyhow, right?
>
> In the terminology chapter of RELOAD Base draft, the connection table 
> is defined as:
> although, the second sentence implies that clients are also involved 
> in, I still suggest to replace the "peers" in the first sentence with 

I don't se the need to.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Oct 2009 06:58:48 -0600

I don't understand why you think a peer would need to change it's  
NodeID.

On Oct 21, 2009, at 1:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote:

>> with

---

From: jc <[email-masked]>
Date: Wed, 21 Oct 2009 12:40:48 -0400

The draft doesn't state that you MUST change you NodeID if you lose  
overlay connectivity. In fact under your given condition you would  
simply retain it and connect again as a Client when the network is  
back up.

Julian

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Thu, 22 Oct 2009 15:18:56 +0800

Hi,

Maybe I'm wrong, but I consider peers in RELOAD are structured with a
DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected with
peer 400 and 600. 

However, what will happen, if peer 500 totally lose both of the
connections due to mobility and NAT, but can set up new ones with peer
100 and peer 300? IMHO, in order to keep the topology structured, if
this node still want to be a peer in the overlay it should change its
Node ID to, say 200, and rejoin the overlay to enable itself still
reachable with the DHT algorithm.

If peers in a overlay can not be connected with a strict order, the DHT
algorithm for structured topology will not work anymore.

Br
Xiao, Lin 

-----Original Message-----
From: ext jc [mailto:[email-masked]] 
Sent: Thursday, October 22, 2009 12:41 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext Cullen Jennings; P2PSIP WG
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft

The draft doesn't state that you MUST change you NodeID if you lose
overlay connectivity. In fact under your given condition you would
simply retain it and connect again as a Client when the network is back
up.

Julian

> and clients. However, there is still a little different between 
> clients and peers while connection is lost besides data replica. What 
> I mean here is the Node ID.
>
> Because all the peers in the overlay are connected according to a 
> strict overlay algorithm. The position of a peer in the overlay is 
> decided by its Node ID. If a peer lost its position (disconnected) in 
> the overlay because of moving and NAT, but still want to work as a 
> peer, it must change its Node ID, which means it need do the 
> enrollment again and rejoin the overlay.
>
> Considering to deploy  RELOAD in reality, stable nodes are preferred 
> to work as peers while mobile nodes can take the advantage of the 
> client behavior mentioned above. Sessions can be kept with high 
> mobility, as unique Node ID is maintained by clients. I'm not sure if 
> RELOAD has considered this distinction of client, which help clients 
> to be attached with the ovelay as long as it can build at least one 
> connection to the overlay.
>
> Br
> Xiao, Lin
>
>
>

>> In my opinions, connection setup and maintenance between client and 
>> its connected peer (responsible peer or arbitrary peer) is a key 
>> issue for client support in RELOAD.  My question is: Does a peer in 
>> RELOAD distinguish if the connection is to a peer or to a client? 
>> Because the reaction of the peer could be different when the 
>> connection is lost.
>

>> other nodes. Or should the Destination List been stored with some 
>> usage, say SIP Usage?
>
>> If so, the SIP usage must be extended to allow a Destination list 
>> containing more than one Node IDs.
>
>> usage draft, the SipRegistration structure only allow one address 
>> being stored in the Destination List, as:
>> Anyway, IMHO, RELOAD should make sure to cover all situations a 
>> client could meet or at least clearly distinguish issues of clients, 
>> especially for arbitrary connected ones, which are left to be solved 
>> by other drafts. Thanks.
>>
>>
>> Best Regards,
>> Xiao, Lin
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of ext Cullen Jennings

---

From: "Neil.Young" <[email-masked]>
Date: Thu, 22 Oct 2009 10:39:23 +0200

500 can of course keep it's node id, regardless of whether 400 and/or 
600 are there or not. Due to stabilization and by means of the 
successorcache the predecessor of 400 will notice the absence and bridge 
directly to 500 as well as 500 will skip 600 after a short time and go 
to 700 (in order to stay in the picture).  Using notify the ring will 
close again. 400 and 600 may return whenever they want.

Regards