Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat

["Schwarz, Albrecht (Albrecht)" <[e-mail]>]

Michael,

neither obvious nor clear to me why SCTP is responsible for PMTUD in a stack such as {SCTP/DTLS/L4/IP} layering.
Perhaps I miss sth, but I would appreciate more text.

Thanks,
Albrecht

-----Original Message-----
From: rtcweb [mailto:[e-mail]] On Behalf Of Michael Tuexen
Sent: Donnerstag, 15. Januar 2015 09:42
To: Christer Holmberg
Cc: [e-mail]
Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat

> On 15 Jan 2015, at 05:45, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
> I don't think the sctp-dtls-encaps draft shall contain data channel specific procedures.
It doesn't. It only makes clear which of the two options are used in RTCWeb.
> 
> I agree with Martin that the best place is the data channel draft.
So you think the text in the data channel draft is not enough? It is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over DTLS is used in RTCWeb. 

Best regards
Michael
> 
> Regards,
> 
> Christer
> 
> Sent from my Windows Phone
> From: Michael Tuexen
> Sent: ‎15/‎01/‎2015 00:40
> To: Harald Alvestrand
> Cc: [e-mail]
> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS 
> heartbeat
> 
> On 14 Jan 2015, at 23:12, Harald Alvestrand <[e-mail]> wrote:
> > 
> > Den 14. jan. 2015 21:06, skrev Michael Tuexen:
> >> On 14 Jan 2015, at 18:17, Martin Thomson <[e-mail]> wrote:
> >>> 
> >>> On 14 January 2015 at 00:49, Michael Tuexen 
> >>> <[e-mail]> wrote:
> >>>> * DTLS does the PMTUD using DTLS heartbeats
> >>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks
> >>>> 
> >>>> My understanding is the RTCWeb uses the second option as 
> >>>> described in
> >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect
> >>>> ion-5
> >>> 
> >>> SGTM.  That means we don't need to reference the DTLS heartbleed extension.
> >> It is not referenced in the RTCWeb documents, only in
> >> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07
> >> which allows both options.
> > 
> > So which document should we put it in that we use the second option?
> > -transport, or a post-last-call update of -datachannel?
> Do we really need a change? We have in
> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5
>    Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
>    layer, since there is no way to identify the corresponding
>    association.  Therefore SCTP MUST support performing Path MTU
>    discovery without relying on ICMP or ICMPv6 as specified in [RFC4821]
>    using probing messages specified in [RFC4820].  The initial Path MTU
>    at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for
>    IPv6.
> 
> In the next revision of
> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti
> on-4
> there will be the sentence:
>    The path MTU discovery is performed by SCTP when SCTP over DTLS is
>    used for data channels (see Section 4 of
>    [I-D.ietf-rtcweb-data-channel]).
> 
> Best regards
> Michael
> > 
> >> 
> >> Best regards
> >> Michael
> >>> 
> >> 
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >> 
> > 
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb