Ingemar, inline...
At 06:36 22/01/2014, Ingemar Johansson S wrote:
Hi
Please find answers inline
/Ingemar
> -----Original Message-----
> From: Bob Briscoe [mailto:[email protected]]
> Sent: den 21 januari 2014 23:50
> To: Ingemar Johansson S; [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2
> or tunnel protocols?
>
> Ingemar,
>
> 1) Thx for the pointer. We should add this as another example where a lower
> layer marks the IP header (the example we already have is the L3 switch in
> the Ethernet world).
>
> 2) It doesn't talk about propagation of ECN markings during encap & decap,
> which is one of the things ecn-encap-guidelines aims to give guidelines on.
> Do you think a doc like the draft we've done
would be useful to help 3GPP in
> this respect? Do you think a formal liaison
would be useful to point it out?
L2 in this respect are the PDCP, RLC and MAC
layers (to be honest I am not fully clear what
constitutes L2). The problem is that to given
encap/decap a meaning in this case it becomes
necessary to encode at least an ECN-CE bit into
any of the PDCP or RLC or MAC headers, as PDCP
is ciphered it probably needs to be in the RLC
or MAC headers. Currently there are no standards
efforts to add an ECN-CE bit to any of these headers.
I didn't mean encap of L3 in L2, because that
would indeed require major protocol changes. In
this case, the L2 node is marking L3 directly (see 1 above).
I meant L3 in L3 (tunnelling), which is prevalent in 3GPP.
>
> 3) 3GPP TS 36.300 is ambiguous whether ECN
marking is applied to all packets
> to "indicate congestion", or whether it is applied with a frequency or
> probability that depends on an AQM (it doesn't mention AQM, altho
> obviously it refers to RFC3168 that is based on AQM). Do you know whether
> it was meant to imply use of AQM?
Yes, it is very ambiguous, I advocate for a
frequency or probability as it makes most sense,
but this is not specified at all. The ECN
marking can imply the use of AQM but that is
again not specified. In short, much of the
actual implementation is vendor specific.
OK. In general vendor-specific is good, and
congestion control can be robust to different behaviours.
Our draft states that algorithm guidance is outside its scope, but...
One of the purposes of the IETF's AQM guidance is
to set bounds on how much variety is feasible
without losing interworking. There's a message in
3GPP TS 36.300 on how the IETF's RFCs could be
(mis)interpreted, if we don't make them clear.
Bob
>
> [Ruediger, thx for the supportive words too]
>
>
> Bob
>
> At 20:29 21/01/2014, Ingemar Johansson S wrote:
> >Hi
> >
> >Please note that ECN over LTE radio access is already standardized in
> >3GPP TS 36.300 (see 11.6 in
> >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zip )
> >
> >/Ingemar
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > Sent: den 21 januari 2014 08:38
> > > To: [email protected]
> > > Cc: [email protected]; [email protected]
> > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN
> > > to L2 or tunnel protocols?
> > >
> > > Hi Bob,
> > >
> > > I support the issue being picked up by IETF. What can be done within
> > > the bounds of IETF responsibility should be done. If ECN is seeing
> > > deployment, especially ECN support for IP over VLAN over IP/MPLS may
> be of interest.
> > > Further, ECN over LTE radio Access may be relevant (but my expertise
> > > is too limited to judge details).
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: [email protected] [mailto:[email protected]] Im
> > > Auftrag von Bob Briscoe
> > > Gesendet: Montag, 4. November 2013 23:04
> > > An: tsvwg IETF list; AQM IETF list
> > > Cc: [email protected]
> > > Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or
> > > tunnel protocols?
> > >
> > > Folks,
> > >
> > > Pls respond if you support this being adopted as a work-group item
> > > in the IETF transport services w-g (tsvwg). The WG
> > chairs need visibility of interest.
> > > Even better, if you're willing to read / comment / review /
> > > implement
> > >
> > > Guidelines for Adding Congestion Notification to Protocols that
> > > Encapsulate IP
> > >
<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines> > > >
> > >
> > > Abstract
> > >
> > > The purpose of this document is to guide the design of congestion
> > > notification in any lower layer or tunnelling protocol that
> > > encapsulates IP. The aim is for explicit congestion signals to
> > > propagate consistently from lower
layer protocols into IP. Then the
> > > IP internetwork layer can act as a portability layer to carry
> > > congestion notification from non-IP-aware congested nodes up to the
> > > transport layer (L4). Following these guidelines should assure
> > > interworking between new lower layer congestion notification
> > > mechanisms, whether specified by the
IETF or other standards bodies.
> > >
> > >
> > > [Cross-posting tsvwg & aqm, just in case]
> > >
> > >
> > > Bob Briscoe,
> > > also for co-authors Pat Thaler and John Kaippallimalil
> > >
> > >
> > >
> __________________________________________________________
> > > ______
> > > Bob Briscoe, BT
> > >
> >
> >_______________________________________________
> >aqm mailing list
> >[email protected]
> >https://www.ietf.org/mailman/listinfo/aqm
>
> __________________________________________________________
> ______
> Bob Briscoe, BT
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
