Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02)

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Apr 2014 12:13:33 -0700

Harald said:
"My memory was faulty; I had thought that the same conclusion had applied
for TCP ICE candidates as for TURN ICE candidates. Version -04 will have
this fixed."

[BA]  My memory was similarly faulty. But assuming the problem is with my
memory as opposed to the minutes, the decision to require support for ICE
TCP brings to mind other questions such as:

a. Is support for RFC 4571 (framing of RTP/RTCP over connection oriented
transport)  also mandated?  With respect to JSEP, what about RFC 4145
(TCP-based media transport in SDP )?
b. Are there any implications for transport of DTLS/SRTP key management?
 (e.g. if ICE TCP is needed because UDP transport is blocked, wouldn't that
also cause the DTLS/SRTP key exchange to fail?)
c. Are there any implications for the data channel?  (e.g. if UDP transport
is blocked, wouldn't SCTP/DTLS/UDP also not work?)

On Mon, Mar 31, 2014 at 8:08 AM, Harald Alvestrand <[email-masked]>wrote:

>  On 03/31/2014 03:54 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
>
> Hi Harald,
>
> The decision in London to make ICE-TCP a "MUST" has not been implemented in the -03 draft
> (I have noticed you have reflected the related TURN-TCP discussion already).
>
> What are your plans for addressing the ICE-TCP decision?
>
>
> Thanks!
>
> Checking the minutes, I find:
>
>
> Chairs called a hum between the alternatives:
>
> 1) TCP ICE Candidates are MUST implement
> 2) TCP ICE Candidates are SHOULD/MAY implement
> 3) TCP ICE Candidates will not be discussed in document.
>
> The hum indicated very strong support for 1).
>
>
> My memory was faulty; I had thought that the same conclusion had applied
> for TCP ICE candidates as for TURN ICE candidates. Version -04 will have
> this fixed.
>
>
>
> Kind regards,
> Uwe
>
>
>
>  -----Original Message-----
> From: rtcweb [mailto:[email-masked] <[email-masked]>] On Behalf Of ext Harald
> Alvestrand
> Sent: Monday, March 31, 2014 3:40 PM
> To: Magnus Westerlund; [email-masked]; Harald Alvestrand
> Subject: [rtcweb] Transport -03, bundling question (Re: Comments on
> draft-ietf-rtcweb-transports-02)
>
> Version -03 is now published. I hope you like it!
>
> New outstanding item:
>
> I added requirements for implementations to be able to generate both
> fully bundled (one 5-tuple for everything) and fully unbundled (one
> 5-tuple for each flow) configurations, and for implementations to be
> able to tolerate being hit with any combination of bundling schemes.
>
> Is there a need to specify at MUST, SHOULD or MAY levels other
> combinations?
>
> Harald
>
> _______________________________________________
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Apr 2014 13:25:50 -0700

> TCP brings to mind other questions such as:

That makes three with faulty memories.  But perhaps that's my
prejudice at play.  The marginal benefit remains...tiny relative to
the cost.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Apr 2014 13:44:59 -0700

Martin said:

"The marginal benefit remains...tiny relative to the cost"

[BA] This is particularly true if you consider *all* of the additional work
items required to enable the usage scenario.  It is one thing to support
SRTP/SRTCP over RFC 4571 framing, but without also  encapsulating DTLS/SRTP
over RFC 4571 framing, how do you reliably obtain the SRTP/SRTCP master
keys?  Similarly, do we also run SCTP/DTLS data channel over RFC 4571
framing?   In my experience, without a great deal of care, running one
reliable transport over another can works poorly if packet loss is
encountered (e.g. the time-out periods interfere with one another).

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 04 Apr 2014 11:02:55 +0200

On 04/03/2014 10:44 PM, Bernard Aboba wrote:
> [BA] This is particularly true if you consider *all* of the additional
> work items required to enable the usage scenario.  It is one thing to
> support SRTP/SRTCP over RFC 4571 framing, but without also
>  encapsulating DTLS/SRTP over RFC 4571 framing, how do you reliably
> obtain the SRTP/SRTCP master keys?  Similarly, do we also run
> SCTP/DTLS data channel over RFC 4571 framing?   In my experience,
> without a great deal of care, running one reliable transport over
> another can works poorly if packet loss is encountered (e.g. the
> time-out periods interfere with one another).  

One result of the London discussion was that I read the TCP TURN
candidate specification, and found that it most explicitly states that
you use 4571 framing for DTLS.

Since it would be very silly to have two types of TCP candidates with
different encapsulation strategies, I wrote in 4571 framing for DTLS too.

"The absence of alternatives clears the mind marvellously".

RFC 4571 is a framing protocol without support for resynchronization. So
it depends on getting whole frames through - something that seems to be
hard to achieve with POSIX TCP send() semantics. A simple implementation
would use blocking writes, in which case packet loss at the higher level
could not occur; another implementation strategy would use non-blocking
mode and drop packets from a higher level buffer if the TCP transmission
buffer filled up, leading to the two-level packet loss issue mentioned.

Which implementation strategy would people expect to use?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Apr 2014 08:41:46 -0700

> Which implementation strategy would people expect to use?

I think that for TURN, we were planning on using non-blocking writes
and discard packets that didn't make the cut.  This means that a
blocked congestion window would manifest as packet loss to upper
layers.

That way, at least congestion indications make it through to SCTP in
some fashion.  It's certainly not ideal, but I'm not sure that there
is a good solution in this space (I do know some people who claim to
have solved the problem of TCP congestion control within a TCP
congestion controlled envelope, maybe you can ask them.