Subject: [tcpPrague] l4s - New Meeting Session Request for IETF 96

From: "\"IETF Meeting Session Request Tool\"" <[email-masked]>
Date: Fri, 10 Jun 2016 09:35:22 -0700

A new meeting session request has just been submitted by Cindy Morgan, on behalf of the l4s working group.

---------------------------------------------------------
Working Group Name: Low Latency Low Loss Scalable throughput
Area Name: Transport Area
Session Requester: Cindy Morgan

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 200
Conflicts to Avoid: 
 First Priority: avtcore, iccrg, alto, aqm, dtn, ippm, mptcp, nfsv4, rmcat, taps, tcpinc, tcpm, tram, tsvwg

Special Requests:
  
---------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 13 Jun 2016 09:36:15 +0100

Mirja, L4S chairs,

[Adding the tcpprague list - which contains the most important people 
who might have conflicts]

Here's my thinking behind the conflict list:
I put: "all Transport Area WGs, avtcore, iccrg", which resulted in the 
current conflicts list:

Conflicts to Avoid:

We have a list of WGs that we have already said L4S will interact with 
in the problem statement:
* tsvwg, aqm, tcpm, rmcat, iccrg, avtcore

* mptcp will be added in the next draft of the problem-statement 
(omission pointed out by Marcelo)

I think we should keep the following:
* dtn: addressing a very similar problem of ultra-low loss, ultra-low 
latency, but currently in a very different way
* taps: l4s is disruptive to taps, because it offers a protocol that 
removes the queuing delay dimension from the requirements dilemma - 
potentially eventually for all transport protocols

That leaves the following that could be trimmed:
* alto, nfsv4, tcpinc, tram

I think tcpinc should stay as a second (or even first) priority 
conflict, because of all the tcp experts who would be conflicted.

Bob

On 11/06/16 19:11, Mirja Kuehlewind (IETF) wrote:
> Hi Phil,
>
> I anyway want to trim the conflict list (because currently there is more stuff on than needed). I guess you as chair should be able to do that as well. Please do so if you want. But please do it soon if possible :-)
>
> Mirja
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 13 Jun 2016 08:57:24 +0000

Hi,

On 2016-06-13, at 10:36, Bob Briscoe <[email-masked]> wrote:
> I put: "all Transport Area WGs, avtcore, iccrg", which resulted in the current conflicts list:
> 
> Conflicts to Avoid:

I'd put these as 2nd order: avtcore, ippm, tram

And these even lower: alto, dtn, nfsv4

Lars

> 
> 
> We have a list of WGs that we have already said L4S will interact with in the problem statement:
> * mptcp will be added in the next draft of the problem-statement (omission pointed out by Marcelo)
> 
> * dtn: addressing a very similar problem of ultra-low loss, ultra-low latency, but currently in a very different way
> * taps: l4s is disruptive to taps, because it offers a protocol that removes the queuing delay dimension from the requirements dilemma - potentially eventually for all transport protocols
> 
> I think tcpinc should stay as a second (or even first) priority conflict, because of all the tcp experts who would be conflicted.
> 
> 
> Bob
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 13 Jun 2016 11:48:19 +0100

Lars,

avtcore specified RFC 6679 (ECN in RTP), which is proposed standard and 
contains more specific uses of ECT(1) than any other RFC (even tho the 
ECT(1) parts have not been implemented as far as anyone can tell). 
RFC6679 is also referenced by 19 3GPP specs (9 reference it normatively).

Bob

On 13/06/16 09:57, Eggert, Lars wrote:
> _______________________________________________
> tcpPrague mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpprague