Re: [P2PSIP] Status of RELOAD

["Bruce Lowekamp" <[e-mail]>]

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,  <[e-mail]> 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
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>

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