Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 4 Feb 2011 11:05:24 -0500

Roni,

Since we made it an option for intermediate peers using SRR to keep
state rather than modify the forwarding header, I think we should try
to keep that option reasonably well supported.  And while I agree with
you that the timeout such an implementation provides is sufficient for
supporting DRR without other modifications, I'd really rather provide
an good way for such implementation to avoid keeping state for all DRR
(potentially most/many messages) until timeout, thus my support for a
flag.

We can flag this as an open issue for more discussion, though (pun intended).

Bruce

On Mon, Jan 31, 2011 at 1:54 AM, Roni Even <[email-masked]> wrote:
> Hi Bruce,
> I do not think it is required for every message, just for the case when the intermediary node keeps state of the message (it is per such a message). This may be needed due to failures on the route and not only for DRR support
> Roni
>
>> -----Original Message-----
>> From: Bruce Lowekamp [mailto:[email-masked]]
>> Sent: Saturday, January 08, 2011 12:30 AM
>> To: Roni Even
>> Cc: David A. Bryan; P2PSIP WG
>> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from
>> meeting - DRR
>>
>> I think requiring the state timeout mechanism to be used for every
>> message would be a bit much to put on the peers.  I would rather
>> provide the explicit flag.
>>
>> Bruce
>>
>> On Thu, Jan 6, 2011 at 9:07 AM, Roni Even <[email-masked]> wrote:
>> > Hi Bruce,
>> > I think that the flag for not keeping state may be useful but there
>> is also another mechanism which is the time out that tells intermediate
>> nodes to discard any state after a timeout.
>> > Roni
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]] On
>> >> Behalf Of Bruce Lowekamp
>> >> Sent: Thursday, December 02, 2010 8:54 PM
>> >> To: David A. Bryan
>> >> Cc: P2PSIP WG; Roni Even
>> >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft
>> from
>> >> meeting - DRR
>> >>
>> >> The motivation for putting it into the base draft was that if it is
>> >> part of the base spec, then in the future nodes that implement
>> >> whatever is specified in the relay/DRR draft can make use of those
>> >> techniques while on an overlay with nodes that only implement the
>> base
>> >> draft.  For example:
>> >>
>> >> - any sort of relay/DRR requires intermediate nodes to not keep any
>> >> state about routed messages.  If support for the routing flag that
>> >> allows this is not in the base draft, they will have to simply
>> reject
>> >> the message.
>> >> - knowledge of how to set up a relay node isn't required to make use
>> >> of the relay node.
>> >>
>> >> The intention of the current text was that it could currently only
>> be
>> >> used with no-ice.  But it would provide support so that nodes that
>> >> only implement the base draft would be able to forward messages
>> using
>> >> relay/DRR and would also be able to send messages to a relay node in
>> >> the future without knowing the details of how that is set up.  As
>> >> currently specified, it definitely needs some text stating
>> explicitly
>> >> that it can currently only be used with no-ice.
>> >>
>> >> There's another option where we add a ForwardingOptions flag to the
>> >> base draft that specifies not to keep state about the message, but
>> >> isn't explicitly a DRR flag.  There might even be a benefit to doing
>> >> that, in that it wouldn't be explicitly tied to the DRR mechanism in
>> >> there now.
>> >>
>> >> Or , of course, we can remove it completely, at the cost that base
>> >> nodes won't be compatible with whatever is done in the relay/DRR
>> >> draft.
>> >>
>> >> Bruce
>> >>
>> >>
>> >> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan
>> <[email-masked]>
>> >> wrote:
>> >> > I also think the current text is too limiting. The best approach
>> is
>> >> to
>> >> > make it clear in the draft that other routing techniques are
>> allowed
>> >> > and supported, leave in the flags but remove the very skeletal
>> direct
>> >> > response routing from this draft and we instead do that in the
>> >> > relay/direct response draft.
>> >> >
>> >> > David (as individual)
>> >> >
>> >> > On Sun, Nov 21, 2010 at 3:04 AM, Roni Even <[email-masked]>
>> >> wrote:
>> >> >>
>> >> >>>
>> >> >>> Direct Response Routing and ICE
>> >> >>> • Specified in §5.3.2.4
>> >> >>> This option can only be used if the direct-return-response-
>> >> permitted
>> >> >>> flag in the configuration for the overlay is set to TRUE. The
>> >> >>> RESPONSE_COPY flag SHOULD be set to false while the
>> >> FORWARD_CRITICAL
>> >> >>> and DESTINATION_CRITICAL MUST be set to true. When a node that
>> >> >>> supports this forwarding options receives a request with it, it
>> >> acts
>> >> >>> as if it had send an Attach request to the the requesting_node
>> and
>> >> it
>> >> >>> had received the connection_information in the answer. This
>> causes
>> >> it
>> >> >>> to form a new connection directly to that node.
>> >> >>> • This doesn’t work with ICE because the sender of the request
>> >> doesn’t
>> >> >>> have your information
>> >> >>> Proposed Resolution: DRR can only be used with No-ICE
>> >> >>> ***NOTE: This slide generated significant discussion in the
>> >> meeting.
>> >> >>> There were some comments that this was incomplete, and
>> discussion
>> >> of
>> >> >>> moving this out of the base draft and into the relay/direct
>> >> response
>> >> >>> draft. ADDITIONAL DISCUSSION REQUIRED.
>> >> >>
>> >> >> I see the problem and think that we should take this section out
>> >> from RELOAD and continue with the individual relay draft (draft-
>> jiang-
>> >> p2psip-relay-04) for the use case where the node is not behind NAT
>> or a
>> >> relay can be used.
>> >> >> In this case we will need to verify that RELOAD allows such
>> >> extensions and that there are no issues with supporting it due to
>> some
>> >> routing assumptions.
>> >> >>
>> >> >> Roni Even
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> > _______________________________________________
>> >> > P2PSIP mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/p2psip
>> >> >
>> >> _______________________________________________
>> >> P2PSIP mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/p2psip
>> >
>> >
>
>

