Re: [P2PSIP] Peer protocol, DHT and running code

[Emil Ivov <[e-mail]>]

Hello Krishna,

Krishna Sankar (ksankar) wrote:
> a)    Enrico, are you using XPP to achieve reliable UDP ?

Reliability is only one of the transport features that we'd need in an 
overlay maintenance protocol. We'd also like to be able to turn it off, 
make it handle fragmentation and remain as light as possible in the same 
time.

> b)    Did you consider SCTP ? Any glaring problems ?

SCTP has a lot of functionality that we don't need, such as: recording 
paths, transporting multiple flows simultaneously, etc. Then, I am also 
wondering how many of the existing NATs and firewalls would let it pass.

> c)    Knowing that TCP is very well optimized in all the devices incl 
> the NICs, why should we explore XPP/RDP et al ?

You may want to have a look at Enrico's reply to Philip, but here's a 
summary: We need it to behave as well as possible behind NATs. We'd like 
to be able to turn reliability off. We'd like it to remain a light and 
easy to implement solution.

> d)    What is our goal ? 

First, make sure that it would work in as many cases as possible. In 
other words we'd like to handle any NAT or firewall that would let UDP 
pass through.

Second, keep it as lite and easy to implement as possible.

Cheers
Emil



> The perfect protocol or a "good-enough" one 
> that has maximum co-existence ?


>  
> I am just asking, no judgment calls.
>  
> Cheers
> <k/>
> 
>     ------------------------------------------------------------------------
>     *From:* Philip Matthews [mailto:[e-mail]]
>     *Sent:* Tuesday, June 19, 2007 5:06 PM
>     *To:* Adam Fisk
>     *Cc:* Emil Ivov; P2PSIP Mailing List
>     *Subject:* Re: [P2PSIP] Peer protocol, DHT and running code
> 
>     Adam:
> 
>     I was not familiar with RDP, but I took a quick look.
>      From what I can see, RDP is an old protocol that who state is
>     roughly comparable to the original specification of TCP.
>     As such, it does not have all the enhancements that TCP has
>     undergone over the years (congestion control, etc.).
>     My guess is that the IESG would strongly urge us to look at TCP,
>     SCTP, and DCCP (the latter two having been
>     invented with all the existing TCP work in mind) before trying
>     to resurrect RDP.
> 
>     Furthermore, using a transport protocol other that TCP or UDP means
>     that we have to do all the work to define
>     how SIP and other protocols get transported over this transport
>     protocol. I don't think we should underestimate
>     how much time that would take.
> 
>     - Philip
> 
> 
>     On 19-Jun-07, at 18:17 , Adam Fisk wrote:
> 
>>     I'm wondering if you considered the "Reliable Data Protocol (RDP)"
>>     for the peer protocol.  It's at
>>     http://www.faqs.org/rfcs/rfc1151.html. 
>>
>>     Seems like an oldie but a goodie with many of the same
>>     characteristics, although I don't believe there's the option to
>>     turn off reliability.  Are you thinking something like XPP would
>>     be easier to implement?  RDP at least has addressed all the thorny
>>     reliability details. 
>>
>>     It seems to me the session negotiation issues could be worked out
>>     for any of these since ICE is designed to be relatively transport
>>     agnostic with a little SDP fiddling.
>>
>>     I agree the NAT hold punching is a little more straightforward
>>     with UDP since you just have more control over the timing of
>>     packets, making something along these lines worthwhile.
>>
>>     -Adam
>>
>>
>>     On 6/17/07, *Enrico Marocco* < [e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Folks,
>>
>>         Emil and I have just submitted two drafts specifying the peer
>>         protocol
>>         (XPP) and the overlay algorithm (CAN based) we have
>>         implemented in the
>>         last version of sipdht
>>         (http://sipdht.sourceforge.net/sipdht2/).  Till
>>         they appear in the repository, you can find them at the
>>         following links
>>         (just s/txt/html/ or s/txt/xml/ if you prefer html or xml):
>>         http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt
>>         <http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt>
>>         http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-pcan-00.txt
>>
>>         We hope this contribution will stimulate discussion on some
>>         key issues
>>         we've tried to address, among which:
>>
>>         + transport and encoding for the peer protocol;
>>         + DHT algorithm;
>>         + peer joins.
>>
>>         On the latter, we propose a mechanism to let nodes join the
>>         overlay only
>>         when they are explicitly invited by existing peers.  Such a
>>         "passive"
>>         approach (yeah, Dean anticipated that the term was going to get
>>         overloaded) has some benefits which deserve to be investigated.
>>
>>         Needless to say, any feedback is very very appreciated.
>>
>>         --
>>         Ciao,
>>         Enrico
>>
>>         _______________________________________________
>>         P2PSIP mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www1.ietf.org/mailman/listinfo/p2psip
>>
>>
>>
>>     _______________________________________________
>>     P2PSIP mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www1.ietf.org/mailman/listinfo/p2psip
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip