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

From: "Amit Jain" <[email-masked]>
Date: Tue, 28 Dec 2004 06:53:08 -0800

I would like to submit following inputs as the feedback:
 
Current draft proposes to add fragmentation, reliability and in-order
delivery to handshake layer while keeping the record layer mostly
unchanged. 
 
Draft seems to imply that the handshake layer sends a collection of
handshake messages (referred as flight) and then waits for the other end
to respond. The timeout causes all the messages in flight to be
retransmitted. 
 
Here the reliability is being tracked for a complete flight of messages
as a single unit. Given that a flight can have considerable amount of
data, the probability of packet loss seems to be high. And since each
packet loss causes complete flight to be retransmitted, this may be a
large retransmission again. And this may again suffer a packet loss. I
think tracking reliability on per flight and retransmitting complete
flight as a response to packet loss may not be an efficient approach.
 
Also building the reliability and in-order delivery into handshake layer
makes handshake state machine complicated.

I think another approach worth considering may be to introduce a thin
layer inside record layer which takes care of fragmentation,
reliability, in-order delivery to record layer. In this approach:
 
1: A Handshake message can never span multiple records. A record can
contain multiple handshake messages though.
 
This will eliminate the need of handshake message re-assembly.
Assembling a record will always result in at least one complete
handshake message or multiple complete handshake messages.
 
