Adhari, Hakim | 1 Oct 10:51 2011
Picon

Deadline Extension: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support

 (Our apologies if you receive multiple copies of this CfP)

=================

Please consider to contribute to and/or forward to the appropriate groups the following opportunity to
submit and publish original scientific results to PAMS 2012.

The submission deadline has been extended to October 16, 2011.

=================

============== CALL FOR PAPERS ===============

2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS 2012) In
conjunction with the 26th IEEE International Conference on Advanced Information Networkingand
Applications (AINA 2012) Fukuoka, Japan, March 26-29, 2012 http://tdrwww.iem.uni-due.de/pams2012.html

The intent of our workshop is to bring together people from research and industry, in order to provide a
discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session
and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session (with short presentations)
to introduce preliminary ideas as well as work in progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing Service and will be included
in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
(Continue reading)

Gorry Fairhurst | 6 Oct 14:42 2011
Picon
Picon

New TSVWG draft: Generic Aggregation of RSVP Reservations over PCN domains


The following draft is approved as a TSVWG work item:

"Generic Aggregation of Resource ReSerVation Protocol (RSVP)
for IPv4 And IPv6 Reservations over PCN domains"
http://tools.ietf.org/html/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01

Authors, please upload a new revision of this draft as:
draft-ietf-tsvwg-rsvp-pcn-00

This draft has the support of the PCN working group and was discussed in 
TSVWG at IETF-81. Since this meeting, the Transport Area ADs have added 
the following milestone to our charter:

"May 2012 - Submit Encoding and Transport of (Pre-) Congestion 
Information from the Domain Egress to the Ingress to the IESG for 
consideration as a Proposed Standard RFC."

Best wishes,

Gorry & James.

internet-drafts | 8 Oct 10:16 2011
Picon

I-D Action: draft-ietf-tsvwg-rsvp-pcn-00.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           : Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over
PCN domains
	Author(s)       : Georgios Karagiannis
                          Anurag Bhargava
	Filename        : draft-ietf-tsvwg-rsvp-pcn-00.txt
	Pages           : 22
	Date            : 2011-10-08

   This document specifies the extensions to the Generic Aggregated RSVP
   [RFC4860] for support of the PCN Controlled Load (CL) and Single
   Marking (SM) edge behaviors over a Diffserv cloud using Pre-
   Congestion Notification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-00.txt
Georgios Karagiannis | 8 Oct 10:22 2011
Picon
Picon
Picon

Re: New TSVWG draft: Generic Aggregation of RSVP Reservations over PCN domains

Hi Gorry, Hi James,

Thanks, I have just submitted the draft:

draft-ietf-tsvwg-rsvp-pcn-00

Best regards,
Georgios

On 10/6/2011, "Gorry Fairhurst" <gorry <at> erg.abdn.ac.uk> wrote:

>
>The following draft is approved as a TSVWG work item:
>
>"Generic Aggregation of Resource ReSerVation Protocol (RSVP)
>for IPv4 And IPv6 Reservations over PCN domains"
>http://tools.ietf.org/html/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01
>
>Authors, please upload a new revision of this draft as:
>draft-ietf-tsvwg-rsvp-pcn-00
>
>This draft has the support of the PCN working group and was discussed in
>TSVWG at IETF-81. Since this meeting, the Transport Area ADs have added
>the following milestone to our charter:
>
>"May 2012 - Submit Encoding and Transport of (Pre-) Congestion
>Information from the Domain Egress to the Ingress to the IESG for
>consideration as a Proposed Standard RFC."
>
>Best wishes,
(Continue reading)

internet-drafts | 11 Oct 08:11 2011
Picon

I-D Action: draft-ietf-tsvwg-sctpsocket-32.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           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
	Author(s)       : Randall R. Stewart
                          Michael Tuexen
                          Kacheong Poon
                          Peter Lei
                          Vladislav Yasevich
	Filename        : draft-ietf-tsvwg-sctpsocket-32.txt
	Pages           : 113
	Date            : 2011-10-10

   This document describes a mapping of the Stream Control Transmission
   Protocol (SCTP) into a sockets API.  The benefits of this mapping
   include compatibility for TCP applications, access to new SCTP
   features and a consolidated error and event notification scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt
Michael Tuexen | 11 Oct 08:32 2011
Picon

Re: I-D Action: draft-ietf-tsvwg-sctpsocket-32.txt

On Oct 11, 2011, at 8:11 AM, internet-drafts <at> ietf.org wrote:

> 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           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
> 	Author(s)       : Randall R. Stewart
>                          Michael Tuexen
>                          Kacheong Poon
>                          Peter Lei
>                          Vladislav Yasevich
> 	Filename        : draft-ietf-tsvwg-sctpsocket-32.txt
> 	Pages           : 113
> 	Date            : 2011-10-10
> 
>   This document describes a mapping of the Stream Control Transmission
>   Protocol (SCTP) into a sockets API.  The benefits of this mapping
>   include compatibility for TCP applications, access to new SCTP
>   features and a consolidated error and event notification scheme.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt
> 
(Continue reading)

Gorry Fairhurst | 18 Oct 13:22 2011
Picon
Picon

WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011


This email announces the start of a working group last call for
draft-ietf-tsvwg-source-quench-02.txt, "Deprecation of ICMP Source 
Quench messages". This document is now thought to be ready
to proceed to be published as a PS. Please send any comments to the
TSVWG list.

The draft is available at:
http://www.ietf.org/id/draft-ietf-tsvwg-source-quench-02.txt

The last call will run for TWO weeks, ending Wednesday 9th October 2011 
2011.

Emails saying "I support" or "I don't support" publication are also most 
helpful in judging the WG consensus. Please let us know if this draft is 
useful and seems to provide the correct advice.

James and Gorry
(TSVWG Chairs)

Scott O. Bradner | 18 Oct 14:05 2011
Picon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,


why does section 6 use SHOULD rather than MUST?

seems to me that there are no known cases where any transport protocol
should ever respond to a Source Quench

Scott

Joe Touch | 18 Oct 23:20 2011
Picon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,

I had suggested:

MUST ignore

SHOULD NOT send

The latter is weaker because there is no impact if a message is sent. However, I do prefer use of SHOULD only
with at least one known exception provided, or at least a clear metric to know when the exception is
appropriate. 

In this case SHOULD should not be driven by legacy cases. 

Joe

On Oct 18, 2011, at 5:05 AM, sob <at> harvard.edu (Scott O. Bradner) wrote:

> 
> why does section 6 use SHOULD rather than MUST?
> 
> seems to me that there are no known cases where any transport protocol
> should ever respond to a Source Quench
> 
> Scott

Fernando Gont | 20 Oct 17:09 2011
Picon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,

Hi, Joe,

Thanks for your input! Please find my comments inline...

On 10/18/2011 06:20 PM, Joe Touch wrote:
> I had suggested:
> 
> MUST ignore
> 
> SHOULD NOT send
> 
> The latter is weaker because there is no impact if a message is sent.

Is there any valid reason *for* sending SQs?

My understanding of Scott's point is that the motivation for a "SHOULD
NOT" rather than "MUST NOT" should be that there are exceptions under
which it could make sense to behave in a different way (rather than
whether there may be a negative impact if the advise is not followed).

So I'd agree with Scott that this should be "MUST NOT send, MUST ignore
if received".

Thoughts?

Thanks!

Best regards,
--

-- 
Fernando Gont
(Continue reading)


Gmane