---

From: Roni Even <[email-masked]>
Date: Sat, 05 Feb 2011 01:05:03 +0200

Bruce,
I am with you and think that having a flag is a good idea
Roni

> Sent: Friday, February 04, 2011 6:05 PM
> To: Roni Even
> Cc: P2PSIP WG
> > I do not think it is required for every message, just for the case
> when the intermediary node keeps state of the message (it is per such a
> message). This may be needed due to failures on the route and not only
> for DRR support
> > Roni
> >

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Feb 2011 16:48:54 -0700

On the topic of a flag to not keep state... just having a flag won't work. It has to be an overlay option because all the nodes in the overlay need to support it. Once you have it as an overlay option, you don't need it in the base spec. I just don't see any reason to put it in the base spec - it can be done in extension just as well - and I see lots of reasons not to but it in the base spec. We don't really know how to make this work well yet. Ideally it would be an optimization you used when you could so that a client could still connect to a peer that would do state and do the DDR for it. Saying something like the flag indicates don't keep state breaks clients among other things. You would need the option to be a little more nuanced than that. I think we should define all of this in the DDR draft - trying to guess what we need before we know what we are doing is likely to result in getting it wrong.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Feb 2011 17:11:47 -0800

> On the topic of a flag to not keep state... just having a flag won't work. It has to be an overlay option because all the nodes in the overlay need to support it. Once you have it as an overlay opt…

I don't think this is quite right: the issue isn't really whether all nodes in the overlay support it but rather whether
they support DRR.

Here's my reasoning: a requester who uses this option is basically committing to only receiving responses via DRR,
since the Via List will not be unwindable by the responder. However, because a requester has no real a priori way
of knowing a responder's capability this means that any node in the overlay must already support DRR because
otherwise any intermediate or terminal node has no way of responding to the request. So, this extension is
only useful in an overlay in which everyone supports DRR; where it's basically a way of indicating "use DRR only"
and telling intermediaries they don't need to store state.