This is different from the current specification where the handshake can
span multiple records. And will need the change in length field of
record layer (it'll have to be extended to 3 bytes)

2: Records are fragmented and is converted to UDP datagram. 
 
These UDP data-grams are then transmitted reliably to other end in the
handshake phase using a very thin layer (built into record layer). It
may be analogous to a simple reliable variant of UDP (something like
TFTP). Here the reliability is tracked for each UDP datagram and only
the missing UDP datagram is re-transmitted.

This may provide following advantages:
 
1: Handshake layer will be similar to the TLS. There won't be any change
needed in the implementation of state machine and the specification of
handshake messages.
 
2: A Record can span multiple UDP packets; this will free DTLS from
strict need of having a correct path MTU.
 
2: Record layer will consist of a thin reliability layer; this layer
will be active during handshake phase and will make sure the reliable
ordered delivery of the handshake messages. During application data
transfer the reliability part of the record layer is switched off.
(Actually this'll mostly depend on the application, and if application
wants to use reliability mode of record layer, that should be possible
too.)
 
3: Having a thin reliability layer in Record layer will allow greater
flexibility and extensibility. Reliability layer can be replaced with
other reliability mechanism like DCCP in future for providing
reliability/congestion control.

Thanks,
-amit
 
> Eric Rescorla wrote:

> As we all know, TLS is popular but is only compatible with reliable
> transports. Unfortunately, a number of important protocols (SIP in
> particular) run over datagram transport and therefore cannot use TLS.
In
> response, Nagendra Modadugu and I have designed a variant of TLS which
> we call Datagram TLS (DTLS).  DTLS consists of only the minimal
changes
> required to TLS to make it operate on datagram transport.

> We've submitted DTLS as an I-D which you can find at:
> draft-rescorla-dtls-01.txt

> You can also read our paper on DTLS from ISOC NDSS at:
> http://crypto.stanford.edu/~nagendra/papers/dtls.pdf

> We've already gotten some useful comments from PMTUD people about
> handling PMTU but any comments TSV people have on the protocol would
be
> appreciated.

> Best,
 >-Ekr

_______________________________________________
tsvwg mailing list
tsvwg at ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

 
_______________________________________________
tsvwg mailing list
tsvwg at ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: EKR <[email-masked]>
Date: Tue, 28 Dec 2004 09:31:12 -0800

> I would like to submit following inputs as the feedback:
Amit,

Thanks for your comments. Responses below.

> delivery to handshake layer while keeping the record layer mostly
That's a fair summary, yes.

> to respond. The timeout causes all the messages in flight to be

Yes, that's correct. We considered a cumulative ACK as in TCP
(see Section 4.4 of the DTLS paper) but we ultimately decided that
it wouldn't add that much efficiency improvement and it of
course makes life more complicated. Our initial measurements
seem to support that, but it would of course be very easy to
add ACKs later.

> large retransmission again. And this may again suffer a packet loss.

Yes, that's correct, but it's fairly unlikely to be the SAME packet.
You keep going until you've received all the bytes at least once,
not until a given flight comes through intact.

> makes handshake state machine complicated.
Yes, that's correct. However, the complexity is relatively minimal,
at least in our implementation. 

> reliability, in-order delivery to record layer. In this approach:
Yes. We considered this approach.  However, we were concerned about
designing a generic reliability layer. Designing reliable transport
protocols is difficult, as evidenced by the fact that we're still
working on TCP after 20+ years. Our feeling was that as the only real
requirement was to make the handshake reliable it was best to tie the
reliability into the handshake process and thus avoid the complexity
and rathole potential of trying to design something more
general. Moreover, there is experience with this kind of state machine
from IKE and other similar protocols.

> handshake message or multiple complete handshake messages.

Of course. But it will replace it with record reassembly, which
is basically the same problem.

> record layer (it'll have to be extended to 3 bytes)

Just a clarification: you mean "the current TLS specification" here,
correct? TLS currently has this feature. 

> needed in the implementation of state machine and the specification of
That's sort of correct, except that the handshake state machine
will need to do signalling to the record layer about when it wants
reliability. It's also important to note that the DTLS handshake
reliability layer lives mostly at the level of the DTLS handshake
wrapper. The handshake payloads themselves don't change.

> strict need of having a correct path MTU.
Not really. The DTLS handshake doesn't need an exact PMTU. It
just needs an approximate PMTU estimate to make sure that its own
messages get through. Typically it's the applications which need
a PMTU estimate because they actually want to send data in
a single UDP datagram. That's what their non-DTLS behavior
is, after all.

Actually, the approach you suggest makes the PTMU problem
worse in some ways. In the current design, the DTLS implementation
can mostly punt the process of PMTU discovery off to the application.
Because the HS is fairly short, it can use a safe PMTU for its
own traffic and then let the application send large messages until
it becomes clear that it can't. This lets the app use PMTU
discovery mechanisms that are better than those described in
RFC 1191. (Note that this isn't exactly what the DTLS draft
says because I just worked it out recently, but it's a fairly
minor change that doesn't affect interop).

By contrast, if DTLS is in the business of fragmenting data
records, then it has to do so efficiently, which means that
it really needs to know the PMTU. Otherwise, it's at risk
of making fragments that are way too small. I suppose you
could say you'll only fragment handshake records, but that's
kind of a layer violation inside TLS.

> transfer the reliability part of the record layer is switched off.
This is actually fairly problematic. Remember that in TLS the
handshake and application data can be interlaced during the
rehandshake process. So, it's not a simple matter of reliability
being "on" or "off". You certainly don't want to suddenly
turn applications that expect unreliable semantics into reliable
ones just because they're rehandshaking. (This is a special
problem if the reliability layer provides in-order delivery as
well, which is what's required if you want to not change the
handshake layer at all).

> wants to use reliability mode of record layer, that should be possible
I think this illustrates the point I made above about genericity.
The transport requirements for the handshake phase of TLS, which
is short and doesn't move a lot of data, are very different from
the requirements for a generic data transport protocol such as
is provided by the DTLS/TLS record layer. If you're going to
use your reliability layer for data, you're going to want much
better efficiency and congestion control guarantees and suddenly
you're reinventing TCP and SCTP.

> reliability/congestion control.

Well, DCCP wouldn't do the job here since it ONLY provides congestion
control and not reliability. DTLS will of course run fine over DCCP.
It just doesn't make the problem any easier. Michael Tuexen and I
are currently talking about the interaction of DTLS and SCTP, but
I don't think that's a universal solution.
   
-Ekr

---

From: Murali Bashyam <[email-masked]>
Date: Tue, 28 Dec 2004 12:53:50 -0800

Hi

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. I think there's also a problem in retransmitting the 
entire flight when 1 packet in that flight from the original 
transmission got dropped because it starts burdening an already 
congested network. And it's clear from simulation and experience that 
it's more efficient to use TCP mechanisms such  as SACK/NewReno/Reno  to 
recover from scenarios where multiple packets/single packet drop occurs 
in that flight of packets.

Are we really convinced that the amount of code in terms of development 
effort, testing, risk etc to add to handshake protocol to bring in 
in-order delivery, reliability, congestion control etc is less than 
simply addressing the issues that arise as a result of doing split 
channel? It wasn't clear to me that the draft compared the details 
involved in the two approaches.

Murali

---

From: EKR <[email-masked]>
Date: Tue, 28 Dec 2004 14:27:35 -0800

Murali Bashyam <[email-masked]> writes:
> overloading it.
We suggest a retransmit timer on the order of 500-1000 ms.

> I think there's also a problem in retransmitting the
> it's more efficient to use TCP mechanisms such  as SACK/NewReno/Reno
> to recover from scenarios where multiple packets/single packet drop
> occurs in that flight of packets.

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.

Obviously, one could optimize this interaction some, but if you're
in a situation where DTLS handshakes represent a significant fraction
of your network congestion, you've got some really serious problems
that marginally better retransmission response is not going to fix.

> Are we really convinced that the amount of code in terms of
> development effort, testing, risk etc to add to handshake protocol to
> bring in in-order delivery, reliability, congestion control etc is
> less than simply addressing the issues that arise as a result of doing
> split channel? It wasn't clear to me that the draft compared the
> details involved in the two approaches.

It's not addressed in the draft, however we do discuss this point in
S 2.2 of our ISOC NDSS paper[2]. The implementation cost of
adding the timeout and retransmission is relatively small and there
are a number of significant difficulties with using multiple channels,
in particular wrt. during-connection rehandshake.

-Ekr

[1] D. Boneh, H. Shacham, E. Rescorla, "Client Side Caching for TLS",
to appear in ACM TISSEC. 
http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf

[2] N. Modadugu and E. Rescorla, "The Design and Implementation of
Datagram TLS", Proc ISOC NDSS 2004.
http://crypto.stanford.edu/~nagendra/papers/dtls.pdf

---

From: Murali Bashyam <[email-masked]>
Date: Tue, 28 Dec 2004 14:55:01 -0800

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

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

Murali

---

From: EKR <[email-masked]>
Date: Tue, 28 Dec 2004 20:59:54 -0800

Murali Bashyam <[email-masked]> writes:

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

> 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