headers
Lars Eggert | 1 Jul 2010 10:42
Picon
Gravatar

Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00

Hi,

On 2010-6-30, at 19:01, ah <at> tr-sys.de wrote:
> Please do not neglect the criticism spelled out repeatedly for
> draft-ietf-tsvwg-iana-ports but rejected by your team.  This
> draft tries to accommodate the restrictions imposed by that memo.
> Yet, to be useful for aligning previous RFCs now deemed non-
> conformant with these rules and recent/ongoing work specifically
> calling for multi-label hierarchical Service Prefixes, this
> draft needs to show a uniform path that can be recommended
> to the authors / WGs where these RFCs are originating from.
> 
> Thus, as a replacement mechanism for specifications using
> Service Prefixes with non-transport protocol Protocol Labels
> and/or more than two labels, the non-normative extension
> mechanism proposed is an essential part of this memo.
> 
> Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports
> on the lenght of Service Names and the one-servie-name-per-
> application rule are being relaxed substantially, this extension
> mechanism will remain in this document.

OK, I'm confused. We had a lunch meeting in Anaheim where Olafur was present, and we went down the list of
planned changes to iana-ports to explicitly make sure the two documents are aligned.

If they now are not aligned, there are basically two possibilities: Either we we messed things up when
updating iana-ports, but I at least don't know where we did. Or draft-gudmundsson changed or is planned to
change in ways that are different than what we agreed on.

Can we pencil in a time for a Webex call in order to make progress here?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois Le Faucheur | 6 Jul 2010 14:32
Picon
Favicon

Fwd: I-D Action:draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt

James, Subha,

The idea of signaling an RSVP policy locator at the granularity of application class make sense to me.

A few comments on the document from a first read:
	* for GUID, I suggest you use something like "http://www.ietf.org/rfc/rfc4594.txt" instead of "RFC4594"
	* have you considered defining a new attribute (eg APP-SC = Application Service Class) to carry the
application service class instead of reusing the existing APP attribute (that is itended to identify applications)?
	* I strongly suggest you remove the DS Codepoint from the name of each "profile" 
(ie s/The Broadcast video (CS5) Profile/The Broadcast video Profile/) because the relationship between
the two is only "RECOMMENDED". So what you want to signal is the Service Class, which typically will be
mapped into the recommended CS codepoint (but possibly into another).  

Cheers

Francois

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: 5 July 2010 21:30:02 CEST
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt 
> Reply-To: internet-drafts <at> ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams
> 	Author(s)       : J. Polk, S. Dhesikan
> 	Filename        : draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 8 Jul 2010 16:55
Picon
Picon

TSVWG Agenda Requests for IETF-78: THURSDAY, July 29, 2010


TSVWG

This is a call for agenda requests for the upcoming TSVWG session.

We are meeting at 9am local time on THURSDAY, July 29, under the current 
IETF agenda (subject to change).

If you have already asked for a timeslot (see below), you do not need to 
ask again. If, on the other hand, you have not asked for a speaking slot 
(or have "???" against your draft), please do contact us and ask before 
14th June.

Please include the filename of the current ID you wish to present, who 
is going to present, that person's email address, and the amount of time
you/they wish to present.

And finally,

Everything that occurs during and around the the TSVWG session falls 
under  the NOTE WELL as written in RFCs 3978 and 3979.  Please 
understand this when presenting, and talking, in and near the TSVWG 
session room.

Thank you, and see you in about 2 weeks!

Gorry & James
_______________________________________________

Current Requests:
(Continue reading)

Permalink | Reply | 0 comments |
headers
James M. Polk | 9 Jul 2010 23:13
Picon
Favicon

Regarding TSVWG Agenda requests for IETF78

Authors

For anyone wanting presentation time in TSVWG

    - PLEASE send requests to BOTH chairs -

My partner in crime (i.e., my co-chair Gorry) is not going to be 
available for all of the next two weeks, and I can only plan an 
agenda for what I know something about.

James
(with chair hat on)
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 12 Jul 2010 18:30
Picon
Favicon

I-D Action:draft-ietf-tsvwg-sctpsocket-23.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)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctpsocket-23.txt
	Pages           : 98
	Date            : 2010-07-12

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-23.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-tsvwg-sctpsocket-23.txt): message/external-body, 70 bytes
Permalink | Reply | 0 comments |
headers
James M. Polk | 12 Jul 2010 21:00
Picon
Favicon

New ID on RSVP APP-ID Profiles

TSVWG

(as an individual)

Subha and I have written a new ID based on the RSVP application-ID 
template specified within RFC 2872, to define what field values are 
appropriate to describe several real-time applications (i.e., voice 
and video).  There are 5 voice and video applications described 
within RFC 4594, and a 6th was introduced by RFC 5865.

We simply, in 8 whole pages, define what field values are necessary, 
and what values are to be in each field within the Add-ID template 
for each of these 6 real-time applications. More applications are 
always possible, but we've limited it to these 6 for now.

http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt

