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
