Subject: Re: [Last-Call] Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 29 Jan 2020 21:58:56 +0000

Hi all,

see below inline [MS].

Michael

Von: Gunnar Hellström<mailto:[email-masked]>
Gesendet: Mittwoch, 29. Januar 2020 17:30
An: Christer Holmberg<mailto:[email-masked]>; Scharf, Michael<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11

Hi,

I will try to add to the answers,
Den 2020-01-29 kl. 07:05, skrev Christer Holmberg:

Hi Michael,

Thank you for review! Please see inline.

---

    > 1/ I wonder why Section 4.2.1 does not include any normative statements on how

    > to handle the maximum character transmission rate ('cps' attribute). RFC 4103

    > states that "In receipt of this parameter, devices MUST adhere to the request

    > by transmitting characters at a rate at or below the specified <integer>

    > value." Isn't a similar statement needed in this document?

The assumption has been that the associated procedures in 4103 apply.
Note that section 6 in RFC 4103 continues:
"

Note that this parameter was not defined in RFC 2793<https://tools.ietf.org/html/rfc2793> [16<https://tools.ietf.org/html/rfc4103#ref-16>].

   Therefore implementations of the text/t140 format may be in use that

   do not recognize and act according to this parameter.  Therefore,

   receivers of text/t140 MUST be designed so they can handle temporary

   reception of characters at a higher rate than this parameter

   specifies.  As a result malfunction due to buffer overflow is avoided

   for text conversation with human input.

"

This note may be historic now, but for the T140-usage draft we may have the similar case when an implementation has not succeeded to implement support for the CPS parameter, or for dcsa at all.

[MS] I have also read that paragraph, but to me it sounded as a historic transition problem. Also, as far as I read this text in 4103, the MUST is only about the design of the implementation, not about its actual operation. For instance, receiption at a higher rate could be an optional feature turned off by default may not violate that MUST.

We had specific wording for that case earlier, but I think we deleted most of it.

Do you think we should insert a similar precaution in the t140-usage draft, but referring to other reasons than RFC 2793 interop?

[MS] I don’t understand why the draft specifies a parameter if implementations shall just ignore the value. I guess the actual use of this parameter could be better specified in the document.

But, I can for sure make it explicit, e.g., by adding the sentence from 4103 to the end of the 1st paragraph.

---

    > 2/ Also, it is not really clear from the document what would happen if a peer

    > exceeds this maximum character transmission rate (or the rate allowed by

    > congestion/flow control). What happens if the sender types faster than the

    > 'cps' attribute (say, an automated chat bot)? I guess characters would be

    > dropped at the sender? In that case, no missing text markers would be displayed

    > in the receiver, right?

I assume it could result in a buffer overflow sooner or later, but I think it is a local implementation issue how it is dealt with by the sender application.

Perhaps Gunnar knows more about how implementations handle this?

What the CPS parameter tries to prevent is buffer overflow in slow ancient receiving devices.

Modern implementations will likely have buffer space enough for storing quite a large volume of text for eventual transmission to the limited device. It is instead another risk that appears. If you have a receiving device only able to present 4 characters per second which is the reality if you have interop with the old TTYs through a gateway, then a modern device user happening to paste a large piece of text or use speech to text technology will generate text in buffers that will take a very long time to present at the receiving device. The sense of a real-time conversation will be lost. (1000 characters will take 4 minutes to present!)

The users need to realize that this technology is intended for human conversation. It is wise if implementations have the possibility for pasting in short texts, but it should not be used for document transfer.

[MS] The document could better describe this, IMHO. As the data channel is different and has other capabilities, it is not clear to me that all limitations explained in RFC 4103 apply here as well.

So, yes, it is a local implementation issue.

[MS] From a transport protocol design perspective, the „cps“ parameter may realize some sort of (simple) flow control. And in that case sender and receiver typically have to agree on the semantics. And your example actually describes a typical flow control problem: If a 4 cps receiver receives 1000 characters, it may actually be interested in slowing down the sender. Could it do so, for instance, by sending cps=0? As far as I understand the I-D, this would be allowed. How to deal with that case is not a local implementation issue only. Well, we are here probably discussing corner cases of corner cases. But as far as I can see, the document does not comprehensively describe the use of the cps attribute.

---

    > 3/ Section 5.3. "Data Buffering" includes the following statement: "As

    > described in [T140], buffering can be used to reduce overhead, with the maximum

    > buffering time being 500 ms.  It can also be used for staying within the

    > maximum character transmission rate (Section 4.2), if such has been provided by

    > the peer." I don't understand the second sentence. At first sight, enforcing

    > the 'cps' attribute does not only require a buffer, but also some sort of rate

    > shaper/policer (e.g., token bucket or the like). Do I miss something?

The 2nd sentence talks about the case when the user input rate is faster than the maximum transmission rate (see question #2).
Yes, so in the second case, the transmission procedure will detect that not all buffered characters are allowed to be transmitted, when the transmission interval (normally 300 ms) has passed. So they will be kept in a buffer at the sending side. Is that unclear so we need to clarify it?

[MS] I had to partly reverse-engineer the handling of the buffer from RFC 4103, albeit it is not exactly clear if all considerations therein also apply to this specification. For instance, I believe that your additional explanation could be added to the document to better clarify the intention. And just to illusttrate that there could be more ambiguity: To me, Section 5.3 could also imply that characters queued in the sender are dropped from the buffer if they cannot be transmitted within 500ms. That is a relatively small threshold for links with RTT of 200ms or more (e.g., satellite or slow GPRS links), e.g. if retransmissions are needed due to packet loss or congestion/flow control kicks in. Unlike RFC 4103, transport is now reliable and this could have some side effects even if the data rates in text conversations are very small. Out of my head, I would assume that a buffer threshold of 500ms will probably work very well in most parts of the Internet. But there are some areas with bad connectivity, high packet loss rates, etc. I am not sure of the proposed parameters really work well in such corner cases. Typically, such Questions would be answered by measurement data from running code.

---

    > 4/ Also in Section 5.3 is written: "An implementation needs to take the user

    > requirements for smooth flow and low latency in real-time text conversation

    > into consideration when assigning a buffer time.  It is RECOMMENDED to use the

    > default transmission interval of 300 milliseconds [RFC4103], or lower, for

    > T.140 data channels". What is meant here by "or lower"? Does the document want

    > to recommend values much smaller than 300 ms, say, 1 ms? As explained in RFC

    > 4103, this could increase the overhead and bitrate, right? The absolute rate

    > values are relatively small for large parts of today's Internet, but couldn't

    > this text conversation be particularly useful in scenarios with very small

    > capacity of links (i.e., kbps range)?

I suggest to remove the "or lower" part, since the recommendation is to use 300.

Modern applications, especially speech-to-text are better at lower delays. So, having a 300 ms delay may be on the high side. Transmission intervals down to 100 ms will be experienced as an improvement for some applications. The load in both bandwidth and packets per second  is still low compared to what audio and video (often used in the same sessions) cause.

[MS] Indeed, bandwidth and packet rate will be small compared to other traffic. Nonetheless, this I-D somewhat specifies a service with real-time requirement that runs over a reliable transport channel, which could e.g. traverse highly congested links. Just assuming „the transport will just always work“ is a bit dangerous, IMHO.

It is a RECOMMENDATION,  so, yes, "or lower" could be deleted, but I prefer to leave it.

[MS] Maybe the document could write something like „It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103] for T.140 data channels. Implementers MAY also use lower values". However, note that RFC 4103 backs the parameter of 300ms by estimating the overhead. If this document allows smaller values, it may have to similarly reason about the impact.