The goal of this document is to more effectively communicate what a 
reservation is for, by application type, to allow routers - and 
possibly session border controllers (SBCs) to discover what type of 
application a particular flow is, and apply appropriate treatment to 
that flow - at least in the form of marking the flow with the locally 
appropriate Diffserv codepoint (DSCP).

This document competes with the DCLASS Object defined within RFC 
2996, which only specifies a DSCP value to use, and does not give 
flexibility to each domain - on an end-to-end basis - the ability to 
configure different DSCPs within their domain (i.e., "voice will be 
'101110' only"). We see this as a limitation of what could be.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 12 Jul 2010 22:15
Picon
Favicon

I-D Action:draft-ietf-tsvwg-byte-pkt-congest-02.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           : Byte and Packet Congestion Notification
	Author(s)       : B. Briscoe, J. Manner
	Filename        : draft-ietf-tsvwg-byte-pkt-congest-02.txt
	Pages           : 39
	Date            : 2010-07-12

This memo concerns dropping or marking packets using active queue
management (AQM) such as random early detection (RED) or pre-
congestion notification (PCN).  We give two strong recommendations:
(1) packet size should not be taken into account when transports read
congestion indications, not when network equipment writes them, and
(2) byte-mode packet drop variant of AQM algorithms, such as RED,
should not be used to drop fewer small packets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-02.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-tsvwg-byte-pkt-congest-02.txt): message/external-body, 70 bytes
Permalink | Reply | 3 comments |
headers
Michael Menth | 13 Jul 2010 11:18
Picon
Favicon

Re: I-D Action:draft-ietf-tsvwg-byte-pkt-congest-02.txt

Hi Bob,

from my perspective, PCN is not an AQM scheme. It's just a meter and marker.

I just browsed abstract and intro of the document and found it a bit 
confusing. I think you mean that meters (or equivalent entities) should 
take packet sizes into account, but the decision whether to mark/drop a 
packet should be independent of its size. Then, I fully agree, although 
at first read I understood the text in a different way.

"And if the probability of dropping a packet depends on its byte-size it 
is called byte-mode drop, whereas if the drop probability is independent 
of a packet's byte-size it is called packet-mode drop."

Why not just say packet-size-(in)dependent (PSI,PSD) dropping or 
marking? I find this wording more intuitive and less confusing.

Best wishes,

    Michael

Internet-Drafts <at> ietf.org schrieb:
> 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           : Byte and Packet Congestion Notification
> 	Author(s)       : B. Briscoe, J. Manner
> 	Filename        : draft-ietf-tsvwg-byte-pkt-congest-02.txt
> 	Pages           : 39
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bob Briscoe | 13 Jul 2010 14:28
Picon

Re: I-D Action:draft-ietf-tsvwg-byte-pkt-congest-02.txt

Michael,

At 10:18 13/07/2010, Michael Menth wrote:
>Hi Bob,
>
>from my perspective, PCN is not an AQM scheme. It's just a meter and marker.

An AQM typically involves a meter and a marker/dropper. There is 
surely no way PCN is anything but It must be AQM.

The wiki page on AQM defines it as "a technique that consists in 
dropping or ECN-marking packets before a router's queue is full"
<http://en.wikipedia.org/wiki/Active_Queue_Management>
PCN certainly satisfies that description.

>I just browsed abstract and intro of the document and found it a bit 
>confusing. I think you mean that meters (or equivalent entities) 
>should take packet sizes into account, but the decision whether to 
>mark/drop a packet should be independent of its size. Then, I fully 
>agree, although at first read I understood the text in a different way.

OK, I'll take a look - I thought we'd made it clear.

>"And if the probability of dropping a packet depends on its 
>byte-size it is called byte-mode drop, whereas if the drop 
>probability is independent of a packet's byte-size it is called 
>packet-mode drop."
>
>Why not just say packet-size-(in)dependent (PSI,PSD) dropping or 
>marking? I find this wording more intuitive and less confusing.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Menth | 13 Jul 2010 16:46
Picon
Favicon

Re: I-D Action:draft-ietf-tsvwg-byte-pkt-congest-02.txt

Hi Bob,

Bob Briscoe schrieb:
> Michael,
>
> At 10:18 13/07/2010, Michael Menth wrote:
>> Hi Bob,
>>
>> from my perspective, PCN is not an AQM scheme. It's just a meter and 
>> marker.
>
> An AQM typically involves a meter and a marker/dropper. There is 
> surely no way PCN is anything but It must be AQM.
>
> The wiki page on AQM defines it as "a technique that consists in 
> dropping or ECN-marking packets before a router's queue is full"
> <http://en.wikipedia.org/wiki/Active_Queue_Management>
> PCN certainly satisfies that description.
I believe that the common property of the mechanisms in the focus of 
this draft is that they meter traffic in some way and perform some 
actions on the base of the metering result. Whether this is for the 
purpose of actively managing a (physical/virtual) queue is probably not 
so important. That's why I would avoid AQM in this context. But that's a 
not so important detail anyway.

>
>
>> I just browsed abstract and intro of the document and found it a bit 
>> confusing. I think you mean that meters (or equivalent entities) 
>> should take packet sizes into account, but the decision whether to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane