Subject: [P2PSIP] Status of RELOAD

From: [email-masked]
Date: Tue, 22 Jan 2008 20:02:03 -0700

Hi Cullen,

RELOAD-1 was a solid protocol with strengths like the flexibility of TLV, 32-bit alignment, full 160-bit IDs, well defined symbolic values, etc.  By comparison, the ASP draft was pretty rough.  When these two merged into RELOAD-2, most of the RELOAD-1 pros were lost.  Is RELOAD-3 on its way?

Many fields in RELOAD-2 are variable size values or arrays, so why not use Type-Length-Value to make the protocol more "binary readable" and extensible?  RELOAD-1 defines a single fixed header and everything else in TLV.  That is too good to abandon, not to mention being a perfect construct for supporting multiple DHTs.

By the way, I have seen several drafts use 128-bit ID in fixed structures, which means truncating the low 32-bit of a SHA-1 hash.  Is there a potential risk?  Any formal paper about this?

Thanks

--Michael

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 23 Jan 2008 10:17:10 -0500

Michael,

Of course, there is always a new version of a draft on the way...

You're right that reload-01 used a very simple and uniform TLV
structure for everything.  The uniformity of that is nice, but it has
a couple of problems:
- because it allowed the various parameters to be in any order,
parsing it and locating elements of the structure was fairly
complicated.
- for fields that must be there exactly once and have a fixed length
(i.e. a uint32), it's a lot of overhead.

The goal of the reload-02 encoding structure was to get rid of the TLV
structure when it's not necessary.  i.e. when you know what type
you're encoding, give that type a predefined structure when it can
have one.  For example, in reload-02, the CONNECT request in 5.1.2.1
is a good example.  You know what the fields of a connect (it's
encoding the information needed by ICE) need to be.  In this case,
they can be variable length, and there can be varying numbers of
candidate addresses.  The structure there is of a predefined order,
but allows the length of each field to be specified.  Essentially, the
T of TLV isn't needed because we know the order of the types of a
CONNECT request.

Unfortunately, you're absolutely right in observing that the structure
used in reload-02 isn't as clear as it should be.  Basically, we ran
out of time.  There is an underlying type definition language being
used here (thanks to ekr) that ultimately would make things a lot
clearer and easier to implement, but right now it's a bit confusing
until you spend time with it.  I think ultimately this way of encoding
will be much easier to parse.

The header is still basically fixed.  It allows the via and route list
to vary (their order will be reversed in the next version, which will
simplify processing), but otherwise it's very similar.

I don't know of a formal paper on it, but 128-bits is more than enough
to provide reasonable guarantees of uniqueness.  Technically, if what
you do is truncate a hash (rather than using a hash that naturally
produces that length), as long as it's a good hash, all bits are
equally random, so truncating it is still safe.

Bruce

On Jan 22, 2008 10:02 PM,  <[email-masked]> wrote:
> Hi Cullen,
>
> RELOAD-1 was a solid protocol with strengths like the flexibility of TLV,
> 32-bit alignment, full 160-bit IDs, well defined symbolic values, etc.  By
> comparison, the ASP draft was pretty rough.  When these two merged into
> RELOAD-2, most of the RELOAD-1 pros were lost.  Is RELOAD-3 on its way?
>
> Many fields in RELOAD-2 are variable size values or arrays, so why not use
> Type-Length-Value to make the protocol more "binary readable" and
> extensible?  RELOAD-1 defines a single fixed header and everything else in
> TLV.  That is too good to abandon, not to mention being a perfect construct
> for supporting multiple DHTs.
>
>  By the way, I have seen several drafts use 128-bit ID in fixed structures,
> which means truncating the low 32-bit of a SHA-1 hash.  Is there a potential
> risk?  Any formal paper about this?
>
>  Thanks
>
>  --Michael

---

From: Michael Chen <[email-masked]>
Date: Wed, 23 Jan 2008 19:45:32 -0800

Bruce,

I appreciate the clarification and look forward to Reload-3. Just a 
reminder, in early December, Cullen and I had the following Q&A, which I 
hope to be formally defined in the upcoming draft.

Thanks

--Michael

On Nov 28, 2007, at 6:57 PM, Michael Chen wrote:
> I don't see where the protocol sends the originator's peer-ID. At the 
> end of section 4.1, it says the via list starts out empty and the 
> route list has the intermediate and destination peer IDs.  Say A wants 
> to reach C through B, then in the forwarding header sent by A, the 
> route-list contains [B, C], and the via list is empty.  Where does C 
> or B for that matter know the peer ID of A when it's time to send the 
> respond back?
>
> Should the via-list in the forwarding header sent by A contains the 
> peer ID of A?
Yes, we do need the A to get in the list,  but the ID is inserted by B. 
The logic behind this had to do with some security issues and logic 
about what B inserts. B actually inserts the peer it perceives the 
message came from. This helps with spoofing return routes by having 
responses go to where they came from. Sorry this email is brief, I will 
try and write a clearer one if this does make sense.