---

    > 5/ Section 5.4 mandates: "Retransmission of already successfully transmitted

    > T140blocks MUST be avoided, and missing text markers [T140ad1] SHOULD be

    > inserted in the received data stream where loss is detected or suspected." I

    > believe a better wording for the MUST would be "... sucessfully received

    > T140blocks ...", albeit the document does not detail how an implementation can

    > indeed fulfill this MUST. Regarding the SHOULD, I assume that "loss suspected"

    > could be deterrmined by a heuristic. Could such a heuristic fail and result in

    > spurious missing text markers? If so, would a SHOULD be reasonable for that?

Regarding the MUST, T.140 does not provide acknowledgement that T140blocks have been received. It uses a reliable data channel, so as long as the data channel is up and running the sender can only assume that the blocks will be successfully transmitted.

Perhaps Gunnar knows more about how receiving implementations would "suspect" loss?

The requirement from the T.140 presentation level is that the channel shall deliver in order and without duplication. Possible loss should be indicated. For RFC 4103, there is a slight risk that packets are lost, and if more are lost than can be recovered by the redundancy, then a suspected loss has appeared and should be indicated in the text presentation. There is a chance that something invisible in the text stream was lost. We cannot know.

For the t140-usage case, the situation is different. We have reliable delivery in order as long as not more than about 7 retries are made and nothing is blocking transmission so that the watchdog breaks the SCTP associations. But that can happen and the draft says that reestablishment shall be tried. At that moment it may be hard to know from the sender side what was successfully transmitted, because we do not have any application level checking delivery. What must be avoided is to retransmit something that might have been received. It is better to let something be lost and insert an indication that something might have been lost.

[MS] I am not really familiar with internals of the SCTP stack. But to me there is ambiguity in the term „already sucessfully transmitted T140blocks“. What does that mean? That the T140block has been copied into the SCTP send buffer? Or that an IP packet containing this data has been transmitted to the peer? I think the former may not immediately imply the latter, what has exactly happened my be difficult to know. Maybe it would be safer to avoid the word „successfully transmitted“. For instance, „Retransmission of already sent T140blocks MUST be avoided“ may work around some of the terminology issues.

That is what the text tries to say.  It might be a good habit to always insert an indicator for suspected loss by the receiver, when the SCTP associations are refreshed. I think the current wording allows that and smarter solutions if possible. It is good to not require the transmitter to insert the loss marker, because that might make it harder to apply security to the transmission chain.

[MS] I was wondering if it is possible that the transmitter erroneously inserts a loss marker even if _no_ data was lost, because the receiver wrongly „suspected“ loss. As far as I understand, the ITU-T T.140 Addendum specifies the loss marker for „discovered data loss“. So, it is not clear to me if using this for _suspected_ loss would be consistent with the ITU-T T.140 Addendum (which I had to read to actually understand this I-D).

[MS] Anyway, I agree that the current specification allows „smarter“ solutions simply by omitting details on (well, granted) corner cases. The question is whether the current spec is precise enough to ensure interoperability between implementations and to fully describe the characteristics to potential users. I don’t understand this use case well enough and therefore I defer that question to the TSV ADs.

Best regards

Michael

Regards,

Christer

Regards

Gunnar

--

+ + + + + + + + + + + + + +

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2020 09:51:59 +0000

Hi,

See inline [CH].

 ---------
 
    > 1/ I wonder why Section 4.2.1 does not include any normative statements on how
    > to handle the maximum character transmission rate ('cps' attribute). RFC 4103
    > states that "In receipt of this parameter, devices MUST adhere to the request
    > by transmitting characters at a rate at or below the specified <integer>
    > value." Isn't a similar statement needed in this document?

    "  Note that this parameter was not defined in https://tools.ietf.org/html/rfc2793 [https://tools.ietf.org/html/rfc4103#ref-16].
       Therefore implementations of the text/t140 format may be in use that
       do not recognize and act according to this parameter.  Therefore,
       receivers of text/t140 MUST be designed so they can handle temporary
       reception of characters at a higher rate than this parameter
       specifies.  As a result malfunction due to buffer overflow is avoided
       for text conversation with human input. "
 
This note may be historic now, but for the T140-usage draft we may have the similar case when an implementation has not succeeded
to implement support for the CPS parameter, or for dcsa at all.

[MS] I have also read that paragraph, but to me it sounded as a historic transition problem. Also, as far as I read this text in 4103, the
MUST is only about the design of the implementation, not about its actual operation. For instance, reception at a higher rate could
be an optional feature turned off by default may not violate that MUST.

[MS] I don’t understand why the draft specifies a parameter if implementations shall just ignore the value. I guess the actual
use of this parameter could be better specified in the document.
 
