Subject: Re: [P2PSIP] Reload bcast and mcast discovery

From: Michael Chen <[email-masked]>
Date: Fri, 16 Apr 2010 17:23:35 -0700

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-masked] <mailto:[email-masked]>>
>> Date: Thu, April 15, 2010 2:02 pm
>> To: Michael Chen <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> 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
>>
>>
>

---

From: jc <[email-masked]>
Date: Fri, 16 Apr 2010 21:11:18 -0400

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-masked]>  
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);
>
> fragment, which is also inside the boundary of DATA_frame (the 24- 
> bit frame size).
>
> Am I right?
>
> --Michael
>
>
> jc wrote:
>>
>>> To: Michael Chen <[email-masked] <mailto:[email-masked] 
>>> >>
>>>
>>> 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?
>>>
>>>
>>> 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?
>>>
>>>
>> 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
>>>
>>>
>>

---

From: Michael Chen <[email-masked]>
Date: Mon, 19 Apr 2010 09:55:49 -0700

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:
>>>> 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?
>>>>
>>>>
>>> headaches that I know currently exist and as you mention will reduce 
>>> traffic by 50% under certain conditions.
>>>
>>>> --Michael
>>>>
>>>>
>>>
>
>

---

From: jc <[email-masked]>
Date: Mon, 19 Apr 2010 13:51:53 -0400

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).
> 
> 3. Discard the first 9 bytes, and handles the remaining PDU as a normal DATA frame (deserialize).
> 
> --Michael
> 
> jc wrote:
>> On Apr 16, 2010, at 8:23 PM, Michael Chen <[email-masked]> 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);
>>> 
>>> 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:
>>>> 
>>>>> To: Michael Chen <[email-masked] <mailto:[email-masked]>>
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>> 
>> 
>>

---

From: Michael Chen <[email-masked]>
Date: Mon, 19 Apr 2010 12:26:05 -0700

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

---

From: jc <[email-masked]>
Date: Mon, 19 Apr 2010 15:59:03 -0400

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-masked]>  
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,
>>
>>> 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).
>>>
>>>>> 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);
>>>>>
>>>>> 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:
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> response message in the same UDP packet? The response PDU  
>>>>>>> would look like this:
>>>>>>>
>>>>>>>
>>>>>>> [ACK_frame]
>>>>>>>
>>>>>>> [DATA_frame]
>>>>>>>
>>>>>>> [RELO_header]
>>>>>>>
>>>>>>> [RELO_message]
>>>>>>>
>>>>>>> [Security block]
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
>>
>>
>>

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 19 Apr 2010 14:40:46 -0700

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-masked]> wrote:
> On Apr 19, 2010, at 3:26 PM, Michael Chen <[email-masked]> wrote:
>
>> Julian,
>>
>>>>>> 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);
>>>>>>
>>>>>> fragment, which is also inside the boundary of DATA_frame (the 24-bit frame
>>>>>> size).
>>>>>>
>>>>>> Am I right?
>>>>>>
>>>>>> --Michael
>>>>>>
>>>>>>
>>>>>> jc wrote:
>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>> this point, which is why I am hesitated to do it. However, I do have an
>>>>>>>> alternative.
>>>>>>>>
>>>>>>>>
>>>>>>>> response message in the same UDP packet? The response PDU would look like
>>>>>>>> this:
>>>>>>>>
>>>>>>>>
>>>>>>>> [ACK_frame]
>>>>>>>>
>>>>>>>> [DATA_frame]
>>>>>>>>
>>>>>>>> [RELO_header]
>>>>>>>>
>>>>>>>> [RELO_message]
>>>>>>>>
>>>>>>>> [Security block]
>>>>>>>>
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> 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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>