Subject: [ipwave] Congestion control support in draft-ietf-ipwave-ipv6-over-80211ocb-00

From: Michelle Wetterwald <[email-masked]>
Date: Fri, 3 Feb 2017 13:22:04 +0100

Hello,

During some recent discussions, we highlighted that this draft may also
evaluate the impact of supporting congestion control functions specified at
ETSI and SAE, also mentioned in p8 section 4.
In Europe, ETSI TS 102 636-4-2 introduces an optional header field to
disseminate the ITS station's view of the channel busy ratio in its
vicinity. This information is used by the lower ITS-G5 layer to control its
contribution to the channel occupancy and avoid congesting the channel.
In the same idea, an IPv6 option header could be introduced to perform
similar functions and enable congestion control algorithms at 802.11-OCB.
Best regards,

Michelle Wetterwald
[email-masked]
----
Senior expert in networking and telecommunications

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 14:34:27 +0100

Hello Michelle,

Le 03/02/2017 à 13:22, Michelle Wetterwald a écrit :
> Hello,
>
> During some recent discussions, we highlighted that this draft may
> also evaluate the impact of supporting congestion control functions
> specified at ETSI and SAE, also mentioned in p8 section 4.

What are the congestion control functions you refer to (on p4/sec.4 of
IPv6/p document I dont find somehting relevant)?  Are they IP-based
mechanisms for congestion control?  Or non-IP mechanisms?

Which Working Groups at IETF consider congestion control?

TCP does some congestion control - is it TCP that ETSI and SAE need?

QUIC is a new transport protocol under discussion at IETF as we speak -
as fast as UDP yet as reliable as TCP (IIRC).  Is QUIC doing congestion
control?  Is QUIC what ETSI and SAE need?

TCP, UDP and QUIC control congestion on Internet at large.  But maybe
ETSI and SAE need congestion control on a single link?  In that case, is
it a link-layer protocol that ETSI and SAE need to control congestion on
that link?  Or is it a network-layer protocol they need?  Or between
link-layer and network-layer?

> In Europe, ETSI TS 102 636-4-2 introduces an optional header field
> to disseminate the ITS station's view of the channel busy ratio in
> its vicinity. This information is used by the lower ITS-G5 layer to
> control its contribution to the channel occupancy and avoid
> congesting the channel. In the same idea, an IPv6 option header could
> be introduced to perform similar functions and enable congestion
> control algorithms at 802.11-OCB.

There is a discussion ongoing over in the 6MAN WG whether or not new
IPv6 'extension' headers are allowed to be created, or not.  The
tendency seems to be to not allow new 'extension' headers, in  my reading.

This does not mean IPv6 is not 'extensible'.

It will always be possible to create new options in existing IPv6
Extension Headers - e.g. the Destinations Options extension header, or
the Hop-by-Hop header extension header, or so.

At this time I think we are still far from having such a definition.  It
should also be implemented, visible in wireshark, demonstrated on road,
etc.

This may be related to the TCLAS discussion as well (map IEEE TCLAS
fields into IPv6 Traffic Class field, select one Traffic Class for one
ITS channel).

This may be related to draft-ietf-tsvwg-ieee-802-11-01.

Let us see how we can progress this from here.

Alex

>
> Best regards,
>
> Michelle Wetterwald [email-masked]
> <mailto:[email-masked]> ---- Senior expert in
> networking and telecommunications
>
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Tony Li <[email-masked]>
Date: Fri, 10 Feb 2017 07:56:05 -0800

> On Feb 10, 2017, at 5:34 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