[CH] I don't think we are saying that one shall ignore the value. We are simply realizing the fact that there may be legacy implementations that don't support the value.
In any case, I don't think this is a real-life problem - in cases where T.140 is used as intended. As Gunner mentioned, T.140 is not designed or intended for transport of large amount of copy-pasted text but for human interactions.
 
-----
 
    > 2/ Also, it is not really clear from the document what would happen if a peer
    > exceeds this maximum character transmission rate (or the rate allowed by
    > congestion/flow control). What happens if the sender types faster than the
    > 'cps' attribute (say, an automated chat bot)? I guess characters would be
    > dropped at the sender? In that case, no missing text markers would be displayed
    > in the receiver, right?

 
[CH] If the receiver cannot handle the received characters, in my opinion it is better if it uses the direction attributes (4.2.3) to indicate that it is not willing to receive text. I guess we could add some text about that. Something like:

      "If the receiver receives text at a higher rate than it can handle, e.g., because the sender does not support the cps parameter, the receiver
        can indicate to the sender that it is not willing to receive more text using the direction attributes [ref-to-section-4.2.3]"
 
---
    
    > 3/ Section 5.3. "Data Buffering" includes the following statement: "As
    > described in [T140], buffering can be used to reduce overhead, with the maximum
    > buffering time being 500 ms.  It can also be used for staying within the
    > maximum character transmission rate (Section 4.2), if such has been provided by
    > the peer." I don't understand the second sentence. At first sight, enforcing
    > the 'cps' attribute does not only require a buffer, but also some sort of rate
    > shaper/policer (e.g., token bucket or the like). Do I miss something?

[MS] I had to partly reverse-engineer the handling of the buffer from RFC 4103, albeit it is not exactly clear if all considerations therein also apply to this specification. For instance, I believe that your additional explanation could be added to the document to better clarify the intention. And just to illustrate that there could be more ambiguity: To me, Section 5.3 could also imply that characters queued in the sender are dropped from the buffer if they cannot be transmitted within 500ms. That is a relatively small threshold for links with RTT of 200ms or more (e.g., satellite or slow GPRS links), e.g. if retransmissions are needed due to packet loss or congestion/flow control kicks in. Unlike RFC 4103, transport is now reliable and this could have some side effects even if the data rates in text conversations are very small. Out of my head, I would assume that a buffer threshold of 500ms will probably work very well in most parts of the Internet. But there are some areas with bad connectivity, high packet loss rates, etc. I am not sure of the proposed parameters really work well in such corner cases. Typically, such Questions would be answered by measurement data from running code.
 
[CH] I don't know whether it is within the scope of this document to normatively define that characters shall be dropped if they cannot be transmitted within 500ms. In my opinion that is part of the generic T.140 procedures, not specific to data channels. But, perhaps we could say something like:

       "If a character cannot be transmitted within 500ms, and the sender chooses to drop the character from
         the buffer. If that happens, the sender SHOULD inform the user about it."

---
    
    > 4/ Also in Section 5.3 is written: "An implementation needs to take the user
    > requirements for smooth flow and low latency in real-time text conversation
    > into consideration when assigning a buffer time.  It is RECOMMENDED to use the
    > default transmission interval of 300 milliseconds [RFC4103], or lower, for
    > T.140 data channels". What is meant here by "or lower"? Does the document want
    > to recommend values much smaller than 300 ms, say, 1 ms? As explained in RFC
    > 4103, this could increase the overhead and bitrate, right? The absolute rate
    > values are relatively small for large parts of today's Internet, but couldn't
    > this text conversation be particularly useful in scenarios with very small
    > capacity of links (i.e., kbps range)?

 [CH] I guess it depends on whether the recommendation is to specifically use 300ms, or whether the recommendation is to use 300 or lower. RFC 4103 talks about specifically using 300ms, so I think we should follow that for T.140 data channels. So, I am fine with the text you suggest.

---
 
    > 5/ Section 5.4 mandates: "Retransmission of already successfully transmitted
    > T140blocks MUST be avoided, and missing text markers [T140ad1] SHOULD be
    > inserted in the received data stream where loss is detected or suspected." I
    > believe a better wording for the MUST would be "... sucessfully received
    > T140blocks ...", albeit the document does not detail how an implementation can
    > indeed fulfill this MUST. Regarding the SHOULD, I assume that "loss suspected"
    > could be deterrmined by a heuristic. Could such a heuristic fail and result in
    > spurious missing text markers? If so, would a SHOULD be reasonable for that?

The requirement from the T.140 presentation level is that the channel shall deliver in order and without duplication.
Possible loss should be indicated. For RFC 4103, there is a slight risk that packets are lost, and if more are lost than 
can be recovered by the redundancy, then a suspected loss has appeared and should be indicated in the text presentation.
There is a chance that something invisible in the text stream was lost. We cannot know.

For the t140-usage case, the situation is different. We have reliable delivery in order as long as not more than
about 7 retries are made and nothing is blocking transmission so that the watchdog breaks the SCTP associations.
But that can happen and the draft says that reestablishment shall be tried. At that moment it may be hard to know from
the sender side what was successfully transmitted, because we do not have any application level checking delivery. What
must be avoided is to retransmit something that might have been received. It is better to let something be lost and insert
an indication that something might have been lost.

[MS] I am not really familiar with internals of the SCTP stack. But to me there is ambiguity in the term „already successfully transmitted
T140blocks“. What does that mean? That the T140block has been copied into the SCTP send buffer? Or that an IP packet containing this
data has been transmitted to the peer? I think the former may not immediately imply the latter, what has exactly happened may be difficult
to know. Maybe it would be safer to avoid the word „successfully transmitted“. For instance, „Retransmission of already sent T140blocks
MUST be avoided“ may work around some of the terminology issues.

[CH] Perhaps we could remove "already successfully transmitted T140blocks", since there currently is no way to verify that. Maybe something like:

OLD:

   "In case of network failure or congestion, T.140 data channels might
   fail and get torn down.  If this happens but the session sustains, it
   is RECOMMENDED that implementations tries to reestablish the T.140
   data channels.  If reestablishment of the T.140 data channel is
   successful, an implementation MUST evaluate if any T140blocks were
   lost.  Retransmission of already successfully transmitted T140blocks
   MUST be avoided, and missing text markers [T140ad1] SHOULD be
   inserted in the received data stream where loss is detected or
   suspected."

