Re: [tcpPrague] Impact of an L4S experiment on non-TCP transport using ECT(1)

[Ingemar Johansson S <[e-mail]>]

Hi

 

I have now given a fair enough time to get an answer to the question whether or not there exist any implementations of 3GPP TS26.114 that implements ECN support. The answer is still that I have not found any evidence of such implementations. 

Given this piece of information I don’t see a problem that ECT(1) is redefined for L4S.

 

The proper way would of course be to write up an LS to 3GPP with a reference to relevant L4S work and ask for feedback, I believe that this possibility was brought up at the TSVWG session ?

 

/Ingemar

 

From: Ingemar Johansson S 
Sent: den 20 juli 2016 22:51
To: '[e-mail]' <[e-mail]>rg>; '[e-mail]' <[e-mail]>
Cc: '[e-mail]' <[e-mail]>rg>; Ingemar Johansson S <[e-mail]>
Subject: RE: [tcpPrague] Impact of an L4S experiment on non-TCP transports using ECT(1)

 

Hi

 

FYI, I am trying to get some info if there are any implementations (pending or existing) of ECN support for 3GPP MSTI according to TS26.114. I am almost certain that there are no but it needs to be checked out, given vacation period and all it may take a while to get a clear answer.

 

/Ingeamr 

 

From: Colin Perkins [mailto:[e-mail]] 
Sent: den 20 juli 2016 10:34
To: Bob Briscoe <[e-mail] <mailto:[e-mail]> >
Cc: TCP Prague List <[e-mail] <mailto:[e-mail]> >
Subject: Re: [tcpPrague] Impact of an L4S experiment on non-TCP transports using ECT(1)

 

Bob,

 

On 19 Jul 2016, at 19:22, Bob Briscoe <[e-mail] <mailto:[e-mail]> > wrote:

 

Colin,

For the writing about the proposed effect of L4S on RFC6679, see the L4S problem statement section 1.4, item 3B)
https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-02#section-1.4

It there are any other RFCs beyond the list there that use ECT(1) that we're not aware of, pls let me know.
Can you explain the impact on circuit breaker?

 

The ongoing experiments with AQM and ECN, of which L4S is a part, have made it very unclear how a transport should respond to ECN-CE marks, for either ECT(0) or ECT(1). The circuit breaker got caught in that discussion. 

 

Colin

 

 

 

 

Prior to the problem statement, text about 6679 was written in the L4S identifier draft that I've presented in tsvwg, and mentioned the effect on other transports including RTP-ECN.
We wrote what we thought the process would be in https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#section-1.3
However, the tsv management have now clarified how they want this done (I'm expecting discussion in tsvwg tomorrow now we've had the BoF).


I can send you the draft text we're proposing to use to update 3168, 6679 etc, if you want (or you can wait until it's actually submitted as a draft, perhaps tonight.
Essentially the idea is 2-stage:
1) a PS to obsolete RFC3540 (experimental) and to update RFC3168 RFC4960 RFC6679 RFC4340 to reserve ECT(1) for future experiments again
2) the L4S identifier draft (draft-briscoe-tsvwg-ecn-l4s-id) to use the newly reserved ECT(1) codepoint experimentally

I appreciate that there might be implementations in progress that use ECT(1), but as 6679 did not say what ECT(1) is for, I doubt it.
If an RTP implementation is using a field in the IP header for something that hasn't been standardised by the IETF and is not the current experimental use (the ECN nonce), then I think it has no right to complain if it gets stamped on by a new IETF-sanctioned experiment.

You will recall I checked the intent of the ECT(1) text in 6679 on the avtcore list some time ago.
See your response then, pasted below.


Bob


-------- Forwarded Message -------- 


Subject: 

Re: [AVTCORE] RFC6679 ECN in RTP: intent of ect = 0, 1, or random?


Date: 

Mon, 9 Nov 2015 10:55:14 +0000


From: 

Colin Perkins  <mailto:[e-mail]> <[e-mail]>


To: 

Bob Briscoe  <mailto:[e-mail]> <[e-mail]>


CC: 

Ingemar Johansson S  <mailto:[e-mail]> <[e-mail]>om>, Magnus Westerlund  <mailto:[e-mail]> <[e-mail]>om>, Ken Carlberg  <mailto:[e-mail]> <[e-mail]>

 

Bob,
 
