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
