I'm a bit hesitant to support a decision based on message length, though I can't think of a reason it wouldn't work, so I'm not opposed to it offhand, either. However, this is still a draft, and if a change is needed to the base protocol to make it work well, we should do that.
Bruce On Mon, Apr 19, 2010 at 12:59 PM, jc <[email protected]> wrote: > Right. Assuming the ack frame remains the same size this is the best > solution short of base protocol change to support this. > > Sent from my iPhone > > On Apr 19, 2010, at 3:26 PM, Michael Chen <[email protected]> wrote: > >> Julian, >> >> Yes (with correction): "guess if there is an DATA frame based on the UDP >> packet size of an ACK frame". >> >> If you want further confirmation, verify that the 10th byte (just beyond >> the ACK frame) in the packet is DATA(128). >> >> --Michael >> >> >> jc wrote: >>> >>> Michael, >>> >>> So your saying we should guess if there is an ack frame based on packet >>> size? >>> >>> Julian >>> >>> On Apr 19, 2010, at 12:55 PM, Michael Chen wrote: >>> >>> >>>> Julian, >>>> >>>> There is no different in deserializing this and the Reload message >>>> itself, both are full of variable length and nested structures. It's >>>> actually a lot simpler, >>>> >>>> 1. Receive a UDP packet (after DTLS decryption) that starts with ACK >>>> (129) but the packet is size greater than 9 (size of ACK frame). >>>> >>>> 2. Consume the first 9 bytes and handles the ACK frame. >>>> >>>> 3. Discard the first 9 bytes, and handles the remaining PDU as a normal >>>> DATA frame (deserialize). >>>> >>>> --Michael >>>> >>>> jc wrote: >>>> >>>>> Yes but that's darn ugly and would be a deserialization nightmare. :-) >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Apr 16, 2010, at 8:23 PM, Michael Chen <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>>> Julian, >>>>>> >>>>>> UDP transport requires the reload fragment to fit in a single MTU size >>>>>> packet after DTLS encryption. In this case, after DTLS decryption, you >>>>>> get a >>>>>> PDU with known size. Each element in this PDU has their own account of >>>>>> their >>>>>> size. Therefore, >>>>>> >>>>>> sizeof(ACK_frame) == 5; >>>>>> sizeof(DATA_frame) == >>>>>> sizeof(RELOAD_header) + >>>>>> sizeof(RELOAD_message) + >>>>>> sizeof(Security_block); >>>>>> >>>>>> sizeof(PDU) == sizeof(ACK_frame) + sizeof(DATA_frame) >>>>>> >>>>>> If the message is fragmented, then this only applies to the first >>>>>> fragment, which is also inside the boundary of DATA_frame (the 24-bit >>>>>> frame >>>>>> size). >>>>>> >>>>>> Am I right? >>>>>> >>>>>> --Michael >>>>>> >>>>>> >>>>>> jc wrote: >>>>>> >>>>>>> On Apr 15, 2010, at 7:06 PM, Michael Chen wrote: >>>>>>> >>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: Re: Reload bcast and mcast discovery >>>>>>>> From: jc <[email protected] <mailto:[email protected]>> >>>>>>>> Date: Thu, April 15, 2010 2:02 pm >>>>>>>> To: Michael Chen <[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>> >>>>>>>> Right, sorry I keep thinking in the context of ALL messages. Pings >>>>>>>> will work ok using this method but currently no other PDU's because of >>>>>>>> possible need to fragment. In order to support this changes to the base >>>>>>>> draft would need to occur allowing messages without a framing header >>>>>>>> unless >>>>>>>> you have a way around this? >>>>>>>> >>>>>>>> >>>>>>>> I guess it is unlikely the group will accept frameless message at >>>>>>>> this point, which is why I am hesitated to do it. However, I do have an >>>>>>>> alternative. >>>>>>>> >>>>>>>> >>>>>>>> What if the base draft allows sending the ACK frame with the >>>>>>>> response message in the same UDP packet? The response PDU would look >>>>>>>> like >>>>>>>> this: >>>>>>>> >>>>>>>> >>>>>>>> [ACK_frame] >>>>>>>> >>>>>>>> [DATA_frame] >>>>>>>> >>>>>>>> [RELO_header] >>>>>>>> >>>>>>>> [RELO_message] >>>>>>>> >>>>>>>> [Security block] >>>>>>>> >>>>>>>> >>>>>>>> This keeps the compatibility of framing header and Simple >>>>>>>> Reliability for UDP (it's the same logical order of PDUs in TCP). This >>>>>>>> usage >>>>>>>> can be extended to include regular link layer responses when the >>>>>>>> response is >>>>>>>> single hopped like bootstrap node discovery. What do you think? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I think that "piggybacking" ack frames to response's is much needed >>>>>>> and I welcome this change. This would solve any ack related headaches >>>>>>> that I >>>>>>> know currently exist and as you mention will reduce traffic by 50% under >>>>>>> certain conditions. >>>>>>> >>>>>>> >>>>>>>> --Michael >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>> >>> >>> >>> > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
