Subject: Re: [Tsvwg] Looking for feedback on DTLS

From: Murali Bashyam <[email-masked]>
Date: Wed, 19 Jan 2005 14:40:41 -0800

Eric

On a different note, how are the firewall requirements addressed here? 
Are there well-known ports involved (such as 443 for HTTPS) to traverse 
the firewall? How are dynamically negotiated ports handled?

Murali

EKR wrote:

>Murali Bashyam <[email-masked]> writes:
>
>  
>
>>EKR wrote:
>>
>>    
>>
>>>Murali Bashyam <[email-masked]> writes:
>>>
>>>      
>>>
>>>>I had a question on the congestion control aspect of the handshake
>>>>protocol in DTLS. The draft doesn't seem to address the congestion
>>>>control requirements of the handshake protocol such as how soon is it
>>>>okay to send an entire flight of packets into the network without
>>>>overloading it.
>>>>
>>>>        
>>>>
>>>We suggest a retransmit timer on the order of 500-1000 ms.
>>>
>>>      
>>>
>>I was referring more to the TCP capability of slow-start, where TCP
>>tries to probe the network
>>and expands its flight of packets gradually as opposed to sending the
>>entire flight in 1 shot.
>>    
>>
>That's true, but note that the current TCP initial window
>as specified in RFC 3390 is 3 packets with a 1460-byte MSS
>and 4 packets with a 512-byte MSS. This looks pretty similar
>to what you would see out of a DTLS implementation initially
>(though the TCP implementation would back off faster).
>
>  
>
>>Of course the point which u bring up that the
>>flight typically fits in 1-2 packets is true for 1500 MSS probably but
>>when MSS is 512 (the common MSS value on the Internet), this
>>immediately becomes 6 packets. 
>>    
>>
>
>Well, since we're talking about 2k-sized flights here, it's 4 packets,
>not 6 for a 512-byte MSS. 512 bytes is actually fairly conservative
>in the modern network. According to CAIDA's measurements [1],
>over half the TCP traffic by volume uses a 1500-byte packet size:
>
>     The primary features of this distribution originate in the way
>     common TCP implementations divide a data stream into
>     packets. Approximately 85% of the traffic in these traces is TCP,
>     and a large proportion of this TCP traffic is generated by bulk
>     transfer applications such as HTTP and FTP. Consequently, the
>     majority of the packets seen are one of three sizes: 40 byte
>     packets (the minimum packet size for TCP) which carry TCP
>     acknowledgments but no payload; 1500 byte packets (the maximum
>     Ethernet payload size) from TCP implementations that use path MTU
>     discovery; and 552 byte and 576 byte packets from TCP
>     implementations that do not use path MTU discovery.
>
>
>  
>
>>I just want to highlight that by
>>avoiding TCP for handshaking and implementing retransmissions and
>>timers solves only the reliability problem but doesn't address
>>congestion control including efficient retransmission possibilities
>>too.
>>    
>>
>I don't agree that we're not addressing congestion control.  We
>recommend an initial timer value of 500 ms with a typical doubling
>exponential backoff with each retransmit. (I know this isn't exactly
>what I said earlier, but I had to look it up to refresh my
>memory). Given the small amounts of data involved here, I think that's
>fairly congestion friendly.
>
>As for efficient retransmission, it's true that DTLS could be smarter
>(though with 1500 byte packets and medium-sized (order 1k) server cert
>payloads, there's not really much room for improvement) 
>but the overall improvement would be fairly modest and would introduce
>substantial additional complexity.
>
>  
>
>>>Of course, but we're talking extremely small amounts of data here.
>>>It's important to remember that in your average SSL handshake the
>>>total number of bytes exchanged is generally less than 3k and that
>>>the largest single flight (ServerHello ... ServerHelloDone) is
>>>typically less than 2k [1]. In most cases it will fit in 1-2 MTUs.
>>>
>>>      
>>>
>>True when the MSS is 1500, not when the MSS is negotiated to be
>>512. What about large certificates being sent by the server, that
>>would increase the number of messages?
>>    
>>
>
>1k is a fairly large certificate. It's quite uncommon to see a certificate
>chain larger than two certificates. That's where I got 2k from.
>
>-Ekr
>
>[1] http://www.caida.org/outreach/papers/2000/AIX0005/AIX0005.html#plen_hist
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/tsvwg
>  
>

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: EKR <[email-masked]>
Date: Wed, 19 Jan 2005 14:44:51 -0800

Murali Bashyam <[email-masked]> writes:
> Are there well-known ports involved (such as 443 for HTTPS) to
> traverse the firewall? 
I would expect that application layer protocols over DTLS would get their
own ports, just as with TLS.

> How are dynamically negotiated ports handled?
Badly, as with TLS :) I think that's out of scope...

-Ekr

---

From: Ben Laurie <[email-masked]>
Date: Fri, 21 Jan 2005 05:16:34 +0000

> the firewall? How are dynamically negotiated ports handled?

Don't forget that using well-known ports for TLS versions of protocols 
is deprecated.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff