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

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 2 Dec 2010 10:53:44 -0800

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
>

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 15 Dec 2010 16:01:06 -0500

> that, in that it wouldn't be explicitly tied to the DRR mechanism in

I think this is exactly what I would like to see.

My concern with the present routing mechanism is it is a bit
underspecified, and also that if we later flesh out a more detailed
one, there will be confusion. I definitely don't want to remove the
routing stuff completely -- we clearly need the flags -- but think the
current attempt at using it for direct routing is a bit
underspecified. I'd rather remove it (leaving the mechanism) so we can
get the next version out with as few changes as possible, and get
RELOAD published so we can move on to other work.

David (as individual)