NEW:

   "In case of network failure or congestion, T.140 data channels might
   fail and get torn down.  If this happens but the session sustains, it
   is RECOMMENDED that implementations tries to reestablish the T.140
   data channels. As a T.140 data channel does not provide a mechanism
   for the receiver to identify retransmitted T140blocks, the sender MUST
   NOT retransmit T140blocks unless it has strong reasons to suspect that
   a T140block has been lost. Similarly, as a T.140
   data channel does not provide a mechanism for a receiver to detect
   lost T140blocks, it MUST NOT insert missing text markers [T140ad1]
   unless it has strong reasons to suspect that a T140block has been lost.
   Different mechanisms used by senders and receivers to suspect packet loss
   Is outside the scope of this specification."

Regards,
 
Christer

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 30 Jan 2020 13:26:41 +0000

Hi again,

>     "  Note that this parameter was not defined in
> https://tools.ietf.org/html/rfc2793 [https://tools.ietf.org/html/rfc4103#ref-16].
> This note may be historic now, but for the T140-usage draft we may have the
> similar case when an implementation has not succeeded
> [MS] I have also read that paragraph, but to me it sounded as a historic
> transition problem. Also, as far as I read this text in 4103, the
> MUST is only about the design of the implementation, not about its actual
> operation. For instance, reception at a higher rate could
> Do you think we should insert a similar precaution in the t140-usage draft, but
> referring to other reasons than RFC 2793 interop?
> 
> [MS] I don’t understand why the draft specifies a parameter if implementations
> shall just ignore the value. I guess the actual
> [CH] I don't think we are saying that one shall ignore the value. We are simply
> realizing the fact that there may be legacy implementations that don't support
> the value.

I don't understand that rationale. The WebRTC channel apparently requires a new implementation on both endpoints, i.e., there should be no legacy devices that don't support the value in that case. So, if a receiver following this spec decides to announce a cps value, I don't understand why any WebRTC sender should be allowed to send faster. If that was allowed, I would not understand why the parameter is even defined. And it is not clear to me for what the parameter would then actually be used.

Also, if a non-WebRTC legacy device connected via a gateway ignores the value, then this is probably something to that requires attention in the gateway (e.g., by dropping text there).

> In any case, I don't think this is a real-life problem - in cases where T.140 is
> used as intended. As Gunner mentioned, T.140 is not designed or intended for
> transport of large amount of copy-pasted text but for human interactions.

Then probably a big warning sign should be added to the document.
 
> I assume it could result in a buffer overflow sooner or later, but I think it is a
> local implementation issue how it is dealt with by the sender application.
> 
> Modern implementations will likely have buffer space enough for storing quite
> a large volume of text for eventual transmission to the limited device. It is
> instead another risk that appears. If you have a receiving device only able to
> present 4 characters per second which is the reality if you have interop with the
> old TTYs through a gateway, then a modern device user happening to paste a
> large piece of text or use speech to text technology will generate text in buffers
> that will take a very long time to present at the receiving device. The sense of a
> real-time conversation will be lost. (1000 characters will take 4 minutes to
> present!)
> The users need to realize that this technology is intended for human
> conversation. It is wise if implementations have the possibility for pasting in
> short texts, but it should not be used for document transfer.
> 
> [MS] The document could better describe this, IMHO. As the data channel is
> different and has other capabilities, it is not clear to me that all limitations
> explained in RFC 4103 apply here as well.
> [MS] From a transport protocol design perspective, the „cps“ parameter may
> realize some sort of (simple) flow control. And in that case sender and receiver
> typically have to agree on the semantics. And your example actually describes
> a typical flow control problem: If a 4 cps receiver receives 1000 characters, it
> may actually be interested in slowing down the sender. Could it do so, for
> instance, by sending cps=0? As far as I understand the I-D, this would be
> allowed. How to deal with that case is not a local implementation issue only.
> Well, we are here probably discussing corner cases of corner cases. But as far
> as I can see, the document does not comprehensively describe the use of the
> cps attribute.
> 
> [CH] If the receiver cannot handle the received characters, in my opinion it is
> better if it uses the direction attributes (4.2.3) to indicate that it is not willing to
> receive text. I guess we could add some text about that. Something like:
> 
>       "If the receiver receives text at a higher rate than it can handle, e.g.,
> because the sender does not support the cps parameter, the receiver
>         can indicate to the sender that it is not willing to receive more text using
> the direction attributes [ref-to-section-4.2.3]"

With that being allowed, it becomes even less apparent to me why the cps parameter is needed at all.

Also, SCTP has flow control, which should also be able to slow down a sender, or even stop it in case of a slow receiver. From the document is not really clear to me if the T.140-specific rate mechanisms (cps) and buffer timeouts (300/500ms) interact with underlying send and receive buffers for the data channel, and if so, how.

I am not really familiar with WebRTC internals, but running some sort of rate-controlled traffic with soft real-time delay requirements over a reliable transport channel is typically not trivial. In this specific use case, the data rate is expected to be so small that it should usually work well. But, nonetheless, there could be corner cases in particular in challenging network environments and the document is silent about them.

