Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi,

 

Now I have read the Session keeping policy part. I think it covers the basic
case. What from my perspective might be missing is a bit more discussion of
the intermittent reachable node and how to deal with that. But, maybe that
is going into way to much detail. 

 

I would appreciate if someone in the WG would also provide their view on the
next text in version -21. 

 

Cheers

 

Magnus Westerlund

 

From: iesg <[e-mail]> On Behalf Of Magnus Westerlund
Sent: den 23 juni 2020 10:45
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18:
(with DISCUSS and COMMENT)

 

Hi,

 

Sorry for the delay in responding to the new version. I think the new
version resolves everything except the Session keeping policies discussion
below. Sorry for not making it clear that I think such a section would be
good. I see the goal is to provide guidance to BP agent implementors using
this CL.

 

Cheers

 

Magnus Westerlund

 

> > > > > Sec 5.1.1:

> > > 

> 

> Some discussion of the above issue appears motivated to determine if there
> should be some more discussion of what reestablishment behavior TCPCL
should
> have and provide guidance to the higher layer that uses the TCPCL.

> 

BS: You are correct that each CL has it's own notion of connectivity and
session state. Your interpretation of the idle session termination also
looks correct.

Unfortunately, I have less perspective of how the BP Agent implementations
to-date may require or expect CL interfaces to behave at an API level. My
expectation of TCPCL use falls into two extreme use cases, which agree with
your understanding:

1) A permanent physical link with reliable flows between nodes, which is
expected to have steady load of transfers occupying the link. In this case
the TCPCL would establish a session and keep it up as long as possible. The
goal here is total throughput and not wasting any link throughput on TCP
handshaking, TLS establishment, etc.

2) An ephemeral link between nodes which may not even have reliable
long-term connectivity. In this case the TCPCL only attempts a session when
both connectivity is expected and when a bundle transfer is queued (to send)
or some polling interval is reached (to receive).

 

These types of session keeping explanations could be added to the spec,
similar to the existing "Transfer Segmentation Policies" examples. Maybe a
section "Session Keeping Policies"?

[MW]

 

Yes, I think that would resolve my perspective on this issue and allow us to
continue. 

 

 

>  

> 

 

 

> On Section 6.1:

>    A session termination MAY occur immediately after transmission of a

>    Contact Header (and prior to any further message transmit).  This

>    can, for example, be used to notify that the entity is currently not

>    able or willing to communicate.  However, an entity MUST always send

>    the Contact Header to its peer before sending a SESS_TERM message.

> 

> I do see Mirja's issue. The text is a bit contradictory and unclear on
which
> session is referenced. So if the passive part receives a CONTACT header
and
> then sends a SESS_TERM I interpret this as you consider a TCPCL session is
> crated through only Contact exchange. Secondly, as Mirja states it is
> allowable to terminate the TCP session per Section 4.1 prior to this.

> 

>  

> 

> If the passive entity does not receive a Contact Header

> 

>    after some implementation-defined time duration after TCP connection

> 

>    is established, the entity SHALL close the TCP connection. 

> 

>  

> 

> Thus, maybe a clarification that context of the normative text statement
is in
> relation to the TCPCL session. And note that TCP connection termination
may
> occur prior to the CONTACT exchange.

> 

>  

> 

> Maybe:

> 

>  

> 

>  A TCPCL session termination MAY occur immediately after transmission of a

> 

> ^^^^^

> 

>    Contact Header (and prior to any further message transmit).  This

> 

>    can, for example, be used to notify that the entity is currently not

> 

>    able or willing to communicate.  However, an entity MUST always send

> 

>    the Contact Header to its peer before sending a SESS_TERM message.

> 

> Termination of the TCP connection can occur prior to receiving the Contact

> 

> header as discussed in Section 4.1.

> 

>  

> 

> Feedback on this?

> 

>  

BS: The key distinction here is between a "TCP connection being closed" vs.
a "TCPCL session being terminated". TCPCL messaging isn't possible until
after contact header exchange and contact negotiation "[PCH]" in Section
3.3, and TCPCL session isn't actually established until SESS_INIT exchange
and parameter negotiation "[PSI]", so until that occurs there is not
actually a TCPCL session to terminate.

I used your suggested text to update the text in Section 6.1 to refer back
to Section 4.1.

 

 

[MW] The text changes -21 lloks fine to me and this issue is resovled.