Subject: Re: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issue

From: "Michael Chen" <[email-masked]>
Date: Thu, 22 Dec 2011 17:33:24 -0700

Roland,

I believe the fragment bits design is fine as it is, but the language
could be clarified or further restricted. Having the high bit 0x80000000
consistently set for all fragments (first, middle, last) makes more
sense than any other alternatives.

There are certainly some overlapped definitions here, for example,
0xC0000000 and 0x00000000 can both indicate a non-fragmented message.
However, if you only adhere to the definitions of 0x80000000, 0x40000000
and the low 24 bits, it works just fine. Consider these 3 definitions
supersede all other combinations and special cases.

Thanks

--Michael

> -------- Original Message --------
> Subject: Re: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issue
> From: Roland Bless <[email-masked]>
> Date: Wed, December 21, 2011 1:20 pm
> To: Marc Petit-Huguenin <[email-masked]>
> Cc: [email-masked]
> 
> 
> On 21.12.2011 18:54, Marc Petit-Huguenin wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Hi Roland,
> >
> > You may consider subscribing to the RELOAD implementers mailing-list:
> >
> > http://implementers.org/mailman/listinfo/reload
> >
> > One comment below.
> 
> >> And Section 5.7 states:
> >>     If the message is not fragmented, then both the
> >>     first and last fragment bits are set to 1 and the offset is 0
> >>     resulting in a fragment value of 0xC0000000.  Note that this means
> >>     that the first fragment bit is always 1, so isn't actually that
> >>     useful.
> >> - the last sentence is a somewhat weird statement
> >
> > For reference, here's the email exchange for this text (search for "A.20"):
> >
> > http://www.ietf.org/mail-archive/web/p2psip/current/msg05801.html
> 
> Thanks for the pointer, but its doesn't make it more reasonable.
> IMHO it just provides a hint that something is broken: if it is
> always set to 1, it doesn't provide any useful information, so
> you could simply leave it out. Not sure how it was actually meant
> to be used, but if it was indicating "first fragment" then it is
> set for the first fragment and for non-fragmented packets together
> with the last fragment bit. For all intermediate fragments it
> probably had to be set to zero, so then it would have changed.
> I think that my proposed definition is less confusing to
> implementers and protocol debugging people.
> 
> Regards,
>   Roland
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip