At Mon, 02 Mar 2009 21:28:11 -0800,
Michael Chen wrote:
>
> Bruce,
>
> I have 2 suggestions for section "5.5.2.1. Framed Message Format" in the
> current Reload draft relevant to UDP fragmentation and retransmission.
> This section defined framed message as:
>
> enum {data (128), ack (129), (255)} FramedMessageType;
> struct {
> FramedMessageType type;
> select (type) {
> case data:
> uint24 sequence;
> opaque message<0..2^24-1>;
> case ack:
> uint24 ack_sequence;
> uint32 received;
> };
>
> Suggestion 1:
> The 24-bit length for the message payload is unnecessary and should be
> removed. The message is DTLS record, which has its own size and
> integrity check scheme. Also, the UDP packet carries its own packet size
> which is returned with the recvfrom() function on the UDP socket.
This framing is also going to be used with TLS, so you do need
the length there. I'd rather have a consistent framing than
save 3 bytes.
> Suggestion 2:
> Add a third message type "truncated (130)", which can be sent back by
> the receiver to indicate that the UDP packet was truncated, most likely
> due to a smaller MTU in either side. The receiver can easily detect
> this error state by verifying the DTLS record length against the UDP
> packet size.
>
> case truncated:
> uint24 ack_sequence;
> uint32 packet_size;
>
> The ack_sequence in a truncated reply is identical to a ack reply,
> except that the sender MUST retransmit this same sequence with a smaller
> packet size, which is hinted by the second value packet_size; The
> sender can also initiate a MTU discovery.
>
> If MTU discovery (before the first payload is sent) is mandated by later
> revision of this draft, then suggestion 2 can be ignored.
What sort of IP network element do you think would truncate UDP
datagrams? AFAIK, either they should be (1) sent intact (2) fragmented
or (3) dropped.
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
