Hi, Bruce: Thanks for advice. Some responses in line.
Regards Jiang XingFeng > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Bruce Lowekamp > Sent: Wednesday, July 15, 2009 11:06 AM > To: Roni Even > Cc: [email protected] > Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 > > 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. Thanks! > > 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. 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. > > 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. 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. > > 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. 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 protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
