Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF101

[Toerless Eckert <[e-mail]>]

Thanks, Pat - inline.

On Wed, Mar 14, 2018 at 09:41:55AM -0700, Pat Thaler wrote:
> There work underway in detnet WG in the routing area for " point-to-point
> (unicast) and point-to-multipoint (multicast) flows which can be
> characterized in a manner that allows the network to 1) reserve the
> appropriate resources for the flows in advance, and 2) release/reuse the
> resources when they are no longer required."  The purpose is to provide for
> bounded latency, loss and delay variation along with high reliability. The
> current charter is focused on defining the data plane aspects.

Yes, well aware of that. We will also propose he inband signalling fr
that context. The draft already mentions in passing UDP and is really
not difficult to adopt to any transport. TCP was just the most widely
accepted protocol even with more challenges than UDP IMHO, thats why
our inband signaling draft focusses on it. 

> I hope that that will be followed by work to define the control plane.

+1.

> I've only had a quick glance at the draft. It isn't clear to me that it
> would be compatible with a network providing reservations for guaranteed
> bandwidth because it allows for sending at a rate higher than the bandwidth
> guarantee; (i.e. a peak rate higher than the committed rate). If flows are
> allowed to consume more than their reserved resources, they may interfere
> with the resources committed to other flows.

The enforcement of not intruding on reserved capacity is a matter of
the forwarding plane. In the most extreme case which we describe in
our inband singaling, you use per-flow reservation state (shaper/scheduler).

This can be optimized(cost reduced) by only doing per-flow state on the
edge and only admission control (calculate/signal inband) hop-by-hop, but
not establish per-flow packet processing state (shaper/scheduler).

This is all exactly like IMHO it would need to work in DetNet (e.g.:
forwarding plane. Signaling is obviously variable... inband
signaling is just the best IMHO ;-)).

The interesting part of course is that your overall latency and jitter
will go down the drain once you exceed your per-flow shaper/scheduler
CIR + burst size and start to compete based on congestion experience.

For the not really 'realtim' apps like he typical streaming with
guaranteed CIR requiremens but desire for upspeeding, this is a perfect
compromise to strike. For the typical realtime app coming from a CBR
world, thats a surprise that might want them to stick to just CBR = CIR = PIR
requests.

The more advanced video solutions btw would use the AF style forwarding
approach, whereby your <= CIR rate is marked with a hghier priority
AF code point and the CIR..PIR rate with a lower AF code point. And then
you put the more important video frames into your higher AF code point/
<= CIR rate, and the less important frames into the lower priority and
you get even better upspeeding experience (visually). This btw.
is something requiring UDP or SCTP or the like. TCP apps have no
control over message/packet boundaries to mark them accordingly.

Wrt. DetNet: I wam not quite sure about the PHBs defined in TSN.
I sometime have the fear that its a lot more limited than in IP.
I hope we manage to leverage the full extend of IP QoS in DetNet
and not only some L2 TSN QoS subset...

Toerless

> Pat
> 
> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst <[e-mail]>
> wrote:
> 
> > I am unsure yet what the correct group of people world be to explore a
> > "Bandwidth Guaranteed Network". The presentation last IETF looked like the
> > work could imply a need for changes proposed to the network layer (using
> > OAM exchnages) to set the sending rate and make those bandwidth
> > reservations.  In the end, it could result in a protocol quite different to
> > TCP, I think this sort of change may possibly have a home in TSVWG  - but
> > first I'd agree with Michaeland would encourage a presentation of the
> > problem statement in ICCRG to explore the issues.
> >
> > Gorry
> >
> > On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> >
> >>
> >> Hi all,
> >>
> >> From the abstract: ??????This draft proposes a new TCP congestion control
> >> algorithm used in bandwidth guaranteed networks.  It is an extension to the
> >> current TCP standards.???
> >>
> >> In the IETF, I believe the expertise for this specific document would be
> >> in TCPM, which in CC. If the authors are interested in feedback on the
> >> proposed mechanism, I would recommend to ask TCPM.
> >>
> >> Alternatively, corresponding research could perhaps be performed in the
> >> ICCRG. ICCRG has published RFC 6077 to document some of the open research
> >> issues in this space.
> >>
> >> Michael
> >>
> >> *From:*tsvwg [mailto:[e-mail]] *On Behalf Of *Yingzhen Qu
> >> *Sent:* Sunday, March 04, 2018 6:55 AM
> >> *To:* [e-mail]; [e-mail]
> >> *Cc:* Thomas Nadeau <[e-mail]>
> >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101
> >>
> >> Dear Chairs,
> >>
> >> A new draft (The draft was suggested by TSVWG @IETF100) was just
> >> submitted, and we???d like to request a time slot to present it @IETF101.
> >>
> >> Title:A New Congestion Control in Bandwidth Guaranteed Network
> >>
> >> Presenter: Yingzhen Qu (Huawei)
> >>
> >> Time required (including Q/A): 10 mins
> >>
> >> Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/
> >>
> >> If there is any question, please kindly let us know.
> >>
> >> Thanks,
> >>
> >> Yingzhen
> >>
> >>
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >

-- 
---
[e-mail]