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