> The 2nd sentence talks about the case when the user input rate is faster than
> the maximum transmission rate (see question #2).
> 
> Yes, so in the second case, the transmission procedure will detect that not all
> buffered characters are allowed to be transmitted, when the transmission
> interval (normally 300 ms) has passed. So they will be kept in a buffer at the
> sending side. Is that unclear so we need to clarify it?
> 
> [MS] I had to partly reverse-engineer the handling of the buffer from RFC 4103,
> albeit it is not exactly clear if all considerations therein also apply to this
> specification. For instance, I believe that your additional explanation could be
> added to the document to better clarify the intention. And just to illustrate that
> there could be more ambiguity: To me, Section 5.3 could also imply that
> characters queued in the sender are dropped from the buffer if they cannot be
> transmitted within 500ms. That is a relatively small threshold for links with RTT
> of 200ms or more (e.g., satellite or slow GPRS links), e.g. if retransmissions are
> needed due to packet loss or congestion/flow control kicks in. Unlike RFC 4103,
> transport is now reliable and this could have some side effects even if the data
> rates in text conversations are very small. Out of my head, I would assume that
> a buffer threshold of 500ms will probably work very well in most parts of the
> Internet. But there are some areas with bad connectivity, high packet loss
> rates, etc. I am not sure of the proposed parameters really work well in such
> corner cases. Typically, such Questions would be answered by measurement
> data from running code.
> 
> [CH] I don't know whether it is within the scope of this document to normatively
> define that characters shall be dropped if they cannot be transmitted within
> 500ms. In my opinion that is part of the generic T.140 procedures, not specific
> to data channels. But, perhaps we could say something like:
> 

That makes sense to me.

> Modern applications, especially speech-to-text are better at lower delays. So,
> having a 300 ms delay may be on the high side. Transmission intervals down to
> 100 ms will be experienced as an improvement for some applications. The load
> in both bandwidth and packets per second  is still low compared to what audio
> and video (often used in the same sessions) cause.
> 
> [MS] Indeed, bandwidth and packet rate will be small compared to other
> traffic. Nonetheless, this I-D somewhat specifies a service with real-time
> requirement that runs over a reliable transport channel, which could e.g.
> traverse highly congested links. Just assuming „the transport will just always
> work“ is a bit dangerous, IMHO.
> [MS] Maybe the document could write something like „It is RECOMMENDED to
> use the default transmission interval of 300 milliseconds [RFC4103] for T.140
> data channels. Implementers MAY also use lower values". However, note that
> RFC 4103 backs the parameter of 300ms by estimating the overhead. If this
> document allows smaller values, it may have to similarly reason about the
> impact.
> 
>  [CH] I guess it depends on whether the recommendation is to specifically use
> 300ms, or whether the recommendation is to use 300 or lower. RFC 4103 talks
> about specifically using 300ms, so I think we should follow that for T.140 data
> channels. So, I am fine with the text you suggest.

OK, then we may have sorted this out

> Regarding the MUST, T.140 does not provide acknowledgement that
> T140blocks have been received. It uses a reliable data channel, so as long as
> the data channel is up and running the sender can only assume that the blocks
> will be successfully transmitted.
> 
> The requirement from the T.140 presentation level is that the channel shall
> deliver in order and without duplication.
> Possible loss should be indicated. For RFC 4103, there is a slight risk that
> packets are lost, and if more are lost than
> can be recovered by the redundancy, then a suspected loss has appeared and
> should be indicated in the text presentation.
> the sender side what was successfully transmitted, because we do not have any
> application level checking delivery. What
> must be avoided is to retransmit something that might have been received. It is
> better to let something be lost and insert
> [MS] I am not really familiar with internals of the SCTP stack. But to me there is
> ambiguity in the term „already successfully transmitted
> T140blocks“. What does that mean? That the T140block has been copied into
> the SCTP send buffer? Or that an IP packet containing this
> data has been transmitted to the peer? I think the former may not immediately
> imply the latter, what has exactly happened may be difficult
> to know. Maybe it would be safer to avoid the word „successfully transmitted“.
> For instance, „Retransmission of already sent T140blocks
> That is what the text tries to say.  It might be a good habit to always insert an
> indicator for suspected loss by the receiver, when the SCTP associations are
> refreshed. I think the current wording allows that and smarter solutions if
> possible. It is good to not require the transmitter to insert the loss marker,
> because that might make it harder to apply security to the transmission chain.
> 
> [MS] I was wondering if it is possible that the transmitter erroneously inserts a
> loss marker even if _no_ data was lost, because the receiver wrongly
> „suspected“ loss. As far as I understand, the ITU-T T.140 Addendum specifies
> the loss marker for „discovered data loss“. So, it is not clear to me if using this
> for _suspected_ loss would be consistent with the ITU-T T.140 Addendum
> (which I had to read to actually understand this I-D).
> 
> [MS] Anyway, I agree that the current specification allows „smarter“ solutions
> simply by omitting details on (well, granted) corner cases. The question is
> whether the current spec is precise enough to ensure interoperability between
> implementations and to fully describe the characteristics to potential users. I
> don’t understand this use case well enough and therefore I defer that question
> to the TSV ADs.
> 
> [CH] Perhaps we could remove "already successfully transmitted T140blocks",
> since there currently is no way to verify that. Maybe something like:
> 
> OLD:
> 

That looks better to me.

Thanks

Michael

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2020 13:57:58 +0000

Hi,
    
----

    > I don't understand that rationale. The WebRTC channel apparently requires a new implementation on both
    > endpoints, i.e., there should be no legacy devices that don't support the value in that case. So, if a receiver following
    > this spec decides to announce a cps value, I don't understand why any WebRTC sender should be allowed to send
    > faster. If that was allowed, I would not understand why the parameter is even defined. And it is not clear to me for
    > what the parameter would then actually be used.
    
You can implement T.140 data channels with current WebRTC stacks. They do support data channels.

    > Also, if a non-WebRTC legacy device connected via a gateway ignores the value, then this is probably something to that requires attention in the gateway (e.g., by dropping text there).

We should not drop the parameter just because there might be legacy endpoint that doesn't support it. Sure, implementations need to be aware that such implementations exist, but eventually the legacy devices will hopefully be replaced or updated.
    
    > Then probably a big warning sign should be added to the document.

We do reference T.140, and I assume the scope and usage are described there. RFC 4103 does not have such statement either.

But, sure, if people think it is useful we can add a note saying that T.140 is intended for real-time interaction, not for transfer of text files, documents etc.
 
    -----
     
    > With that being allowed, it becomes even less apparent to me why the cps parameter is needed at all.

It is used in order to help to prevent buffer overflow and sending of I-do-not-want-more-text requests to be sent.

I really don't understand what the problem is by having a way to indicate the maximum rate. Having legacy equipment that do not support certain protocol elements is nothing new in IETF, and not specific to data channels, but that hasn't prevented us from adding new features etc when we specify new versions of protocols etc.

   > Also, SCTP has flow control, which should also be able to slow down a sender, or even stop it in case of a slow receiver. From the document is not 
   > really clear to me if the T.140-specific rate mechanisms (cps) and buffer timeouts (300/500ms) interact with underlying send and receive buffers for the data channel, and if so, how.

No matter what data channel usage you have, whatever you send and at whatever rate, the underlying transport mechanism (SCTP) obviously need to support it.
    
   >  I am not really familiar with WebRTC internals, but running some sort of rate-controlled traffic with soft real-time delay requirements over a reliable
   >  transport channel is typically not trivial. In this specific use case, the data rate is expected to be so small that it should usually work well. But, nonetheless, 
   > there could be corner cases in particular in challenging network environments and the document is silent about them.

The current version of the data channel specification does not contain load balance and rate control - applications need to make sure they don't try to send more than the data channel can handle.

However, I don't overloading the SCTP association is going to be a problem in the case of T.140. 

---
     
    >          the buffer. If that happens, the sender SHOULD inform the user about it."

Thanks! I will add it.

---
     
    > OK, then we may have sorted this out

Good :)

 ---
     
    >    Is outside the scope of this specification."

