Re: [PCN] Corridor discussion about draft-satoh,

[SATOH Daisuke <[e-mail]>]

Hi Phil and All,


> >
> > Hi Phil,
> >
> >
> >
> > > We had a long discussion yesterday about draft-satoh's & the WG draft's marking behaviours. I wanted to email two high level things that I concluded, without getting into the particular details of the satoh proposal.
> > >
> > >
> > >
> > > Draft-pcn-marking-behaviour sets out with a goal in mind. This was to come up with something that works reasonably well in a variety of scenarios:
> > >
> > > -          if your network has 3 encoding states (not PCN-marked, and 2 states for PCN-marking), then you can get both accurate admission control (via threshold-markings) and accurate flow termination control (via excess-traffic-markings).
> > >
> > > -          If your network has 2 encoding states (no PCN-marked; PCN-marked) then you have 3 choices: either have accurate admission control (via threshold-markings; and do something else for flow termination); or accurate flow termination control (via excess-traffic-markings; and do something else for admission control); or do both (the single marking idea - but pay the penalty of less accurate admission control when small numbers of flows on the ingress-egress-aggregate).
> > >
> >
> >
> >
> > I believe PCN WG has decided 2 encoding states as standard and 3
> > encoding states as experimental. Do I misunderstand?
> >
> > [phil]. yes. this changes nothing i wrote.
> >
> >
> 
> 
> If it is true, does PCN for both admission and termination with 2
> codepoints have to pay the penalty of less accurate admission control?
> 
> It seems to me that PCN with three codepoints is standard.
> 
> [phil] to repeat:-
> 
> > > -          If your network has 2 encoding states (no PCN-marked; PCN-marked) then you have 3 choices: either have accurate admission control (via threshold-markings; and do something else for flow termination); or accurate flow termination control (via excess-traffic-markings; and do something else for admission control); or do both (the single marking idea - but pay the penalty of less accurate admission control when small numbers of flows on the ingress-egress-aggregate).
> 
> 



That sounds for me PCN with three codepoints is standard.




> 
> >
> >
> > >
> > >
> > > Draft-satoh has a different goal in mind. This is to come up with something that works as well as possible for a scenario where you know you need both admission control and flow termination and where you know you only have 2 encoding states (no PCN-marked; PCN-marked). Now we can argue about whether this particular scenario is better achieved by the single marking draft or by the draft-satoh approach (not clear either way to me), and this is a discussion worth having, at least for academic interest. But from the point of view of the WG I don't think this comparison matters:
> > >
> > > -          it's clear that the draft-satoh approach doesn't give as good performance as {draft-pcn-marking-behaviour + 3 encoding states}
> > >
> >
> >
> > Actually, STM (my proposal) is slightly less accurate than CL in
> > admission control. However, it is better than CL in flow termination
> > when the load is 2x supportable rate without packet loss.
> > I wrote in this ML and explain the mechanism and the reason why accuracy
> > of flow termination in CL is low when the load is 2x supportable rate. I
> > believe CL must know the order of packets at the bottleneck link in
> > order to achieve accurate termination. Getting information of the order
> > of packets at the bottleneck link is almost impossible.
> >
> >
> > [phil] why must it know the order? this problem hasnt been seen in all the simulations others have done.
> 
> 
> 
> Because CL has to terminate appropriate flows in order to keep PCN rate
> stable after one shot termination. Knowing the order of packets is just one
> of example. I want to say traffic information in detail is necessary in
> order to keep PCN rate stable after one shot termination.
> 
> 
> [phil] this is counter-intuitive. your argument seems to be: "I have seen this is my simulations". but what's the intuition about what would happen in reality? i havent heard this. 
> 

No.
The load can be over 2*SR in reality. We cannot say the load is always
lower than 1.25*SR in reality. 
We know quantity of flows to terminate by SAR but we cannot know how to
terminate flows in order to make rate of traffic after termination
stable.





> > please do not confuse the marking behaviour with the edge behaviour. the old CL draft describes one particular edge behaviour based on measuring the CL edge behaviour. however, we know several others are possible - as documented by michael - including when you could terminate little by little. However, your marking behaviour forces the termnination edge behaviour to be little by little, there is no alternative.
> >
> 
> My marking behaviour does not foce the termination edge behavior.
> [phil] yes it does, it forces termination to be done step by step.
> 
> 
> I want you to wait WG last call by I finish simulating termination of my
> idea I said before.
> 
> 
> [phil] i disagree we should wait. only the extreme optimist would think it was a year before we were back to the position we're now in. 
> 
> we have had many simulations done of the WG marking behaviur by joy, anna, michael. it seems that your simulations disagree with their results. that is not an issue that should hold up the WG moving forward. 
> 

No. My simulation does not disagree Joy's results because
they have not simulated the case of 2.0*SR as the load at least. 


I find  1.5*SR is used as the load in draft-zhang-pcn-performance-evaluation-02.
I cannot find out how much load is used in the simulation in draft-charny-pcn-single-marking-03.
I have not read Michael's simluation paper yet. He writes so many papers. Please
tell me URL or the title of the paper that my simulation disagrees.


 

> 
> I do not confuse. I want to say accuracy of my algorithm is not
> necessarily less than that of CL.
> 
> 
> [phil] "not necessarily less" is a weak reason to stop & not move forward now.
> 
> 

When a new thing is discovered, in my opinion, we should prefer to think
of them again.







> 
> 
> 
> >
> >
> > I think it is not late to WG Last Call after solving the above problem.
> >
> >
> > > -          draft-satoh can't be modified for a situation when there's a 3rd encoding state.
> > >
> > >
> > >
> > > The second high level point I wanted to raise is that the draft-satoh work is "in progress". For instance, Daisuke agrees that the marking algorithm described in the draft is too complicated to implement, and has talked about a marking algorithm with 'two steps' [traffic rate above AR, jump to marking say 10% pkts; traffic rate above SR, jump to marking all pkts]. Daisuke also has ideas for improvements for modified behaviour around the sustainable rate. But this is all stuff that needs to be refined, simulated, compared etc. it is clear that there is substantial effort to get any such new proposal in a similar state to what's in draft-pcn-marking-behaviour - what's in the WG draft hasn't changed at all since the -00 version, and in fact for a long time before that.
> > >
> > >
> > >
> > > So there seem to me two choices. One option is that we change our minds & decide that we will optimise for the case where there's only one state for PCN-marking & the operator ewants both adm ctrl & flow termination - then we need to wait for revisions to draft-satoh, compare it with the SM approach, etc - most optimistically in a year's time we'd be in the same position we were perhaps 18months ago for draft-pcn-marking-behaviour. The second choice is that we go forward now with draft-pcn-marking-behaviour - with this choice, there is no benefit to waiting yet further, let's WG last call and get done.
> > >
> > >
> > >
> > > You can probably guess which option I prefer!!
> > >
> > >
> > >
> > > Thanks
> > >
> > > phil
> > >
> > >
> > >
> > > -         
> > >
> > > -          available. But I don't think this is a discussion worth having's performance compares with the performance of
> >
> >
> 


Best regards,
Daisuke