However, with that said, it seems to me that the forward compatibility issue goes away: if we do decide to use this
flag to enable DRR, then all the nodes in the overlay will have to be DRR-capable, at which point we can define
this extension or similar at the time we define DRR.

So while I had originally edited this extension into the draft, I have now concluded we should remove it after
all.

Best,
-Ekr

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 8 Feb 2011 21:42:02 -0500

> and telling intermediaries they don't need to store state.

I don't think this is what is proposed here.  DRR requires the sender
and receiver to support it.  The no-state flag simply indicates that
the intermediate peer should not keep internal state (i.e. use a
compressed id, etc).   It can forward the message by adding itself to
the via-list as normal.

Now an intermediate peer that was aware of DRR could know that adding
itself to the via-list is unnecessary and not do it.  But I think that
should be left to the extension.

And for DRR, in particular, the nodes need to be prepared for the
response to be dropped regardless of whether they both support the
extension, so presumably any such extension would specify a fallback
to normal routing on retransmissions of the original request.

Certainly we need a draft that fully specifies DRR and eventually
other routing options.  But I don't believe it's true that all nodes
need to support it.  On the contrary, if we don't have the flag then
all nodes (at least routing peers) would need to support DRR, but if
we do have the flag then DRR can be implemented to work between any
two nodes that support it.

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Feb 2011 21:04:08 -0800

On Feb 8, 2011, at 6:42 PM, Bruce Lowekamp wrote:

> compressed id, etc).

Right now, there isn't a no-state flag, so I think what it indicates is what's
at question here. The no-state flag in the version I checked in meant 
that there was not going to be a response and so no state should be
kept of any kind.

>   It can forward the message by adding itself to
> the via-list as normal.

I'm not sure this is "normal". It's one of several options, that as far as I know of
have no preference ranking in the draft. I'm very uncomfortable with creating
a flag that affects only one mechanism for symmetric return routing.

> to normal routing on retransmissions of the original request.

Really? Why would you think that? All sorts of things can go wrong that don't
indicate that reverse routing is the problem.

> two nodes that support it.

With no discovery mechanism, I don't see how this is useful, which is why the DRR
mechanism we just removed required universal support in the overlay.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Wed, 09 Feb 2011 11:43:39 +0200

Hi Guys,
I am not sure I understand your points. I would like to describe again the
DRR proposal in draft-jiang-p2psip-relay-04 and explain the status keeping
flag.

The DRR proposal proposes to add a new forwarding option for an extensive
routing mode that will supply the information that will allow the
destination peer to connect directly back to the requestor to establish a
DRR mode. So this still allows the receiver to use SRR if it does not
support DRR. Note that the new forwarding option must include all the
information needed to support the DRR or Relay mode.
The issue with the state keeping flag in my view is to try to address the
issue where according to the base draft as describe at the figure at the end
of section 3.3 where the intermediary node keep the state of the via list
expecting the response to go back via itself, note that the flag only
recommends to the intermediary that it may not be useful to change the via
list but it does not change the via list. If DRR is preferred, the flag
means that it is not required to keep state. On the other hand I think that
the solution will work even without the flag since there is timeout for the
response, the intermediary will delete the state after the timeout but
having the flag will make it cleaner. 

Regards
Roni Even

