Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

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

Hi

Comments inline

/Ingemar

> -----Original Message-----
> From: Bob Briscoe [mailto:[e-mail]]
> Sent: den 10 december 2012 22:52
> To: Ingemar Johansson S
> Cc: [e-mail]; Ingemar Johansson S
> Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt
> 
> Ingemar,
> 
> You're right. Good point. Certainly true for downstream cases out of the
> cellular network, where long-running flows are not uncommon.
[IJ] Also, novel features like HTTP 2.0 and SPDY may make persistent TCP connections more common.

> 
> When I wrote that, I wasn't thinking of mobility, I was thinking of much less
> frequent re-routing after failures, so I wasn't trying to make it seamless.
> 
> For explicit hand-overs as in the case you describe, there's explicit hand-over
> of operational state, so it wouldn't be impossible to hand-over credit too. Am
> I right, at least in an arm-wavy sense?
[IJ] Yes, one option is to transfer the credit via the X2 interface, needs standardization of course (not in IETF though)

> 
> We should make it clear that the only state that re-creates itself is the flow-
> ID state, not the credit associated with it. I wrote that sentence (not Matt),
> and my motivation was to explain that a switch to a different audit wouldn't
> be catastrophic for the flow. I wasn't trying to claim that it would hand-over
> without a glitch. The audit would drop some packets, so the flow would send
> some Re-Echo-Loss, which would establish some credit and the flow could
> continue.
[IJ] Hmm, perhaps I did not get that part, what you say is that if the audit drops a packet, that will count as a credit ?.  This credit thing is is still a mystery so I probably need to get this explained better...

> 
> 
> Bob
> 
> Sorry for delay replying.
> 
> At 13:27 21/11/2012, Ingemar Johansson S wrote:
> >Hi
> >
> >First time I had time to read carefully through this document The
> >document is comprehensible and I don't find any serious issues with it.
> >
> >One comment though on page 5, 3rd para.
> >" the flow-state required for audit creates itself as it detects new
> >flows.  Therefore a flow will not fail if it is re-
> >    routed away from the audit box currently holding its flow-state. "
> >
> >If I map ConEx to a 3GPP LTE use case, the audit functions are best
> >placed in the eNodeB. When a new (long lived) flow is created it is
> >preferably preloaded with credit marks which are stored in the auditor
> >in the eNodeB which the terminal is "connected" to. When the terminal
> >hands over to another eNodeB the credit marks will be lost.  This means
> >that the ConEx markings will in this case be at least one RTT behind
> >with a higher risk of false positives in the auditor in the new eNodeB
> >To avoid this the credit marks would need to be forwarded to the new
> >eNodeB via e.g the X2 interface.
> >
> >So my question is, is it needed to add a statement that mentions this ?
> >
> >/Ingemar
> >
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On Behalf
> >Of marcelo bagnulo braun
> >Sent: 23 October 2012 06:54
> >To: 'ConEx IETF list'
> >Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt
> >
> >Hi,
> >
> >This note issues the WGLC for
> >
> >draft-ietf-conex-abstract-mech-06.txt
> >
> >Please reivew the document and provide comments. The WGLC will close
> on
> >the 20th of november.
> >
> >For you convenience, the draft can be found at:
> >
> >https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech
> >
> >Regards, marcelo
> >
> >_______________________________________________
> >conex mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/conex
> >
> >_______________________________________________
> >conex mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/conex
> 
> __________________________________________________________
> ______
> Bob Briscoe,                                BT Innovate & Design