This sounds interesting, and would be a good fit for the RMCAT working group, but doesn’t sound like it would be an update to the ECN-for-RTP RFC (which specifies ECN negotiation, marking, and feedback, but no congestion control algorithms).
 
Colin
 
 
 
 
> On 5 Nov 2015, at 10:04, Bob Briscoe  <mailto:[e-mail]> <[e-mail]> wrote:
> 
> Colin,
> 
> OK. In the fullness of time, if our proposal continues to get traction, I'll draft a little experimental bis to ECN in RTP to specify scalable congestion control. It will be v simple:
> 
> If using scalable cc:
> * sender only uses scalable cc if (all) receiver(s) report ECN support
> * sender rate equation is like TFRC equation, but with 1/p instead of 1/sqrt(p)
> * fall back to TFRC equation on loss rather than ECN (and also possibly on ECN accompanied by high variable delay) for 'a few' 1RTT (TBD)
> * sender sets ECT(1) not ECT(0)
> * no changes on receiver
> * I think it would work deployed one RTP hop at a time, but that would have to be tested
> 
> But I'd want to implement and test it first, of course.
> 
> 
> 
> Bob
> 
> On 05/11/15 07:34, Colin Perkins wrote:
>> Bob,
>> 
>>> On 4 Nov 2015, at 17:50, Bob Briscoe  <mailto:[e-mail]> <[e-mail]> wrote:
>>> 
>>> Piers,
>>> 
>>> I realised I didn't send the mail thanking you for your response. Thank you - v useful, and confirmation of my vague memory of events.
>>> 
>>> 1. Would the authors (and wider community) be happy to allow ECT(1) not to be set-aside for future anti-cheating use, as long as there was another way, in principle, for the sender to check for cheating?
>> I have no objection. You might check with the RMCAT chairs, since some of their proposals make use of ECN with RTP, but I doubt this will be a problem.
>> 
>>> For TCP, we worked out a way for the sender to check for cheating without burning a codepoint - by the sender introducing one or two CE codepoints of its own, and checking the receiver reports them. Would this be harder for RTP? Are the receiver reports deterministic enough for the sender to determine whether codepoints it injected are correctly counted in the next report?
>> The sender could easily set a CE mark on a small number of packets it’s sending. For unicast cases, where there’s an explicit control loop, it should be able to correlate this with the returned RTCP feedback. Where it might be difficult is with open loop layered multicast congestion control, where some receivers might see the CE mark and drop a layer since they don’t know it’s a synthetic mark.
>> 
>> Colin
>> 
>> 
>> 
>> 
>>> 2. A couple of days after I posted the original question, we posted the -00 individual draft aiming to start the process of repurposing ECT(1). You will see the sentence in the scope section  <https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-00#section-1.3> <https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-00#section-1.3>
>>> 
>>> See security considerations for discussion on feedback integrity checking.
>>> 
>>> 
>>> Bob
>>> 
>>> On 19/10/15 10:15, Piers O'Hanlon wrote:
>>>> Hi Bob,
>>>> 
>>>> I think the reasoning was that ECT(1)/random could potentially be used to detect cheating/failures as mentioned in section 7.4, but I can't see that it's going to make a lot of difference if ECT(1) is not used.
>>>> 
>>>> Piers
>>>> 
>>>> On 17 Oct 2015, at 22:59, Bob Briscoe wrote:
>>>> 
>>>>> Guys,
>>>>> [Ignore last identical email - I left the list off the distr in error]
>>>>> 
>>>>> I'm writing a draft to propose a new use for ECT(1).
>>>>> 
>>>>> In reading RFC6679, It says that the there is no intent to use an ECN nonce.
>>>>> Also it says the receiver might want to advise the sender not to use ect=random, if its behind a header compression link. And that ect=0 is recommended and the default.
>>>>> 
>>>>> But it doesn't seem to actually say why a sender might send ECT(1) instead of ECT(0). Or why a sender might use the two randomly. Or why a receiver might ask for ect=1, or ect=random.
>>>>> 
>>>>> I'm trying to work out whether there would be any detriment to RFC6679 if it couldn't use ECT(1). It looks like not.
>>>>> 
>>>>> 
>>>>> Bob
>>>>> 
>>>>> -- 
>>>>> ________________________________________________________________
>>>>> Bob Briscoehttp://bobbriscoe.net/
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoehttp://bobbriscoe.net/
>>> 
>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/avt
 

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

 

 

-- 

Colin Perkins

https://csperkins.org/