Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission

From: [email-masked]
Date: Tue, 03 Mar 2009 04:30:57 -0700

Eric,

-------- Original Message --------

Subject: Re: [P2PSIP] proposal for reload congestion control,

fragmentation, and retransmission

From: Eric Rescorla <[email-masked]>
...

> 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.

My thought section 5.2.2 is for unreliable link (UDP/DTLS) only. I assume the TLS record layer is sufficient for TCP. Even if framing is used for TCP, wouldn't it be using rfc4571 as suggested by draft-ietf-mmusic-ice-tcp-07? Please clarify.

Please ignore suggestion 2. I misread the Linux man page for udp(7).

Thanks

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 03 Mar 2009 10:01:48 -0800

[Note: please figure out how to send plaintext email. HTML is
not convenient for me]

At Tue, 03 Mar 2009 04:30:57 -0700,
> > This framing is also going to be used with TLS, so you do need<br>
> >  the length there. I'd rather have a consistent framing than<br>
> > save 3 bytes.<br>
> 

> My thought section 5.2.2 is for unreliable link (UDP/DTLS) only.

Editorial error. It was our intent that everything be framed.

> I
> assume the TLS record layer is sufficient for TCP.

TLS does not preserve write boundaries.

> Even if framing
> is used for TCP, wouldn't it be using rfc4571 as suggested by
> draft-ietf-mmusic-ice-tcp-07? Please clarify.

No, that's at the wrong layer--below TLS rather than above.

-Ekr