Subject: [P2PSIP] direct routing support

From: "Das, Saumitra" <[email-masked]>
Date: Tue, 24 Mar 2009 16:37:49 -0700

At the previous IETF there was consensus to add direct response routing as an option in the protocol.

See: http://tools.ietf.org/wg/p2psip/minutes?item=minutes73.html

This is not yet reflected in the base draft.

My previous post to this effect with some changes is  below

"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. If the flag is set, the requesting node also needs to include its reachable address in the forwarding header.

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 and can configure the implementation to behave accordingly."

Thanks
Saumitra

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 24 Mar 2009 21:59:10 -0400

There was no consensus to include direct response in the base draft.
Here's the text of the hum from the notes you point to:

--------
First hum:  whether or not we include direct routing as an option in
the protocol (not worrying about what draft):  result was consensus
for including it in the protocol.
--------

Direct response routing can be implemented as a forwarding option as
described in the base.

http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4

So while it's possible to do it in other ways, and to include those
techniques in the base draft, it's not required.

(obviously it's a question of group consensus on whether it should be
added to the base draft)

Bruce

2009/3/24 Das, Saumitra <[email-masked]>:
> "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. If the flag is set, the requesting node also
> needs to include its reachable address in the forwarding header.
>
>
>
> 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 and can
> configure the implementation to behave accordingly."
>
>
>
> Thanks
>
> Saumitra
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Mar 2009 22:08:12 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bruce Lowekamp
> Sent: Tuesday, March 24, 2009 6:59 PM
> To: Das, Saumitra
> Cc: [email-masked]
> Subject: Re: [P2PSIP] direct routing support
> 

Right, there was consensus to include it in the base protocol.  To me, it would make sense to add it to the base draft, since it doesn't seem to make sense to say in the base draft that it is not permitted and yet have the notion of allowing it in the base protocol.  

> http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4

I'm assuming that you are talking about a yet-to-be-defined forwarding option?  Or, did I miss something that is already specified that can be used for this purpose? 

I think defining a forwarding option for this does make sense and corresponding to that option, we need to say what the forwarding behavior should be.  The node sending the request also needs to provide its direct reachability parameters in the message.  

While we are on the topic of forwarding options, could anyone describe the purpose of the ones that are already defined in section 5.3.2.4?  I don’t quite see an explanation and I am quite perplexed by them :) 

Thanks,
Vidya

> > At the previous IETF there was consensus to add direct response
> routing as
> > an option in the protocol.
> >
> >
> >

---

From: "Das, Saumitra" <[email-masked]>
Date: Wed, 25 Mar 2009 00:40:47 -0700

Hi Bruce,

I did say that there was consensus on the it being part of the base protocol. The base draft however explicitly prevents this.

Maybe we should reach consensus on the base draft on this issue. 

It may be useful also to not have text explicitly saying direct routing is not supported as it currently is in the base draft and mention that the forwarding option can be used to implement this functionality if needed.

Thanks
Saumitra

-----Original Message-----
From: Bruce Lowekamp [mailto:[email-masked]] 
Sent: Tuesday, March 24, 2009 6:59 PM
To: Das, Saumitra
Cc: [email-masked]
Subject: Re: [P2PSIP] direct routing support

--------

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 25 Mar 2009 08:00:26 -0400

On Wed, Mar 25, 2009 at 1:08 AM, Narayanan, Vidya <[email-masked]> wrote:
> Right, there was consensus to include it in the base protocol.

The text inside the parenthesis means there was no consensus where to
put it, to me at least.

>  To me, it would make sense to add it to the base draft, since it doesn't seem to make sense to say in the base draft that it is not permitted and yet have the notion of allowing it in the base protocol.
>

Sorry to be unclear.  I meant to say that a direct response forwarding
option could be defined, not that the base draft defines one.

> While we are on the topic of forwarding options, could anyone describe the purpose of the ones that are already defined in section 5.3.2.4?  I don’t quite see an explanation and I am quite perplexe…

I'm not sure what you're referring to.
http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4
doesn't define any forwarding options, it defines a structure that
forwarding options could use, but does not itself define a forwarding
option (i.e. no values for "type" are given meaning).

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 25 Mar 2009 08:00:32 -0400

> I did say that there was consensus on the it being part of the base protocol. The base draft however explicitly prevents this.

There was no consensus to include it in the base draft.  That's what
the part in parenthesis "((not worrying about what draft)" meant.  The
specific conclusion what that a more detailed direct routing proposal
would be presented, and a later discussion would take place regarding
where it went.  Chairs, please correct me if I'm wrong on this.

> It may be useful also to not have text explicitly saying direct routing is not supported as it currently is in the base draft and mention that the forwarding option can be used to implement this fu…

If there is text anywhere in the base draft that says direct routing
is not supported, please cite a location (this is a general request
whenever anyone says "the draft says foo").  It's a big draft and it's
possible to lose track of what different sections say.  I reorganized
and rewrote parts of section 5 since last IETF and certainly the intro
to 5 and 5.2
http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5
http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.2
say nothing that explicitly prevents direct response routing.

Bruce

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 25 Mar 2009 10:00:51 -0700

> The text inside the parenthesis means there was no consensus where to

What "protocol" other than RELOAD is being referred to in that statement then? I believe the discussion was about RELOAD, without worrying about whether it will be another draft that will add it to RELOAD or it will be part of the base draft.  I was looking for the chairs to confirm the consensus on the list and also ask the question about the document, but I saw none after the meeting. 

<snip>

> option (i.e. no values for "type" are given meaning).

Sorry, I was referring to the flags defined in that section.  I'm confused by them and the draft doesn't seem to describe their purpose. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 25 Mar 2009 10:08:30 -0700

> whenever anyone says "the draft says foo").  

Please see this text towards the end of section B.3: 

"   An extension to RELOAD that supports direct response routing but
   relies on symmetric responses as a fallback would be possible, but
   due to the complexities of determining when to use direct response
   and when to fallback to symmetric, and the reduced performance for
   responses to peers behind restrictive NATs, we have chosen not to
   include it as an option at this point." 

I believe the discussion in Minneapolis was not about making it an extension to RELOAD, rather, making it a part (and an option) of RELOAD.  

Vidya

---

From: "Roni Even" <[email-masked]>
Date: Wed, 25 Mar 2009 11:01:12 +0200

Hi,
I agree with Bruce that it was not decided where the direct response
functionality will be defined.
Currently http://tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt specifies
the extension for direct response as well as relay response.
I will present the document on Friday session since Jiang XingFeng could not
attend the meeting.
I have no preference where direct response or relay support is specified but
the Jiang draft tries to address the fall back issues as well as the needed
extensions to forwarding header for this solution to work.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Narayanan, Vidya
Sent: Wednesday, March 25, 2009 7:09 PM
To: Bruce Lowekamp; Das, Saumitra
Cc: [email-masked]
Subject: Re: [P2PSIP] direct routing support

I believe the discussion in Minneapolis was not about making it an extension
to RELOAD, rather, making it a part (and an option) of RELOAD.  

Vidya