[tsvwg] [Fwd: Re: Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt]

gorry@erg.abdn.ac.uk Mon, 16 June 2014 18:34 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF891A014C for <tsvwg@ietfa.amsl.com>; Mon, 16 Jun 2014 11:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpFfMQczJqfT for <tsvwg@ietfa.amsl.com>; Mon, 16 Jun 2014 11:34:34 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1FE1A013B for <tsvwg@ietf.org>; Mon, 16 Jun 2014 11:34:34 -0700 (PDT)
Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 637D52B4271; Mon, 16 Jun 2014 19:34:33 +0100 (BST)
Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 16 Jun 2014 19:34:33 +0100
Message-ID: <ce9ee9be24eef04770ed81730a000954.squirrel@www.erg.abdn.ac.uk>
Date: Mon, 16 Jun 2014 19:34:33 +0100
From: gorry@erg.abdn.ac.uk
To: tsvwg@ietf.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/bV5ipycvpJ-8IFD4rt5qZHgZKh0
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: [tsvwg] [Fwd: Re: Fwd: New Version Notification for draft-eggert-tsvwg-rfc5405bis-00.txt]
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2014 18:34:37 -0000

I'll respond on the RTT query - since I wrote that section.

I'm, not sure what you are saying, are you saying there are methods that
determine how to respond to congestion that take less than one RTT, or
simply the group RTT isn't an issue - maybe I'd see better with an
example?

Gorry


> Thanks Lars. Much of this text is taken directly from my previous
> draft, draft-shepherd-multicast-udp. Can you please add me to the authors
> list of this draft?
>
> Content notes:
>
> Section 4.1:
>
> Congestion control mechanisms for multicast may operate on longer
>    timescales than for unicast (e.g., due to the higher group RTT of a
>    heterogeneous group); appropriate methods are particularly for any
>    multicast session were all or part of the multicast distribution tree
>    spans an access network (e.g., a home gateway).
>
>
> The above isn't relevant for application based CC mechanism. In fact, an
> application-based mechanism may often operate faster than any RTT
> dependent
> mechanism. I think we should either remove this paragraph entirely or
> restructure it to make the point that application based CC operates
> without
> dependency on RTT.
>
> Greg
>
>
> On Mon, Jun 16, 2014 at 1:50 AM, Eggert, Lars <lars@netapp.com> wrote:
>
>> Hi,
>>
>> Gorry and me have started to put together an update to RFC5405 in light
>> of
>> the recent discussions. Comments welcome.
>>
>> Lars
>>
>>
>> Begin forwarded message:
>>
>> > From: <internet-drafts@ietf.org>
>> > Subject: New Version Notification for
>> draft-eggert-tsvwg-rfc5405bis-00.txt
>> > Date: June 14, 2014 at 12:14:42 GMT+2
>> > To: Lars Eggert <lars@netapp.com>, Godred Fairhurst <
>> gorry@erg.abdn.ac.uk>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Lars
>> Eggert <lars@netapp.com>
>> >
>> >
>> > A new version of I-D, draft-eggert-tsvwg-rfc5405bis-00.txt
>> > has been successfully submitted by Lars Eggert and posted to the
>> > IETF repository.
>> >
>> > Name:         draft-eggert-tsvwg-rfc5405bis
>> > Revision:     00
>> > Title:                UDP Usage Guidelines
>> > Document date:        2014-06-14
>> > Group:                Individual Submission
>> > Pages:                36
>> > URL:
>> http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-rfc5405bis-00.txt
>> > Status:
>> https://datatracker.ietf.org/doc/draft-eggert-tsvwg-rfc5405bis/
>> > Htmlized:
>> http://tools.ietf.org/html/draft-eggert-tsvwg-rfc5405bis-00
>> >
>> >
>> > Abstract:
>> >   The User Datagram Protocol (UDP) provides a minimal message-passing
>> >   transport that has no inherent congestion control mechanisms.
>> >   Because congestion control is critical to the stable operation of
>> the
>> >   Internet, applications and other protocols that choose to use UDP as
>> >   an Internet transport must employ mechanisms to prevent congestion
>> >   collapse and to establish some degree of fairness with concurrent
>> >   traffic.  They may also need to implement additional mechanisms,
>> >   depending on how they use UDP.
>> >
>> >   This document provides guidelines on the use of UDP for the
>> designers
>> >   of applications, tunnels and other protocols that use UDP.
>> >   Congestion control guidelines are a primary focus, but the document
>> >   also provides guidance on other topics, including message sizes,
>> >   reliability, checksums, and middlebox traversal.
>> >
>> >   If published as an RFC, this document will obsolete RFC5405.
>> >
>> >
>> >
>> >
>> > 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.
>> >
>> > The IETF Secretariat
>> >
>>
>>
>