Re: [tcpm] [tsvwg] draft-han-tsvwg-cc

Thanks, Michael

There are a lot of Standards track RFC about L3 PHB in conjunction
with admission control/CAC and i can't remember a single one
that discusses underlying L2 CAC unless it defines how to 
map to such L2 mechanisms or defines them. But not any RFC
simply expecting admission control mechanisms to define higher
layer behavior.

[ RFC5865 is maybe an interesting example to see how
  expectations against capacity admission are described in a
  standards track RFC that is arguing to modify / expand PHB
  And this is already going farther in outlining
  options than i've seen in othre RFCs. Note that there is
  also no notion of "controlled networks" or the like to constrain
  applicability, because that AFAIK is really only done in
  docs targeting Internet/EF. ]

I am not saying this to dismiss your point (quite the opposite),
but rather in fear of past experiences where such explanatory 
text was seen as unnecessary/gratuitous given how the particular 
drafts text was meant to be orthogonal to whatever underlying
option was used to provide dependencies.

Maybe one way to look at this is that there may be a community
in the IETF well aware of DiffServ/QoS/CAC, but its not the
TCP community, so more informational text about feasible
alternatives and expectations to deploy this type of
"hybrid CAC + CC" for TCP flow would be helpful for acceptance
by the TCP community ?!

If so, then maybe it would be better to provide such framework
information in a draft separately from one specifically targeted
for an individual CC algorithm such as Reno or any of the
other popular ones. What do you think ?

Cheers
    Toerless

On Sat, Mar 17, 2018 at 08:47:56PM +0000, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> Resource guarantees and admission control will in many cases also be needed below IP, e.g., if there are shared resources (e.g., Ethernet switches or Wifi meshes). If there are shared resources below IP, resource reservation at IP layer will not be sufficient for this proposed congestion control.
> 
> So, the assumptions on the network architecture and its functionality are not limited to the IP layer only. This needs to be made explicit in the document.
> 
> Michael
> 
> 
> > -----Original Message-----
> > From: Toerless Eckert [mailto:tte@cs.fau.de]
> > Sent: Saturday, March 17, 2018 9:26 PM
> > To: Eggert, Lars <lars@netapp.com>
> > Cc: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>;
> > Thomas Nadeau <tnadeau@lucidvision.com>; tcpm@ietf.org; Yingzhen Qu
> > <yingzhen.qu@huawei.com>
> > Subject: Re: [tcpm] [tsvwg] draft-han-tsvwg-cc
> > 
> > Thanks, Lars
> > 
> > Maybe please read my reply to Michael where i was trying to explain that this
> > is not intended for Internet/BE, but for PHBs where admsision control and
> > upspeeding are feasible - and support TCP there.
> > 
> > Cheers
> >     Toerless
> > 
> > On Sat, Mar 17, 2018 at 07:20:17AM +0000, Eggert, Lars wrote:
> > > Hi,
> > >
> > > I tried to write up a detailed reply, but I stopped myself. Here is the meta-
> > argument:
> > >
> > > Essentially, there seems to be an underlying desire here - for whatever
> > reason - to change the Internet to an architecture that has admission control,
> > and discuss how transport protocols should change in response to that.
> > >
> > > I don't think such an change to the Internet will happen anytime soon. I
> > hence don't think that spending any time on discussing CC for such an
> > unlikely future is a very productive use of our time in the IETF.
> > >
> > > Lars
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
---
tte@cs.fau.de