IETF Logo Mail Archive

Re: [Spud] Additional SPUD use-cases

Aaron Falk <aaron.falk@gmail.com> Wed, 18 March 2015 17:37 UTC

Return-Path: <aaron.falk@gmail.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43011A00F5 for <spud@ietfa.amsl.com>; Wed, 18 Mar 2015 10:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 iK4G-si0oIyz for <spud@ietfa.amsl.com>; Wed, 18 Mar 2015 10:37:25 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2CE1A003B for <spud@ietf.org>; Wed, 18 Mar 2015 10:37:24 -0700 (PDT)
Received: by igcqo1 with SMTP id qo1so51195647igc.0 for <spud@ietf.org>; Wed, 18 Mar 2015 10:37:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n65iidLL0kdgTwKDRrh+OzwGy+JkevRKHJZS3iM1sv0=; b=C2jy5GXkjpPADQM3bYmDg33RMgkVx01rxldzZjBliwbuI2/4uXBrle9s70XNHVytZc izjtTBZfBGiFVjGGwuCbMcAF6GZ0RYsfkeA5wDGcFokfyEBhXddvkjarmRzgqnV2RFeC NowMo/s+JPQ50jsVaRBXuNBDIAig5xdyo20x97f50t1G7dfimV30d16l78U8zQ9MUmTA VIYAp+88HndRB2GkWrEkAXvStf9eFGBRkHS15CFjRe6af1lepL+ZAcj5PssoRAhvPUhG EsMtUyhK/52d7I1xOANKgEfDbzWm0zHNk02wiM7dxtsdhzSFOVW+FQ2RjMGnls6nSmJ0 rxwg==
MIME-Version: 1.0
X-Received: by 10.50.129.9 with SMTP id ns9mr9043258igb.24.1426700244425; Wed, 18 Mar 2015 10:37:24 -0700 (PDT)
Received: by 10.64.113.196 with HTTP; Wed, 18 Mar 2015 10:37:24 -0700 (PDT)
In-Reply-To: <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk>
References: <B57E4F68-A0C6-44D8-A729-47B1BED309C9@cisco.com> <CA+9kkMB4kfmMuR61aAhHLzrhEK37dEqy9cpdaqdtzpuyoCbBfg@mail.gmail.com> <CE03DB3D7B45C245BCA0D24327794936412E51@MX104CL02.corp.emc.com> <CAD62q9WRVazAO5QNGbaLwVuesSHrASYVwY5W7A+UACY9x0G1BQ@mail.gmail.com> <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk>
Date: Wed, 18 Mar 2015 13:37:24 -0400
Message-ID: <CAD62q9X1YGQe6_N9qDDBHTJJOj2j_mjAsUBdMvtH1vhJxktopQ@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Content-Type: multipart/alternative; boundary=047d7b343c9c45236d05119389c4
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/lAIcVhXEpyyTHRCZJN87Be7lm4E>
Cc: "Pal Martinsen \(palmarti\)" <palmarti@cisco.com>, "Black, David" <david.black@emc.com>, Ted Hardie <ted.ietf@gmail.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] Additional SPUD use-cases
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2015 17:37:27 -0000

Ah, so in TSVWG.  +1 to your list of hopes.

--aaron

On Wed, Mar 18, 2015 at 1:13 PM, <gorry@erg.abdn.ac.uk> wrote:

> David & I  approved the talk as a presentation of current research.
>
> My own hopes are that this talk focusses on:
>
> - the existing experiments and running code, showing how this handles
> congestion-control.
> - Actual gains of a L2-enhanced approach, such as this, compared to a
> mechanism such as ECN.
> - How to handle speed-increases, previous attempts at explicit signals for
> speed increases at the IETF have all failed to progress. I am dubious that
> this signal is useful for a shared capacity bearer.
> - Explain the security requirements and model (which I do not understand).
> - Help understand if this useful outside of a single-bottleneck radio
> network.
>
> To avoid any confusion: This is an individual submission expected to start
> a discussion, this draft will not be considered as a candidate for
> adoption at this meeting.
>
> Gorry
>
> > On Mon, Mar 16, 2015 at 5:02 PM, Black, David <david.black@emc.com>
> wrote:
> >
> >>  Here are four potentially related drafts:
> >>
> >>
> >>
> >> -- Rate Adaptation based on network feedback, and (to some extent) FCFS
> >> (weak) admission control:
> >>
> >>
> >>
> >> This work is TCP based, but with similar goals:
> >>
> >>
> >>
> >>
> >>
> https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arch/
> >>
> >>
> https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/
> >>
> >>
> >>
> >> The latter draft is (IMHO) better viewed as a proof-of-concept
> >> demonstration that this can work, as opposed to a specific protocol
> >> design
> >> for how to do it.  Design concerns have been raised about what was done
> >> there (e.g., aggressive use of TCP options).
> >>
> >
> > Hi David-
> >
> > Are the congestion control concerns being discussed within a working
> > group?
> >
> > --aaron
> > _______________________________________________
> > Spud mailing list
> > Spud@ietf.org
> > https://www.ietf.org/mailman/listinfo/spud
> >
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

v2.8.7 | Report a Bug | By Email