Re: [Spud] Additional SPUD use-cases

> - Explain the security requirements and model (which I do not understand).

I believe that I do understand the security model, and I see serious problems with it.

Overall, as Gorry noted, we (tsvwg chairs) put this topic (primarily draft-sprecher-mobile-tg-exposure-req-arch) on the tsvwg Dallas  agenda because we think there’s an interesting discussion to be had about what could and should be done in this area.
Speaking for myself, understanding the possibilities here is useful, so the experiments are valuable, but I don’t regard the protocol used to run the experiments as useful for much beyond than running experiments.

Thanks,
--David

From: Aaron Falk [mailto:aaron.falk@gmail.com]
Sent: Wednesday, March 18, 2015 1:37 PM
To: Gorry Fairhurst
Cc: Pal Martinsen (palmarti); Black, David; Ted Hardie; spud@ietf.org
Subject: Re: [Spud] Additional SPUD use-cases

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<mailto: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<mailto: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<mailto:Spud@ietf.org>
> https://www.ietf.org/mailman/listinfo/spud
>

_______________________________________________
Spud mailing list
Spud@ietf.org<mailto:Spud@ietf.org>
https://www.ietf.org/mailman/listinfo/spud