Jose Saldana | 17 Dec 10:41 2014
Picon

Re: A new draft submitted to tsvwg: Simplemux

Hi, Fernando.

 

> - Multiplexing layer 3 packets in layer 2 frames?

 

My idea is that this is an IETF draft, so the protocols considered are those defined by IANA: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

 

The "protocol" field to be included in Simplemux would be 8 bits long, in my opinion. This would not be the “EtherType” field of the Ethernet frame (16 bits long): http://en.wikipedia.org/wiki/EtherType.

 

However, if someone thinks a 16 bytes protocol field could be interesting, we can also consider it as an option (with a bit indicating it in the first header).

 

 

> - Multiplexing layer 3 packets in layer 3 packets?

 

This would allow these kind of things, if the “multiplexing protocol” is IP:

 

- encapsulating a number of IP packets in an IP packet: Encapsulated Protocol number=4 (IPv4 encapsulation, RFC2003)

 

- Encapsulating a number of Transport Segments in an IP packet (this would be equivalent to TMux, RFC1692, https://tools.ietf.org/html/rfc1692 ). Encapsulated Protocol number=6 (TCP, RFC793)

 

- Encapsulating a number of Ethernet Frames in an IP datagram: Encapsulated Protocol number=97  ETHERIP, Ethernet-within-IP Encapsulation, RFC3378

 

 

> Multiplexing layer 3 packets in layer 4 datagrams?

 

If the “multiplexing protocol” is UDP, it would also make sense: this would avoid the need for a new “protocol” number. The two extremes would just need to agree on a port number. In fact, this is what is done in the implementation. https://github.com/TCM-TF/simplemux

 

Best regards,

 

Jose

 

De: FERNANDO PASCUAL BLANCO [mailto:fernando.pascualblanco <at> telefonica.com]
Enviado el: miércoles, 17 de diciembre de 2014 9:56
Para: Jose Saldana; tsvwg <at> ietf.org
Asunto: RE: [tsvwg] A new draft submitted to tsvwg: Simplemux

 

Hi Jose,

 

What multiplexing and what multiplexed protocols are you considering here? Are you focused on a determined protocol layer options? Or maybe you are defining something generic?

For example:

 

- Multiplexing layer 3 packets in layer 2 frames?

- Multiplexing layer 3 packets in layer 3 packets?

- Multiplexing layer 3 packets in layer 4 datagrams?

 

More options?

 

Thanks!

 

Fernando

 

From: tsvwg [mailto:tsvwg-bounces <at> ietf.org] On Behalf Of Jose Saldana
Sent: jueves, 11 de diciembre de 2014 11:11
To:
tsvwg <at> ietf.org
Subject: [tsvwg] A new draft submitted to tsvwg: Simplemux

 

Hi all,

 

This is an Internet Draft I submitted yesterday to tsvwg:

http://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/?include_text=1

 

Simplemux could be seen as a generic protocol for multiplexing any protocol on any other protocol. The initial idea was: could this be used instead of PPPMux in TCM? However, I think it may have more fields of application.

 

The idea is similar to that of PPPMux (RFC3153). However, PPP, and L2TP in turn, are not required, thus reducing complexity:

 

| Ext hdr || Mux hdr | packet || Mux hdr | packet || ...||

 

It is different from TMux [RFC1692], because TMux  combines multiple short transport segments, but not full packets, so it works between the same pair of machines.  However, there are scenarios where a number of low-efficiency flows share a common path, but they do not travel between the same pair of machines. 

 

A “Protocol” number should be requested to IANA for saying in the external header that Simplemux is inside. Each Mux header would include another “Protocol” field, so it would permit the multiplexing of different packets in the same bundle: IPv4, IPv6, ROHC, etc.

 

If you could have a look to the draft and send your comments, it would be fine.

 

An implementation of Simplemux using IP/UDP as the multiplexing (external) protocol and IP or ROHC as the multiplexed protocol can be found here:

https://github.com/TCM-TF/simplemux

 

 

Thanks in advance!

 

Jose

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

Jose Saldana | 11 Dec 16:48 2014
Picon

Some results obtained with TCM

Hi all,

 

Today I have performed a small battery of tests with the TCM implementation (https://github.com/TCM-TF/simplemux/). We hope we will be able to test it in other scenarios and with better machines soon.

 

Multiplexing and compressing with ROHC 10 VoIP flows (G729a with 2 samples per packet):

Average BW reduction: 36.50%

Average PPS reduction: 78.83%

Average multiplexing delay: 4123.33 us

stdev of the multiplexing delay: 3845.13 us

 

Multiplexing and compressing with ROHC 10 flows of Quake3 (a First Person Shooter game)

Average BW reduction: 22.23%

Average PPS reduction: 92.99%

Average multiplexing delay: 5148.72 us

stdev of the multiplexing delay: 2991.43 us

 

 

You can find the full report (with graphs and details) here: https://github.com/TCM-TF/simplemux/blob/develop/Simplemux_VoIP&Quake3_results_v1.pdf?raw=true

 

Best regards,

 

Jose

 

De: tsvwg [mailto:tsvwg-bounces <at> ietf.org] En nombre de Jose Saldana
Enviado el: jueves, 11 de diciembre de 2014 11:01
Para: tsvwg <at> ietf.org
CC: 'Gorry Fairhurst'; 'David Flórez Rodríguez'; 'Manuel Núñez Sanz'; 'Juan Antonio Castell Lucía'; 'Gonzalo Camarillo'; Martin Stiemerling; 'Fernando Pascual Blanco'; 'Dan Wing (dwing)'; 'Michael Ramalho (mramalho)'
Asunto: [tsvwg] New version of the TCM drafts

 

Hi all,

 

We have just submitted new versions of the two TCM drafts:

 

- Tunneling Compressing and Multiplexing (TCM) Traffic Flows. Reference Model. draft-saldana-tsvwg-tcmtf-08

http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

 

- Delay Limits and Multiplexing Policies to be employed with Tunneling Compressing and Multiplexing Traffic Flows. draft-suznjevic-tsvwg-mtd-tcmtf-04

http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

In addition, yesterday I submitted another draft about Simplemux (http://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/), a multiplexing protocol simpler than PPPMux (I will send another e-mail explaining it).

 

We have built an implementation of TCM over Simplemux (https://github.com/TCM-TF/simplemux), and we will soon report the results of some tests we are planning.

 

Best regards,

 

Jose Saldana

PS: These are some of the improvements:

- keywords have been added

    multiplexing

    header compression

    optimization

    small-packet flows

 

- We talk about “Tunneling, Compressing and Multiplexing (TCM)” instead of “Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF)”. It is a bit confusing if we talk about TCM in some places and TCM-TF in others. In addition, TCM is very easy to remember.

 

- We have improved the abstract and the introduction, talking about “optimization”, “small-packet flows” here and there.

 

- We have updated the reference to COAP (it is now an RFC and it was a draft some months ago).

 

- We have added a reference for supporting the statement saying that routers have a limit in the number of pps they can manage.

 

- We have modified the titles of some subsections.

 

internet-drafts | 11 Dec 11:16 2014
Picon

New Version Notification - draft-ietf-tsvwg-sctp-prpolicies-06.txt


A new version (-06) has been submitted for draft-ietf-tsvwg-sctp-prpolicies:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-prpolicies-06.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-prpolicies-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

Jose Saldana | 11 Dec 11:11 2014
Picon

A new draft submitted to tsvwg: Simplemux

Hi all,

 

This is an Internet Draft I submitted yesterday to tsvwg:

http://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/?include_text=1

 

Simplemux could be seen as a generic protocol for multiplexing any protocol on any other protocol. The initial idea was: could this be used instead of PPPMux in TCM? However, I think it may have more fields of application.

 

The idea is similar to that of PPPMux (RFC3153). However, PPP, and L2TP in turn, are not required, thus reducing complexity:

 

| Ext hdr || Mux hdr | packet || Mux hdr | packet || ...||

 

It is different from TMux [RFC1692], because TMux  combines multiple short transport segments, but not full packets, so it works between the same pair of machines.  However, there are scenarios where a number of low-efficiency flows share a common path, but they do not travel between the same pair of machines. 

 

A “Protocol” number should be requested to IANA for saying in the external header that Simplemux is inside. Each Mux header would include another “Protocol” field, so it would permit the multiplexing of different packets in the same bundle: IPv4, IPv6, ROHC, etc.

 

If you could have a look to the draft and send your comments, it would be fine.

 

An implementation of Simplemux using IP/UDP as the multiplexing (external) protocol and IP or ROHC as the multiplexed protocol can be found here:

https://github.com/TCM-TF/simplemux

 

 

Thanks in advance!

 

Jose

 

Jose Saldana | 11 Dec 11:01 2014
Picon

New version of the TCM drafts

Hi all,

 

We have just submitted new versions of the two TCM drafts:

 

- Tunneling Compressing and Multiplexing (TCM) Traffic Flows. Reference Model. draft-saldana-tsvwg-tcmtf-08

http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

 

- Delay Limits and Multiplexing Policies to be employed with Tunneling Compressing and Multiplexing Traffic Flows. draft-suznjevic-tsvwg-mtd-tcmtf-04

http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

In addition, yesterday I submitted another draft about Simplemux (http://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/), a multiplexing protocol simpler than PPPMux (I will send another e-mail explaining it).

 

We have built an implementation of TCM over Simplemux (https://github.com/TCM-TF/simplemux), and we will soon report the results of some tests we are planning.

 

Best regards,

 

Jose Saldana

PS: These are some of the improvements:

- keywords have been added

    multiplexing

    header compression

    optimization

    small-packet flows

 

- We talk about “Tunneling, Compressing and Multiplexing (TCM)” instead of “Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF)”. It is a bit confusing if we talk about TCM in some places and TCM-TF in others. In addition, TCM is very easy to remember.

 

- We have improved the abstract and the introduction, talking about “optimization”, “small-packet flows” here and there.

 

- We have updated the reference to COAP (it is now an RFC and it was a draft some months ago).

 

- We have added a reference for supporting the statement saying that routers have a limit in the number of pps they can manage.

 

- We have modified the titles of some subsections.

 

internet-drafts | 10 Dec 17:23 2014
Picon

I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : DTLS Encapsulation of SCTP Packets
        Authors         : Michael Tuexen
                          Randall R. Stewart
                          Randell Jesup
                          Salvatore Loreto
	Filename        : draft-ietf-tsvwg-sctp-dtls-encaps-07.txt
	Pages           : 9
	Date            : 2014-12-10

Abstract:
   The Stream Control Transmission Protocol (SCTP) is a transport
   protocol originally defined to run on top of the network protocols
   IPv4 or IPv6.  This document specifies how SCTP can be used on top of
   the Datagram Transport Layer Security (DTLS) protocol.  Using the
   encapsulation method described in this document, SCTP is agnostic
   about the protocols being used below DTLS, explicit IP addresses can
   not be used in the SCTP control chunks.  As a consequence, the SCTP
   associations are single homed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-dtls-encaps-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Michael Tuexen | 9 Dec 17:48 2014
Picon

Re: AD Evaluation of draft-ietf-tsvwg-sctp-dtls-encaps

On 08 Dec 2014, at 22:44, Spencer Dawkins <spencerdawkins <at> gmail.com> wrote:

> Dear Authors,
> 
> I had a small number of comments, mostly but not entirely at nit level, on this draft. I suspect that you
would see them again from other ADs and from review teams. 
Hi Spencer,

thanks for the comments. See my replies inline.
> 
> Would you like to respin before Last Call?
Sure. This makes things simple, I think and will make Gorry happy, who suggested already
a text change...

Best regards
Michael
> 
> Spencer
> 
> -- my notes
> 
> In this text:
> 
> 3.  Encapsulation and Decapsulation Procedure
> 
>    When an SCTP packet is provided to the DTLS layer, the complete SCTP
>    packet, consisting of the SCTP common header and a number of SCTP
>    chunks, MUST be handled as the payload of the application layer
>    protocol of DTLS.  When the DTLS layer has processed a DTLS record
>    containing a message of the application layer protocol, the payload
>    MUST be given up to the SCTP layer.  The SCTP layer expects an SCTP
>    common header followed by a number of SCTP chunks.
>    
> I don't read the MUSTs as 2119 MUSTs. You're just describing functionality. "is handled" and "is given up
to" (which I might suggest saying as "is passed to") are probably more appropriate.
OK, changed. I think there was a comment requesting some normative language in the part
of the document describing the actual encap/decaps, that is why the MUST went in. But
if you think this is not necessary, I take them out.
>    
>    In this text:
> 
> 5.  DTLS Considerations
> 
>    If path MTU discovery is performed by the SCTP layer and IPv4 is used
>    as the network layer protocol, the DTLS implementation SHOULD allow
>    the DTLS user to enforce that the corresponding IPv4 packet is sent
>    with the Don't Fragment (DF) bit set.  If controlling the DF bit is
>    not possible, for example due to implementation restrictions, a safe
>    value for the path MTU has to be used by the SCTP stack.  It is
>    RECOMMENDED that the save value does not exceed 1200 bytes.  Please
>                         ^^^^ is this "safe"?
This is what the WG thinks is save. We discussed this also with members
of the RTCWeb WG. Do you think that we should use a different value? If yes,
which one? The motivation was based on the value for IPv6, and then taking
into account some more bytes for headers... and we ended up with 1200.
>    
>    note that [RFC1122] only requires end hosts to be able to reassemble
>    fragmented IP packets of reassembled size of 576 bytes.
>    
> In this text:
> 
> 5.  DTLS Considerations
> 
>    If path MTU discovery is performed by the SCTP layer and IPv4 is used
>    as the network layer protocol, the DTLS implementation SHOULD allow
>    the DTLS user to enforce that the corresponding IPv4 packet is sent
>    with the Don't Fragment (DF) bit set.  If controlling the DF bit is
>    not possible, for example due to implementation restrictions, a safe
>    value for the path MTU has to be used by the SCTP stack.  It is
>    RECOMMENDED that the save value does not exceed 1200 bytes.  Please
>    note that [RFC1122] only requires end hosts to be able to reassemble
>    fragmented IP packets of reassembled size of 576 bytes.
>                             ^^^^^^^^^^^^^^^^^^^
> I'm not sure you need to say "reassembled size of", but if you don't just delete this text, I'd suggest "able
to reassemble fragmented IP packets up to 576 bytes in length".
Taken.
> 
> In this text:
> 
> 6.5.  Partial Reliability Extension
> 
>    Partial reliability as defined in [RFC3758] can be used in
>    combination with DTLS encapsulation.  It is also possible to use
>                                             ^^^^^^^^^^^^^^^^
>    additional PR-SCTP policies.
>    
> Is there a reference you could provide for implementers? Perhaps to
draft-ietf-tsvwg-sctp-prpolicies, also submitted for publication, but please note my use of future
tense in 6.7 comment ...
Changed to
It is also possible to use
additional PR-SCTP policies, for example the ones defined in
<xref target='I-D.ietf-tsvwg-sctp-prpolicies'/>.</t>
>    
> In this text:
> 
> 6.7.  Interleaving of Large User Messages
> 
>    SCTP as defined in [RFC4960] does not support the interleaving of
>    large user messages that need to be fragmented and reassembled by the
>    SCTP layer.  The protocol extension defined in
>    [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and can be used
>    with DTLS encapsulation.
>    
> I think I understand why you have https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/
listed as Informational, but it feels like it's on the edge of being Normative, or at least implementers
are encouraged to support this extension now. Is this important enough to need to be said in this
specification? If so, would it be correct to say this?
> 
>    The protocol extension being defined in
>    [I-D.ietf-tsvwg-sctp-ndata] would overcome this limitation and could be used
>    with DTLS encapsulation.
I just want to say that the extension defined in I-D.ietf-tsvwg-sctp-ndata (whatever RFC it will be)
can be used with DTLS encaps. For RTCWeb it will be used (it is mandatory to implement), but there
might be other use cases where this extension is not necessary.
Since I'm not sure I got the point you want to make, please let me know if my intention is now
clearer and which text you prefer to express this.

Best regards
Michael

gorry | 6 Dec 10:14 2014
Picon
Picon

draft-ietf-tsvwg-sctp-dtls-encaps-06 as a PS (editorial comment)

I've just requested the publication of the above ID, however I have one
editorial request that I would like to suggest when the document is being
revised,

 I think I it would be wise to change the introductory paragraph in
section 1 to also mention the relationship to different versions of DTLS.
I think the current introduction could be read as only defining support
for DTLS 1.0, which is not correct. Please consider this as an early
comment in the next stage of review.

OLD:
 This document specifies
   how SCTP is used on top of the Datagram Transport Layer Security
   (DTLS) protocol defined in [RFC4347].

SUGGESTED NEW:
 This document specifies
   how SCTP is used on top of the Datagram Transport Layer Security
   (DTLS) protocol. DTLS 1.0 is defined in [RFC4347] and the present
   latest version, DTLS 1.2, is defined in [RFC6347].

Best wishes,

Gorry

gorry | 6 Dec 10:12 2014
Picon
Picon

Publication has been requested for draft-ietf-tsvwg-sctp-dtls-encaps-06 as PS


Gorry Fairhurst as tsvwg co-chair  has requested publication of
draft-ietf-tsvwg-sctp-dtls-encaps-06 as Proposed Standard on behalf of the
TSVWG working group.

--------------------------------------------------------------------------

The writeup is:

As required by RFC4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

PS

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:
The Stream Control Transmission Protocol (SCTP) is a transport protocol
originally defined to run on top of the network protocols IPv4 or IPv6.
This document specifies how SCTP can be used on top of the Datagram
Transport Layer Security (DTLS) protocol. Using encapsulation method
described in this document, SCTP is agnostic about the protocols being
used below DTLS, explicit IP addresses can not be used in the SCTP control
chunks.

Working Group Summary:
This document is being prepared at the request of the RTCweb/webRTC activity.

Document Quality:
The document is thought ready to publish. As far as the authors know, this
this is implemented in the Chrome, Firefox and Opera browser. PMTUD is not
yet implemented.

Personnel:

Who is the Document Shepherd?
G Fairhurst (TSVWG Co-Chair)

Who is the Responsible Area Director?
Spencer Dawkins (TSV AD)

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of
the document is not ready for publication, please explain why the document
is being forwarded to the IESG.

The document was reviewed against related documents and is thought ready
to proceed. Security expertise was requested (Ekr) to help identify
requirements for using DTLS and  to recommend the appropriate version of
DTLS.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

It should be reviewed by security experts.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?

M. Tuexen- Confirmed.
R. Stewart - Confirmed.
R. Jesup  - Confirmed.
S. Loreto - Confirmed.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

None known.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

The document received support from 5 people within TSVWG plus the WG
chair. The work replayed to RTCweb requirements. Feedback was received
from RTCweb implementors during document development. A WGLC ended 28th
February 2014, with some reviews that resulted in an updated document.
Since then discussion has focussed on which version of DTLS to mandate.
This conclude in November 2014.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

None

(13) Have all references within this document been identified as either
normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

OK

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 5226).
This document requires no actions from IANA

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None

--------------------------------------------------------------------------

You may verify the document's state at
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

Black, David | 2 Dec 01:33 2014

Adoption of diffserv-intercon and rfc5405bis drafts

Having seen no further comment on this matter:

> 2) The sense of the room in Honolulu was to adopt the following two
> 	drafts as WG drafts:
> 
>       DiffServ interconnection classes and practice
> 	draft-geib-tsvwg-diffserv-intercon
> http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/
> 
>       UDP Usage Guidelines
>       draft-eggert-tsvwg-rfc5405bis
> http://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/
> 
>       Absent objection on the list, these drafts will be adopted.
>       Please comment by November 30.

These drafts have been adopted by the tsvwg WG.  Would the authors
please submit -00 draft-ietf-tsvwg- versions with no change of text
from the latest individual submission version?

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces <at> ietf.org] On Behalf Of Black, David
> Sent: Friday, November 14, 2014 10:48 PM
> To: tsvwg <at> ietf.org
> Cc: aqm <at> ietf.org
> Subject: [tsvwg] Draft Honolulu minutes posted
> 
> ... before I get on the plane out of here!
> 
> http://www.ietf.org/proceedings/91/minutes/minutes-91-tsvwg
> 
> Many thanks to Aaron Falk and Joel Halpern for taking notes, as
> there were lively discussions in both sessions that were not easy
> to follow.  They captured everything important.
> 
> Here are some important items that people should know about:
> 
> 1) There are a number of expired WG drafts that need author attention:
> 	ECN Encapsulation Guidelines
> 	NAT Behavioral Requirements Updates
> 	RSVP Multiple Instance Object
> 	SCTP NAT Support
> 
> 2) The sense of the room in Honolulu was to adopt the following two
> 	drafts as WG drafts:
> 
>       DiffServ interconnection classes and practice
> 	draft-geib-tsvwg-diffserv-intercon
> http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/
> 
>       UDP Usage Guidelines
>       draft-eggert-tsvwg-rfc5405bis
> http://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/
> 
>       Absent objection on the list, these drafts will be adopted.
>       Please comment by November 30.
> 
> 3) The meeting determined that there is no WG rough consensus
>       for requiring use of the full UDP checksum for GRE-in-UDP
>       with IPv6.  The design team will continue work on when
>       zero checksum is acceptable (as well as congestion
>       considerations).
> 
> 4) See the minutes for the lengthy and interesting discussion of the
>       tunnel congestion feedback draft.  There is one important issue
> 	that needs to be followed up across the TSVWG and AQM WGs (aqm
>       list cc:'d for this reason):
> 
>       OPEN ISSUE *1: Should ECN indications (CE) be treated as equivalent
>       to drops?  This also came  up in AQM.  This is primarily about
>       endpoint (or tunnel egress) reaction to CE.
> 
> Enjoy,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 

Black, David | 1 Dec 18:39 2014

Final Honolulu tsvwg minutes

Uploaded: http://www.ietf.org/proceedings/91/minutes/minutes-91-tsvwg

FYI,
--David


Gmane