By and large, congestion control at the engineering level is considered a solved problem. Improvements can be made, of course, which is why the IRTF has the Internet Congestion Control Research Group (https://irtf.org/iccrg <https://irtf.org/iccrg>).

Based on my limited understanding of DSRC, perhaps what’s really more at issue here is a cooperative, secure, and fair link layer traffic scheduling mechanism. Yes, I do realize that may well be a unicorn.

Tony

---

From: Jérôme Härri <[email-masked]>
Date: Sat, 11 Feb 2017 15:02:37 +0100

Hello Alex, Michelle,

I think Michelle referred to the SAE 'wireless' congestion control mechanism
in SAE J2945/1...or the ETSI mechanisms in the DCC set of standards TS 103
165 (and the access TS 102 187). Although I think the SAE does not indicate
a specific 'stack' (SAE being above IEEE 1609.x), the ETSI counterpart is
connected to the ETSI stack and Geonet.

This being said, these mechanisms are not related to what IP traditionally
understand as 'congestion control'. This is 'wireless' congestion control.
Additionally to adjusting the 'rate' or the 'modulation',  'wireless'
congestion control also play with transmit power or Rx sensitivity.
Measuring the channel 'load' (congestion level) is also more complicated
than with TCP-like congestion measurements. 

As you said, both SAE and ETSI (so far) try to address single 'link'
congestion (or multiple links, but not jointly as far as I know), whereas
TCP does it on a larger scale. As I mentioned, the current ETSI harmonized
standard requires a 'wireless' congestion control mechanism to use the
ITS-G5 bands (5.9GHz). How this should be done is not mentioned, although,
there is a 'strict' indication for ITS-G5/OCB technology. Considering that
in EU, the only specification for using ITS-G5 is through the ETSI stack
(even if using IP), the 'wireless' congestion control from ETSI is there.

Now, if you do not use the ETSI stack, we have a loophole (at least for EU).
We need to have a 'wireless' congestion control (and maybe with some limits
specified for ITS-G5), but we do not have any document explaining how to do
this. So, this means we should provide something, otherwise we will not be
able to use (pure)  IPv6 on the ITS-G5 spectrum in EU. 

I am not sure about the restrictions in the US.

As for the IRTF congestion control group, I will have a look, but the
question is if they address 'wireless' aspects. 

Best Regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 14:34
To: [email-masked]
Subject: Re: [ipwave] Congestion control support in
draft-ietf-ipwave-ipv6-over-80211ocb-00

Hello Michelle,

QUIC is a new transport protocol under discussion at IETF as we speak - as
fast as UDP yet as reliable as TCP (IIRC).  Is QUIC doing congestion
control?  Is QUIC what ETSI and SAE need?

TCP, UDP and QUIC control congestion on Internet at large.  But maybe ETSI
and SAE need congestion control on a single link?  In that case, is it a
link-layer protocol that ETSI and SAE need to control congestion on that
link?  Or is it a network-layer protocol they need?  Or between link-layer
and network-layer?

> vicinity. This information is used by the lower ITS-G5 layer to 
> control its contribution to the channel occupancy and avoid congesting 
> the channel. In the same idea, an IPv6 option header could be 
> introduced to perform similar functions and enable congestion control 
> algorithms at 802.11-OCB.

There is a discussion ongoing over in the 6MAN WG whether or not new
IPv6 'extension' headers are allowed to be created, or not.  The tendency
seems to be to not allow new 'extension' headers, in  my reading.

It will always be possible to create new options in existing IPv6 Extension
Headers - e.g. the Destinations Options extension header, or the Hop-by-Hop
header extension header, or so.

At this time I think we are still far from having such a definition.  It
should also be implemented, visible in wireshark, demonstrated on road, etc.

This may be related to the TCLAS discussion as well (map IEEE TCLAS fields
into IPv6 Traffic Class field, select one Traffic Class for one ITS
channel).

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its

---

From: Michelle Wetterwald <[email-masked]>
Date: Tue, 14 Feb 2017 13:18:20 +0100

Hi Alex, Jerome,

Thank you very much to Jerome for clarifying the discussion.
Yes, as I mentioned in my post, I was addressing the congestion control at
the link level, i.e. 802.11-OCB level not at IP level and above. It is
different from the mechanisms (e.g. TCP window, TCLAS, etc...) mentioned by
Alex below.
These algorithms may be required by regional directives and imply some
support from the networking layer above the 802.11-OCB. They may as well
have an impact on the TCP congestion control operation, but this is not in
scope of the current draft dealing with IPv6 only.
Some provision for supporting these algorithms should be found and added to
the draft.

@Alex, there have been a lot of parallel discussions in the past days.
Could you share with us an updated version of the draft, or a document with
all the changes planned / implemented since the last version, so we get a
clean view and can suggest revisions?

Thanks,
Michelle Wetterwald

-- 
Michelle Wetterwald

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Feb 2017 13:40:19 +0100

Le 14/02/2017 à 13:18, Michelle Wetterwald a écrit :
> Yes, as I mentioned in my post, I was addressing the congestion control
> at the link level, i.e. 802.11-OCB level not at IP level and above. It
> is different from the mechanisms (e.g. TCP window, TCLAS, etc...)
> mentioned by Alex below.

I agree.

> have an impact on the TCP congestion control operation, but this is not
> in scope of the current draft dealing with IPv6 only.
> Some provision for supporting these algorithms should be found and added
> to the draft.
>
> Could you share with us an updated version of the draft, or a document
> with all the changes planned / implemented since the last version, so we
> get a clean view and can suggest revisions?

I will submit a -01 during this week.

Expect to see the least common denominators, and less PHY text, less 
mandates about handover behaviour or security.

Alex

>
> Thanks,
> Michelle Wetterwald
> [email-masked] <mailto:[email-masked]>
> ----
> 2017-02-11 15:02 GMT+01:00 Jérôme Härri <[email-masked]
> <mailto:[email-masked]>>:
>
>     Hello Alex, Michelle,
>
>     From: its [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Alexandre Petrescu
>     To: [email-masked] <mailto:[email-masked]>
>     tendency
>     Extension
>     fields
>     <mailto:[email-masked]>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>> ---- Senior expert in
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>     >
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>
> --
> Michelle Wetterwald
> [email-masked] <mailto:[email-masked]>