Subject: [tsvwg] Prague: Confirming meeting decisions

From: "Black, David" <[email-masked]>
Date: Sun, 2 Aug 2015 16:25:42 +0000

As with all IETF meetings, decisions made during the TSVWG meeting in Prague
need to be confirmed on the list.  The following is the "sense of the room"
on these items from Prague.  Anyone who disagrees should say so on the list,
please.

-- 4.2 GRE over UDP direction

The proposed path forward is write two different sets of applicability text:

(1) Network operator usage.  This could use GRE in full generality and omit
UDP checksum for IPv6 if/as appropriate, text can be extensively based on
RFC 7510 (MPLS/UDP).

(2) General Internet usage.  This would be restricted - traffic SHOULD be
congestion controlled/responsive (e.g., IP traffic aggregates), UDP checksum
for IPv6 would be REQUIRED.

NB: The "This could" and "This would" sentences above are intended as
examples to illustrate the different applicability scopes - actual WG support
(or lack thereof) for the specific provisions in those sentences will be
based on list discussion, at WG Last Call at the latest.

-- 5.1 SCTP (RFC 4960) Errata and Issues

The "sense of the room" is that the WG should work on SCTP specification
maintenance above and beyond the RFC Editor's collection of errata.  The
WG chairs should consult with the ADs on how to move forward on this.

-- 6.2 DSCPs for Web RTC

Justin Uberti's proposal - set SCTP association DSCP to highest applicable
DSCP of any DataChannel in WebRTC, and reset the congestion control if
needed at the point where the DSCP changes - was supported by the Friday
rtcweb WG meeting.

If there are any tsvwg WG objections to this direction, they should be
posted to the list promptly, please.

-- 6.5 draft-wei-tsvwg-tunnel-congestion-feedback

The "sense of the room" is that the tsvwg WG should adopt this draft
with an Informational RFC target that could be upgraded once the
details on the Congestion Management (response) mechanisms are
specified (which may be via reference to other drafts.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Tue, 4 Aug 2015 09:14:14 +0200

Hi David,

to avoid me getting something wrong about "DataChannel", the decision below refers to the rtcweb-qos draft table 1 Data Type "Data". If available, DSCP AF21 is set, if not but AF11 is available then the latter and so on. You don't refer to any other Data Type of table 1 below?

If that's the case, I don't object.

Regards, Ruediger

[snip]
-- 6.2 DSCPs for Web RTC

Justin Uberti's proposal - set SCTP association DSCP to highest applicable DSCP of any DataChannel in WebRTC, and reset the congestion control if needed at the point where the DSCP changes - was supported by the Friday rtcweb WG meeting.

If there are any tsvwg WG objections to this direction, they should be posted to the list promptly, please.

Thanks,
--David

---

From: "Black, David" <[email-masked]>
Date: Tue, 4 Aug 2015 23:28:29 +0000

Yes, that interpretation is correct, Thanks, --David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, August 04, 2015 3:14 AM
> To: Black, David
> Cc: [email-masked]
> Subject: AW: Prague: Confirming meeting decisions
> 
> Hi David,
> 
> to avoid me getting something wrong about "DataChannel", the decision below
> refers to the rtcweb-qos draft table 1 Data Type "Data". If available, DSCP
> AF21 is set, if not but AF11 is available then the latter and so on. You don't
> refer to any other Data Type of table 1 below?
> 
> DSCP of any DataChannel in WebRTC, and reset the congestion control if needed
> at the point where the DSCP changes - was supported by the Friday rtcweb WG
> meeting.
>