Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2)

gorry@erg.abdn.ac.uk Fri, 22 August 2014 19:13 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6281A0491 for <dart@ietfa.amsl.com>; Fri, 22 Aug 2014 12:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level:
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdJopaUDFZ41 for <dart@ietfa.amsl.com>; Fri, 22 Aug 2014 12:13:05 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id AC7071A04B4 for <dart@ietf.org>; Fri, 22 Aug 2014 12:13:04 -0700 (PDT)
Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5BF282B4305; Fri, 22 Aug 2014 20:13:03 +0100 (BST)
Received: from 139.133.204.3 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 22 Aug 2014 20:13:03 +0100
Message-ID: <d6c630fad706a9a6ba5761bcb7d8ca78.squirrel@www.erg.abdn.ac.uk>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42A58@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712077B951FF0@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A58@MX15A.corp.emc.com>
Date: Fri, 22 Aug 2014 20:13:03 +0100
From: gorry@erg.abdn.ac.uk
To: "Black, David" <david.black@emc.com>
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/-1-ex3eCsWEiKC3Hm8e56T1_xss
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>
Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2)
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 19:13:07 -0000

I could live with that - it would be even nicer if we actually had a
document with set of recommendations to point to - but since we don't,
this seems an appropriate statement.

Gorry


> Here's the next to last paragraph in Section 5.3:
>
>    SCTP [RFC4960] differs from TCP in a number of ways, including the
>    ability to deliver messages in an order that differs from the order
>    in which they were sent and support for unreliable streams.  However,
>    SCTP performs congestion control and retransmission across the entire
>    association, and not on a per-stream basis.  Although there may be
>    advantages to using multiple drop precedence across SCTP streams or
>    within an SCTP stream that does not use reliable ordered delivery,
>    there is no practical operational experience in doing so (e.g., the
>    SCTP sockets API [RFC6458] does not support use of more than one DSCP
>    for an SCTP association).  As a consequence, the impacts on SCTP
>    protocol and implementation behavior are unknown and difficult to
>    predict.  Hence a single PHB and DSCP should be used for all packets
>    in an SCTP association, independent of the number or nature of
>    streams in that association.  Similar reasoning applies to a DCCP
>    connection; a single PHB and DSCP should be used because the scope of
>    congestion control is the connection and there is no operational
>    experience with using more than one PHB or DSCP.
>
> I propose to add the following new sentence as its own paragraph:
>
>    Guidance on transport protocol design and implementation to provide
>    support for use of multiple PHBs and DSCPs in a transport connection
>    (e.g., DCCP) or association (e.g., SCTP) is out of scope for this
>    document.
>
> I could add examples of topics that could be addressed, but would prefer
> to leave that to the actual design activity.
>
> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: Black, David
>> Sent: Thursday, August 14, 2014 9:16 AM
>> To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de
>> Cc: dart@ietf.org; Black, David
>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2)
>>
>> Wearing none of my hats, I would prefer to put Gorry's item (2) into a
>> TSV
>> (Transport Area) draft somewhere, and hence prefer the suggestion to say
>> that this document does not provide that sort of guidance.
>>
>> > > (2) I don't know if the document's goal is also to make transport
>> > > recommendations for using multiple code points - i.e., things such
>> as must
>> > > be robust to the network changing a DSCP; needs to independently
>> verify
>> > > that a particular DCSP is not being black-holed, needs to not imply
>> > > relative precedence when interpreting loss or marking of packets for
>> a
>> > > flow using multiple DCSPs etc. ???
>> > >
>> > > If these are out of scope, then maybe the document should say that
>> this
>> > > particular document does not provide this sort of guidance.
>>
>> Thanks,
>> --David
>>
>> > -----Original Message-----
>> > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of
>> gorry@erg.abdn.ac.uk
>> > Sent: Thursday, August 14, 2014 9:06 AM
>> > To: Ruediger.Geib@telekom.de
>> > Cc: gorry@erg.abdn.ac.uk; dart@ietf.org
>> > Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
>> >
>> > Thanks
>> >
>> > When I said "transport" I was thinking of the algorithms to be used in
>> the
>> > end-host to figure out what was operational and where congestion and
>> delay
>> > were experienced. But what you say is all an import part. I expect
>> what
>> > you discuss, could go into the tsvwg intercom draft.
>> >
>> >
>> > Gorry
>> > > Hi Gorry,
>> > >
>> > > the following text will likely appear in the next version of my
>> > > diffserv-intercon draft. The more DSCPs appear in a flow which
>> aren't
>> > > deployed end-to-end for the corresponding PHB, the more often one of
>> the
>> > > scenarios will be encountered.
>> > >
>> > > The following scenarios start from a domain sending
>> > > IP traffic using a PHB and a corresponding DSCP to an interconnected
>> > > domain. The receiving domain may
>> > > -	Support the PHB and offer the same corresponding DSCP
>> > > -	Not support the PHB and use the DSCP for a different PHB
>> > > -	Not support the PHB and not use the DSCP
>> > > -	Support the PHB with a differing DSCP, and the DSCP of the
>> > >        sending domain is not used for another PHB
>> > > -	Support the PHB with a differing DSCP, and the DSCP of the
>> > >        sending domain is used for another PHB
>> > >
>> > > Another question to be answered then is how a network provider will
>> treat
>> > > unrecognized or unexpected DSCPs received at network boundaries.
>> > >
>> > > Regards,
>> > >
>> > > Ruediger
>> > >
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry
>> Fairhurst
>> > > Gesendet: Mittwoch, 13. August 2014 22:33
>> > > An: dart@ietf.org
>> > > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
>> > >
>> > >
>> > > I can see good points raised on the details, instead I have some
>> questions
>> > > about the overall document strcuture:
>> > >
>> > > [snip]
>> > >
>> > > (2) I don't know if the document's goal is also to make transport
>> > > recommendations for using multiple code points - i.e.things such as
>> must
>> > > be robust to the network changing a DSCP; needs to independently
>> verify
>> > > that a particular DCSP is not being black-holed, needs to not imply
>> > > relative precedence when interpreting loss or marking of packets for
>> a
>> > > flow using multiple DCSPs etc. ???
>> > >
>> > > If these are out of scope, then maybe the document should say that
>> this
>> > > particular document does not provide this sort of guidance.
>> > >
>> > > Gorry
>> > >
>> > > _______________________________________________
>> > > Dart mailing list
>> > > Dart@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/dart
>> > >
>> >
>> > _______________________________________________
>> > Dart mailing list
>> > Dart@ietf.org
>> > https://www.ietf.org/mailman/listinfo/dart
>