> Behalf Of Eric Rescorla
> Sent: Wednesday, February 09, 2011 3:12 AM
> To: Cullen Jennings
> Cc: P2PSIP WG; Roni Even
> > On the topic of a flag to not keep state... just having a flag won't
> work. It has to be an overlay option because all the nodes in the
> overlay need to support it. Once you have it as an overlay option, you
> don't need it in the base spec. I just don't see any reason to put it
> in the base spec - it can be done in extension just as well - and I see
> lots of reasons not to but it in the base spec. We don't really know
> how to make this work well yet. Ideally it would be an optimization you
> used when you could so that a client could still connect to a peer that
> would do state and do the DDR for it. Saying something like the flag
> indicates don't keep state breaks clients among other things. You would
> need the option to be a little more nuanced than that. I think we
> should define all of this in the DDR draft - trying to guess what we
> need before we know what we are doing is likely to result in getting it
> wrong.
> >
> 
> 
> I don't think this is quite right: the issue isn't really whether all
> nodes in the overlay support it but rather whether
> they support DRR.
> 
> Here's my reasoning: a requester who uses this option is basically
> committing to only receiving responses via DRR,
> since the Via List will not be unwindable by the responder. However,
> because a requester has no real a priori way
> only useful in an overlay in which everyone supports DRR; where it's
> basically a way of indicating "use DRR only"
> However, with that said, it seems to me that the forward compatibility
> issue goes away: if we do decide to use this
> flag to enable DRR, then all the nodes in the overlay will have to be
> DRR-capable, at which point we can define

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Feb 2011 09:20:12 -0800

Yes, I understand this argument.

My point is that you need to make symmetric return routing work in any case,
which means you need to do whatever you do to the via list to make that
work, so that this flag doesn't work.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Wed, 09 Feb 2011 21:31:19 +0200

EKR,
I am not sure why the flag does not work for  symmetric return, state
keeping by intermediaries is optional according to section 3.3 and is not
required for it to work.

Roni

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Wednesday, February 09, 2011 7:20 PM
> To: Roni Even
> Cc: 'Cullen Jennings'; 'P2PSIP WG'
> >> otherwise any intermediate or terminal node has no way of responding
> to
> >> the request. So, this extension is
> >> So while I had originally edited this extension into the draft, I
> have
> >> now concluded we should remove it after
> >> all.
> >>
> >> Best,
> >> -Ekr
> >>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Feb 2011 11:42:19 -0800

> keeping by intermediaries is optional according to section 3.3 and is not

The intermediary's job is to keep the via list in a state where it is unwindable. It
is a purely local matter how it does so. It's not reasonable to tell intermediaries
who would otherwise keep state that they must instead modify the via list to
include the full unwind path.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Thu, 10 Feb 2011 00:03:53 +0200

Hi, 
I see what EKR means but I think that there is some inconsistency in section
3.3.
The requirement says: 

"Low state:    RELOAD's routing algorithms must not require
      significant state to be stored on intermediate peers."

Yet when talking about state keeping later in the section it says what EKR
points out

"This  option requires greater state to be stored on intermediate peers but
   saves a small amount of bandwidth and reduces the need for modifying
   the message en route.  Selection of this mode of operation is a
   choice for the individual peer;"

I think that maybe this should be changed and that the selection of this
mode whould be allowed by overlay configuration and may be overridden by a
flag. I am not sure why an intermediary should decide on the via list
content.

Roni Even

> Sent: Wednesday, February 09, 2011 9:42 PM
> To: Roni Even

---

From: Bruce Lowekamp <[email-masked]>
Date: Sun, 13 Feb 2011 20:16:13 -0500

There are some proposals for why an intermediate peer might wish to
use a compressed (opaque) via-list entry.  Mostly to do with hiding
some of the topology from other nodes.

To some extent, maybe the central question here is whether such
behavior should be controlled by routing flags or overlay flags, and
if a node wishes to hide topology, is it permissible for it to refuse
to route messages inconsistent with this goal, thus forcing nodes
trying to use other routing algorithms to fallback to more basic
routing techniques.

Roni, I think your suggestion of overlay parameters to restrict what
routing options are available would accomplish the same goals as the
routing flag (as far as enabling DRR-compliant forwarding), so I think
if you think that's compatible with what you want to accomplish and
are happy with it, we should go in that direction.

Bruce