Subject: [iccrg] Draft agenda available

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Feb 2013 14:23:05 +0100

Hi,

The draft agenda is now available at:
http://www.ietf.org/proceedings/86/agenda/agenda-86-iccrg

and below. As you can see, there is still space available - send us your requests!

Cheers,
Michael

***

ICCRG agenda, IETF #84
Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

Rong Pan: "A follow up on the PIE queue management algorithm", 30 min

Toke Hoeiland-Joergensen: "The State of the Art in Bufferbloat Testing and Reduction on Linux", 30 min

---

From: Matt Mathis <[email-masked]>
Date: Wed, 27 Feb 2013 09:47:14 -0800

I would like to present "Drawing the line between transport and network
requirements"

Mini abstract:

How should we draw the line between problems that should be solved in the
network layer vs the transport protocol?  Imagine co-engineering a
diagnostic to certify correct network behavior and the future evolution of
TCP.  What network properties would you test, and why?    Model Based
Metrics (IPPM ID) suggests some answers, but there are still open
questions.   For example the current state of transport protocols severely
limits equal cost multi-path routing -- is this a bug?   Should such
a diagnostic discourage (forbid?) reordering or should we consider
transport intolerance to reordering to be a bug?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Wed, Feb 27, 2013 at 5:23 AM, Michael Welzl <[email-masked]> wrote:

> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Feb 2013 21:36:03 +0100

that's very welcome. what's your time estimate? 30 mins, including discussion?

On Feb 27, 2013, at 6:47 PM, Matt Mathis <[email-masked]> wrote:

> I would like to present "Drawing the line between transport and network requirements"
> 
> Mini abstract:
> 
> How should we draw the line between problems that should be solved in the network layer vs the transport protocol?  Imagine co-engineering a diagnostic to certify correct network behavior and the future evolution of TCP.  What network properties would you test, and why?    Model Based Metrics (IPPM ID) suggests some answers, but there are still open questions.   For example the current state of transport protocols severely limits equal cost multi-path routing -- is this a bug?   Should such a diagnostic discourage (forbid?) reordering or should we consider transport intolerance to reordering to be a bug?
> 
> Thanks,
> --MM--
> Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.
> 
>

---

From: Matt Mathis <[email-masked]>
Date: Wed, 27 Feb 2013 12:40:19 -0800

30 min would be a good plan.   Mind you I haven't written the talk or
slides yet.

BTW It isn't totally clear that this is in scope for iccrg.  Burst and
reordering tolerance are not necessarily viewed as congestion control
issues.  The case being that they are entangled in the same code.

Thanks,
--MM--

On Wed, Feb 27, 2013 at 12:36 PM, Michael Welzl <[email-masked]> wrote:

> > How should we draw the line between problems that should be solved in
> the network layer vs the transport protocol?  Imagine co-engineering a
> limits equal cost multi-path routing -- is this a bug?   Should such a
> diagnostic discourage (forbid?) reordering or should we consider transport
> intolerance to reordering to be a bug?
> >
> > Thanks,
> > --MM--

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Feb 2013 22:28:03 +0100

On Feb 27, 2013, at 9:40 PM, Matt Mathis <[email-masked]> wrote:

> 30 min would be a good plan.   Mind you I haven't written the talk or slides yet.

Thanks (no worries about the slides)

> BTW It isn't totally clear that this is in scope for iccrg.  Burst and reordering tolerance are not necessarily viewed as congestion control issues.  The case being that they are entangled in the same code.

I think it is in scope. From our charter:
"Because congestion control is typically a key function of transport protocols, it is hard to separate other transport layer issues from congestion control. Considerations for deployment of transport protocols are therefore also considered within scope."

(yeah, not sure if you could call this "considerations for deployment of…" but anyway I'd take these two sentences as a clear in-scope hint for your presentation)

Cheers,
Michael

---

From: Janardhan Iyengar <[email-masked]>
Date: Wed, 27 Feb 2013 16:47:30 -0500

Matt,

It seems to me that a discussion of the line where an endpoint's
responsibility ends and where the network's begins does belong in ICCRG,
but may *also* belong in TSVAREA.

I look forward to the discussion.
- jana

On Wed, Feb 27, 2013 at 4:28 PM, Michael Welzl <[email-masked]> wrote:

> "Because congestion control is typically a key function of transport
> protocols, it is hard to separate other transport layer issues from
> congestion control. Considerations for deployment of transport protocols
> are therefore also considered within scope."
>
> (yeah, not sure if you could call this "considerations for deployment of…"
> but anyway I'd take these two sentences as a clear in-scope hint for your
> presentation)
>
> Cheers,
> Michael
>
>
> >
> > Thanks,
> > --MM--

---

From: Scott Brim <[email-masked]>
Date: Wed, 27 Feb 2013 16:52:59 -0500

> I look forward to the discussion.

I look forward to the discussion too, in both groups.  But let's abandon
layers and just deal with the functionality, e.g. congestion control.
The same issues exist if you have "smart" nodes along a path and
possibly very different transport mechanisms in different segments.

Scott