Good :)

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 30 Jan 2020 16:30:06 +0000

Hi,

I have a few comments marked [GH]

Den 2020-01-30 kl. 14:57, skrev Christer Holmberg:

Hi,

----

[GH] RFC 4103, has the following wording in its introduction:

The text is intended to be entered by human users from a keyboard,
   handwriting recognition, voice recognition or any other input method.
   The rate of character entry is usually at a level of a few characters
   per second or less.

I suggest that the first sentence is added to our introduction.

    -----

---

Thanks! I will add it.

[GH] No, I do not think that is a good implementation ever.

Let me start with another small correction to do in this area.

This sentenct in the first paragraph of 5.3 is not logical anymore and should be modified:

OLD

"It can also be used for staying within the maximum character transmission rate (Section 4.2), if such has been provided by the peer."

NEW

"It can also be used for staying within the maximum character transmission rate (Section 4.2.1)."

Because we changed in 4.2.1 so that there is now always a maximum transmission rate with the default being 30 cps.

Now, let us solve the wording about buffering.

5.3 starts with:

"As described in [T140], buffering can be used to reduce overhead, with the maximum buffering time being 500 ms."

This requirement comes from T.140. Research has shown that users of human typed text conversation can accept one second delay from typing to remote presentation. The maximum of 500 ms buffering time allows 500 ms for network transmission and remote presentation.

This is the maximum. There is a better user experience if the delay can be a bit shorter. Therefore RFC 4103 RECOMMENDS 300 ms buffering time between transmissions as a balance between delay and overhead. And we have copied that recommendation into next paragraph, with the added consideartion that some modern automatic applications benefit from shorter buffering time (down to 100 ms).

The expression "buffering time" would have been better expressed if it said "transmission interval".

The second use of the transmission buffer is for the case when we need to limit the flow because of the CPS parameter value. This is mentioned in the second sentence (corrcted above).

Even if some text cannot be transmitted within the 500 ms limit because we are on the way to exceed the CPS value, the text does not become worthless immediately. It should be stored in a buffer, and as much as can be transmitted because of the CPS value will be transmitted from that buffer at each transmission interval.

If a sending user happened to type extremely fast for a long time, or in some other way fill the transmission buffer so that it takes a very long time to send it, the receiving user will experience that they lost real-time conversational contact. I cannot see any better option than letting the receiving user have the usual option to hang up.

So, in order to sort out the text and explain the two different ways to use the transmission buffer I suggest the following wording for 5.3:

OLD 5.3:

"As described in [T140], buffering can be used to reduce overhead, with the maximum buffering time being 500 ms. It can also be used for staying within the maximum character transmission rate (Section 4.2), if such has been provided by the peer.

An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when assigning a buffer time. It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103], or lower, for T.140 data channels."

NEW:

"As described in [T140], buffering can be used to reduce overhead, with the maximum transmission interval as long as there is text to send being 500 ms. Buffering can also be used for staying within the maximum character transmission rate (Section 4.2.1).

An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when assigning a buffer time. It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103], for T.140 data channels. Implementers MAY also use lower values, for specific applications requiring low latency, taking the increased overhead in consideration."

Note that I added more wording about the lower transmission interval. I got the impression that that was desired as discussed below.

---

    > OK, then we may have sorted this out

[GH] See my proposal for  5.3 above

Good :)

 ---

Good :)

[GH] I suggest slight modifications

NEW2

   "In case of network failure or congestion, T.140 data channels might
    fail and get torn down.  If this happens but the session sustains, it
    is RECOMMENDED that implementations tries to reestablish the T.140
    data channels. As a T.140 data channel does not provide a mechanism
    for the receiver to identify retransmitted T140blocks after channel reestablishment, the sender MUST
    NOT retransmit T140blocks unless it has strong indications that
    a T140block has been lost. Similarly, as a T.140
    data channel does not provide a mechanism for a receiver to detect
    lost T140blocks during channel reestablishment, it SHOULD NOT insert missing text markers [T140ad1]
    unless it has reasons to suspect that a T140block might have been lost.
    Different mechanisms used by senders and receivers to detect or suspect packet loss
    are outside the scope of this specification."

Regarding the change for the receiving side, it is better to insert a loss mark too much than omitting one.
The text keep reminding the reader that it is only in the case of tear down and reestablishment that these situations appear.

Regards,

Christer

Regards

Gunnar

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Jan 2020 10:32:24 +0000

Hi,

I have removed much of the text, but I have kept the issue numbers for reference.

---

1/

...

>      "The text is intended to be entered by human users from a keyboard,
>        per second or less."

[CH] I suggest adding both sentences.  

 -----

2/

...

    >> I really don't understand what the problem is by having a way to indicate the maximum rate. Having legacy equipment
    >> that do not support certain protocol elements is nothing new in IETF, and not specific to data channels, but that hasn't
    >> prevented us from adding new features etc when we specify new versions of protocols etc.
    >>
    >>The current version of the data channel specification does not contain load balance and rate control - applications need to
    >> make sure they don't try to send more than the data channel can handle.
    >>

[CH]  Just to keep everyone in sync, the current proposal is to add some text like:

