After further thought, I think this is going to be addressed naturally by what tsvwg is doing in specifying proper tunneled protocols and ICE negotiation for them. I think it would be better to keep the base simple protocol as simple as possible, rather than adding the complexity of delayed ACK to it.
Bruce On Mon, Apr 19, 2010 at 2:40 PM, Bruce Lowekamp <[email protected]> wrote: > 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
