Subject: [P2PSIP] 32-bit length in ForwardingHeader of draft-ietf-p2psip-base-02

From: Michael Chen <[email-masked]>
Date: Thu, 07 May 2009 10:04:23 -0800

Hi,

In draft-ietf-p2psip-base-02, section 5.3.2, the Forwarding Header's 
length field was increased from 24-bit to 32-bit from version-01.  This 
change is unwarranted and should be reverted.

1) The maximum message size remain 24-bit (5.2.3. Message Contents 
Format, payload). There is no need to have a 32-bit length in the 
forwarding header.

2) This change throw off the alignment of all fields after 'length' in 
the header. They are now all start with an odd address offset, and the 
fixed portion of the header (up to options_length) is now an odd number.

This design incurs performance penalty on many hardware, and it requires 
clumsy software implementation. It is just ugly. Some common sense is in 
order.

Thanks

--Michael

---

From: glitch <[email-masked]>
Date: Thu, 07 May 2009 16:46:19 -0700

I second this as it is also a hack in my implementation, at least IMHO.

@Michael Do you have a public implementation for interoperability  
testing? I cannot locate one.

-g

On May 7, 2009, at 11:04 AM, Michael Chen wrote:

> length field was increased from 24-bit to 32-bit from version-01.   
> This change is unwarranted and should be reverted.
>
> 2) This change throw off the alignment of all fields after 'length'  
> in the header. They are now all start with an odd address offset,  
> and the fixed portion of the header (up to options_length) is now an  
> odd number.
>
> This design incurs performance penalty on many hardware, and it  
> requires clumsy software implementation. It is just ugly. Some  
> common sense is in order.
>
> Thanks
>
> --Michael
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Michael Chen <[email-masked]>
Date: Fri, 08 May 2009 07:38:05 -0800

g,

This thing is very much a moving target now. However, we do plan on 
releasing a close source free Windows binary when it levels off 
feature-wise. Stay tuned.

--Michael

glitch wrote:
>> in the header. They are now all start with an odd address offset, and 
>> the fixed portion of the header (up to options_length) is now an odd 
>> number.
>>
>> requires clumsy software implementation. It is just ugly. Some common 
>> sense is in order.
>>
>> Thanks
>>
>> --Michael

---

From: jolix <[email-masked]>
Date: Mon, 11 May 2009 00:34:56 -0700

M,
I am implementing a cross platform C++ library which will be open  
source and free. Will yours be "paid" and if not then why closed  
source? The reason I ask is if it misbehaves with my implementation  
the only reaction I can take is ban it and not investigate it. Then  
again this all depends on if your using central or shared security  
model and/or support both and if I retain Chord  "periodic  
stabilization" vs "cou" which the first creates churn even in the  
absense of said churn. :-)

thx
-g

On May 8, 2009, at 8:38 AM, Michael Chen wrote:

>>> In draft-ietf-p2psip-base-02, section 5.3.2, the Forwarding  
>>> Header's length field was increased from 24-bit to 32-bit from  
>>> version-01.  This change is unwarranted and should be reverted.
>>>
>>> 2) This change throw off the alignment of all fields after  
>>> 'length' in the header. They are now all start with an odd address  
>>> offset, and the fixed portion of the header (up to options_length)  
>>> is now an odd number.
>>>