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

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 3 Jan 2011 17:00:47 -0500

I support this.

Bruce

On Wed, Dec 15, 2010 at 4:01 PM, David A. Bryan <[email-masked]> wrote:
> I think I would be most happy with your suggestion:
>
>> 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.
>
> 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)
>
>
> On Thu, Dec 2, 2010 at 1:53 PM, Bruce Lowekamp <[email-masked]> wrote:
>> 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: Roni Even <[email-masked]>
Date: Thu, 06 Jan 2011 16:07:56 +0200

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
> 
> >> 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
> >>
> >>
> >>
> >>

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 7 Jan 2011 17:29:34 -0500

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jan 2011 04:38:26 -0800

Done.

-Ekr

On Nov 18, 2010, at 3:21 PM, Michael Chen wrote:

> Bruce and Eric,
> 
> I am submitting some proposed changes to the base-12 draft based on
> the Attach Race Condition discussion as follows (leading "-" is
> deletion, "+" is addition):
> 
> 5.4.2.3. Update
>   ...
>   the state change.  In general, peers send Update messages to all
>   their adjacencies whenever they detect a topology shift.
> +
> +  When a peer receives an Attach request with the send_update flag
> +  set to "true" (see 5.5.1.1), it MUST send an Update message back
> +  to the sender of the Attach request after the completion of the
> +  corresponding ICE check and TLS connection. Note that the sender
> +  of a such Attach request may not have joint the overlay yet.
> 
> 
> 5.5.1.2. Response Definition
> -
> -  If a peer receives an Attach request, it MUST process the request and
> -  SHOULD generate its own response with a AttachReqAns.  A peer which
> -  is overloaded or detects some other kind of error may of course
> -  generate an error instead of an AttachReqAns.  It should then begin
> -  ICE checks.  When a peer receives an Attach response, it SHOULD parse
> -  the response and begin its own ICE checks.
> +
> +  If a peer receives an Attach request, it MUST determine how to process
> +  the request as follows:
> +
> +  o  If it has not initiated an Attach request to the originating peer
> +     of this Attach request, it MUST process this request and SHOULD
> +     generate its own response with an AttachReqAns. It should then
> +     begin ICE check.
> +
> +  o  If it has already sent an Attach request to and received the
> +     response from the originating peer of this Attach request, and
> +     as a as a result, an ICE check and TLS connection is in progress,
> +     then it SHOULD generate an error instead of an AttachReqAns.
> +     [[I suggest adding a new error number for this condition.]]
> +
> +  o  If it has already sent an Attach request to but not yet received
> +     the response from the originating peer of this Attach request,
> +     it SHOULD apply the tie-breaker heuristic to determine how to
> +     handle this Attach request and the incomplete Attach request it
> +     has sent out.
> +
> +     The tie-breaker heuristic is to compare the Node-IDs of both
> +     peers as unsigned integers, and
> +
> +     *  If the peer's own Node-ID is smaller, it MUST cancel its
> +        own incomplete Attach request. It MUST then process this
> +        Attach request, generate an AttachReqAns response, and
> +        proceed with the corresponding ICE check.
> +
> +     *  If the peer's own Node-ID is larger, it MUST generate an
> +        error to this Attach request, then proceed to wait for
> +        and complete the Attach and the corresponding ICE check
> +        it has originated.
> +
> +  o  If the peer is overloaded or detects some other kind of error, it
> +     may generate an error instead of an AttachReqAns.
> +
> +  When a peer receives an Attach response, it SHOULD parse
> +  the response and begin its own ICE checks.
> 
> 
> Feel free to change and discuss further.
> 
> Thanks
> 
> --Michael
> 
> 
> On 11/16/2010 11:53 AM, David A. Bryan wrote:
>> At the meeting, the following issues were presented related to the
>> RELOAD base draft. As planned, I have cut and pasted the proposals
>> from Ekr's slides here to take the discussion to list.
>> 
>> Except as noted, there was no discussion on the issue in the meeting,
>> and unless there is list discussion, the proposals mentioned for the
>> open issues without discussion will be deemed as consensus (for the
>> TODOs noted, we assume they will be completed).
>> 
>> As the draft is very close to going to the editor, if you have issues,
>> speak up quickly!
>> 
>> David (as chair)
>> 
>> 
>> SLIDES/ISSUES WITH DISCUSSION/OPEN ISSUES RAISED FOR MAILING LIS
> ...
>> Join race condition I (Michael Chen)
>> • §9.4: – Step 7: routing table from AP → JP – Step 8: routing table
>> from AP → NP
>> • In some cases (e.g., Chord predecessors) this may cause simultaneous
>> connects between JP and it’s new neighbors
>> Proposed Resolution: Tiebreaker when multiple connections are
>> established between a pair of nodes. Terminate the connection
>> originating from the smaller Node-Id seems like a natural choice.
>> ***NOTE: There was significant list discussion ongoing at the time
>> this slide was presented. Need to reach consensus on list for this
>> item.
> ...
>> ______________________________________________
>> P2PSIP mailing list
>> [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jan 2011 02:40:24 -0800

I've made this change.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Mon, 31 Jan 2011 08:54:16 +0200

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

> From: Bruce Lowekamp [mailto:[email-masked]]
> Sent: Saturday, January 08, 2011 12:30 AM
> To: Roni Even
> Cc: David A. Bryan; P2PSIP WG
> > 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
> >
> >> 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
> >> >>> 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
> >> >>> There were some comments that this was incomplete, and
> discussion
> >> of