I guess we could also say that the receiver might choose to close the T.140 data channel.

                  "If the receiver receives text at a higher rate than it can handle, e.g.,
                    because the sender does not support the cps parameter, the receiver
                    can either close the T.140 data channel, or maintain the data channel but 
                    indicate to the sender that it is not willing to receive more text using
                    the direction attributes [ref-to-section-4.2.3]"

---
     
3/

...

    >>>>        "If a character cannot be transmitted within 500ms, and the sender
    >>>>          chooses to drop the character from the buffer. If that happens, the
    >>>>          sender SHOULD inform the user about it."
    >>>>
    >>> That makes sense to me.
    >>>
    >> Thanks! I will add it.
    >>

   [CH] Makes sense. I can modify as suggested.

   > This requirement comes from T.140. Research has shown that users of human typed text conversation can accept one second
   > delay from typing to remote presentation. The maximum of 500 ms buffering time allows 500 ms for network transmission and remote presentation.
   >
   > This is the maximum. There is a better user experience if the delay can be a bit shorter. Therefore RFC 4103 RECOMMENDS 300 ms buffering time
   > between transmissions as a balance between delay and overhead. And we have copied that recommendation into next paragraph, with the added
   > consideration that some modern automatic applications benefit from shorter buffering time (down to 100 ms). 
   >
   > The second use of the transmission buffer is for the case when we need to limit the flow because of the CPS parameter value. This is mentioned in the
   > second sentence (corrected above).
   > Even if some text cannot be transmitted within the 500 ms limit because we are on the way to exceed the CPS value, the text does not become
   > worthless immediately. It should be stored in a buffer, and as much as can be transmitted because of the CPS value will be transmitted from that
   > buffer at each transmission interval.
   > 
   > If a sending user happened to type extremely fast for a long time, or in some other way fill the transmission buffer so that it takes a very long time
   > to send it, the receiving user will experience that they lost real-time conversational contact. I cannot see any better option than letting the receiving
   > user have the usual option to hang up.
   >
   >       "As described in [T140], buffering can be used to reduce overhead, with the maximum buffering time being 500 ms. It can also be used for staying
   >        within the maximum character transmission rate (Section 4.2), if such has been provided by the peer. 
   >         An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when
   >         assigning a buffer time. It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103], or lower, for T.140 data channels."
   >
   > NEW:
   >
   >       "As described in [T140], buffering can be used to reduce overhead, with the maximum transmission interval as long as there is text to send being 500 ms.
   >        Buffering can also be used for staying within the maximum character transmission rate (Section 4.2.1).
   >
   >       An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when assigning a
   >      buffer time. It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103], for T.140 data channels. Implementers MAY also use
   >      lower values, for specific applications requiring low latency, taking the increased overhead in consideration."
   >

[CH]  I am fine with your suggested new text, but it does not address the case when the interval exceeds 500 ms (e.g., because the sender is about to exceed the cps value).

---
     
4/

    > [GH] See my proposal for  5.3 above

[CH] For synch purpose, no actions for this issue is currently identified, as it is covered by the suggested way to address issue 3/.

---

5/

...
     
    > GH] I suggest slight modifications
    >
    >  NEW2
    >       NOT retransmit T140blocks unless it has strong indications that a T140block has been lost. Similarly, as a T.140
    >       data channel does not provide a mechanism for a receiver to detect lost T140blocks during channel reestablishment, it
    >       SHOULD NOT insert missing text markers [T140ad1] unless it has reasons to suspect that a T140block might have been lost.
    >       Different mechanisms used by senders and receivers to detect or suspect packet loss are outside the scope of this specification."
    >

     [CH]  Ok. However, I think we could use "MUST NOT insert missing text markers unless it has reasons to suspect".

    Because, why would the receiver insert a missing text marker if it does not suspect that a T140block has been lost?

    Regards,

    Christer

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 31 Jan 2020 14:47:49 +0000

Hi all,

in general, I believe that this is useful discussion heading into the right direction.

More inline.

Michael

> >> We do reference T.140, and I assume the scope and usage are described
> there. RFC 4103 does not have such statement either.
> >>
> >> But, sure, if people think it is useful we can add a note saying that T.140 is
> intended for real-time interaction, not for transfer of text files, documents etc.
> >

Regarding the congestion control impact, both sentences provide useful information. With the second sentence it is easier to understand how low the data rate will be (and that it will not cause much issues in many parts of the Internet).

>     >> I really don't understand what the problem is by having a way to indicate
> the maximum rate. Having legacy equipment
>     >> that do not support certain protocol elements is nothing new in IETF, and
> not specific to data channels, but that hasn't
>     >>> Also, SCTP has flow control, which should also be able to slow down a
> sender, or even stop it in case of a slow receiver. From the document is not
>     >>> really clear to me if the T.140-specific rate mechanisms (cps) and buffer
> timeouts (300/500ms) interact with underlying send and receive buffers for the
> data channel, and if so, how.
>     >>>
>     >> No matter what data channel usage you have, whatever you send and at
> whatever rate, the underlying transport mechanism (SCTP) obviously need to
> support it.
>     >>
>     >>>  I am not really familiar with WebRTC internals, but running some sort
> of rate-controlled traffic with soft real-time delay requirements over a reliable
>     >>>  transport channel is typically not trivial. In this specific use case, the
> data rate is expected to be so small that it should usually work well. But,
> nonetheless,
>     >>> there could be corner cases in particular in challenging network
> environments and the document is silent about them.
>     >>>
>     >>The current version of the data channel specification does not contain load
> balance and rate control - applications need to

That would work for me.

