Subject: [P2PSIP] direct routing support in RELOAD

From: "Das, Saumitra" <[email-masked]>
Date: Mon, 16 Feb 2009 22:11:42 -0800

Hi all,

  In the last meeting there was a discussion on direct routing and the conclusions were (if I recall correctly) that this should not be something that complicates the  protocol and that we could have support for indicating the use of direct routing if the deployment is amenable to such a scenario.

 I would like to propose we add a flag bit in the forwarding/common header that indicates that a direct routing response to a message be used by the responding node. As a policy, implementations in certain scenarios would enable the flag as necessary.

We can indicate that the responding node need not keep state to minimize complications. The sending node can simply resend a request (e.g STORE) with the flag turned off if does not receive a response to the initial STORE request with the flag turned on.

This allows direct routing support in scenarios where the deployer or the implementation knows it is dealing with reachable IP addresses. This is also possible without any complications to the base protocol.

Best
Saumitra

---

From: "Roni Even" <[email-masked]>
Date: Tue, 17 Feb 2009 11:40:25 +0200

Saumitra,
I think that draft-jiang-p2psip-relay-01 suggests similar solution of adding
a flag to the forwarding header.
Thanks
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Das, Saumitra
Sent: Tuesday, February 17, 2009 8:12 AM
To: [email-masked]
Subject: [P2PSIP] direct routing support in RELOAD

Hi all,

  In the last meeting there was a discussion on direct routing and the
conclusions were (if I recall correctly) that this should not be something
that complicates the  protocol and that we could have support for indicating
the use of direct routing if the deployment is amenable to such a scenario.

 I would like to propose we add a flag bit in the forwarding/common header
that indicates that a direct routing response to a message be used by the
responding node. As a policy, implementations in certain scenarios would
enable the flag as necessary.

We can indicate that the responding node need not keep state to minimize
complications. The sending node can simply resend a request (e.g STORE) with
the flag turned off if does not receive a response to the initial STORE
request with the flag turned on.

This allows direct routing support in scenarios where the deployer or the
implementation knows it is dealing with reachable IP addresses. This is also
possible without any complications to the base protocol.

Best
Saumitra
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Das, Saumitra" <[email-masked]>
Date: Tue, 17 Feb 2009 10:18:11 -0800

Hi Roni,

  Thanks. I was asking that this support be added to the base draft. I think the relay issue and the direct routing issue can be separated as they require different levels of solutions.

Best,
Saumitra

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 1:40 AM
To: Das, Saumitra; [email-masked]
Subject: RE: [P2PSIP] direct routing support in RELOAD

Saumitra,

-----Original Message-----

Hi all,

Best
Saumitra

---

From: "Roni Even" <[email-masked]>
Date: Tue, 17 Feb 2009 22:56:57 +0200

Saumitra,
Having the flag is not enough since the responding node may not know the
address of the requestor since intermediate peers may keep state and give
only their address in the via list.
The other issue is how does the sending peer know that it has a routable
address and this is what the relay draft suggest. 
Roni Even

-----Original Message-----
From: Das, Saumitra [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 8:18 PM
To: Roni Even; [email-masked]
Subject: RE: [P2PSIP] direct routing support in RELOAD

Hi Roni,

  Thanks. I was asking that this support be added to the base draft. I think
the relay issue and the direct routing issue can be separated as they
require different levels of solutions.

Best,
Saumitra

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 1:40 AM
To: Das, Saumitra; [email-masked]
Subject: RE: [P2PSIP] direct routing support in RELOAD

Saumitra,

-----Original Message-----

Hi all,

Best
Saumitra

---

From: jiangxingfeng <[email-masked]>
Date: Wed, 18 Feb 2009 10:05:56 +0800

Hi, Saumitra:

I don't think direct routing and relay peer require different level of solutions. As we discussed in Minneapolis, we can use a configuration file to indicate to all nodes in the p2psip systems that you can use direct response routing. But you know, in any system, you can not control whether a node is behind NAT, even it is still in a closed system. For example, in Chinese campus, NAT device is often deployed at the entry to the CERNET. Further, for computers in the lab, they often connect to the campus network through the NAT. 

So even in a closed system, network administrators can't think all nodes in the closed network are in the same address realm, even they would like to by set options in the configuration files. In this case, it will make direct response fail frequently so that the introduction of the direct response routing mode seems not bring enough benefits. 

So as proposed in draft-jiang-p2psip-relay-01, a simple test to detect whether the transport address is publicable in the p2psip system is very important to direct response, and relay peer as well. This way, a general solution can make direct response and relay peer work. 

Note: draft-jiang-p2psip-relay-01 is not meant to propose a solution to test whether a transport address is publicable. Instead, it shows that there are some existing mechanisms can do that, such as uPNP-IGD, NAT-PMP, etc. The focus of the draft is proposing how to extend RELOAD-base to support direct response and relay peer routing. 

Any comments are welcome. 
Regards

Jiang XingFeng

> the relay issue and the direct routing issue can be separated as they require
> different levels of solutions.