Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

[Joe Touch <[e-mail]>]

Hi, Mirja,

On 2/4/2015 8:59 AM, Mirja Kühlewind wrote:
> Hi Joe.
> 
> see below...
> 
> On 30.01.2015 20:23, Joe Touch wrote:
>> Hi, Mirja,
>>
>> On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
>>> Hi Joe,
>>>
>>> I reply to the TCP part in this mail... see below.
>>>
>>> On 19.12.2014 00:39, Joe Touch wrote:
>>>> Some feedback below. Although I focus on some TCP and UDP specifics,
>>>> some observations apply to other transports as well.
>>>>
>>>> Joe
>>>>
>>>> -----
>>>>
>>>> 3.1.1
>>>>      TCP segments fit into IP packets, but those packets are not
>>>>      necessarily constrained to fit into a lower-layer frame.
>>>>      They can be source fragmented.
>>   >
>>> Yes, but this is handled by IP and not by the transport. Therefore I
>>> believe that does not need to be mention here...?
>>
>> The problem is in the first sentence:
>>
>>      TCP partitions a continuous stream of bytes into segments, sized to
>>      fit in IP packets, constrained by the maximum size of lower layer
>>      frame.
>>
>> The first part is true (TCP fits into IP), but the second is not (IP is
>> NOT constrained by the max size of the lower-layer frame). IP is
>> constrained only by the ability of IP (i.e., of L3 to reassemble at the
>> destination).
> 
> Okay, I've just removed the second part of the sentence to avoid
> confusion because it is actually not important in this doc. That's okay
> for you?

Sure.

>>>>      PathMTU discovery is supported by TCP but may be inhibited
>>>>      by network conditions (ICMP blocking); PLMTUD is supposed
>>>>      to be supported as well.
>>   >
>>> I added PLMTUD separately as well as the respective RFCs for both.
>>> However, I'm not sure if we actually need to distinguish which mechanism
>>> is used than rather just saying TCP supports path MTU discovery. (The
>>> notation in the draft current is PathMTU discovery which references to a
>>> specific mechanism but that be changes...).
>>
>> "Path MTU discovery" is ambiguous; it can refer to any mechanism that
>> allows the path MTU to be known, or it can refer to the specific
>> mechanism by that name in RFC 1191.
>>
>> If you mean the more general concept, it would be better to use a term
>> that is unambiguous in referring to both (e.g., discovery of the path
>> MTU). Once you tie the words together as "path MTU discovery", it could
>> be misinterpreted as meaning only RFC 1191.
>>
>> However, IMO, in this doc it would be better to be more clear and
>> explicit by naming both mechanisms.
> 
> K. Done.
> 
>>
>> ...
>>>> 3.1.3
>>>>      TCP provides a byte-ordered reliable stream. How that
>>>>      is delivered - e.g., by segments - is irrelevant, if only
>>>>      because TCP can change those segment boundaries during
>>>>      operation (e.g., with path MTU updates).
>>   >
>>> Yes but it is still something that TCP implements as a component.
>>
>> TCP definitely does not. There is no required correlation between SEND
>> boundaries and segment boundaries.
>>
>> Some TCP implementations do, but there is nothing to ensure that
>> boundaries controlled by the sending application are exposed to the
>> receiving application.
>>
>> I don't think this doc should discuss how implementations go astray in
>> this way.
> 
> I think this is again a terminology problem. We agreed that a (transport
> protocol) component is something that a transport protocol implements. I
> don't think there are any TCP implementations that do not implement
> segmentation...? So it's a component.

TAPS describes the services that transports provide to applications (as
per the charter).

The details of how that service is implemented internally are not
relevant because they're not exported as part of that service interface.

Although TCP uses segments to talk to other TCPs, TCP is not required to
export or import the segment boundary to the application.

> A transport feature is something that you would reveal to the
> application.

A transport feature is something you *can* reveal to the application.
The spec for TCP allows implementations to segment data in different
ways and still interconnect just fine.

> This is currently not the case and will probably also in
> future not be the case for segmentation. (However if you would want to
> reveal it, the functionality is already there you just need a different
> API...)

You need a different protocol.

E.g., if TCP is sending 1000B segments and learns new information about
the path MTU, it can retransmit lost data using the new MTU. Similar
changes in segment boundaries can occur if a small segment is sent
(because of a timeout waiting for new data) and the data from that small
segment is retransmitted after new data arrives, i.e., the
retransmission might end up being a larger overlapping region.

> However, in this document we should still list all TCP components and
> then add a discussion which of these components should be revealed to
> the app and in which from.

RFC793 defines TCP's API.

The rest of RFC793 describes how TCP interacts with other TCPs, not the
API.

Please don't confuse the two. The latter is not an opportunity to
augment the former.

>> ...
>>>>      additionally, the ports ought to be discussed in more detail.
>>>>      ports in the SYN have a different meaning that ports in other
>>>>      segments. The SYN destination port indicates the receiving
>>>> `    service, which typically involves BOTH demuxing to a process
>>>>      within a host AND indicating the format of the stream. Ports
>>>>      there and in all other segments are only demultiplexing
>>>>      indicators.
>>   >
>>> Added one sentence in section 3.1.1. and extended the connection setup
>>> up point to
>>>
>>>       "connection setup with feature negotiation and application-to-port
>>> mapping"
>>>
>>> Does that make sense to you?
>>
>> The sentence does, but that doesn't sufficiently (IMO) address the
>> feedback I gave above.
>>
>> TCP has two portions:
>>     - connection establishment
>>         feature negotiation
>>         service-to-port mapping
>>         connection identification
>>
>>     - established connection data transfer
>>         which continues to use the connection identifier
> 
> At this point in the document it is not important for me anymore to have
> in mind with bit in the header is used for with kind of functionality.

I said nothing about the header. Again, I'm referring to the API defined
in RFC793.

> Therefore being able to identify a connection (or as we named it: 'port
> multiplexing') is one component 

It's socket multiplexing, where socket is defined in RFC793 as the local
IP/port pair.

> while 'connection establishment' is
> another.

Agreed. That's negotiation of service parameters, including whether
there's a service at all.

> As in your list 'connection identification' shows up in both
> bullets, I'd say it's sensible to list this as an own component.
> However, 'negotiation' and 'service-to-port mapping' are always bounded
> to the setup. Therefore it's not an own component.

But those two items are very tightly related too, i.e., there's no way
(in current TCP) to decouple the service-to-port mapping' from the
negotiation of the socket pair during connection establishment.

(see http://datatracker.ietf.org/doc/draft-touch-tcpm-sno/ for a
proposed extension that would decouple the two)

Joe

> We already discussed
> if we need a finer granularity than components; Brian has been calling
> this an aspect... I'm still not convinced that declaring another
> confusion term will make our life easier...
> 
> So the only real different that see to what you propose above is that
> the currently list does not name 'data transfer' as a component. For me
> that's implicit a task of every transport protocol, so I would name it
> explicitly.
> 
> I'd like to leave it as it is for now and will be waiting for further
> options on this.
> 
> Mirja
> 
> 
> 
> 
>>
>> Joe
>>
>> _______________________________________________
>> Taps mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/taps
>>
>