Subject: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02

From: Roni Even <[email-masked]>
Date: Tue, 07 Jul 2009 09:07:47 +0300

Hi,

At the previous IETF meeting there was consensus to have direct response as
a WG item. The authors of the draft suggested that they will submit a new
revision with better text about the relay mode.

We did  a new revision now in
http://www.ietf.org/internet-drafts/draft-jiang-p2psip-relay-02.txt .  We
feel that we addressed the concerns that were raised during the IETF
meeting.

We are now looking for input about the draft and more specifically about the
relay mode in order to get a final consensus if to add this mode to the work
or only have the direct response mode.

Please review the draft.

Thanks

Roni Even

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 14 Jul 2009 23:05:31 -0400

I would like to see a couple changes in how the ideas in this draft
are implemented, but the concepts are basically sound.  I would
support adopting this draft as an extension.

Section 3 should probably reflect in its discussion that the DRR and
RPR responses require the establishment of a (D)TLS session before the
message is exchanged.  I think a precise analysis of the cost isn't
necessary, but the diagrams are a bit misleading in how many messages
are involved.

In Section 5.2, why not implement IGNORE-STATE-KEEPING as a
ForwardingOption with FORWARD_CRITICAL?  The WG can then discuss
whether to incorporate that into the base draft or leave it as an
extension.  Parenthetically, the state to be concerned about is not so
much the hop-by-hop retransmission, but state that may be kept if the
peer is keeping per-transaction forwarding state rather than encoding
it in the via-list.

Also in 5.2, with the changes in the via list structure, I think we
need to revisit adding an IP address as a DestinationType in an
extension.  I think the ForwardingOption works, but it smells a bit
too much like a hack to me.

Bruce

---

From: jiangxingfeng <[email-masked]>
Date: Thu, 16 Jul 2009 09:54:50 +0800

Hi, Bruce:

Thanks for advice. Some responses in line. 

Regards
Jiang XingFeng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bruce Lowekamp
> Sent: Wednesday, July 15, 2009 11:06 AM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02
> 

Thanks!
> necessary, but the diagrams are a bit misleading in how many messages

Right. I think it is better to illustrate transport connections between peers. (D)TLS Connections between peers or between source peers and relay peers are reused to send the requests. But for responses, in common case, (D)TLS connections should be established between destination peers and relay peers or source peers. Authors will improve the diagram in next version. 
> peer is keeping per-transaction forwarding state rather than encoding

The reason for defining IGNORE-STATE-KEEPING as a flag in forwarding header is there were a flag field in ForwardingHeader. I just noticed that flags field (unit16) has been removed in base-03. Adding IGNORE-STATE-KEEPING is to avoid intermediate peers keeping state in order to forward response what SRR requires if DRR or RPR will be used. If intermediate peers still keep per-transaction forwarding state in case of DRR or RPR, the state will have to expire when timer fired. 

I think it's feasible to define a new extension to implement IGNORE-STATE-KEEPING. It's up to WG decide which one will choose. A little concern about using a new forwarding option: if several forwarding options are in the same requests, so what's the relationship between forwarding options? IMO, some options are related, so peers need process them in atomic way. But some are irrelevant, so peers can process them in independent way. 
> too much like a hack to me.

Do you mean we need replace ExtensiveRoutingModeOption with a new type of destination? The only idea in my mind for how to achieve it is to make intermediate peers change its ways to encode via-list in case of RPR and DRR. Via-lists are populated by the source peers based on information of source peer and relay peers. In case of DRR and RPR, intermediate peers won't change via-list in transit. So that destination peers can use the via-lists to construct destination list for response. I think it works. Is that the same in your mind? 

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

---

From: Roni Even <[email-masked]>
Date: Wed, 22 Jul 2009 10:33:04 +0300

Hi Bruce,
Inline
Roni

> From: Bruce Lowekamp [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 6:06 AM
> To: Roni Even
> Cc: [email-masked]

You are right that the responder needs to establish (D)TLS session. We can add text explaining the link layer behavior for the response. It can also be used to find out if DRR connectivity exists.

> peer is keeping per-transaction forwarding state rather than encoding

I think that is what 5.2.1 says we will put the right language. The current text meant to have it in the forwarding option flags but the note asks if it should be specified in the forwarding option in the base draft.
Maybe this should be discussed in a separate thread with reload base as the topic. I think that there are two questions here
1. Should this flag be part of forwarding option flags in base draft. There is no registry for the flags
2. Should this flag be part of forwarding header since it may have other uses.

> too much like a hack to me.

This may be a good solution for DRR but I am not sure if it will work for the relay peer case since the relay may be used only in the response. Also the peer that sends the response will not know who is the relay from the via/destination list and the relay need to know who is the final receiver. So there is a need to give the response path which is not defined in base draft.
The use of the ForwardingOption is the way to extend the forwarding header.

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 22 Jul 2009 08:24:57 -0400

> 2. Should this flag be part of forwarding header since it may have other uses.

I agree we need to have the discussion of where this is defined.  I
personally believe it should be an option rather than part of the
header, but that's another issue for the WG to decide.  We removed the
flags from the header in -03 since we had no use for them.  Obviously
that's another issue where the WG can decide to add them back, but all
of this can be implemented with Forwarding Options rather than flags.

> The use of the ForwardingOption is the way to extend the forwarding header.

A requesting peer can preload the via-list with the relay peer and
itself to ensure that the desired response path is followed.

There does need to be a specification for a Forwarding Option that
prevents on-path peers from adding their own entries to the via list.
Whether that should be the state keeping or a separate option is an
interesting question.

Bruce