Subject: Re: [tram] New Version Notification for draft-martinsen-tram-turnbandwidthprobe-00.txt

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 1 Jun 2015 11:45:08 +0000

> On 29 May 2015, at 21:41, Gonzalo Salgueiro (gsalguei) <[email-masked]> wrote:
> 
> 
>> On May 29, 2015, at 10:57 AM, Simon Perreault <[email-masked]> wrote:
>> 
>> Le 2015-05-29 07:31, Pal Martinsen (palmarti) a écrit :
>>> It is s a simple draft describing how a client can utilise a TURN server
>>> to measure available bandwidth by sending traffic to itself through the
>>> turn server. No TURN server modifications are needed. 
>> 
>> Cool! I can see this being useful.
> 
> Our thoughts exactly ;-)
> 
>> I think it would be worth mentioning that the client is in theory free
>> to use any format for the payload, but in practice using STUN makes it
>> possible to multiplex with existing traffic. So a client that doesn't
>> need multiplexing could do away with all the STUN complexity and just
>> use a home-grown, simple format. This may seem obvious but it still took
>> me a good 5 minutes of head scratching to figure out.
> 
> Good point. We’ll update the draft clarifying this.

In section 4.3 the draft says:
The specific calculation and measurement of the bandwidth is client
dependent and implementation-specific and is thus outside the scope
of this document.

If the client want to use STUN packets as the basis for the probing
packets, then a TIMESTAMP attribute is defined in this specification
(see Section Section 6.1) to simplify measurement of round-trip time
(RTT) and available bandwidth.  A PADDING attribute is already
defined in RFC 5780 [RFC5780] that makes it easy to vary the size of
the STUN probing packet.

The intention was to make it clear that STUN usage for the probe is optional.

But I do agree. Adding some generic text in the introduction and Early in Section 4 would make that more obvious.

Some feedback from the WG regarding document complexity would be nice. I think we have two options, move it in a simpler direction with only the basic bits in it. Or move in a more complex direction describing how bandwidth can be measured and how probes should look like and so on. (Consider this as a agenda request for Prague.)

> 
>>> The three drafts
>>> - PMTUD using
>>> STUN(https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud)
>>> - STUN Traceroute
>>> (https://tools.ietf.org/html/draft-martinsen-tram-stuntrace)
>>> - TURN Bandwidth (The draft in this mail)
>>> (https://www.ietf.org/internet-drafts/draft-martinsen-tram-turnbandwidthprobe)
>>> 
>>> form a simple solution to probe the network for useful information
>>> without requiring any change to the network infrastructure. 
>> 
>> This is starting to look like... *gasp*... a framework! ;)
> 
> This is our intent. We’d like the WG to consider their usefulness and entertain the possibility of adopting these as WG documents (obviously with associated milestones created).
> 
A thought… (Maybe not a good one so please feel free to shoot it down before it evolves)

Can we keep the content of the three drafts (PMTUD, STUNTrace and TURN BW Probe) as simple as we can with only basic functionality described, and then have a draft-tram-probe-framework describing how various probing techniques can be combined and safely used. The framework draft could have all the nasty details regarding timers, how often things should be done and so on. Idea is to have a set of simple drafts that does not change so much over time, but usage of them might. 

.-.
Pål-Erik

> Cheers,
> 
> Gonzalo
> 
>> 
>> Simon
>> 
>> _______________________________________________
>> tram mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Jun 2015 08:34:09 -0400

Le 2015-06-01 07:45, Pal Martinsen (palmarti) a écrit :
> (Consider this as a agenda request for Prague.)

ACK.

> Can we keep the content of the three drafts (PMTUD, STUNTrace and
> TURN BW Probe) as simple as we can with only basic functionality
> described, and then have a draft-tram-probe-framework describing how
> various probing techniques can be combined and safely used. The
> framework draft could have all the nasty details regarding timers,
> how often things should be done and so on. Idea is to have a set of
> simple drafts that does not change so much over time, but usage of
> them might.

You know what, I think I would prefer a single document for everything.
But that's just my personal preference, so it doesn't carry much weight.
I'd like to know what others think.

Simon