The receiver could IMHO also just use SCTP flow control to slow down the sender. If the receiver only reads data from the SCTP receive buffer with rate cps, the sender will not be able to transmit faster than cps once SCTP flow control kicks in and the  SCTP send buffer fills up. A similar effect will happen if the network is very slow and cannot deliver the data rate needed to deliver cps (which is most likely a rare event in today's Internet for these low bit rates, but clearly it can happen in corner cases). In those cases, it could be beneficial not to have huge send buffers inside SCTP as data can get queued there, too.

Maybe it would make sense to add a heads-up in the document to take into account potential buffering inside SCTP when sizing buffers.

>    >      "It can also be used for staying within the maximum character
> transmission rate (Section 4.2), if such has been provided by the peer."
>    >
>    > NEW
>    >
>    > Because we changed in 4.2.1 so that there is now always a maximum
> transmission rate with the default being 30 cps.
> 
>    > This requirement comes from T.140. Research has shown that users of
> human typed text conversation can accept one second
>    > delay from typing to remote presentation. The maximum of 500 ms
> buffering time allows 500 ms for network transmission and remote
> presentation.
>    >
>    > This is the maximum. There is a better user experience if the delay can be a
> bit shorter. Therefore RFC 4103 RECOMMENDS 300 ms buffering time
>    > between transmissions as a balance between delay and overhead. And we
> have copied that recommendation into next paragraph, with the added
>    > The second use of the transmission buffer is for the case when we need to
> limit the flow because of the CPS parameter value. This is mentioned in the
>    > Even if some text cannot be transmitted within the 500 ms limit because we
> are on the way to exceed the CPS value, the text does not become
>    > worthless immediately. It should be stored in a buffer, and as much as can
> be transmitted because of the CPS value will be transmitted from that
>    > If a sending user happened to type extremely fast for a long time, or in
> some other way fill the transmission buffer so that it takes a very long time
>    > to send it, the receiving user will experience that they lost real-time
> conversational contact. I cannot see any better option than letting the receiving
>    > So, in order to sort out the text and explain the two different ways to use
> the transmission buffer I suggest the following wording for 5.3:
>    >
>    > OLD 5.3:
>    >
>    >       "As described in [T140], buffering can be used to reduce overhead, with
> the maximum buffering time being 500 ms. It can also be used for staying
>    >         An implementation needs to take the user requirements for smooth
> flow and low latency in real-time text conversation into consideration when
>    >         assigning a buffer time. It is RECOMMENDED to use the default
> transmission interval of 300 milliseconds [RFC4103], or lower, for T.140 data
> channels."
>    >
>    > NEW:
>    >
>    >       "As described in [T140], buffering can be used to reduce overhead, with
> the maximum transmission interval as long as there is text to send being 500
> ms.
>    >       An implementation needs to take the user requirements for smooth
> flow and low latency in real-time text conversation into consideration when
> assigning a
>    >      buffer time. It is RECOMMENDED to use the default transmission
> interval of 300 milliseconds [RFC4103], for T.140 data channels. Implementers
> MAY also use
>    > Note that I added more wording about the lower transmission interval. I got
> the impression that that was desired as discussed below.
> 
> [CH]  I am fine with your suggested new text, but it does not address the case
> when the interval exceeds 500 ms (e.g., because the sender is about to exceed
> the cps value).

The proposed text is better than the original wording.

As already mentioned, there would (or at least could) be two buffers in the sender:
* A buffer in the T.140 message processing (at application level), from which data is handed over to SCTP
* A send buffer inside the SCTP stack used e.g. for retransmissions

The maximum amount of data that can be queued in the sender is the sum of both buffers. In contrast, as far as I understand, an RFC4103 implementation conceptually may only have one buffer. So, here the different transports actually matter.

My understanding is that the "buffer time" would _only_ include the application-level buffer. In that case, it could be useful to mention that addition queuing inside the transport protocol implementation is possible and should be taken into account when setting values.

> [CH] For synch purpose, no actions for this issue is currently identified, as it is
> covered by the suggested way to address issue 3/.
> 
> ---
> 
> 5/
> 
> ...
> 
>     >       NOT retransmit T140blocks unless it has strong indications that a
> T140block has been lost. Similarly, as a T.140
> lost T140blocks during channel reestablishment, it
>     >       SHOULD NOT insert missing text markers [T140ad1] unless it has
> reasons to suspect that a T140block might have been lost.
>     >       Different mechanisms used by senders and receivers to detect or
> suspect packet loss are outside the scope of this specification."
>     >
>      [CH]  Ok. However, I think we could use "MUST NOT insert missing text
> markers unless it has reasons to suspect".
> 

Both variants work for me. At the end of the day, this is mostly about the question what service is delivered to the user.

Michael

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 31 Jan 2020 15:54:44 +0000

Hi, yes it is converging. I have a few more comments.

> Regarding the congestion control impact, both sentences provide useful information. With the second sentence it is easier to understand how low the data rate will be (and that it will not cause muc…
[GH] Yes, possible. I hesitated to propose adding both because of the 
expression "a few", considering that with speech-to-text and a rapid 
speaker, text production can reach about 20 CPS. But the sentence says 
"usually", so I can accept that both are added.
> Maybe it would make sense to add a heads-up in the document to take into account potential buffering inside SCTP when sizing buffers.

[GH] I don't like the text about closing the channel. Using SCTP flow 
control sounds better if that is an available action from WebRTC 
applications. Real-time text transmission needs to be equally robust as 
audio and video transmission, because it is used as an alternative to 
these media. Therefore we should not attract implementors to ideas of 
reducing its robustness. Saying that, I realize that it could instead 
build up huge queues of text, or cause receiver buffer overflow so that 
text will be lost. But that is better handled by user decisions about 
what to do with the call.

> My understanding is that the "buffer time" would _only_ include the application-level buffer. In that case, it could be useful to mention that addition queuing inside the transport protocol impleme…
[GH] To [CH]: Deletion of the term "500 ms maximum buffering time" and 
replacing it with a "maximum transmission interval of 500 ms" was 
intended to show that some characters might stay in buffers longer than 
500 ms if production is more rapid than the CPS, but that transmission 
is continued at every transmission interval with the number of 
characters allowed within the CPS mean value, but possibly leaving some 
characters in the buffer until next interval. The wording "500 ms 
maximum buffering time" was misleading. Woops, I realize that the text 
proposal still contains one "maximum buffering time". Can you please 
replace that also with "transmission interval". Can you after that 
change still read it as if a solution would be to temporarily increase 
the transmission interval if the CPS value is reached?

To [MS] Yes, there are characters even in the SCTP stack. Also for the 
RFC 4103 case, it is very common with buffers on lower levels in the 
transmission stack (e.g. WiFi). I don't mind some words about SCTP buffers.

> Both variants work for me. At the end of the day, this is mostly about the question what service is delivered to the user.
[GH] Yes, I can accept your wording[CH] for the second part of the text.

Regards

Gunnar

-- 

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288